Bug 725185

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.

(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.

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.

(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.

can you reproduce with 'yum localinstall' rather than 'rpm'?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(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

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.

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 ...

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?

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.

whoops, i forgot, grub2 *is* default for f16, so presumably this will affect all f16 alpha clean installs.

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.

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.

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.

grub-0.97-77.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-77.fc16

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

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).

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.

*** Bug 645611 has been marked as a duplicate of this bug. ***

(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).

(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.

/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

(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).

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.

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.

(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).

grub-0.97-78.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-78.fc16

grub-0.97-79.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grub-0.97-79.fc16

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.

grubby-8.3-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/grubby-8.3-1.fc16

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.

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.

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.

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.

added to Common Bugs as the kernel update didn't go out yet.

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.

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.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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

To get the patch into RHEL, would it be necessary to clone this bug? Or is this already being tracked for RHEL?

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.

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.

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?

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.