Bug 857523 - Removal of /boot/grub/splash.xpm.gz causes grub errors on UEFI systems
Removal of /boot/grub/splash.xpm.gz causes grub errors on UEFI systems
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fedora-logos (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 879345 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-14 13:33 EDT by Tim Flink
Modified: 2012-11-29 18:03 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-28 21:00:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tim Flink 2012-09-14 13:33:30 EDT
Description of problem:
The file /boot/grub/splash.xpm.gz was removed from fedora-logos in fedora-logos-16.0.2-2.fc16 but the file is still referenced by grub-efi on UEFI systems.

Once the file is removed, there are grub errors on boot:

grub_open("hd(1,1)/grub/splash.xpm.gz") failed
Press any key to enter the menu

Version-Release number of selected component (if applicable):
fedora-logos-16.0.2-2.fc16

How reproducible:
Every Time

Steps to Reproduce:
1. Install fedora-logos-16.0.2-2.fc16 from updates-testing on a UEFI system
2. Reboot
  
Actual results:
Error message on boot

Expected results:
Grub splash behind menu, no error messages

Additional info:
This will also affect F17 since /boot/grub/splash.xpm.gz was removed in fedora-logos-17.0.2-6.fc17

This will not affect F18 because grub-efi is no longer being used for EFI systems
Comment 1 Kamil Páral 2012-11-22 11:31:19 EST
*** Bug 879345 has been marked as a duplicate of this bug. ***
Comment 2 Kamil Páral 2012-11-22 11:36:05 EST
See bug 879345, this also concerns F17 -> F18 upgrades. I believe we shouldn't knowingly break boot menu for users, can we please do something about it?
Comment 3 Tim Flink 2012-11-22 12:26:18 EST
The problem with this is the transition from grub-efi (based on grub1) and grub2 in F18. The installed bootloader is not upgraded during the upgrade process so while a fresh F18 install on an EFI machine will be using grub2, an upgraded F17 machine will still be using grub1 until the user upgrades the bootloader manually.

I filed a bug about this (see https://bugzilla.redhat.com/show_bug.cgi?id=873455) but my impression was that there would be no grub installation update during upgrade. I wasn't thinking about the grub1 -> grub2 UEFI change at the time. I will update that bug with the question of what the best thing is to do.

For now, I think that the best thing to do would be to document the problem and be better about telling people what to expect.
Comment 4 Mads Kiilerich 2012-11-26 16:22:55 EST
(In reply to comment #3)
> an upgraded F17 machine will still be using grub1 until the user upgrades
> the bootloader manually.
...
> For now, I think that the best thing to do would be to document the problem
> and be better about telling people what to expect.

If the documentation includes a description of how to upgrade to grub2 then keep in mind that /etc/default/grub perhaps should be created, that grub2-mkconfig must be run to create a grub.cfg the right place, and that f18 systems also need shim.
Comment 5 Adam Williamson 2012-11-27 04:48:04 EST
Tim, can you add this to CommonBugs? i'd do it, but I'm not clear whether the error is fatal, or what the procedure would be to workaround / fix the bug.
Comment 6 Kamil Páral 2012-11-27 07:10:43 EST
Mads, I have no extensive grub knowledge. Would you be so kind and document here or on the wiki [1] the detailed steps required to fix the problem (probably how to upgrade to grub2-efi). Or if we do we have such documentation somewhere, could you link it here? Thanks.

[1] https://fedoraproject.org/wiki/Common_F18_bugs#grub-upgrade-uefi
Comment 7 Mads Kiilerich 2012-11-28 20:39:01 EST
I wrote something on https://fedoraproject.org/wiki/FedUp#Updating_GRUB_.28UEFI_systems.29 . But I do consider it essential that the "system version upgrade tool" (fedup these days?) always and automatically reinstalls the bootloader when upgrading the system.
Comment 8 Tim Flink 2012-11-28 21:00:04 EST
(In reply to comment #7)
> I wrote something on
> https://fedoraproject.org/wiki/FedUp#Updating_GRUB_.28UEFI_systems.29 . But
> I do consider it essential that the "system version upgrade tool" (fedup
> these days?) always and automatically reinstalls the bootloader when
> upgrading the system.

This may be true but this is rather orthoganal to the bug report here which is about the removal of the splash used for grub-efi. grub-efi is no longer being used on F18 systems and the only problems with removing the splash is on upgrade from F17 to F18 on initial reboot before upgrading to grub2-efi.

Upgrading the bootloader during upgrade is part of #873455 so let's keep discussing there. I don't think anyone is saying that fedup shouldn't upgrade the bootloader but someone needs to write the code in a way that makes it safe for unattended usage.
Comment 9 Kamil Páral 2012-11-29 05:06:01 EST
(In reply to comment #7)
> I wrote something on
> https://fedoraproject.org/wiki/FedUp#Updating_GRUB_.28UEFI_systems.29 .

I tried that, but it throws me into a grub command line prompt. I think it is because grub2 wasn't configured and installed into MBR, just installed as a package. I can still use the old entry (also named 'Fedora') to boot into the grub-efi bootloader.

Which is actually my second remark, I think we should not create another option named Fedora, but modify the previous one.
Comment 10 Tim Flink 2012-11-29 08:59:07 EST
(In reply to comment #9)
> (In reply to comment #7)
> > I wrote something on
> > https://fedoraproject.org/wiki/FedUp#Updating_GRUB_.28UEFI_systems.29 .
> 
> I tried that, but it throws me into a grub command line prompt. I think it
> is because grub2 wasn't configured and installed into MBR, just installed as
> a package. I can still use the old entry (also named 'Fedora') to boot into
> the grub-efi bootloader.

I'm a little confused here - grub isn't installed into the MBR on an EFI system AFAIK. It just lives on an EFI partition that is pointed to by the boot entry. Unless you delete the /boot/efi/EFI/redhat directory, you will still be able to boot that entry.

One problem might be with the documentation - I assume that you did proper substitutions for X and Y in those docs? Do you still have the efibootmgr command you used?

> Which is actually my second remark, I think we should not create another
> option named Fedora, but modify the previous one.

I suppose that I could add a command to remove the boot entry. Hadn't really thought about that but you do have a point.
Comment 11 Mads Kiilerich 2012-11-29 10:12:15 EST
(In reply to comment #7)
> I wrote something on
> https://fedoraproject.org/wiki/FedUp#Updating_GRUB_.28UEFI_systems.29 .

Sorry, it was late and I posted the wrong URL. It should have been https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems . The descriptions should perhaps be merged ... or at least learn from each other.

My testing in a custom environment shows that shim works - it is just not "secure". I suggest using it anyway so we get used to using these components and use the right paths.

I suggest installing shim and let efibootmgr point at \EFI\fedora\shim.efi . It will then invoke grubx64.efi.

If you just get a command line then verify that grub.cfg is created correctly. If you just did what is on the FedUp page then I assume that is the problem.

The grub2 command 'set' can also give some hints what is going on, perhaps in combination with the output of the 'blkid' linux command.
Comment 12 Kamil Páral 2012-11-29 17:15:48 EST
I can't access the system now, but I assume my problem was caused by the fact that I didn't run grub2-mkconfig (it's not mentioned in the FedUp link), therefore no grub.cfg was created, therefore I ended up in grub interactive console mode (and I confused it with MBR, sorry).
Another issue is that /etc/default/grub does not exist after installing grub2-efi, won't that preclude running grub2-mkconfig command?
Comment 13 Tim Flink 2012-11-29 17:26:14 EST
(In reply to comment #12)
> I can't access the system now, but I assume my problem was caused by the
> fact that I didn't run grub2-mkconfig (it's not mentioned in the FedUp
> link), therefore no grub.cfg was created, therefore I ended up in grub
> interactive console mode (and I confused it with MBR, sorry).

That's weird. I know I wrote those instructions yesterday but they are indeed missing. I must have forgotten to hit "save" after preview but I'll fix that now.

> Another issue is that /etc/default/grub does not exist after installing
> grub2-efi, won't that preclude running grub2-mkconfig command?

The instructions are also supposed to involve symlinking /boot/efi/EFI/fedora/grub.cfg with /etc/grub2.cfg but I'm not sure that'll get around the lack of /etc/default/grub
Comment 14 Mads Kiilerich 2012-11-29 17:44:23 EST
(In reply to comment #13)
> The instructions are also supposed to involve symlinking
> /boot/efi/EFI/fedora/grub.cfg with /etc/grub2.cfg 

???

No, don't touch /etc/grub2*.cfg. grub2 (bios) and grub2-efi will use different grub.cfg.

grub2-efi ships /etc/grub2-efi.cfg which points at ../boot/efi/EFI/fedora/grub.cfg . 

> but I'm not sure that'll
> get around the lack of /etc/default/grub

You should be fine without /etc/default/grub. It is mainly cosmetics.
Comment 15 Mads Kiilerich 2012-11-29 18:01:19 EST
(In reply to comment #12)
> Another issue is that /etc/default/grub does not exist after installing
> grub2-efi, won't that preclude running grub2-mkconfig command?

That file is created by anaconda. The grub2 rpms used to provide a default  / fallback, but the maintainer dropped it a year ago.
Comment 16 Tim Flink 2012-11-29 18:03:03 EST
(In reply to comment #14)
> (In reply to comment #13)
> > The instructions are also supposed to involve symlinking
> > /boot/efi/EFI/fedora/grub.cfg with /etc/grub2.cfg 
> 
> ???
> 
> No, don't touch /etc/grub2*.cfg. grub2 (bios) and grub2-efi will use
> different grub.cfg.
> 
> grub2-efi ships /etc/grub2-efi.cfg which points at
> ../boot/efi/EFI/fedora/grub.cfg . 

Ha, I mistyped the instructions I was forwarded (originally from pjones). My bad.

The instructions I have read:

"The process is actually pretty simple:

yum install grub2-efi
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
ln -sf /boot/efi/EFI/fedora/grub.cfg /etc/grub2-efi.cfg

And that should have you at a place where everything is working."

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