Bug 725185

Summary: grubby doesn't add the initrd line at the kernel update
Product: [Fedora] Fedora Reporter: Martin-Gomez Pablo <pablomg+fedora>
Component: grubbyAssignee: Peter Jones <pjones>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 19CC: awilliam, bcl, bruno, dennis, eblake, glennjohnson57, lars.seipel, madko, mads, mishu, pjones, steved, tflink, toracat
Target Milestone: ---Keywords: Reopened
Target Release: ---Flags: awilliam: needinfo? (pjones)
Hardware: Unspecified   
OS: Linux   
Whiteboard: RejectedBlocker
Fixed In Version: grub-0.97-79.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-18 08:35:49 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
new-kernel-pkg.patch none

Description Martin-Gomez Pablo 2011-07-23 16:06:12 EDT
Description of problem:
When the kernel is updated with yum, grubby add a new entry to the /boot/grub/grub.conf file, but without the grub command line initrd despite the fact the initrd img is present in the directory

Version-Release number of selected component (if applicable):
grubby-8.0-1.fc16.x86_64

How reproducible:
Always since the kernel-3.0-0.rc7.git10.1.fc16.x86_64 update, which coincide with grubby-8.0-1.fc16.x86_64 update     

Steps to Reproduce:
1. Update your kernel
2. Reboot on the newly installed kernel
3. Look at the kernel panic because there is non initrd
  
Actual results:
title Fedora (3.0.0-1.fc16.x86_64)
	root (hd0,1)
	kernel /boot/vmlinuz-3.0.0-1.fc16.x86_64 ro root=UUID=92fd9674-0274-4901-b107-5f567ae229f6 acpi.power_nocheck=1 LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 usbcore.autosuspend=1 pcie_aspm=force

Expected results:
title Fedora (3.0.0-1.fc16.x86_64)
	root (hd0,1)
	kernel /boot/vmlinuz-3.0.0-1.fc16.x86_64 ro root=UUID=92fd9674-0274-4901-b107-5f567ae229f6 acpi.power_nocheck=1 LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=fr-latin9 usbcore.autosuspend=1 pcie_aspm=force
	initrd /boot/initramfs-3.0-0-1.fc16.x86_64.img

Additional info:
Comment 1 Tim Flink 2011-08-04 15:51:28 EDT
It doesn't squarely hit the following Fedora 16 alpha release criterion, but it does hit the intention:

The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops 

Even though the update DOES technically install, it leaves the system in a non-bootable state.

I assume that manually adding the initrd to grub would be the workaround?

Unless I'm missing something here, I'm +/- 0 on alpha blocker for this. Editing grub.conf isn't so bad of a workaround but it is a bit of a pain. I'd be for Alpha NTH or beta blocker, though - IMHO, this would need to be fixed by beta.

+0 alpha blocker, +1 alpha NTH, +1 beta blocker.
Comment 2 Mads Kiilerich 2011-08-04 16:09:43 EDT
(In reply to comment #1)
> I assume that manually adding the initrd to grub would be the workaround?

Correct. grub.cfg can be edited manually or the missing line can be added on boot time. Until the user figures out what is going on and what is missing he will just see a scary oops without any hints that it "just" is initrd is missing.

It should perhaps be mentioned in the known issues document if the alpha is released without a fix.
Comment 3 Adam Williamson 2011-08-04 18:46:09 EDT
Has anyone else actually seen this bug? I haven't, and I install kernels quite a lot. Just did one yesterday. It booted fine on restart.
Comment 4 Mads Kiilerich 2011-08-05 07:38:31 EDT
(In reply to comment #3)
> Has anyone else actually seen this bug? I haven't, and I install kernels quite
> a lot. Just did one yesterday. It booted fine on restart.

I can reproduce it on f16 with updates-testing:

[root@localhost ~]# cat /boot/grub/grub.conf 
#boot=/dev/sda3
default=0
#timeout=0
splashimage=(hd0,2)/grub/splash.xpm.gz
#hiddenmenu
title Fedora (3.0.0-3.fc16.i686)
	root (hd0,2)
	kernel /vmlinuz-3.0.0-3.fc16.i686 ro root=/dev/mapper/VolGroup-LogVol01 rd_LVM_LV=VolGroup/LogVol01 rd_LVM_LV=VolGroup/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
	initrd /initramfs-3.0.0-3.fc16.i686.img
title Fedora (3.0.0-1.fc16.i686)
	root (hd0,2)
	kernel /vmlinuz-3.0.0-1.fc16.i686 ro root=/dev/mapper/VolGroup-LogVol01 rd_LVM_LV=VolGroup/LogVol01 rd_LVM_LV=VolGroup/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
	initrd /initramfs-3.0.0-1.fc16.i686.img

[root@localhost ~]# rpm -ihv kernel-3.0.0-4.1.fc16.i686.rpm 
Preparing...                ########################################### [100%]
   1:kernel                 ########################################### [100%]
W: Skipping program kexec as it cannot be found and is flagged to be optional

[root@localhost ~]# cat /boot/grub/grub.conf 
#boot=/dev/sda3
default=0
#timeout=0
splashimage=(hd0,2)/grub/splash.xpm.gz
#hiddenmenu
title Fedora (3.0.0-4.1.fc16.i686)
	root (hd0,2)
	kernel /vmlinuz-3.0.0-4.1.fc16.i686 ro root=/dev/mapper/VolGroup-LogVol01 rd_LVM_LV=VolGroup/LogVol01 rd_LVM_LV=VolGroup/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
title Fedora (3.0.0-3.fc16.i686)
	root (hd0,2)
	kernel /vmlinuz-3.0.0-3.fc16.i686 ro root=/dev/mapper/VolGroup-LogVol01 rd_LVM_LV=VolGroup/LogVol01 rd_LVM_LV=VolGroup/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
	initrd /initramfs-3.0.0-3.fc16.i686.img
title Fedora (3.0.0-1.fc16.i686)
	root (hd0,2)
	kernel /vmlinuz-3.0.0-1.fc16.i686 ro root=/dev/mapper/VolGroup-LogVol01 rd_LVM_LV=VolGroup/LogVol01 rd_LVM_LV=VolGroup/LogVol00 rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
	initrd /initramfs-3.0.0-1.fc16.i686.img

[root@localhost ~]# rpm -q grubby
grubby-8.1-1.fc16.i686

I have also seen it on x86_64. My test systems was installed from f15 live desktop and yum upgraded to f16.
Comment 5 Adam Williamson 2011-08-05 11:19:15 EDT
can you reproduce with 'yum localinstall' rather than 'rpm'?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Mads Kiilerich 2011-08-05 11:46:28 EDT
(In reply to comment #5)
> can you reproduce with 'yum localinstall' rather than 'rpm'?

[root@imac ~]# grep -v ^# /boot/grub/grub.conf
default=0
splashimage=(hd0,3)/grub/splash.xpm.gz
title Fedora (3.0.0-3.fc16.i686.PAE)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-3.fc16.i686.PAE ro root=/dev/mapper/VolGroup-lv_root32 rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
	initrd /initramfs-3.0.0-3.fc16.i686.PAE.img
title Fedora (3.0.0-3.fc16.x86_64)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-3.fc16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
title Fedora (3.0.0-1.fc16.x86_64)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-1.fc16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
	initrd /initramfs-3.0.0-1.fc16.x86_64.img
title grub2
	kernel /grub2/core.img

[root@imac ~]# yum localinstall kernel-3.0.0-4.1.fc16.x86_64.rpm 
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Local Package Process
Examining kernel-3.0.0-4.1.fc16.x86_64.rpm: kernel-3.0.0-4.1.fc16.x86_64
...
Running Transaction
Warning: RPMDB altered outside of yum.
  Installing : kernel-3.0.0-4.1.fc16.x86_64   1/1
Installed:
  kernel.x86_64 0:3.0.0-4.1.fc16
Complete!

[root@imac ~]# grep -v ^# /boot/grub/grub.conf
default=1
splashimage=(hd0,3)/grub/splash.xpm.gz
title Fedora (3.0.0-4.1.fc16.x86_64)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-4.1.fc16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
title Fedora (3.0.0-3.fc16.i686.PAE)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-3.fc16.i686.PAE ro root=/dev/mapper/VolGroup-lv_root32 rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
	initrd /initramfs-3.0.0-3.fc16.i686.PAE.img
title Fedora (3.0.0-3.fc16.x86_64)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-3.fc16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
title Fedora (3.0.0-1.fc16.x86_64)
	root (hd0,3)
	kernel /vmlinuz-3.0.0-1.fc16.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us nomodeset
	initrd /initramfs-3.0.0-1.fc16.x86_64.img
title grub2
	kernel /grub2/core.img

[root@imac ~]# rpm -q grubby yum rpm
grubby-8.1-1.fc16.x86_64
yum-3.4.3-4.fc16.noarch
rpm-4.9.0-10.fc16.x86_64
Comment 7 Adam Williamson 2011-08-05 12:49:36 EDT
huh. I just a few minutes ago did:

yum localinstall http://kojipkgs.fedoraproject.org/packages/kernel/3.0.1/1.fc16/x86_64/kernel-3.0.1-1.fc16.x86_64.rpm

and in my grub.conf is:

title Fedora (3.0.1-1.fc16.x86_64)
        root (hd0,0)
        kernel /vmlinuz-3.0.1-1.fc16.x86_64 ro root=/dev/mapper/vg_adam-lv_root rd_LVM_LV=vg_adam/lv_root rd_LVM_LV=vg_adam/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet fbcon=rotate:3
        initrd /initramfs-3.0.1-1.fc16.x86_64.img

it would be nice if we could figure out what actually causes this...I have same package versions as you.
Comment 8 Mads Kiilerich 2011-08-05 13:41:45 EDT
Most of my other tests has been on EFI machines, but I see it on regular PCs too:

...
Running Transaction
  Installing : kernel-PAE-3.0.1-1.fc16.i686   1/1
grubby fatal error: unable to find a suitable template

Installed:
  kernel-PAE.i686   0:3.0.1-1.fc16

Complete!

[root@user07 ~]# grep -v ^# /boot/grub/grub.conf
default=0
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora (3.0.1-1.fc16.i686.PAE)
	root (hd0,0)
	kernel /vmlinuz-3.0.1-1.fc16.i686.PAE ro root=/dev/mapper/VolGroup-lv_root16 rd_LVM_LV=VolGroup/lv_root16 rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
title Fedora (3.0.0-3.fc16.i686.PAE)
	root (hd0,0)
	kernel /vmlinuz-3.0.0-3.fc16.i686.PAE ro root=/dev/mapper/VolGroup-lv_root16 rd_LVM_LV=VolGroup/lv_root16 rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us
	initrd /initramfs-3.0.0-3.fc16.i686.PAE.img


I "usually" don't get that fatal error, so I'm not sure it is related.

I guess someone familiar with the grubby source could give us a hint what the difference could be ...
Comment 9 Mads Kiilerich 2011-08-05 13:43:52 EDT
News flash: If I remove the grub2 package it starts working correctly.

That is strange, as grub2 is unrelated and uses /boot/grub2/grub.cfg.

Can you reproduce the problem by installing grub2?
Comment 10 Adam Williamson 2011-08-05 13:54:37 EDT
yes, indeed: if I remove the 3.0.1-1 kernel, install grub2, then re-install the 3.0.1-1 kernel, it shows up with no initrd line.

since grub2 isn't a default component, that makes this a less serious bug.
Comment 11 Adam Williamson 2011-08-05 13:56:40 EDT
whoops, i forgot, grub2 *is* default for f16, so presumably this will affect all f16 alpha clean installs.
Comment 12 Adam Williamson 2011-08-05 14:01:23 EDT
okay, new world order: we're now pretty sure this happens only if both grub and grub2 are installed, which should be a case you can only trigger manually: if left to their own devices, f15 systems upgraded to f16 currently get grub, and new f16 installs get grub2. so this isn't a really big problem.
Comment 13 Tim Flink 2011-08-05 14:19:59 EDT
Discussed in the 2011-08-05 blocker review meeting. Rejected as Fedora 16 alpha blocker because it requires grub and grub2 to be installed at the same time which is not a supported configuration.

A future release of grub2 will %obsolete grub and fix this issue.
Comment 14 Bruno Wolff III 2011-08-16 09:33:36 EDT
I am seeing this as well. It did cause me to report a kernel bug thinking it was a raid problem since my raid arrays weren't starting up and that was the last thing on the console before the boot failed, and I didn't think to check for missing initrd lines.
Comment 15 Fedora Update System 2011-09-01 16:09:01 EDT
grub-0.97-77.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-77.fc16
Comment 16 Gene Snider 2011-09-02 19:17:37 EDT
With the broken F16 alpha installer, I was forced to use F15 netinstall.iso to install the F16 DVD.iso.  This turns out to be one way to get both grub and grub2 installed.  I was hit with this bug and had to manually add the initrd lines to grub.conf.

Gene
Comment 17 Fedora Update System 2011-09-06 14:10:03 EDT
Package grub-0.97-77.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing grub-0.97-77.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/grub-0.97-77.fc16
then log in and leave karma (feedback).
Comment 18 Mads Kiilerich 2011-09-06 16:02:03 EDT
With the latest grub2 fixes it has been clarified that installing or updating the boot loader package just makes it possible for the sysadmin to actually install/update the active boot loader.

grubby just maintain the boot loader config file, assuming that it already exists and is valid.

So why can't grub and grub2 be installed at the same time? Why can't grubby maintain both config files at the same time? Why shouldn't it be left to the sysadmin to decide which of the boot loaders available on the system that he installs in the MBR? Is it really the right solution to let grub and grub2 conflict?

I understand that grub "1" is unmaintainable and agree that it should die ASAP, but I think the most smooth way to do it would be to let the sysadmin have them installed side by side and make the switch without burning any bridges.
Comment 19 Mads Kiilerich 2011-09-06 16:35:31 EDT
*** Bug 645611 has been marked as a duplicate of this bug. ***
Comment 20 Lars Seipel 2011-09-09 17:53:22 EDT
(In reply to comment #12)
> okay, new world order: we're now pretty sure this happens only if both grub and
> grub2 are installed, which should be a case you can only trigger manually:

That's not correct. When F16 is installed on UEFI machines you'll get both packages installed, with legacy grub being used by default.

I actually experienced this bug and mistook it for a kernel issue first (bug 733851). Like Mads, I also got the grubby fatal error on yum updating/installing the kernel package.

It's a fresh F16 installation from Alpha media (efidisk.img).
Comment 21 Mads Kiilerich 2011-09-09 18:34:31 EDT
(In reply to comment #20)
> It's a fresh F16 installation from Alpha media (efidisk.img).

Alpha is so last month. Since then grub-0.97-77.fc16 - which conflicts with grub2 - has been released, so there is no (legal) way you can have both at the same time.
Comment 22 Mads Kiilerich 2011-09-11 12:40:45 EDT
/me realizes a (obvious?) problem:

In f15 the grub package was used for both bios and efi boot.

In f16 grub is replaced with grub2 for bios boot - but apparently not for efi boot as grub2-efi unfortunately isn't ready for f16. f16 thus has to continue to use grub for efi boot.

Now grub and grub2 conflicts, but one is needed for bios boot and the other for efi boot. We thus need different package sets for the different boot methods - can anaconda really handle that?

It seems to me like the options are:
* desupport efi in f16 ... but I hope/assume that isn't an option
* make sure grub and grub2 no longer conflicts and that grubby can handle both simultaneously (as suggested in #18)
* start using grub2-efi in f16 ... but it is probably too late for that
Comment 23 Mads Kiilerich 2011-09-12 10:46:14 EDT
(In reply to comment #22)
> We thus need different package sets for the different boot methods -
> can anaconda really handle that?

Ok, according to pjones anaconda _can_ handle installation of either grub (for efi) or grub2 (for bios).
Comment 24 Mads Kiilerich 2011-09-13 10:00:45 EDT
Created attachment 522935 [details]
new-kernel-pkg.patch

I think I found and fixed one root cause for the original issue:


Fix new-kernel-pkg invocation of grubby for grub

new-kernel-pkg did not specify --grub when it called grubby to update the
kernel entry with an initrd. Grubby would then try to probe what to do and
would give preference to grub2 and thus leave an incomplete grub entry.

new-kernel-pkg did also not specify the grub config file explicitly to grubby
as it do for the grub2 config file. That could perhaps in some situations cause
grubby to do something else than new-kernel-pkg expected.

Now --grub -c $grubConfig is specified explicitly in all cases.


I think it would be nice to have this patch in f16 even though we have the conflicts as a workaround.
Comment 25 Adam Williamson 2011-09-13 15:42:10 EDT
there's an unfrozen period after Beta and before Final freeze, you could put it in then. I don't see any reason we'd need to take this urgently for Beta, as I understand the issue at present.
Comment 26 Eric Blake 2011-09-15 14:00:02 EDT
(In reply to comment #24)
> I think it would be nice to have this patch in f16 even though we have the
> conflicts as a workaround.

See bug 737261 for why the conflicts is not a good workaround - it gets in the way of installing libguestfs for management of multiple guest VM images that happen to use different bootloaders (such as installing F15 and F16 guests side-by-side).
Comment 27 Fedora Update System 2011-09-27 17:21:05 EDT
grub-0.97-78.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-78.fc16
Comment 28 Fedora Update System 2011-09-28 19:40:01 EDT
grub-0.97-79.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-79.fc16
Comment 29 Adam Williamson 2011-09-29 14:09:42 EDT
Clearing the rejectedblocker status of this and re-proposing so it will come up at the go/no-go today, as we have new data.

It became apparent that there is one 'out of the box' case that hits this at present: EFI installation. EFI installs use grub, but because grub2 is in comps, and anaconda is special and allowed to install conflicting packages in some situations, after an EFI install of F16 Beta you get both grub and grub2 packages installed. The installed kernel works, but on the first kernel update, you hit this bug.

There is, of course, a workaround: remove grub2 after installation. And as you'll only hit this bug on the first post-install update, we have a bit of wiggle room to fix it with an update to grubby.
Comment 30 Fedora Update System 2011-09-29 16:52:37 EDT
grubby-8.3-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grubby-8.3-1.fc16
Comment 31 Tim Flink 2011-09-30 11:14:17 EDT
Discussed in the 2011-09-29 go/no-go meeting. Rejected as a blocker for Fedora 16 beta because although this is a problem, it only shows up at kernel updates. As long as the next kernel update requires grubby-8.3-1, things should be OK and this potential issue can be fixed with a post-beta update.
Comment 32 Fedora Update System 2011-10-02 14:13:48 EDT
grubby-8.3-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 33 Fedora Update System 2011-10-03 13:57:39 EDT
grub-0.97-79.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 34 Adam Williamson 2011-10-03 22:43:05 EDT
There is no kernel update which requires this grubby version yet; we should at least document that EFI installs should update grubby before kernel. Will try the kernel team again.
Comment 35 Adam Williamson 2011-10-04 03:30:41 EDT
added to Common Bugs as the kernel update didn't go out yet.
Comment 36 Jeff Layton 2011-10-21 15:33:01 EDT
This is apparently fixed in f16, but is still broken in rawhide (f17). Perhaps there was confusion when f16 was branched off? In any case, reopening this bug to ensure that rawhide gets the fix too.
Comment 37 Jeff Layton 2011-10-21 15:34:06 EDT
To be clear, latest package in koji for f16 is grubby-8.3-1.fc16, but for f17 it's grubby-8.2-1.fc17.
Comment 38 Adam Williamson 2011-11-07 23:38:44 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 39 Fedora End Of Life 2013-04-03 15:38:19 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 40 Akemi Yagi 2013-08-16 13:49:27 EDT
To get the patch into RHEL, would it be necessary to clone this bug? Or is this already being tracked for RHEL?
Comment 41 Glenn Johnson 2014-01-17 12:33:42 EST
I'm seeing this today with Fedora 20. I have 20 installed on /dev/sdb2 and CentOS 6.5 installed on /dev/sdb6. Fedora's grub is running the show (booting all installed OS's). There was a recent kernel update for CentOS 6.5 (kernel 2.6.32-431.3.1.el6.x86_64). After updating to this kernel I booted back to Fedora 20 and ran grub2-mkconfig so I would be able to boot into the new CentOS kernel. What I got was a kernel panic. As it turns out, there was no initrd line for the new kernel in the CentOS portion of /boot/grub2/grub.cfg. Once I added the line I was able to boot the new CentOS kernel.
Comment 42 Fedora End Of Life 2015-01-09 16:51:17 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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 this bug is closed as described in the policy above.

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 43 Adam Williamson 2015-01-09 17:01:17 EST
I'm really not sure that what Glenn wrote in c#41 is at all related to the initial bug here. pjones, do you think there's any reason to keep this open?
Comment 44 Fedora End Of Life 2015-02-18 08:35:49 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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