I just switched from lilo to grub2 and my first attempt failed with kernel panic - not syncing vfs unable to mount root fs on unknown block(0 0)
. It turned out that the problem was that the root partition was specified in terms of a UUID instead of a device name. The solution was to uncomment GRUB_DISABLE_LINUX_UUID=true
in /etc/default/grub
.
The original auto-generated /boot/grub/grub.conf
contained some UUID entries and some /dev entries.
- How does update-grub choose between UUID and /dev rootfs, i.e. why is it sometimes a UUID and sometimes not?
- What keeps UUIDs from working? I didn't find a kernel parameter which could be set wrongly (kernel 3.8.2)
- Do I need UUIDs in my fstab when grub uses UUIDs?
Best Answer
The value of
GRUB_DISABLE_LINUX_UUID
is used byupdate-grub
and the scripts in the directory/etc/grub.d/
. If you still get UUIDs in yourgrub.conf
it looks like one of the scripts is not checking against theGRUB_DISABLE_LINUX_UUID
setting.Best thing to do there is trying to figure out what the filesystem type is and check that against the names of the scripts in
/etc/grub.d
to see if there is a pattern.As to why UUIDs are not working, I have no definitive answer, I would suspect this depends on the filesystem type, but that is a wild guess.
You don't need UUIDs in your fstab even when grub uses them, but it is of course a possible way to see if you are using the right UUIDs in the first place (but I rather look in
/dev/disk/by-uuid
for that).