Bug 858086 - grub2/grub.cfg "root=" should prefer UUID instead of /dev/hd
grub2/grub.cfg "root=" should prefer UUID instead of /dev/hd
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
17
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-17 18:58 EDT by John Reiser
Modified: 2013-08-01 05:02 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 05:02:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2012-09-17 18:58:48 EDT
Description of problem: After installing grub2 (replacing grub), "half" of my partitions won't boot because they specify the wrong "root=/dev/...".  It would be better to use "root=UUID=" instead.

grub2/grub.cfg has a lot of machinery to designate the correct filesystem to interpret the paths of vmlinuz and initrd.  Logically, the same machinery is needed to specify the correct filesystem for "root=" on the kernel command line; but I still see "root=/dev/hdX" instead of "root=UUID=".  "root=/dev/hdX" is unlikely to work, because /dev/hdX at OSprobe time is not necessarily the same /dev/hdX inside that running kernel.  It is especially true for older kernels that use /dev/hdX instead of /dev/sdX.  It is even more problematic when the box has both IDE and SATA drives and both old and new kernels (see Additional Information below.)


Version-Release number of selected component (if applicable):
grub2-2.0-0.38.beta6.fc17.x86_64


How reproducible: once is too many times


Steps to Reproduce:
1. Install Fedora 17 grub2 bootloader, which converts previous [custom] grub1/grub.cfg.
2.
3.
  
Actual results:
----- typical bad entry in grub2/grub.cfg
menuentry 'CentOS release 5.6 (Final)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-7ef173f3-abc3-47a8-a24d-9a68e2ac95b4' {
        insmod part_msdos
        insmod ext2
        set root='hd1,msdos9'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos9 --hint-efi=hd1,msdos9 --hint-baremetal=ahci1,msdos9 --hint='hd1,msdos9'  7ef173f3-abc3-47a8-a24d-9a68e2ac95b4
        else
          search --no-floppy --fs-uuid --set=root 7ef173f3-abc3-47a8-a24d-9a68e2ac95b4
        fi
        linux /boot/vmlinuz-2.6.18-194.26.1.el5 root=/dev/sdb9
        initrd /boot/initrd-2.6.18-194.26.1.el5.img
}
-----
Notice all the work to use 7ef173f3-abc3-47a8-a24d-9a68e2ac95b4 as the filesystem for the paths to vmlinuz and initrd, but only the simplistic "root=/dev/sdb9" for the running root.  This is unlikely to work because /dev/sdb9 does not necessarily designate the same filesystem each time.

Expected results:
Use "root=UUID=":
        linux /boot/vmlinuz-2.6.18-194.26.1.el5 root=UUID=7ef173f3-abc3-47a8-a24d-9a68e2ac95b4

Additional info:  How can I force the "root=UUID=" style for the next OS probe (and all subsequent probes), regardless of what is in grub2/grub.cfg ?

-----device.map
(hd0)      /dev/sda
(hd1)      /dev/sdb
(hd2)      /dev/sdd
(hd3)      /dev/sde
(hd0,msdos1)      /dev/sda1
-----

Actual hardware:
-----
sda, hda: IDE  channel 0 master           fixed harddrive
sdb, hdb: IDE  channel 0 slave            fixed harddrive
sr0, hdc: IDE  channel 1 master           CD/DVD removable
sdc, hdd: IDE  channel 1 slave            removable ZIP100 harddrive
sdd, sda: SATA channel 0 ("5th IDE")      fixed harddrive
sde, sdb: SATA channel 1 ("6th IDE")      fixed harddrive
-----
Note the complication that sdc is hdd; and also sda means two entirely different drives depending on age of kernel (even with deterministic initialization order.)  Furthermore, *sometimes* sdb and sdd swap places (in newer kernels) based on random initialization order.  UUID is the only way to sanity.
Comment 1 Mads Kiilerich 2012-09-17 19:10:00 EDT
I assume you are referring to the entries for booting other OS's in the 30_os-prober section. Attaching a full grub.cfg would clarify that.

These boot entries are not reliable ... and fixing it with the os-prober approach is hardly feasible. See upstreams comments on http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config .
Comment 2 Fedora End Of Life 2013-07-03 22:39:43 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 3 Fedora End Of Life 2013-08-01 05:02:21 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.