Bugzilla Bug 156766

When I reboot or shutdown my notebook, the shutdown process stops with

  * Unmounting filesystems ... [ok]
  INIT: no more processes in this runlevel

Unfortunately, this happens before the filesystems are properly unmounted so
the ReiserFS journal needs to be played back during the next boot.

-- 

Portage 2.1.2_rc2-r3 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0,
2.6.18-gentoo-r3 i686)
=================================================================
System uname: 2.6.18-gentoo-r3 i686 Genuine Intel(R) CPU           L2400  @
1.66GHz
Gentoo Base System version 1.13.0_alpha7
Last Sync: Fri, 01 Dec 2006 06:00:01 +0000
ccache version 2.4 [disabled]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.4.4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium-m -msse3 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-march=pentium-m -msse3 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig cvs distlocks fixpackages metadata-transfer
parallel-fetch sandbox sfperms sign strict"
GENTOO_MIRRORS="http://mirror.gentoo.no/ ftp://ftp.du.se/pub/os/gentoo
ftp://trumpetti.atm.tut.fi/gentoo/
ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo
http://gentoo.oregonstate.edu"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="  "
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X a52 aac acpi alsa asf berkdb bitmap-fonts bluetooth browserplugin
bzip2 cairo cli cracklib crypt cups dbus dga divx4linux dlloader dri dvd
dvdread eds elibc_glibc exif fame firefox flac foomaticdb fortran gaim gdbm gif
glitz gnome gpm graphviz gstreamer gtk hal iconv input_devices_evdev
input_devices_keyboard input_devices_mouse iproute2 ipv6 isdnlog java jpeg
kdeenablefinal kdehiddenvisibility kernel_linux libg++ libnotify libsexy lzo
mad matroska mjpeg mmx mmxext mng moznocompose moznoirc moznomail mozsvg mp3
mpeg ncurses nls nomotif nptl nptlonly nsplugin ogg oggvorbis opengl pam
pam_console pcre pdf perl png ppds pppd python quicktime readline reflection
samba session smp spl sse sse2 ssl startup-notification svg tcpd tetex theora
tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU
video_cards_i810 vim-syntax vorbis win32codecs wmf xcb xml xml2 xorg xv xvid
xvmc zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS

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 an attachment (id=104045) [edit]
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 an attachment (id=104047) [edit]
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 an attachment (id=104054) [edit]
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 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 :)

(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 :-)