On Apr 8, 2014, at 4:29 PM, Andrew Lutomirski <l...@mit.edu> wrote: > > $ sudo efibootmgr -v [snip] > Boot0003* grub > HD(1,800,40000,75f192ff-2a82-4e4e-b83c-c41f3bb39847)File(\EFI\grub\grubx64.efi)
Option A: This entry is correct if you aren't using UEFI Secure Boot, and you're using a grub2-install produced grubx64.efi/core.img, and you realize it points to /boot/grub2/grub.cfg. Option B: You need to remove the entry if you're going to revert or change to the Fedora 18-20 way of doing this with the prebaked grubx64.efi in grub2-efi package. Delete this entry with this efibootmgr -b 0003 -B You need to install or reinstall grub2-efi and shim packages. You need to write a new NVRAM entry pointing to shim.efi, and realize this grubx64.efi points to /boot/efi/EFI/fedora/grub.cfg. > I can't fix it because any attempt to > change my efi variables results in an OOPS. I can't report the OOPS > with abrt because of a correct but inconsequential kernel taint due to > #906568, which is probably fixed in 3.14. So I was going to wait for > the 3.14 rebase or perhaps boot a custom kernel to see what helps. I > haven't had time for that yet. Make sure the firmware is up to date. And if with 3.14 and current firmware you still get an oops when modifying NVRAM entries you'll want to file a bug against the kernel. If it were me I'd file both on kernel.org and redhat.com bugzillas with the proper cross-referencing. It may still end up being a firmware problem that the kernel folks can't do anything about, but to have a chance of it being fixed kernel side requires a bug > >> 2. Do you have a /boot/efi/EFI/fedora/grub.cfg ? > > No. But I have a /boot/efi/EFI/redhat/grub.conf, attached. > /etc/grub.conf is a symlink to it. That's what grub legacy EFI used. I forget if fedup upgrades grub on UEFI systems. > > The immediate cause of my need to reconfigure the bootloader was that > I changed hard disks. Imaging the partition table and fs superblocks > directly causes all manner of problems because the UUIDs will be the > same if I have both disks in the machine at the same time. So I > copied files, and at first all I got was a grub prompt. It's not finding the grub.cfg possibly because it's a grub2-install grubx64.efi which looks to /boot/grub2/fedora but you don't have a grub.cfg there. > > It's currently mostly working, modulo the efibootbgr issue. But I > don't actually know what to type into efibootmgr to fix it, the OOPS > notwithstanding. I can probably figure it out once the OOPS is fixed. Strictly speaking you don't need to point UEFI non-Secure Boot computer to shim.efi, you can just leave it alone and put a grub.cfg in the proper place. At the grub prompt if you type set you should see either config_directory= and prefix= to show where it's looking for the grub.cfg. > or, even better, if anaconda's bootloader > installation process were factored out into a command I could run. I don't understand what this means. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
