4

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?
Improve this question
4
  • Any particular filesystem type that still has UUIDs? What distribution & version? What grub version?
    – Anthon
    May 3, 2014 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, 2014 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, 2014 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 'SO- stop being evil'
    May 3, 2014 at 14:25

2 Answers 2

Reset to default
4

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).

Improve this answer
2
  • 2
    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, 2014 at 8:19
  • 1
    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, 2014 at 8:37
3

In case anyone stumbles across this post and is using Centos 7 / GRUB2 (like I am), the variable name appears to have changed to GRUB_DISABLE_UUID (not GRUB_DISABLE_LINUX_UUID).

You can check yours at /usr/share/grub/grub-mkconfig_lib. Mine has this:

if [ "x$GRUB_DISABLE_UUID" != "xtrue" ]

After a grub2-mkconfig, the UUIDs were replaced with /dev/sda1, etc. (which we needed because we clone these systems).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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