...making Linux just a little more fun!
Deividson Okopnik [deivid.okop at gmail.com]
Hello everyone!
A student here brough to me a problem i couldnt solve, so i'm forwarding it to tag.
After an hibernation, his laptop froze and he had to do a hard-shutdown on it, and after that ubuntu stopped booting, giving him this kernel panic message:
[ 2.222518] Kernel panic - not sycing: VFS: Unable to mount root fs on unknown-block(0,0)
After a few trys, he noticed that he can boot into other kernels he's got on his machine, but they don't work properly (weird beeps, auto-mount doesnt work, compiz - that kind of stuff)
Heres some messages:
Mounting something without su: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Starting compiz: root@ricardo-laptop:~/a# compiz Checking for Xgl: not present. Detected PCI ID for VGA: Checking for texture_from_pixmap: not present. Trying again with indirect rendering: Checking for texture_from_pixmap: present. Checking for non power of two support: present. Checking for Composite extension: present. Comparing resolution (1280x800) to maximum 3D texture size (2048): Passed. Checking for Software Rasterizer: present. Software rasterizer detected, abortingaborting and using fallback: /usr/bin/metacity
--- Then several of the above errors ---
I checked his menu.lst, and heres the entry for the problematic kernel:
title Ubuntu 8.10, kernel 2.6.27-11-generic uuid 1ac63e0f-dff7-48f8-9506-ce783a5dd383 kernel /boot/vmlinuz-2.6.27-11-generic root=UUID=1ac63e0f-dff7-48f8-9506-ce783a5dd383 ro locale=pt_BR quiet splash initrd /boot/initrd.img-2.6.27-11-generic quiet
I noticed that weird root=UUID= on kernel, and changed it to root=/dev/sda2 UUID=**** but it didnt work
Well, this is all for now - thanks for reading Deividson
Michael SanAngelo [msanangelo at gmail.com]
Hello, try omitting the /dev/sda2 part from the root line or just omit the entire uuid part. both should refer to the root partition but you only need one or the other.
Help this helps, cheers.
-- Michael SanAngelo Visit my Website - https://www.michaelsweb.uni.cc Get Ubuntu Today! - https://www.ubuntu.com
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Thu, 12 Feb 2009, Deividson Okopnik wrote:
> A student here brough to me a problem i couldnt solve, so im > forwarding it to tag.
A yummy exercise for TAG!
> [ 2.222518] Kernel panic - not sycing: VFS: Unable to mount root fs on > unknown-block(0,0)
Common enough message for borked systems unfortunately
> root@ricardo-laptop:~/a# compiz > Checking for Xgl: not present.
compiz is probably not useful unless the hardware supports GL.
In any case, for such a system, getting a command line environment first should be the first priority.
> I checked his menu.lst, and heres the entry for the problematic kernel: > title Ubuntu 8.10, kernel 2.6.27-11-generic > uuid 1ac63e0f-dff7-48f8-9506-ce783a5dd383 > kernel /boot/vmlinuz-2.6.27-11-generic > root=UUID=1ac63e0f-dff7-48f8-9506-ce783a5dd383 ro locale=pt_BR quiet > splash > initrd /boot/initrd.img-2.6.27-11-generic > quiet > > I noticed that weird root=UUID= on kernel, and changed it to > root=/dev/sda2 UUID=**** but it didnt work
That is probably not a good idea! The UUID is a unique identifier for the root block device. It is possible (for example) that the root device is on a logical volume (or a logical volume on an encrypted partition etc.) in which case the UUID may be the best way to identify the block device.
Here is some information that would help in trouble-shooting:
1. To what extent the student is interested in/capable of messing around with the system to figure out what went wrong. It may be easier to re-install and (if this was not done already) create a separate "/home" directory so that if something goes wrong, the user files are recoverable.
2. The disk layout (fdisk and if LVM is used then that fact should be mentioned).
3. The messages you get when you suppress the "quiet" in the grub menu and in the kernel command line.
Regards,
Kapil. --
Deividson Okopnik [deivid.okop at gmail.com]
>> [ 2.222518] Kernel panic - not sycing: VFS: Unable to mount root fs on >> unknown-block(0,0) > > Common enough message for borked systems unfortunately>
Yuup, that's what I told him :'(
>> root@ricardo-laptop:~/a# compiz >> Checking for Xgl: not present. > > compiz is probably not useful unless the hardware supports GL.
It does - Compiz was working before the failed hibernation, and you know how much young students love eyecandy
> In any case, for such a system, getting a command line environment > first should be the first priority.
We have an almost fully working system - even gnome works, but some weird stuff happens, making the system not 100%
>> >> I noticed that weird root=UUID= on kernel, and changed it to >> root=/dev/sda2 UUID=**** but it didnt work > > That is probably not a good idea! The UUID is a unique identifier for > the root block device. It is possible (for example) that the root > device is on a logical volume (or a logical volume on an encrypted > partition etc.) in which case the UUID may be the best way to > identify the block device.
Ok - I added a new grub menu option for my change to test, so the original is still there too
> 1. To what extent the student is interested in/capable of messing > around with the system to figure out what went wrong. It may be > easier to re-install and (if this was not done already) create a > separate "/home" directory so that if something goes wrong, the > user files are recoverable.
He didn't want to have to format it - it is his first Linux installation, and he fully customized it and everything (and didnt know he could do a separate /home) - he's able to do that if there's no other way
> 2. The disk layout (fdisk and if LVM is used then that fact should be > mentioned).
I'll check with him later - for now all I know is that he's on ReiserFS and has got an ntfs partition for some stuff, no LVM.
> 3. The messages you get when you suppress the "quiet" in the grub menu > and in the kernel command line.
Checking with him too - I'll send this information as soon as he answers me
Jason Wigg [jw5801 at gmail.com]
If it's only a few parts of the system that are buggered, he can probably still take a backup of his home directory, so if he does need to format and reinstall he's still got all his customisations there and he can put them on a separate partition for next time.
Cheers, JW
Thomas Adam [thomas.adam22 at gmail.com]
2009/2/12 Deividson Okopnik <deivid.okop@gmail.com>:
> Hello everyone! > > A student here brough to me a problem i couldnt solve, so im > forwarding it to tag. > > After an hibernation, his laptop froze and he had to do a > hard-shutdown on it, and after that ubuntu stopped booting, giving him > this kernel panic message: > > [ 2.222518] Kernel panic - not sycing: VFS: Unable to mount root fs on > unknown-block(0,0)
Is this using swsuspend or tux-on-ice?
> I noticed that weird root=UUID= on kernel, and changed it to > root=/dev/sda2 UUID=**** but it didnt work
It's not down to you to go changing that; so you broke it further, and hopefully handed your student with even more broken pieces. Sigh.
-- Thomas Adam
Ben Okopnik [ben at linuxgazette.net]
On Fri, Feb 13, 2009 at 09:31:46PM +0000, Thomas Adam wrote:
> 2009/2/12 Deividson Okopnik <deivid.okop@gmail.com>: > > > I noticed that weird root=UUID= on kernel, and changed it to > > root=/dev/sda2 UUID=**** but it didnt work > > It's not down to you to go changing that; so you broke it further, and > hopefully handed your student with even more broken pieces. Sigh.
There's nothing wrong with trying a different 'root=' setting in GRUB; it doesn't break anything more than what's already broken, and changing it to the correct setting is all that's necessary either before or after such a change.
On the other hand, 'root=UUID=<blah>' is perfectly valid syntax - and is even exactly the right thing to use if you have a reason for doing so (i.e., you're going to shuffle the hardware in your system weekly just for the heck of it.) If you don't, but you do know that your /dev/sda2 contains your root FS, then you should ask GRUB very politely to
root=/dev/sda2
What is NOT a good idea is engaging in cargo-culting (i.e., doing something without understanding why you're doing it - such as copying just a part of a commandline and trying to run it.) There's no 'UUID=' option for GRUB - that was part of the "address" given to the 'root=' argument - so Don't Do That.
Since I seem to recall Deividson mentioning being able to fire up the system to at least some degree, I'd suggest running 'sudo /sbin/blkid' to get the UUIDs for the system. Conversely, 'sudo tune2fs -l /dev/hdXN' can be used to see the UUID for partition N of hard drive X.
Taking a broader view of this - since the system does come up, at least somewhat, it seems that GRUB is doing its job (the boot would fail part-way through - no applications would run - unless a valid FS was found.) Given that, I'd check to see if all the required partitions were mounted; "/usr" would cause no end of problems if it failed to come up, while absence of "/home" would wreak all sorts of havoc for the user-specific apps.
In short, take it easy - step by step. Start with what you know is still good: boot to single-user and see what the system looks like. If that's OK, "telinit" to the multi-user level defined for your distro (either 2 or 3 or 5, depending; it's usually 2 for Ubuntu.) Find where things first start breaking, and fix the first problem [1], then check again. If compiz, whatever, fail to come up, start X manually and try running the X apps from the console (you may need to set DISPLAY explicitly to do so); the error messages should be informative.
[1] One of the things that I find myself having to continually hammer on when teaching programming classes: when you see a huge slew of errors, don't let it bother you. The greatest majority of the time, fixing the first error fixes all the rest of them - or at least greatly reduces the list.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Deividson Okopnik [deivid.okop at gmail.com]
2009/2/13, Ben Okopnik <ben@linuxgazette.net>:
> > In short, take it easy - step by step. Start with what you know is still > good: boot to single-user and see what the system looks like. If that's > OK, "telinit" to the multi-user level defined for your distro (either 2 > or 3 or 5, depending; it's usually 2 for Ubuntu.) Find where things > first start breaking, and fix the first problem [1], then check again. > If compiz, whatever, fail to come up, start X manually and try running > the X apps from the console (you may need to set DISPLAY explicitly to > do so); the error messages should be informative. > > > > [1] One of the things that I find myself having to continually hammer on > when teaching programming classes: when you see a huge slew of errors, > don't let it bother you. The greatest majority of the time, fixing the > first error fixes all the rest of them - or at least greatly reduces the > list. > > -- > * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET * >
I couldn't figure out anything about this error tho - and this seem to be what stops everything that doesn't work from working:
DBus[1] error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[1] Not always DBus
I'm considering telling him to boot with a livecd and backing up his whole /home as Jason said.
Thomas Adam [thomas.adam22 at gmail.com]
2009/2/13 Ben Okopnik <ben@linuxgazette.net>:
> On Fri, Feb 13, 2009 at 09:31:46PM +0000, Thomas Adam wrote: >> 2009/2/12 Deividson Okopnik <deivid.okop@gmail.com>: >> >> > I noticed that weird root=UUID= on kernel, and changed it to >> > root=/dev/sda2 UUID=**** but it didnt work >> >> It's not down to you to go changing that; so you broke it further, and >> hopefully handed your student with even more broken pieces. Sigh. > > There's nothing wrong with trying a different 'root=' setting in GRUB; > it doesn't break anything more than what's already broken, and changing > it to the correct setting is all that's necessary either before or after > such a change.
Perhaps I was unclear -- changing it bears no relation to the other symptoms for the stated problem.
> [1] One of the things that I find myself having to continually hammer on > when teaching programming classes: when you see a huge slew of errors, > don't let it bother you. The greatest majority of the time, fixing the > first error fixes all the rest of them - or at least greatly reduces the > list.
Well, that applies to compiling, to perl, to anything programming-related. The first error is always the one that counts. It's common sense though, which is invariably why it needs to be taught.
-- Thomas Adam
Ben Okopnik [ben at linuxgazette.net]
On Thu, Feb 12, 2009 at 07:21:20PM -0300, Deividson Okopnik wrote:
> Hello everyone! > > A student here brough to me a problem i couldnt solve, so im > forwarding it to tag. > > After an hibernation, his laptop froze and he had to do a > hard-shutdown on it, and after that ubuntu stopped booting, giving him > this kernel panic message: > > [ 2.222518] Kernel panic - not sycing: VFS: Unable to mount root fs on > unknown-block(0,0)
^^^^^^^^^^^^^^^^^
Well, that's quite the clue. Seems like GRUB doesn't know what you
want it to use as the root of your FS. if you're in any doubt of what
that might be, play around with it at the boot prompt (i.e., interrupt
GRUB and edit the boot command line.) Be aware that GRUB uses a slightly
different numbering scheme than the FS: e.g., 'root=(hd0,0)' represents
hda1; 'root=(hd1,2)' would be hdb3 and so on. You also need to make sure
that the kernel is in the right place and that you know which partition
contains '/sbin/init' (you can find this stuff out by running 'find
/vmlinuz' and 'find /sbin/init' from the GRUB command line.)
Once you've got that, you can use
root (hd0,0) kernel /vmlinuz root=/dev/hda1 boot
OR
kernel (hd0,0)/vmlinuz root=/dev/hda1 boot
at the GRUB command line. The resulting fireworks should be grand.
Do note that the two seemingly-conflicting 'root=' statements have
nothing to do with one another: the first one tells GRUB where to root
the FS; the second one is an argument to the 'kernel' keyword, and tells
GRUB where /sbin/init lives.
Incidentally, I've often seen the above kernel panic resulting from the absence of the 'initrd=' line in 'menu.lst' after "update-grub" was executed. Might be something to look for. If it's gone, you should restore it for that stanza.
> I checked his menu.lst, and heres the entry for the problematic kernel: > title Ubuntu 8.10, kernel 2.6.27-11-generic > uuid 1ac63e0f-dff7-48f8-9506-ce783a5dd383
As I recall, many versions of GRUB have problems with the 'uuid' keyword. You're better off specifying it in the 'root' line, just as it is.
> kernel /boot/vmlinuz-2.6.27-11-generic > root=UUID=1ac63e0f-dff7-48f8-9506-ce783a5dd383 ro locale=pt_BR quiet > splash > initrd /boot/initrd.img-2.6.27-11-generic > quiet
Seems OK. Do check that all of the above is correct; stuff like 'blkid', 'vol_id', and 'ls -l /dev/disk/by-uuid/' can be very helpful here.
> I noticed that weird root=UUID= on kernel, and changed it to > root=/dev/sda2 UUID=**** but it didnt work
Not surprising - as I'd mentioned elsewhere.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Deividson Okopnik [deivid.okop at gmail.com]
2009/2/13, Thomas Adam <thomas.adam22@gmail.com>:
> > Perhaps I was unclear -- changing it bears no relation to the other > symptoms for the stated problem.
The error said it couldn't mount - mount during boot time reminded me
of grub - and as I said before, I added a new option on grub, I did
not remove the old one - so, no, I did not break anything
Ben Okopnik [ben at linuxgazette.net]
On Fri, Feb 13, 2009 at 07:52:56PM -0300, Deividson Okopnik wrote:
> 2009/2/13, Ben Okopnik <ben@linuxgazette.net>: > > > > In short, take it easy - step by step. Start with what you know is still > > good: boot to single-user and see what the system looks like. If that's > > OK, "telinit" to the multi-user level defined for your distro (either 2 > > or 3 or 5, depending; it's usually 2 for Ubuntu.) Find where things > > first start breaking, and fix the first problem [1], then check again. > > If compiz, whatever, fail to come up, start X manually and try running > > the X apps from the console (you may need to set DISPLAY explicitly to > > do so); the error messages should be informative. > > > > > > > > [1] One of the things that I find myself having to continually hammer on > > when teaching programming classes: when you see a huge slew of errors, > > don't let it bother you. The greatest majority of the time, fixing the > > first error fixes all the rest of them - or at least greatly reduces the > > list. > > > > -- > > * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET * > > > > I couldnt figure out anything about this error tho - and this seem to > be what stops everything that doesnt work from working: > > DBus[1] error org.freedesktop.DBus.Error.NoReply: Did not receive a reply.
Is 'dbus-daemon' running?
Sample 'ps ax' output:
ben@Tyr:~$ ps ax|grep '[d]bus' 5108 ? Ss 0:00 /usr/bin/dbus-daemon --system 6315 ? Ss 0:00 dbus-daemon --fork --print-address 24 --print-pid 26 --session
> [1] Not always DBus
Easily checked for other things, as well.
> Im considering telling him to boot with a livecd and backing up his > whole /home as Jason said.
It's certainly a good idea no matter what else happens.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *