Created attachment 662146 [details] grub2-install.log Description of problem: grub2-install will install grubx64.efi with hardcoded (,gpt2)/grub2 as the prefix. After reboot, grubx64.efi can't find its grub.cfg and falls back into rescue shell. Despite whether there is a legitimate use case of grub2-install on UEFI F18, grub2-install could avoid doing harm when the user hasn't updated their expectation of bootloder installation. Version-Release number of selected component (if applicable): F18 Beta grub2-tools-2.00-12.fc18.x86_64 grub2-efi-2.00-12.fc18.x86_64 How reproducible: Reproduced on IBM x3550 M3 and QEMU VMs (all UEFI). Steps to Reproduce: 1. A standard pxeboot installation on a UEFI system. 2. sh -x grub2-install /dev/sda >grub2-install.log 3. reboot Actual results: [root@localhost ~]# grep -ao .,gpt.. /boot/efi/EFI/fedora/grubx64.efi (,gpt2) (reboot, and fall into rescue shell) grub> echo $prefix (hd0,gpt2)/grub2 Expected results: grub2-install uses correct prefix for grubx64.efi. Or grub2-install fails gracefully and points user to proper method of UEFI bootloader installation. Additional info: Disk layout: sda 8:0 0 16G 0 disk ├─sda1 8:1 0 200M 0 part /boot/efi ├─sda2 8:2 0 500M 0 part /boot └─sda3 8:3 0 15.3G 0 part ├─fedora-swap (dm-0) 253:0 0 4G 0 lvm [SWAP] └─fedora-root (dm-1) 253:1 0 11.4G 0 lvm / A temporary workaround: grub> configfile (hd0,gpt1)/efi/fedora/grub.cfg
I don't see any bug here. grub2-install will do what upstream intended it to do (considering the grub2 name mangling): install the boot loader where it has to be and everything else in /boot/grub2. If you run grub2-install on an EFI system then you have to create /boot/grub2/grub.cfg, if you use the signed efi then you have to create /boot/efi/EFI/fedora/grub.cfg. The real "bug" (which is a design decision) is that the signed efi use a non-standard $prefix. Besides that: Don't specify a destination for grub2-install on EFI systems. It will use ESP mounted on /boot/efi.
Yes, grub2-install's grubx64.efi uses /boot/grub2/grub.cfg and grub2-efi's grubx64.efi uses /boot/efi/EFI/fedora/grub.cfg. They are two different things. I should have distinguished them. Meanwhile, it will help if the design decision of file hierarchy change in efi grub2 from standard grub2 is documented. Feel free to close this if there is no more question.
This looks most pertinent to the Secure Boot guide. I've CC'd the guide author to advise.
1) After upgrading to Fedora 19 and making some partition changes, I ran grub2-install on an EFI laptop. The system would not boot, it put me in a grub shell. 2) To recover I had to point to the correct grub config file: a) In the grub shell: configfile (hd0,gpt1)/EFI/Fedora/grub.cfg b) To fix permanently: yum reinstall grub2-efi Looks like grub2-install points at the wrong config file when EFI is involved. grub2-efi-2.00-23.fc19.x86_64 grub2-tools-2.00-23.fc19.x86_64 3) After recovering I was looking at the Fedora documentation and came across: a) https://fedoraproject.org/wiki/GRUB_2#Updating_GRUB_2_configuration_on_UEFI_systems ---------------------------------------- The active bootloader will be updated immediately when the grub2-efi package is updated. It doesn't depend on running grub2-install and there is no fallback if a bad grub2-efi update is released. ---------------------------------------- => Perhaps explicitly state that grub2-install MUST NOT be run. b) https://fedoraproject.org/wiki/FedUp#Updating_GRUB_.28UEFI_systems.29 => Perhaps also explicitly state that grub2-install MUST NOT be run. 4) In the long run, grub2-install should check if it is an EFI system and point to the relevant config file.
Took me a while to resolve this problem after running 'grub2-install', thinking it would solve some other booting problems I was having. I expect grub-install to fix boot problems, not make them worse. I think it would be worth putting a wrapper around grub2-install to check this so that people don't run into this problem. Something like: "Are you sure you want to replace the boot file /boot/efi/EFI/fedora/grubx64.efi? This appears to have been customised for your distribution. Press Y to continue."
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.
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.