3

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.

  • Comments are not for extended discussion; this conversation has been moved to chat. – terdon Jul 5 '17 at 9:14
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

  • Nice work, Rui. I'll try to test this patch today. But could you regenerate with diff -u, please? That's more standard. I don't know why it's not the default. Or add it to your previous paste, if you prefer. – Faheem Mitha Jul 5 '17 at 16:01
  • diff done with -u – Rui F Ribeiro Jul 5 '17 at 17:04
  • 1
    Thanks very much, Rui. I'll test it and get back to you. And any other Debian users out there, please also test. – Faheem Mitha Jul 5 '17 at 17:05
  • 1
    And any non-Debian users, please check if this bug applies to you too. – Faheem Mitha Jul 5 '17 at 17:28
  • 1
    Just a side comment - a good way to paste/post a patch is by using gist-paste, from the gist package. It makes a git repository for the file. – Faheem Mitha Jul 5 '17 at 17:50

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.