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.
Responding with an error makes iPXE print a misleading error message (misleading because it doesn't break the boot in any way, it just makes humans uncomfortable).
The quick commands are just aliases for the `boot` command with
various pre-cooked kernel/initrds/cmdline combinations. Currently
supported are Debian, Ubuntu, Fedora and Centos. There's also code
for Arch, but it's currently disabled as I'm failing to get the
HTTP rootfs to work.
The service file is added as documentation, rather than in the system
services directory, because it will almost certainly require customization
before it can be used.
So why bother including one at all? Because I've gone through the trouble of
figuring out the various systemd-exec security flags to lock down pixiecore
as much as possible with chroots, capabilties, syscall filters, etc. Having
that as a baseline will encourage people to run Pixiecore with maximum constraints,
even if they have to write their own ExecStart for it.
By supporting Type 9 ( „EFI x86-64“ ), pixiecore can boot VMware (Fusion) EFI-Type Machines.
The const for FirmwareEFI64 has been renamed to FirmwareEFIBC ( see RFC-4578, Section 2.1 ) and FirmwareEFI64 is assign to type 9 and uses the same ipxe blob as FirmwareEFIBC.
Signed-off-by: Mathias Kaufmann <me@stei.gr>
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.
iPXE appears to have *really* poor performance (orders of magnitude worse) if
it doesn't know the length of the kernel/initrds that it's downloading. Without
this change, booting CoreOS takes longer than I've had patience to wait. With
this change, the bottleneck becomes the network transfer speed.
Fixes#10.
pixiecore: Plumb NewSnooperConn into Server as an advanced option.
pixiecore/cli: Plumb DHCPNoBind to the CLI.
Now, by default, Pixiecore will bind() to the DHCP server port in a way
that shows up in `netstat` by default. If you want to enable the "coexist
with my existing DHCP server" mode, you need to explicitly pass
--dhcp-no-bind.
