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.

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.
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 05 '17 at 09:14

Rui F Ribeiro · Answer 1 · 2017-07-06T19:34:39.587

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

edited Jul 06 '17 at 19:34

answered Jul 05 '17 at 15:34

Rui F Ribeiro

56,709
26
150
232

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 05 '17 at 16:01
diff done with -u – Rui F Ribeiro Jul 05 '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 05 '17 at 17:05
1

And any non-Debian users, please check if this bug applies to you too. – Faheem Mitha Jul 05 '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 05 '17 at 17:50
I thought about upload to my github, thanks for the tip. – Rui F Ribeiro Jul 05 '17 at 17:53
I'm not clear how long that gist repos will stick around for, but it's a reasonable short term solution, and probably better than the average paste site. See also https://help.github.com/articles/creating-gists/#creating-an-anonymous-gist. Note also that gist-paste will authenticate to your existing Github account if you want it to - see man gist-paste. – Faheem Mitha Jul 05 '17 at 17:59
@FaheemMitha Did it work? – Rui F Ribeiro Jul 06 '17 at 12:44
I'm looking at it now. I'd replace your pastebin by a gist link. I think it will be easier for people to work with, as they can just clone the git repos. I'm having to cut and paste from the pastebin web page, which is inelegant, and may introduce errors. And do make sure to use diff -u. – Faheem Mitha Jul 06 '17 at 16:41
You should also include your patch in the question, though make it clear that people should use the gist to obtain the patch. – Faheem Mitha Jul 06 '17 at 16:51
Let us continue this discussion in chat. – Faheem Mitha Jul 06 '17 at 17:09

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

1 Answers1