Having re-re-read UEFI, UEFI*, and UEFI*(*), the title represents my takeaway.
I felt right at home earlier this year when I installed a Fedora for the first time ever. DnfDrake is exactly the same hideous UI I have three decades of experience with, on my SGI Indy MIPS R5000 IRIX box. The only copies of Photoshop and Illustrator I apparently actually own, are the v3 R5K SGI house-hotrodded-for-IRIX I can now only ssh -X into, on a Motif CDE which uses ELF packages and RPM. The rest of the system is SVR4 packages and pkgsrc, this is still the factory install, patched until there were no more patches. The machine has 64MB RAM and a 2GB SCSI-2 drive with proprietary SGI terminator interface, dual HDD's were not an option, this drive is now irreplaceable to the point it's why I'm afraid to power up the system, and what I really want is an SGI-branded IRIX zone so I can see how well my Adobe products work without the resource limitations imposed by hardware that was ahead of the game in its day. Closing in on 30 years of XFS without so much as a hiccup. No wonder UEFI (no-*) recommends XFS for PXE! I couldn't agree more. What UEFI has to say about ESP sizing is, "big enough for your bootloader, duh" and some fs's are OK with UEFI's 1 MiB minimum (which is half wrong). Others, fat32 and XFS included, need to support both the encrypted and unencrypted use cases. As the encryption requires 32 MiBs and unencrypted at least 1 MiB, the fs's both require a 33 MiB minimum, and this is why my advice for ESP sizing is 64 MiB, not 32 MiB or lower. UEFI* says i386 firmware, as implemented and allowed, looks for /EFI in a fat32 ESP, while allowing multiple ESPs to share a drive. UEFI*(*) supports my 320MiB (as required by whatever Fedora's installer is called) MS-DOS PXE's (label=BOOTER) fallback bootloader's loading a r/o GRUB xfs.efi driver, before scanning the other ESP (LOADER) for /EFI/boot/*.efi and doesn't care if it isn't a Windows PE binary. So, loader.efi can = loader.4th, seeing as how loader64.efi's a subset of cc which supports FICL, and *that's* what's compiled as a wrapper around loader.4th. What else is a tiny cc which covers the subset FICL requires? Zig. So, the only reason to make loader.efi have anything to do with MS-DOS is if you need to get your ticket punched for entry to Microsoft Security Theatre, which has UEFI as a dependency, but this is not reciprocal. Which means, we can solve UEFI Secure Boot *and* implement CRC to avoid the hole I blamed UEFI for falling bass-ackwards into. Because we can code that bit in Zig and configure it with 4th and have ONE unified bootloader on i386 for any # of boot scenarios involving a FICL-booted OS, *and* it's a UEFI 2+ compatible software boot manager like rEFInd. Which is the catch, making it work on i386 requires a Windows PE boot manager, but the fallback bootloader and shim.efi and all that applies to *.efi not MS-DOS. The trick I don't have time to work out, and I'm a noob with Zig who's only just begun working on "zmake config", is how to make its runtime BE the PXE. What I'm using as my test code for building zmake is lighttpd, straight-up POSIX C, and modular so I can leave out everything that isn't HTTP 1.1 pipelining and... use it to pixie-boot an OS installed in a local partition, on another system. -Eric ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tead303addea2207e-M7b20da4cd5cb2b6c07ac7564 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
