On Sat, Apr 27, 2019 at 5:46 PM Chris Murphy <li...@colorremedies.com> wrote:
> On Wed, Apr 24, 2019 at 5:24 PM Richard Shaw <hobbes1...@gmail.com> wrote: > > On Wed, Apr 24, 2019 at 5:35 PM Chris Murphy <li...@colorremedies.com> > wrote: > >> On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw <hobbes1...@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. > > > > > > I'm pressing F12 and manually selecting Fedora, but I did later try to > change the boot order, both with efibootmgr and in the BIOS to no avail. > > OK you changed the bootorder using 'efibootmgr --bootorder' and you > got what result from that command? Whether it works or doesn't, it > returns a result that might be useful. And then you can confirm it > with 'efibootmgr -v' and that also would be useful. And whenever there > are unexplained results, I like to look at dmesg right before and > after running efibootmgr (or use journalctl -f in another shell) to > see if there are any kernel messages at the time. Ultimately the NVRAM > is modified by the kernel, and efibootmgr is just the user interface > to those kernel ioctls that do the actual modification of NVRAM. > The boot order showed as changed (no error) and as far as I know it remained after rebooting. It was just not working right and moved on to the Windows Boot Manager > Also, there's a bunch of bugs in this area, so I suggest making sure > the firmware is up to date. I've seen all kinds of weird garbage > collection issues where entries don't get deleted, or even bootorder > not sticking, or bootnext not getting set. > What's weird is that the exact same laptop was working fine dual booting before the HD crash. I restored using the same Window (factory USB) restore stick. The only difference I can think of is that I MIGHT have installed Fedora 28 on it. > >> 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. > > > > > > I disabled it to remove it as the problem, still won't boot Fedora. Once > I get it working I can mark the efi file (presumably shimx64.efi) as > trusted and re-enable. > > There should be no need to mark any of the Fedora bootloaders, > shimx64.efi or grubx64.efi, as trusted. The shimx64.efi file is signed > by both Microsoft and Fedora, the computer firmware should have in its > database the Microsoft UEFI X.509 cert, and therefore will trust > shimx64.efi. And shimx64.efi provides the firmware with the Fedora > X.509 cert so that the firmware will trust grubx64.efi and the kernel > and kernel modules, all of which are signed by Fedora's signing key. > If you have to do something special to get the firmware to trust any > of these things, and you're not compiling your own binaries somewhere > somehow, then something's wrong - and that needs to be figured out. > Well, I "fixed" it but I can't say exactly why it works... On a whim I re-enabled Secure Boot and then set shimx64.efi as trusted, which actually created a new EFI entry (Fedora2) and it works! The only difference I can see is that the entry I setup through the BIOS uses the PciRoot(...) method instead of HD(...). Thanks, Richard
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
