2012/6/14 Kevin Chadwick <ma1l1ists@xxxxxxxxxxx> > > 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: http://www.linuxjournal.com/content/rebooting-magic-way 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 http://www.mjmwired.net/kernel/Documentation/sysrq.txt to check which tasks are still stuck right?
