Bug 801535

Summary: f16 grub2-mkconfig and os-prober creates defective and incomplete fedora 17 menu entries
Product: [Fedora] Fedora Reporter: cornel panceac <cpanceac>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: dennis, germano.massullo, hugh, mads, pjones, PTrenholme, stanley.king
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 21:16:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
grub2 menu entries created by grub2-mkconfig
none
grub.cfg, as generated by yum update to kernel 3.3.0-1.fc17.i686.PAE
none
grub cfg regenerated with grub2-mkconfig
none
state of partitions on the three hard disks
none
grub.cfg generated with grub2-mkconfig -o /boot/grub2/grub.cf none

Description cornel panceac 2012-03-08 18:41:35 UTC
Created attachment 568717 [details]
grub2 menu entries created by grub2-mkconfig

Description of problem:

running 

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
grub2-1.99-13.fc16.i686

How reproducible:
always

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.)
3.
  
Actual results:
as described

Expected results:
menu entries should describe what kernel they are pointing to, and root should be referred by uuid not by device name.

Additional info:

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.

Comment 1 Stan King 2012-03-22 05:03:27 UTC
Created attachment 571912 [details]
grub.cfg, as generated by yum update to kernel 3.3.0-1.fc17.i686.PAE

Comment 2 Stan King 2012-03-22 05:10:02 UTC
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_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
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"

Comment 3 Mads Kiilerich 2012-04-14 23:42:41 UTC
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?

Comment 4 cornel panceac 2012-04-15 08:05:03 UTC
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.

Comment 5 Mads Kiilerich 2012-04-15 22:56:02 UTC
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)"
and
  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.

Comment 6 cornel panceac 2012-04-16 12:52:00 UTC
(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.

Comment 7 Mads Kiilerich 2012-04-16 13:45:26 UTC
(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?

Comment 8 cornel panceac 2012-04-16 17:24:41 UTC
right.

Comment 9 Mads Kiilerich 2012-04-16 19:37:50 UTC
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.

Comment 10 Peter Trenholme 2012-05-03 21:40:00 UTC
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

and

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.

Comment 11 Mads Kiilerich 2012-05-03 23:55:29 UTC
(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.

Comment 12 Germano Massullo 2012-05-30 17:01:05 UTC
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.

#blkid:
/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

Comment 13 Germano Massullo 2012-05-30 17:03:13 UTC
Created attachment 587778 [details]
grub.cfg generated with grub2-mkconfig -o /boot/grub2/grub.cf

Comment 14 Mads Kiilerich 2012-05-30 18:05:07 UTC
(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.

Bug 826537.

Comment 15 D. Hugh Redelmeier 2012-12-01 23:04:49 UTC
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.

Comment 16 Fedora End Of Life 2013-01-16 16:59:39 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Fedora End Of Life 2013-02-13 21:16:19 UTC
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.