On Wed, Jul 9, 2025, at 9:11 PM, Chris Adams wrote:
> Different Chris, but... it sounds like Windows gets a "fallback" > position for when the firmware has no boot entries; is there a way to > get Fedora into that position instead (in a dual-boot setup)? Or is it > a case of the firmware just explicitly looking for the Windows loader? I used to know these things, but it seems I have a garbage collection routine. And now the UEFI spec is > 2500 pages, which is a ... nevermind. I thought the spec used the ESP:\EFI\BOOT\BOOTX64.EFI as one of the (final) fallback locations even on whatever the term is for "not removable media" but I'm only seeing this location and the machine type short-name naming convention mentioned in 3.5.1.1 Removable Media Boot Behavior. So... *shrug* maybe this file isn't expected or mandated to do anything when it's on anything other than removable media? What I can tell you is my laptop has shimx64.efi in that location but it was not used. Windows booted instead, so I guess that location is hardwired and not exposed to the user. $ sudo sha256sum /boot/efi/EFI/BOOT/BOOTX64.EFI 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 /boot/efi/EFI/BOOT/BOOTX64.EFI $ sudo sha256sum /boot/efi/EFI/fedora/shimx64.efi 4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1 /boot/efi/EFI/fedora/shimx64.efi Whereas when I booted from the USB stick, I briefly saw blue screen with red text to the effect of doing some kind of reset, followed by the GRUB menu. What I later discovered is that this added a menu entry to NVRAM for Fedora pointing to the bootloader on that specific USB stick. UEFI 2.8 spec excerpts: 3.1.2 Load Option Processing If all entries of BootNext and BootOrder have been exhausted without success, or if the firmware has been instructed to attempt boot order recovery, the firmware must attempt boot option recovery (see Section 3.4). 3.4 Boot Option Recovery In the event that boot option recovery must be performed, the boot manager must first attempt OS- defined recovery, re-attempt normal booting via Boot#### and BootOrder variables, and finally attempt platform-defined recovery if no options have succeeded. 3.4.1 describes this in substantial detail. But after skimming all that, I realize that after resetting to defaults within the firmware's setup menu, sure if BootOrder and Boot#### entries were reset (and they seem to have been), then presumably also OSRecoveryOrder and OsRecovery#### variables are reset. At least right now there aren't any. I'm also not sure if they'd matter because the restored default BootOrder early on includes Boot0011 which points to the Boot Menu. That'll always work, but it drops the problem into the user's lap before OSRecovery would even apply. In order for OSRecovery to apply, we'd need to trim the BootOrder to make sure neither Fedora nor Windows boot success, thereby falling back to OSRecovery. I also still don't have an explanation why Windows booted at all instead of just taking me to the boot menu. It might be some kind of hard coded thing. -- Chris Murphy -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
