Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?
share|improve this question
    
Any particular filesystem type that still has UUIDs? What distribution & version? What grub version? –  Anthon May 3 at 7:15
    
What do you mean by "still has UUIDs"? I thought the UUID identifies the device and has little to do with the filesystem which lives there. The filesystem is BTW an ext4. –  Martin Drautzburg May 3 at 8:22
    
You write that the auto-generated grub.conf contained some UUIDs and some /dev entries, I assumed that was after changing GRUB_DISABLE_LINUX_UUID and running update-grub, if that is not the case please update your Q with the word 'original' before auto-generated. –  Anthon May 3 at 8:30
    
What type of filesystem does the root filesystem use? What type of container is it on (e.g. PC partition, GPT partition, fakeraid, dmraid, LVM, dmcrypt, …)? –  Gilles May 3 at 14:25

1 Answer 1

The value of GRUB_DISABLE_LINUX_UUID is used by update-grub and the scripts in the directory /etc/grub.d/. If you still get UUIDs in your grub.conf it looks like one of the scripts is not checking against the GRUB_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).

share|improve this answer
    
GRUB_DISABLE_LINUX_UUID does work and I no longer see UUIDs in my grub.cfg. My question was, why I need to set this in the first place. The documentation suggests that not using UUIDs is a cosmetic issue (/dev looks nicer), but it my case UUIDs don't work at all. The filsystem is an ext4. Just checked dmesg and I see "EXT3-fs (sda1): error: couldn't mount because of unsupported optional features (240)". Could that be the reason why /dev works but UUIDs don't? –  Martin Drautzburg May 3 at 8:19
    
The nice things about UUIDs is that they don't change if you move your discs around, and they do change if you put new filesystems on your partition. The error is IIRC a result of your system first trying those ext4 filesystems as ext3 (or ext2) –  Anthon May 3 at 8:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.