[arch-general] Shutdown and reboot not working after last weekend update

Victor Silva vfbsilva at gmail.com
Thu Jun 14 13:52:00 EDT 2012

2012/6/14 Kevin Chadwick <ma1l1ists at yahoo.co.uk>

> > It reports a problem
> > reading /boot partition saying something about it being not a valid ext2
> I see /boot is ext4
> There was a time recently when a kernel bug gave invalid warnings about
> other filesystem types like ext2, ext3 before mounting ext4 so it could
> be a red herring, is the exact error gone too quick to note.
> I presume by Vanilla you mean an arch package?
> p.s. If you can edit the kernel commandline you can change the init part to
> init=/bin/sh and hitting b to boot
> It's limited in what can be done but that way you may be
> able to troubleshoot some things more quickly by using the built in
> kernel commands, see if there is a reboot command. If there is it is
> internal and not from any filesystem. If it works you could then do it
> again and this time mount your root filesystem and try the reboot
> command from that.
> There are also kernel debug configs like printk but I'm not sure that's
> the route to go down yet.
> ________________________________________________________
>  Why not do something good every day and install BOINC.
> ________________________________________________________

Yeah by vanilla I mean the stock kernel. I dont get what do you mean by:
be a red herring, is the exact error gone too quick to note.

Well I can chroot as I did to revert to the old kernel so changing grub
menu seems harder than chroot. My main problem is that reverting to the old
kernel did not work.

Maybe I forgot to run mkinitcpio

By did not work I mean that I don't get boot. it fails with the message you
meantioned to be listed on a bug. I will look for it later but if you could
provide me a link I would be gratefull (I'm at work atm). Also I own you a
post of the exact error message on boot over the new kernel.  A thing I
dont understand is what if the difference of doing a magic reboot:
and calling a shutdown lies mainly on the umounting of the file systems if
this is the case I should be able to reboot after a umount -f all right?

I wonder if a -l would be better:
-l     Lazy unmount. Detach the filesystem from the filesystem  hierarchy
now, and cleanup all references to the filesystem as soon as it is not busy
anymore.  (Requires kernel 2.4.11 or later.)
I could not run fsck on /boot as it reported to be mounted.

Should I maybe run a normal shutdown -h now in parallel with
to check which tasks are still stuck right?

More information about the arch-general mailing list