Re: restoring GRUB loading after partition/device rename

[Gary S. Trujillo]

Thanks much to Jordan Uggla, who, on 9/19/2010 3:27 PM, wrote in reply to my earlier posting in which I asked:

 2. What's the easiest way to figure out what all I need to do to
    get myself back into a bootable condition, and what's the best
    procedure to use?

Jordan said:

Follow this guide: http://grub.enbug.org/Grub2LiveCdInstallGuide

Well, with a few minor, and probably unimportant difference, the procedure outlined in that guide Jordan cites is pretty much what's given in the article at https://help.ubuntu.com/community/Grub2 that I cited in my posting.  The only real differences are:

  1. It uses "grub-mkconfig -o /boot/grub/grub.cfg" rather than "update-grub" which I think performs the same function (but I'd be glad to be corrected on this point), and it omits the "mount --bind /sys /mnt/sys" command for an Ubuntu-derived system.  The procedures described are so similar, in fact, that I suspect that the information in the help.ubuntu.com article was derived from the other one.  It was that procedure I've been using in an attempt to fix up my GRUB config file so I can boot.

At present, I get:

[    0.892038] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

when I try to boot one of the Linux kernels in the /boot partition

I've discovered through a bit of googling that that error is associated with no appropriate driver being available for the file system being referred to, which may be because an inappropriate device is being referred to in the grub.cfg file.

If I go into edit mode in GRUB with the default kernel selected, I see:

recordfail
insmod ext2
set root=(hd0,7)
search --no-floppy --fs-uuid --set ba5e22b1-d340-44e7-8ebc-7e19f914a659
linux /vmlinuz-2.6.32-24-generic root=/dev/sda6 ro quiet splash

I'm wondering about what seems to be an inconsistency between the "(hd0,7)" and "/dev/sda6" - one being what I assume to be the root device used for the boot (which is actually the /boot partition), and the one the kernel is being told about.  Maybe that's just how things work, and maybe I'll get an answer to that question by reading the GRUB manual slowly and carefully (which I'm hoping to be able to avoid, if possible :-) .

I should also note that the UUID referred to in the "search" command is for /dev/sda7:

/dev/sda6: UUID="89026b1d-ed74-465c-a925-c73d1b964c59" TYPE="ext4"
/dev/sda7: UUID="ba5e22b1-d340-44e7-8ebc-7e19f914a659" TYPE="ext4"
/dev/sda8: UUID="8b30e890-c52e-417f-8ee7-f33ca3f0998b" TYPE="swap"

I've alterned my /etc/fstab along the lines of what Jordan suggests:

UUID=89026b1d-ed74-465c-a925-c73d1b964c59 /     ext4 errors=remount-ro 0 1
UUID=ba5e22b1-d340-44e7-8ebc-7e19f914a659 /boot ext4 defaults  0       2
UUID=8b30e890-c52e-417f-8ee7-f33ca3f0998b none  swap sw        0       0

though I'm pretty sure the failure is happening long before the root filesystem would get mounted, since the kernel isn't even getting loaded (right?).

Well, I'll go back to reading the GRUB2 manual, but if anyone has any ideas or suggestions meanwhile, please let me know.

Thanks.

Gary