Red Hat Bugzilla – Bug 801535
f16 grub2-mkconfig and os-prober creates defective and incomplete fedora 17 menu entries
Last modified: 2013-02-13 16:16:19 EST
Created attachment 568717 [details]
grub2 menu entries created by grub2-mkconfig
Description of problem:
grub2-mkconfig -o /boot/grub2/grub.cfg
from f16, when there's also f17 installed on different partition (btrfs), creates menu entries that only have the fedora 17 label (no reference to the kernel verion) and the root is reffered to by the device name, not by uuid. also the entries are in reverse order, unlike the ones from f16 or scientific 6.
Version-Release number of selected component (if applicable):
# rpm -qf /sbin/grub2-mkconfig
Steps to Reproduce:
1.grub2-mkconfig -o /boot/grub2/grub.cfg
2.(on a system that has also f17 installed on one of the hard disk drives.)
menu entries should describe what kernel they are pointing to, and root should be referred by uuid not by device name.
i have three hard disks, and f17 and f16 and scientific are all installed in the one that bios sees as the first.
see also attachment.
Created attachment 571912 [details]
grub.cfg, as generated by yum update to kernel 3.3.0-1.fc17.i686.PAE
Created attachment 571914 [details]
grub cfg regenerated with grub2-mkconfig
This file is a result of running grub2-mkconfig with no change to /etc/default/grub.
I would love to make some changes to /etc/default/grub to reflect my preferences, but I'll leave the file alone, in case its original form is helpful to someone in figuring out the solution to this bug. The contents of /etc/default/grub is as follows:
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet"
Please describe your disk layout - for example by adding some comments to the output of "blkid".
Are you using the same /boot for f16 and f17?
Created attachment 577503 [details]
state of partitions on the three hard disks
i did a little investigation and blkid shows two partitions having same label. scientific an f17 are installed on one partition each (sda1 and sda6). f16 has an /boot. it's interesting that the duplicate labeled partiton is correctly parsed, and the no-label one (which also happens to be a btrfs) is not. details in the attachment.
Please put your comments in the comment field.
(Please be very explicit and pay attention to details - the opposite makes it very hard to grok your report. It isn't obvious what it is you are reporting - it requires digging through the attachments to guess that you are pointing at
menuentry "Fedora release 17 (Beefy Miracle) (on /dev/sda6)"
linux /boot/vmlinuz-3.3.0-0.rc3.git7.2.fc17.i686.PAE root=/dev/sda6
. It has also not been mentioned which partitions is used for f16. However:)
Is the headline of what you are saying here that the content of the 30_os-prober section is imperfect? If so: Yes, it is "extra" functionality that makes a best effort at probing and guessing something it can't know and doesn't fully understand. It might be convenient and make the right guess, but don't trust it. If you have multiple OSs on your system then I would recommend adding some kind of chainload entries to /etc/grub.d/40_custom and perhaps remove 30_os-prober.
Arguably the 30_os-prober section should create entries for chaining boot loaders instead of booting kernels directly (which will start failing when the kernel get updated). That would however have to be fixed upstream. It is not feasible for Fedora to pursue this further. In my opinion.
(In reply to comment #5)
> Is the headline of what you are saying here that the content of the
> 30_os-prober section is imperfect?
no. what i'm saying is that fedora 16 can't create the right boot entries for fedora 17, while on another system, that probably doesn't have the label issue, debian 6 can.
(i do agree that chainloading was a better option but even so, debian 6 has a way to update the boot entries of all known operating systems on hard disk, dpkg-reconfigure grub-pc, while fedora 16 has no way to do that. but that's another story.)
i'll try changing the label on one of those partitions and see if this helps.
thank you for assistance.
(In reply to comment #6)
> (In reply to comment #5)
> > Is the headline of what you are saying here that the content of the
> > 30_os-prober section is imperfect?
> no. what i'm saying is that fedora 16 can't create the right boot entries for
> fedora 17, while on another system, that probably doesn't have the label issue,
> debian 6 can.
But these entries are in the 30_os-prober section, right?
Ok. The real bug is in my opinion that it try to create specific entries for another os at all. It should just leave that to the f17 boot loader. There is for example no way a f16 boot loader can predict how a f17 system should be booted.
I'm not sure if this is the right bug, but I was just trying grub2-mkconfig on an old laptop (i686), and the script failed because:
1) It tried to source /usr/lib/grub/grub_mkconfig_lib whilst the correct location is /usr/share/grub/grub_mkconfig_lib
2) Most of the scripts in /etc/grub.d/ attempt to execute grub_get_device_id which does not appear to be available.
viz, (from the tail of the mkconfig output (after symlinking the grub_mkconfig_lib to /usr/share/grub/)
### BEGIN /etc/grub.d/10_linux ###
Found linux image: /boot/vmlinuz-3.3.4-1.fc16.i686
Found initrd image: /boot/initramfs-3.3.4-1.fc16.i686.img
/etc/grub.d/10_linux: line 84: grub_get_device_id: command not found
[root@localhost ~]# yum provides *bin/grub2_get_device_id
Loaded plugins: dellsysid, fastestmirror, keys, langpacks, presto, refresh-packagekit, remove-with-leaves, rpm-
: warm-cache, upgrade-helper
Loading mirror speeds from cached hostfile
* fedora: mirrors.nebo.edu
* rpmfusion-free: mirror.liberty.edu
* rpmfusion-free-updates: mirror.liberty.edu
* rpmfusion-nonfree: mirror.liberty.edu
* rpmfusion-nonfree-updates: mirror.liberty.edu
* updates: mirrors.nebo.edu
No Matches found
Note: I reinstalled grub2, but the problems were unchanged.
On the other hand, I can't believe a problem of this magnitude would not have occurred long ago. But I also can't see how something I did could cause this.
(In reply to comment #10)
No, this is not the right bug.
Please tell what grub2 version you are using.
Please show the output of 'rpm -qV grub2'.
The only way grub2_mkconfig could source something in /usr/lib is if you for some reason have the environment variable pkgdatadir set to point there.
grub_get_device_id is defined in /usr/share/grub/grub-mkconfig_lib which is sourced by 10_linux.
I upgraded from Fedora 16 to 17 with preupgrade. The computer is a Thinkpad T60 with one hard drive. After the upgrade, grub missed the Fedora 17 kernel entry by leaving the old Fedora 16 kernels entries.
I solved by doing:
grub2-mkconfig -o /boot/grub2/grub.cfg
This happened also to a my friend with another laptop. Actually I am downloading upgrades on another 2 computers, so I can recreate the problem.
/dev/sda1: UUID="removed" TYPE="ext4" /boot
/dev/sda2: UUID="removed" TYPE="swap"
/dev/sda3: UUID="removed" TYPE="crypto_LUKS" main partition
/dev/mapper/luks-removed: LABEL="_Fedora-14-i686-" UUID="removed" TYPE="ext4"
#rpm -qV grub2
S.5....T. c /etc/default/grub
I attatch the grub.cfg
Created attachment 587778 [details]
grub.cfg generated with grub2-mkconfig -o /boot/grub2/grub.cf
(In reply to comment #12)
> I upgraded from Fedora 16 to 17 with preupgrade.
> After the upgrade, grub missed the Fedora 17 kernel
> entry by leaving the old Fedora 16 kernels entries.
Off topic (I got here while looking for still another bug):
I quite agree with Mads Kiilerich #9. Here's an example. My ubuntu 12.04 needs nomodeset. Fedora 18 beta's grub2-mkconfig doesn't discover this. So it screws up.
I guess that this should be its own bug report.
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 '16'.
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 16'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 16 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 to click on
"Clone This Bug" and open it against that version of Fedora.
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.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.