You are not logged in.
Pages: 1
As I wrote here https://bbs.archlinux.org/viewtopic.php … 8#p2220788:
In https://wiki.archlinux.org/title/Unified_kernel_image:
It's possible to UKI to efi/boot/bootx64.efi (bootia32.efi for 32-bit BIOS UEFI) in the ESP, instead of EFI/Linux/arch-linux.efi or other, in general efi/boot/bootx64.efi (& bootia32.efi) in the ESP is auto detected by the BIOS UEFI (not legacy: MBR & PBR), directly available to boot, no need to create a boot entry by efibootmgr or a boot loader.
Strange there isn't it, archlinux-2025.01.01-x86_64.iso contains EFI/BOOT/BOOTx64.EFI (why all caps except x?) & EFI/BOOT/BOOTIA32.EFI.
In https://wiki.archlinux.org/title/EFI_boot_stub:
If a boot entry is created by efibootmgr then the ESP is unplugged from the PC then the PC boots, the boot entry is deleted (at least for my PC).
Last edited by jebez (Yesterday 12:12:28)
Offline
Both of these things are inherent specialties of how UEFI works -- and are not specific and have no direct relation to UKIs -- and are explained in the general UEFI article: https://wiki.archlinux.org/title/Unifie … ble_drives https://wiki.archlinux.org/title/Unifie … nced_drive
Technically case doesn't matter on FAT but it's a pseudoconvention to use BOOTx64.EFI. BOOTIA32.EFI is for 32bit UEFI systems... you're hard pressed to find these outside of 10 year old netbooks, but this has nothing to do with the processor bitness, it's possible to have a 32bit UEFI but a 64bit capable processor.
Last edited by V1del (Yesterday 10:58:01)
Online
OK i edited my 1st post thanks.
The 1st thing:
Yes there's https://wiki.archlinux.org/title/Unifie … ble_drives but it's not explicit for the beginner (like me before), it would be nice to add this trick, I did it it works.
The 2nd thing:
So like "Warning" then a link to https://wiki.archlinux.org/title/Unifie … nced_drive.
Last edited by jebez (Yesterday 11:37:13)
Offline
the uefi spec defines \EFI\BOOT\ specifically for removable media and states that fixed media have a boot entry set in the nvram
booting fixed media this way by abusing \EFI\BOOT\ as fallback should be seen as a de-facto only but it's not required by spec - it working at all is more likely due to sharing the same code for removable media and it may be simpler to just scan all devices rather to check it only on removable but not on fixed media
"disappearing" entries are also quite common as many implementations check if an entry is valid and either hide or delete them when the drive is removed - but this highly implementation dependet
all caps vs all lower vs mixed: as the filesystem is set to be fat32 it doesn't matter as it's case-insensitive - the spec explicitly calls it all caps BOOTX64.EFI - but writing it x64 with a lower case x is way more common - likely due to be equal to x64 and x86-64 which are pretty much always are written with a lower case x - at least I've never seen it written with an upper case X
so, not mentioned an UKI possible at /efi/boot/bootx64.efi or other points are reasonable because they are not specific to uki itself but rather to uefi in general and hence should be mentioned there with a reference to the uefi spec
Offline
it's a pseudoconvention to use BOOTx64.EFI
the spec explicitly calls it all caps BOOTX64.EFI - but writing it x64 with a lower case x is way more common
The lower case "x" in BOOTx64.EFI is not just a random convention, it's explicitly spelt like that in the UEFI specification. Though it's true that it does not matter for the case insensitive FAT file system family.
Offline
seems the spec is a bit non-consistent about the X vs x as at other points it's explicit selled with an upper case X
thiy could lead to issues when additional file system drivers for case-sensitive FS
Offline
thiy could lead to issues when additional file system drivers for case-sensitive FS
But we're talking about the fallback path, which would only ever be used directly by the firmware, not after external drivers are loaded.
Offline
Pages: 1