Bug 857523
| Summary: | Removal of /boot/grub/splash.xpm.gz causes grub errors on UEFI systems | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Flink <tflink> |
| Component: | fedora-logos | Assignee: | Tom "spot" Callaway <tcallawa> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | awilliam, kparal, mads, tcallawa |
| Target Milestone: | --- | Keywords: | CommonBugs |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F18_bugs#grub-upgrade-uefi | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-11-29 02:00:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
*** Bug 879345 has been marked as a duplicate of this bug. *** 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? 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. (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. 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. 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 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. (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. (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. (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. (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. 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? (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 (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. (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. (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." |
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