Delete the vendored source under `thirds_party/ipxe` and replace it with a
submodule reference to https://github.com/ipxe/ipxe.git at commit
8f1514a00450119b04b08642c55aa674bdf5a4ef a.k.a. tag `v1.20.1` a.k.a. the latest
release as of this writing.
Edit `Makefile` to change the rule body of the `update-ipxe` target:
* Discover the full path of `pixiecore/boot.ipxe`; i.e., the `EMBED` script
given to the `ipxe` build.
* Use `$(MAKE) -C` instead of subshelled `cd`.
* Leave the four built ipxe binaries where they are built.
* Change the `go-bindata` to operate on the four files (instead of the
directory that contains them), write to `out/ipxe/bindata.go` (instead of
`third_party/ipxe/ipxe-bin.go`), and lose the `-prefix`.
Edit `cmd/pixiecore/main.go` use the new `ipxe` import path and reference the
binaries by the longer, un-prefixed path keys.
Add `out/ipxe/bindata.go`, the thing generated by `go-bindata`. Yeah, we
shouldn't source-control that which we can generate, but...
* `ipxe` builds are not reproducible (yet)
* building those four binaries takes a appreciable amount of time
* we can avoid a build-time dependency on `go-bindata`
Remove `third_party/Makefile` because it looks like dead code. At any rate, it
seems this patch obviates everything it may have done.
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.
iPXE has an annoying race condition where it sometimes doesn't notice
the ProxyDHCP response when booting, and fails. So we embed a boot
script in the builtin iPXE binaries that implements the retry loop
recommended in the documentation. Empirically, this has resolved
flaky boots on my test machine, usually no more than a single
retry is needed.
