Description of problem: When updating the F18 Alpha 1 kernel on a EFI system, initrd is used instead of initrdefi. Steps to Reproduce: 1. Install F18 Alpha 1 2. Update F18 Alpha 1 to 3.6.0-rc6 3. Reboot (fails) a) Reboot fails because initrd is used, not initrdefi. Error message is shown, saying that initrd is not a valid command. Actual results: Kernel panic if boot is continued (option to continue booting is available) Expected results: No kernel panic, boots normally. Additional info: Workaround: Modify all "initrd" commands in /boot/efi/EFI/fedora/grub.cfg to "initrdefi". The original grub commands are fine, they should not need to be modified.
Created attachment 615222 [details] The original grub.cfg file grub.cfg with the initrd line (the original, before I modified it).
Created attachment 615223 [details] The grub.cfg file that will boot correctly I modified the initrd to initrdefi in this file. This enables the computer to boot correctly. The initrd line was the only line modified.
It shouldn't be possible to get linuxefi without initrdefi. See http://pkgs.fedoraproject.org/cgit/grub2.git/tree/grub2-linuxefi.patch . Please try to hack your /etc/grub.d/10_linux and find out how that could happen.
I tried using a similar if-then-else that the 10_linux used, to see if for some reason if [ -d /sys/firmware/efi ] was giving an erroneous response after one call. The other point of failure, initrdefi ${rel_dirname}/${initrd} looks fine. I invoked the grub-mkconfig utility manually, and it worked properly. I don't have a way to invoke it automatically through an update. I'll reinstall F18 and update the kernel (and only the kernel). I'll then reinstall F18 again, and update everything at once. (This should still give me the initrd entry. Its a "control" that isn't really controlled though.) After that, I'll reinstall and update everything but the kernel, reboot, then update the kernel.
When I say kernel, I mean the kernel and the kernel-modules-extra packages. I use the Update Manager to update. Conclusion of my reinstalls: Updating only the kernel immediately after installation gives the initrdefi entry. Updating everything at once gives the initrd entry. Updating everything but the kernel, rebooting, then updating the kernel gives the initrd entry. Running grub2-mkconfig with initrd entry adds efi to initrd. (Tested with updating everything but kernel, rebooting, updating kernel, then running grub2-mkconfig.)
Right. Kernel updates are handled by grubby - it has apparently not been updated to handle linuxefi kernels correctly despite http://pkgs.fedoraproject.org/cgit/grubby.git/commit/?h=f18&id=bc96cb63c8e7b6ef8210e61fb35689fcdbbd7a9b http://git.fedorahosted.org/cgit/grubby.git/commit/?id=41f4052da0ef1c69058f42136ac8c31f1df8fcbc What grubby version do you have?
grubby-8.17-1.fc18 (64-bit) is the version showing in the software manager. From grubby --version grubby version 8.17
Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . pjones says he can see that this could be broken even with the commits Mads links, so we are accepting the report as valid. Accepted as a blocker per criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" in the case of kernel updates on UEFI installs. In theory this could be fixed outside of the release, we don't really need to fix grubby on the shipped images. We would have to fix grubby before any post-Beta kernel updates were submitted, and then make sure the kernel depended on at least that version of grubby to ensure no ordering problems. We felt that this is too likely not to be done properly, though, and the safest course is to accept this bug as a blocker. That way grubby will be fixed at Beta ship time and we're pretty safe against this problem.
Please test with grubby-8.19-1.fc18.
Since it hasn't been pushed to the updates-testing repository yet, I downloaded and installed it from the build information page (http://koji.fedoraproject.org/koji/buildinfo?buildID=356662 ). The command I ran (in case it makes a difference): rpm --replacefiles --nosignature -iv grubby-8.19-1.fc18.x86_64.rpm I then proceeded to uninstall the kernel and reinstall the kernel with the following command: yum remove kernel; yum install kernel kernel-modules-extra That got me the 3.6.0 RC7 kernel and initramfs. So, before rebooting, I did a cat on /boot/efi/EFI/fedora/grub.cfg. Now the installed kernel doesn't have an initrd or initrdefi. So I then checked to see if there was an initramfs for RC7 on /boot, and there was (initramfs-3.6.0-0.rc7.git1.4.fc18.x86_64.img). So there isn't an initrd instead of initrdefi problem anymore. In any case, I then proceeded to reboot, just in case I was misinterpreting something. It didn't have an error, and the kernel panicked. Note: If I wasn't testing correctly, please let me know of a better/preferred way to test grubby besides removing and reinstalling the kernel.
(In reply to comment #10) > rpm --replacefiles --nosignature -iv grubby-8.19-1.fc18.x86_64.rpm Why not just rpm -Uhv grubby-8.19-1.fc18.x86_64.rpm ? > yum remove kernel; yum install kernel kernel-modules-extra That removed all of your kernels. That shouldn't happen in real life and handling that is a special case in grubby. > So, before rebooting, I did a cat on /boot/efi/EFI/fedora/grub.cfg. Now the > installed kernel doesn't have an initrd or initrdefi. Probably because all kernels had been removed. Please redo the test and make sure you always have at least one kernel installed. When removing kernels then remove just one of them. You can find other kernel versions that you can use for testing in koji. Please create a new grub.cfg before installing the kernel grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg and attach the grub.cfg you had before and after.
Ok for the rpm command, I rarely use so I had to use the man pages. Now for my command set: yum remove kernel-3.6.0-0.rc7.git1.4.fc18 #this leaves rc2 ls /boot | grep rc2 #outputs the following: # config-3.6.0-0.rc2.git2.1.fc18.x86_64 # initramfs-3.6.0-0.rc2.git2.1.fc18.x86_64.img # System.map-3.6.0-0.rc2.git2.1.fc18.x86_64 # vmlinuz-3.6.0-0.rc2.git2.1.fc18.x86_64 grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg cp /boot/efi/EFI/fedora/grub.cfg /home/grubBefore.cfg yum update #Updates the kernel from rc2 to rc7 cp /boot/efi/EFI/fedora/grub.cfg /home/grubAfter.cfg #not asked for grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg cp /boot/efi/EFI/fedora/grub.cfg /home/grubCheck.cfg
Created attachment 618010 [details] grub.cfg from grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg before kernel update
Created attachment 618011 [details] grub.cfg after yum update
Thanks - that was convincing. The new entry has echo 'Loading initial ramdisk ...' } and thus loses the initrdefi line.
grubby-8.20-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/grubby-8.20-1.fc18
Thanks, the grubby-8.20-1.fc18 package correctly installs a newer kernel (3.6 rc2 -> 3.6 rc7).
Package grubby-8.20-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing grubby-8.20-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-15272/grubby-8.20-1.fc18 then log in and leave karma (feedback).
VERIFIED per comment #17, close when grubby is pushed stable.
update was pushed stable on 10-13, closing.
With grubby-8.22-1.fc18, if the grub.cfg is located in /boot/grub2 on EFI hardware, I get a grub.cfg using linuxefi and initrd, and then a kernel panic. Shouldn't grubby consistently use both linuxefi and initrdefi on EFI hardware, regardless of the location of the grub.cfg?
i too am seeing this with every new kernel update on f18, grubby-8.22-1. Can this be re-opened, or should we file a new bug?
A new report seems best, since it's not the same bug exactly.