Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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).
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.
(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.
(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.
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.
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
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).