undionly.kpxe doesn't work if you chainload from a native iPXE, but it's
required for physical machines with NICs that iPXE doesn't natively
support.
In my previous attempt to handle Virtualbox's crippled iPXE, I switched
all BIOS-based boots to use ipxe.pxe. This was a bad idea, so now instead
we specifically recognize third-party iPXE builds, and only chainload
*those* with ipxe.pxe, and stick with undionly.kpxe for the rest.
This guarantees that we load the real OS from an iPXE with a known
featureset, rather than rely on the firmware iPXEs to be correct.
Also switch to ipxe.pxe for BIOS boots instead of undionly.kpxe.
ipxe.pxe works when you chainload from one iPXE to another, whereas
undionly.kpxe encounters some kind of poorly explained bug where
it loses the ability to configure networking.
Tested against the following configurations:
- VirtualBox + BIOS w/ iPXE
- VirtualBox + BIOS w/ Intel UNDI
- VirtualBox + EFI
- KVM + SeaBIOS w/ iPXE
- KVM + OVMF (EFI)
- Dell R610 + Dell BIOS/PXE
Fixes#51, fixes#52.
Virtualbox inexplicably ships with an iPXE image that knows
how to speak HTTP, but cannot handle bzImage files. This is a
quick and dirty fix for that specific issue, while I work on
the more permanent fix of always chainloading into a known
good iPXE.
The UI is optional and need to be explicitly activated, since I
don't want existing users to suddenly have an information-spewing
thing show up on their network.
Also introduces a "Trace" member to the API, for the future addition of
extremely verbose and complete tracing, to be used for bug reports. But
for now, only Log is used.
This version is still *extremely* barebones, and the unstable tag
in the README applies triple for it, but the code in its current
state is capable of booting x86 and UEFI clients correctly, and
that was hard enough to merit a snapshot checkpoint.
