Setting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub not working as expected

Question

I'm using Debian stretch (9.0), the current stable. My arch is AMD64. My root and boot partitions are LVM volume groups on top of an MD RAID 1 device.

According to my understanding of the documentation, uncommenting

GRUB_DISABLE_LINUX_UUID=true

in /etc/default/grub should stop GRUB2 from using UUIDs in /boot/grub/grub.cfg. However, it continues to use UUIDs even after I have made that change.

I'm not sure if this is somehow user error on my part, but the instructions seem simple enough.

A couple of additional comments.

1. There is also a file /usr/share/grub/default/grub, which has identical contents (same md5sum) to /etc/default/grub. I'm not sure what the point of that file is.
2. I would expect /usr/sbin/grub-mkconfig to include a check for GRUB_DISABLE_LINUX_UUID, but I don't see one, though that script does include GRUB_DISABLE_LINUX_UUID. Can someone explain to me where this script is checking GRUB_DISABLE_LINUX_UUID?

I can post more details if it would help, of course.

Background: I was motivated to change this because the UUID of my root VG changed, and my machine refused to boot, saying that the UUID didn't exist. Which was correct. It didn't any longer. See Unable to determine sync status errror when trying split LVM2 RAID 1 mirror for how that happened.

Debian bug report: grub-common: Setting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub does not work as expected.

Answer 1

(This answer tries to explain what is happening and offers a (possible) patch.)

It seems the offending code is in grub-mkconfig_lib lines 169-182 in current Debian 9.

The point of the bug is that the setup and boot insists on setting up and using the UUID for one part of the boot process despite not being told to by the sysadmin/configuration.

Possibly failing to load grub.cfg in consequence. e.g. it is always doing grub-probe --target=fs_uuid / in grub-mkconfig_lib ; in our case should be grub-probe --target=device / or to be code specific, it should use $fs_hint, and not redo again grub_probe with fs_uuid

I have done a patch to disable the generation of UUID when GRUB_DISABLE_LINUX_UUID is configured as true for Debian 9. It works here. Please test it.

I confirm again the offending file is: /usr/share/grub/grub-mkconfig_lib

I wrote a patch that if GRUB_DISABLE_LINUX_UUID is set to true, it does not include the search directive trying to select an UUID based root. The sysadmin should then understand the consequences of selecting this option when inserting new disks.

The patch for /usr/share/grub/grub-mkconfig_lib was done with:

diff -u grub-mkconfig_lib.old grub-mkconfig_lib > grub-mkconfig_lib.patch 

and is here: https://jpst.it/10_iY

or you can get it here:

https://github.com/ruyrybeyro/grub-mkconfig_lib.patch

and to apply it:

cd /usr/share/grub
patch -p0 < grub-mkconfig_lib.patch

Basically, starting on line 169, I added the new if, and proper indentation, to disable the root partition search for UUID that supersedes the choice by device if a partition with a valid UUID is found:

  if [ "x${GRUB_DISABLE_LINUX_UUID}" != "xtrue" ] ; then   

   if fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; then
      hints="`"${grub_probe}" --device $@ --target=hints_string 2> /dev/null`" || hints=
      echo "if [ x\$feature_platform_search_hint = xy ]; then"
      echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
      echo "else"
      echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
      echo "fi"
    fi

  fi

I tested it, regenerating the grub config, changing the UUID, and it booted without a hitch, contrary to the former situation, where we would be dropped into grub.

PS: This seems not to be restricted to Debian. After I pin pointed it to grub-mkconfig_lib I found a related thread about fedora