| Summary: | Shutdown/Reboot does not work with sys-apps/baselayout-1.13.0_alpha7-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sebastian Bergmann (RETIRED) <sebastian> |
| Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | desintegr, pesa, robert.golding, scottsshort, sgtphou, wilburpan, wonkey_donkey |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Attempt to fix the issue
Another attempt This should work Work without error? |
||
|
Description
Sebastian Bergmann (RETIRED)
2006-12-01 00:52:45 UTC
Fixed in baselayout-1.13.0_alpha8 *** Bug 158052 has been marked as a duplicate of this bug. *** *** Bug 158128 has been marked as a duplicate of this bug. *** (In reply to comment #1) > Fixed in baselayout-1.13.0_alpha8 > Okay, if this issue is fixed, then can we have this backported to the stable version 1.12.7 since the bug reports for that version of baselayout have been marked as a duplicate for an ALPHA version of baselayout? I do not wish to install an ALPHA version of baselayout on my PC, so a backport of this fix would be very helpful. Check out the other bug reports that were so kindly marked as a dupe for more information. ;) Sorry I am kind of in a pissy mood because a bug report should not be marked as a duplicate of an alpha version and the alpha version gets the fixed rather than the friggin STABLE version. If anything, the Alpha version bug report should be a duplicate of a stable versions bug report and then Stable version fixed first and then the fix migrating up to the alpha version. I just hope you can get this resolved for the stable version and in the meantime, I think one of the other bug reports should be unlisted as a dupe and reopened by someone that can so then the bug will be listed for the STABLE version and hopefully fixed. Thanks. (In reply to comment #4) > (In reply to comment #1) > > Fixed in baselayout-1.13.0_alpha8 > Okay, if this issue is fixed, then can we have this backported to the stable > version 1.12.7 since the bug reports for that version of baselayout have been > marked as a duplicate for an ALPHA version of baselayout? Sadly no - the changes are way to big. Just to make you happy I'll re-open the bug. Created attachment 104045 [details, diff]
Attempt to fix the issue
In the meantime, try this patch
Hallo Leute wie gehts?(In reply to comment #6) > Created an attachment (id=104045) [edit] > Attempt to fix the issue > > In the meantime, try this patch > Tried the patch. Didn't help. Same message as before: INIT: no more processes in this runlevel + Freeze + fsck on manual reboot Created attachment 104047 [details, diff]
Another attempt
Try this one
*** Bug 158026 has been marked as a duplicate of this bug. *** (In reply to comment #8) > Created an attachment (id=104047) [edit] > Another attempt > > Try this one > Nope. Not working. I already thought of this because fuser -m -c is giving an error msg (and even tried it myself). OK, you want to put this in
echo "unmounting ${x}"
just before the line
if ! umount "${x}" &>/dev/null; then
So we can see what it's trying to unmount.
(In reply to comment #11) > OK, you want to put this in > > echo "unmounting ${x}" > > just before the line > > if ! umount "${x}" &>/dev/null; then > > So we can see what it's trying to unmount. > OK I get: unmounting /var unmounting /usr unmounting /share unmounting /opt unmounting /home unmounting /boot * Remounting remaining filesystems readonly... [OK] INIT: no more processes left in this runlevel I did a few more investigations. It seems like halt.sh kills itself while trying to unmount "/". Seems like it has problems with realizing it is the only process (or one of he only processes) left using "/" (In reply to comment #12) > I did a few more investigations. > It seems like halt.sh kills itself while trying to unmount "/". Seems like it > has problems with realizing it is the only process (or one of he only > processes) left using "/" > What's interesting is, that if I do a test run with a little script running from a partition, only the script itself uses, it can detect that it's using the partition. Can it be that, halt.sh isn't able to determine it's PID on shutdown? I wish I could replicate this :/ OK, see if it gets to the last line in halt.sh echo "going to load /etc/init.d/$1" just before [[ -e /etc/init.d/"$1".sh ]] && source /etc/init.d/"$1".sh (In reply to comment #14) > I wish I could replicate this :/ > > OK, see if it gets to the last line in halt.sh > > echo "going to load /etc/init.d/$1" > just before > [[ -e /etc/init.d/"$1".sh ]] && source /etc/init.d/"$1".sh > OK. Seems like he gets to the last line... On reboot the system displays "going to load /etc/init.d/reboot" just before the INIT: no more blah stuff. And that may be the problem. Apperently there is no /etc/init.d/reboot. At least on my system... (In reply to comment #15) > (In reply to comment #14) > > I wish I could replicate this :/ > > > > OK, see if it gets to the last line in halt.sh > > > > echo "going to load /etc/init.d/$1" > > just before > > [[ -e /etc/init.d/"$1".sh ]] && source /etc/init.d/"$1".sh > > > > OK. Seems like he gets to the last line... > > On reboot the system displays "going to load /etc/init.d/reboot" just before > the INIT: no more blah stuff. > > And that may be the problem. Apperently there is no /etc/init.d/reboot. At > least on my system... > Just checked it again baselayout-1.12.6 had a reboot.sh in /etc/init.d baselayout-1.12.7 is missing it. Could it be the update got it deleted? It's /etc/init.d/reboot.sh, which is now provided by sysvinit That's a very simple file - check that we have enought to reboot ls /dev/initctl ls /sbin/reboot What version of sysvinit do you have installed? (In reply to comment #17) > It's /etc/init.d/reboot.sh, which is now provided by sysvinit > > That's a very simple file - check that we have enought to reboot > > ls /dev/initctl > ls /sbin/reboot > Yes they exist both. And halt.sh just calls /etc/init.d/reboot.sh when it exists. But the problem is, that "/" isn't unmounted on shutdown and then apperently halt.sh dies/getskicked/eixts and INIT stands there with nothing left to do (while it should call reboot I guess). (In reply to comment #18) > What version of sysvinit do you have installed? > sys-apps/sysvinit-2.86-r6 (In reply to comment #20) > (In reply to comment #18) > > What version of sysvinit do you have installed? > > > > sys-apps/sysvinit-2.86-r6 > OK I remerged sysvinit and now have a reboot.sh again and the system reboots normally. Could it be that the emerge of baselayout-1.12.7-r3 deleted the reboot.sh file? Anyways. The not rebooting problem is gone, but the rootfs not cleanly unmounted problem stays. Created attachment 104054 [details, diff]
This should work
OK, I think I have this solved now, try this patch.
(In reply to comment #22) > Created an attachment (id=104054) [edit] > This should work > > OK, I think I have this solved now, try this patch. > It works! I get some output about /dev being busy (couldn't read exactly what it was because it was gone too fast), but the reboot worked and the file system was clean too. Thank you very much! Created attachment 104055 [details, diff]
Work without error?
OK, this should clear the error up, and hopefully work.
If so I'll commit it right away :)
(In reply to comment #24) > Created an attachment (id=104055) [edit] > Work without error? > > OK, this should clear the error up, and hopefully work. > If so I'll commit it right away :) > Would I be right in assuming this will be committed to 'baselayout' or some other package ? (In reply to comment #24) > Created an attachment (id=104055) [edit] > Work without error? > > OK, this should clear the error up, and hopefully work. > If so I'll commit it right away :) > Error msg gone. rootfs clean Reboot without problem. And for the INIT: no more processes left in this runlevel thing a remerge of sysvinit will do the trick. Again Thank you very much for your effort! :-) (In reply to comment #25) > (In reply to comment #24) > > Created an attachment (id=104055) [edit] > > Work without error? > > > > OK, this should clear the error up, and hopefully work. > > If so I'll commit it right away :) > > > > Would I be right in assuming this will be committed to 'baselayout' or some > other package ? > Well since halt.sh is in baselayout it will be baselayout-1.12.7-r4 I guess. Fixed, thanks for helping test the issue guys :) (In reply to comment #28) > Fixed, thanks for helping test the issue guys :) > When I tried baselayout-1.12.7-r4 yesterday I still needed to emerge sysvinit-2.86-r6 (~x86) to restore shutdown.sh and reboot.sh, yet if I reverted to baselayout-1.12.6 (stable) they were dropped and reinstated without remerging sysvinit. RESOLVED, yes, but does this make it FIXED, not so sure about that :-) |