Bug 1027833

Summary: grub2-mkconfig does not honor GRUB_DISABLE_LINUX_UUID correctly
Product: Red Hat Enterprise Linux 7 Reporter: Jiri Benc <jbenc>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: jbenc, mbanas, pholica
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: grub2-2.02-0.11.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 11:12:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Benc 2013-11-07 12:56:04 UTC
Although /etc/grub.d/10_linux correctly handles GRUB_DISABLE_LINUX_UUID=true specified in /etc/default/grub and generates correct "linux" entry, it's not checked in prepare_grub_to_access_device, generating

        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root  xxxxxxxx-...
        else
          search --no-floppy --fs-uuid --set=root xxxxxxxx-...
        fi

in grub.cfg (my UUID replaced by xxxxxxxx-...).

This makes grub2 output error message, waiting for a key to be pressed (thus fatal on remote machines) if the UUID is changing (which is the reason to use GRUB_DISABLE_LINUX_UUID in the first place).

Comment 2 Pavel Holica 2014-01-17 13:22:13 UTC
According to info pages:
'GRUB_DISABLE_LINUX_UUID'
     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'.

If I get this right, you want to disable lookup by UUID of partition containing kernel and ramdisk? Looking to grub documentation, this can be done by looking for file on partition or by filesystem label.

I'm asking because there is no information how result should look like.

Comment 3 Jiri Benc 2014-01-17 13:33:50 UTC
(In reply to Pavel Holica from comment #2)
> If I get this right, you want to disable lookup by UUID of partition
> containing kernel and ramdisk? Looking to grub documentation, this can be
> done by looking for file on partition or by filesystem label.

Yes, and the GRUB_DISABLE_LINUX_UUID is exactly for that but it doesn't work.

> I'm asking because there is no information how result should look like.

I'd expect /dev/sda1 or so.

Comment 4 Jiri Benc 2014-01-17 13:35:33 UTC
Or (hd0,0) or whatever the correct syntax is at that place.

Comment 6 Jiri Benc 2014-01-17 13:58:46 UTC
(In reply to Pavel Holica from comment #5)
> No, If you read documentation, it's for linux root, which means setting
> kernel parameter root=...
> The search is for grub to know where /boot is located, so it can load kernel
> and ramdisk.

Okay, I stand corrected. Nevertheless, the GRUB_DISABLE_LINUX_UUID option is kinda pointless without this.

> Grub at this stage doesn't know anything about linux devices, so it needs
> some way of looking for such device (using UUID, label or something like
> this).
> 
> Anyway, I'm adding qa_ack+, but I don't agree with using this option, I'd
> vote for GRUB_DISABLE_UUID or something like this.

Works for me. Any solution that allows not relying on UUIDs is okay.

Comment 11 Pavel Holica 2015-01-14 09:04:45 UTC
When GRUB_DISABLE_UUID is used in /etc/default/grub (and grub config re-generated), there are no UUIDs when specifying device holding kernel and ramdisk.

Comment 13 errata-xmlrpc 2015-03-05 11:12:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0492.html