In my honest opinion (I could be wrong, but anyway), what I want should be
pretty simple:
boot - in UEFI mode - a bootloader from a FAT32 ESP, which in turn would execute
the extlinux boot sector of a second partition.
Both partitions being physically located on the same disk / media.
I don't see any reason why this should be quaternionic quantum physics...
I honestly have no idea so far what PXE is, I never used it, never needed it,
never even read about it.
And this is all the more painful when I actually managed to achieve one big
impossible step on the ladder to my goal:
Although I was told by the technical support for my 64-bit motherboard that this
is not supported, I successfully booted Syslinux in pure UEFI mode from an ESP
partition located on an MBR-partitioned disk !!!!
Regarding the development of Syslinux, I'm not sure what to believe. If you
look on the Debian Snapshot website, you will find a lot of versions released
after 2014.
The last one is "syslinux 3:6.04~git20190206.bf6db5b4+dfsg1-3.1",
released on 2025-04-13, so it seems to me that actually someone did keep working
on it all this time.
Aside from that, check out the last Knoppix release, 9.3.
That ISO uses isolinux and UEFI, so somehow this guy managed to handle the
secret about Syslinux and UEFI, meaning Syslinux+UEFI is actually quite possible
today.
You just have to discover the secret method...
CoBra, cobrasov.com
On 07/01/2025 02:11 AM, Frantisek Rysanek wrote:> Respect to your sorrow, my brother in faith...
> I myself have been a long-time fan of Syslinux, and HPA will forever
> be my hero.
>
> That said - note that the development of Syslinux has stalled...
> approaching a decade ago, and in my experience, never quite made it
> to UEFI.
>
> For PXE-booting UEFI x86 machines, I've been using iPXE happily for
> years.
> https://ipxe.org/
> Note that iPXE can be loaded via DHCP+TFTP just like pxelinux.
> (Never mind the original way, where you would need to burn the iPXE
> option ROM into your NIC or implant it in your system BIOS.)
>
> For UEFI booting from local media, take a look at rEFInd.
> https://www.rodsbooks.com/refind/
> Its docs will guide you through the basics of how to partition the
> disk and what the required directory structure is, for UEFI to find
> your "bootable UEFI payload" on your disk. It's not hard.
> From there, you should find it relatively obvious, how to create a
> disk drive that boots Linux in legacy BIOS/MBR mode or UEFI mode.
>
> In the end, to boot Linux via UEFI, you may use rEFInd, or proceed to
> just use Grub and its UEFI support...
>
> Note that the "chainloading paths" are pretty much separate, for
> legacy BIOS/MBR mode vs. UEFI mode. The API's required and offered by
> the BIOS/Firmware are just very different / disjunct for each
> variant. The two different boot paths only meet again once you get
> the Linux kernel loaded and started.
>
> In principle:
> - the legacy BIOS won't allow you to start any UEFI binary.
> - and, the UEFI "firmware" looks for a UEFI binary to start, at a
> well-known path, with a well-known name. UEFI binaries are similar to
> Win32 EXE, only expecting a different "system API" (the UEFI
> services). That "first stage loader" UEFI binary is then allowed
to
> chainload or "exec()" further UEFI binaries: can be a Windows
loader,
> or the Linux shim, or the UEFI shell, or memtest, or whatever have
> you. Over the last few years, the UEFI64 ecosystem has become fairly
> stable and debugged...
>
> Traditionally / for a long time the rule has been, that you
> categorically cannot boot a legacy OS (such as DOS) on a UEFI-only
> machine.
> Recently, the CSMwrap project has allowed this to happen again.
> https://github.com/FlyGoat/CSMWrap
> Yet, it doesn't run on just *any* machine. On some machines it
won't
> work at all. Or, you may be limited by the set of legacy BIOS-era
> hardware actually still present in your modern machine.
> CSMWrap provides some key legacy BIOS services, but is not a complete
> emulator of potentially missing legacy hardware.
>
> Frank
>