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?
  • Any particular filesystem type that still has UUIDs? What distribution & version? What grub version?
    – Anthon
    Commented 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. Commented 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
    Commented 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, …)? Commented May 3, 2014 at 14:25

2 Answers 2


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

  • 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? Commented 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
    Commented May 3, 2014 at 8:37

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

Update March 2023 Prompted by @MelroyvandenBerg followup comment, I took a quick look to see if my 2016 answer was still relevant.

We've switched away from Centos in 2019 (see Centos Stream discussion elsewhere) but I spun up an old machine that is still running CentOS Linux release 7.2.1511. I reconfirmed the results above:

$ grep GRUB_DISABLE /usr/share/grub/grub-mkconfig_lib
  if [ "x$GRUB_DISABLE_UUID" != "xtrue" ] && fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; then
  if [ "x$GRUB_DISABLE_UUID" != "xtrue" ] && fs_uuid="`"${grub_probe}" --device ${device} --target=fs_uuid 2> /dev/null`" ; then

Looking into this a bit more (still on the Centos 7 system), /usr/share/doc/grub2-tools-2.02/grub.html contains the following (emphasis added to show differences)


Normally, grub2-mkconfig will generate menu entries that use universally-unique identifiers (UUIDs) to identify the root filesystem to the Linux kernel, using a ‘root=UUID=...’ kernel parameter. This is usually more reliable, but in some cases it may not be appropriate. To disable the use of UUIDs, set this option to ‘true’.


Normally, grub2-mkconfig will generate menu entries that use universally-unique identifiers (UUIDs) to identify various filesystems to search for files. This is usually more reliable, but in some cases it may not be appropriate. To disable this use of UUIDs, set this option to ‘true’.

So it does look like there is a specific difference between GRUB_DISABLE_LINUX_UUID and GRUB_DISABLE_UUID

Skipping forward 7 years and looking at Ubuntu 22.04.1 LTS (more current, albeit Debian based), I did observe this snippet in /usr/sbin/grub-mkconfig

if [ "x${GRUB_DISABLE_UUID}" = "xtrue" ]; then
  if [ -z "${GRUB_DISABLE_LINUX_UUID}" ]; then
  if [ -z "${GRUB_DISABLE_LINUX_PARTUUID}" ]; then

Which will cause an (unset) GRUB_DISABLE_LINUX_UUID to be set to true if GRUB_DISABLE_UUID is true. I can only guess that somewhere in the last 7 years someone has been working to clarify and/or eliminate the distinction between these two variables.

I encourage you to check with your specific distribution's code and documentation rather than my original 2016 comment.

  • Are you really sure about this? Commented Mar 26, 2023 at 15:15
  • 1
    @MelroyvandenBerg - I've update my comments above.
    – MikeV
    Commented Mar 26, 2023 at 21:22
  • I think the correct value is GRUB_DISABLE_LINUX_UUID, which needs to be set in the /etc/default/grub file. All the other files are generated, eg. via update-grub. Commented Mar 27, 2023 at 22:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .