On Sat, Apr 27, 2019 at 5:46 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
On Wed, Apr 24, 2019 at 5:24 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
> On Wed, Apr 24, 2019 at 5:35 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>> On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw <hobbes1069@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
