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.
The feature is heavily laced with warnings and a complete lack of
promises around future compatibility. But within those parameters,
it might allow some people to do cool things.
Fixes#60.
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.
Vars declared via the ENV mechanism will also be present at run time, polluting
somewhat the environment. Since both PIXIECORE_{SANDBOX,CONTEXT} are only
needed at build time, using the ARG form is a cleaner solution.
See ¹ for reference.
¹: https://docs.docker.com/engine/reference/builder/#arg
Although it looks like the sequencing of writing bs to the socket
and reusing the slice for the read test is guaranteed by there being
a receive from the socket in between, the race detector disagrees, and
found a race.
Stages and matrices are just 100% incompatible. Stick to doing the
matrix-y stuff in the first (default, implicit) stage, stay far
away from it for the other stages.
It looks like stages *combine* with the top-level stage, rather than
replacing it. So, the first stage will be "test", and will run the
top-level commands no matter what. Based on that, let's try to have
our old script as the top-level thing, but have it only run tests
when GOARCH=amd64. Other architectures will just build and vet/lint.
