On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw <hobbes1069(a)gmail.com> wrote:
While I had to run it through the shredder I finally sat down and went through all the
passwords I've ever used and figured it out :)
I turned off Secure Boot but it still won't boot Fedora.
I finally figured out I had to use -v to get what I wanted from efibootmgr:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 000E,0001,0003,2001,2002,2003
Offhand, this looks like the problem. 000E points to Windows. You need
to use `efibootmgr --bootorder 0,E,1` so it boots Fedora first. It's
not strictly necessary to list everything in bootorder, you can just
have one. The idea of populating it fully is to have exactly the
predictable fallback boot behavior the user wants, whatever that is.
e.g. if something with the Fedora bootloader gets nerfed then it'd
boot Windows.
Boot0000* Fedora
HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shimx64.efi)
Offhand, looks valid but I can't vouch for either the partition number
or its GUID.
Boot0001* Linpus lite
HD(1,MBR,0x7c3f77cf,0x1c7e4,0x4df8)/File(\EFI\Boot\grubx64.efi)RC
Boot0002* Unknown Device:
HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC
Boot0003* Fedora
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0,0,0)/HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\grubx64.efi)A01
..
Boot0004* Unknown Device:
HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC
I would use efibootmgr to delete these, they look either suboptimal
(unknown device) or use old paths to grub rather than shim.
If you're not sure you can delete them all, and then do:
# grep efibootmgr /var/log/anaconda/program.log
And you'll see the longest command there is what's used to add the
menu entry. You can just use the same command, although you'll need to
escape the backslashes with backslashes, so the path becomes
\\efi\\fedora\\shimx64.efi
Also, firmware password and UEFI Secure Boot are two different things.
Secure Boot I don't recommend disabling, it's a feature that
cryptographically verifies the bootloaders, the kernel and kernel
modules. If you're building out of tree kernel modules, then it's
understandable to run without Secure Boot but I would still go through
the effort to create your own signing cert, register it in the
firmware, and then use it to sign your modules so that you can enable
secure boot.
--
Chris Murphy