Bug 859285 - initrd is used in grub2 for efi system (initrdefi should be used)
Summary: initrd is used in grub2 for efi system (initrdefi should be used)
Alias: None
Product: Fedora
Classification: Fedora
Component: grubby
Version: 18
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F18Beta, F18BetaBlocker
TreeView+ depends on / blocked
Reported: 2012-09-21 02:17 UTC by Taylor Smock
Modified: 2013-08-06 19:49 UTC (History)
9 users (show)

Fixed In Version: grubby-8.19-1.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-10-16 22:34:28 UTC
Type: Bug

Attachments (Terms of Use)
The original grub.cfg file (5.64 KB, application/octet-stream)
2012-09-21 02:21 UTC, Taylor Smock
no flags Details
The grub.cfg file that will boot correctly (5.64 KB, application/octet-stream)
2012-09-21 02:22 UTC, Taylor Smock
no flags Details
grub.cfg from grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg before kernel update (4.78 KB, text/plain)
2012-09-27 11:17 UTC, Taylor Smock
no flags Details
grub.cfg after yum update (5.56 KB, text/plain)
2012-09-27 11:18 UTC, Taylor Smock
no flags Details

Description Taylor Smock 2012-09-21 02:17:12 UTC
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:

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.

Comment 1 Taylor Smock 2012-09-21 02:21:03 UTC
Created attachment 615222 [details]
The original grub.cfg file

grub.cfg with the initrd line (the original, before I modified it).

Comment 2 Taylor Smock 2012-09-21 02:22:08 UTC
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.

Comment 3 Mads Kiilerich 2012-09-21 08:45:57 UTC
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.

Comment 4 Taylor Smock 2012-09-21 12:59:34 UTC
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.

Comment 5 Taylor Smock 2012-09-21 14:19:29 UTC
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.)

Comment 6 Mads Kiilerich 2012-09-21 14:30:06 UTC
Right. Kernel updates are handled by grubby - it has apparently not been updated to handle linuxefi kernels correctly despite



What grubby version do you have?

Comment 7 Taylor Smock 2012-09-21 14:55:22 UTC
grubby-8.17-1.fc18 (64-bit) is the version showing in the software manager.

grubby --version
grubby version 8.17

Comment 8 Adam Williamson 2012-09-26 20:06:12 UTC
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.

Comment 9 Peter Jones 2012-09-26 21:36:16 UTC
Please test with grubby-8.19-1.fc18.

Comment 10 Taylor Smock 2012-09-27 02:10:17 UTC
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.

Comment 11 Mads Kiilerich 2012-09-27 09:04:06 UTC
(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.

Comment 12 Taylor Smock 2012-09-27 11:16:04 UTC

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

Comment 13 Taylor Smock 2012-09-27 11:17:46 UTC
Created attachment 618010 [details]
grub.cfg from grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg before kernel update

Comment 14 Taylor Smock 2012-09-27 11:18:34 UTC
Created attachment 618011 [details]
grub.cfg after yum update

Comment 15 Mads Kiilerich 2012-09-27 11:54:19 UTC
Thanks - that was convincing.

The new entry has
	echo 'Loading initial ramdisk ...'
and thus loses the initrdefi line.

Comment 16 Fedora Update System 2012-10-02 18:21:04 UTC
grubby-8.20-1.fc18 has been submitted as an update for Fedora 18.

Comment 17 Taylor Smock 2012-10-02 18:52:34 UTC
Thanks, the grubby-8.20-1.fc18 package correctly installs a newer kernel (3.6 rc2 -> 3.6 rc7).

Comment 18 Fedora Update System 2012-10-03 17:01:29 UTC
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:
then log in and leave karma (feedback).

Comment 19 Adam Williamson 2012-10-04 18:49:51 UTC
VERIFIED per comment #17, close when grubby is pushed stable.

Comment 20 Adam Williamson 2012-10-16 22:34:28 UTC
update was pushed stable on 10-13, closing.

Comment 21 Chris Murphy 2013-01-30 01:03:56 UTC
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?

Comment 22 Robert Story 2013-08-04 01:20:17 UTC
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?

Comment 23 Adam Williamson 2013-08-06 19:49:25 UTC
A new report seems best, since it's not the same bug exactly.

Note You need to log in before you can comment on or make changes to this bug.