Restore the ten options f61a90d97 dropped, and gate against an eleventh

[mastacontrola]

What

Three commits:

1. Restore CONSOLE_FRAMEBUFFER on BIOS builds. This is what the forum report is about — the boot menu renders as unstyled text on a black screen on every legacy-BIOS client.
2. Restore the five remaining options an audit turned up, of which DOWNLOAD_PROTO_HTTPS on BIOS is serious breakage.
3. Add a CI gate so the next one cannot ship unnoticed.

Why the menu was plain text

CONSOLE_FRAMEBUFFER is what pulls in vesafb and fbcon, the only graphical console a BIOS build can have — EFI gets its own through efifb, which is why no amount of UEFI testing was ever going to catch this.

It fails silently rather than falling back. bootmenu.class.php emits

console --picture <booturl>/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console

and alt_console exists to catch exactly this. It never fires: with no console implementing .configure, console_configure() has nothing to hand the pixel buffer to and returns success, so the command reports success having drawn nothing. The picture is fetched over HTTP, PNG-decoded, and dropped.

The HTTPS one

Without DOWNLOAD_PROTO_HTTPS there is no https_uri_opener in the binary at all, so a legacy-BIOS client cannot fetch an https:// URL by any route.

FOG hands it one on every -S/--force-https install — the installer writes chain ${httpproto}://$ipaddress${webroot}service/ipxe/boot.php##params into default.ipxe. So on an HTTPS server every BIOS client chainloads default.ipxe over TFTP, fails to open the first https:// URL, and lands in ipxescript's "Chainloading failed" reboot loop.

Those installs are also the only ones that build from this tree instead of taking a release asset, because CERT=/TRUST= bake a per-server CA in — which is how it rode in under a commit titled "Fix iPXE compilation error for HTTPS FOG Installs".

The full audit

Comparing effective macro state per platform against the pre-f61a90d97 headers, rather than diffing the text, finds every remaining loss at once:

Option	Platform	Impact
CONSOLE_FRAMEBUFFER	BIOS	Boot menu is unstyled text
DOWNLOAD_PROTO_HTTPS	BIOS	HTTPS installs unbootable
DOWNLOAD_PROTO_FTP	both	Parity only
DOWNLOAD_PROTO_NFS	both	Parity only
NET_PROTO_LLDP	BIOS	Parity only
PXE_CMD	BIOS	Parity only

After this, effective option state matches the pre-drift headers exactly on both platforms. HTTP_AUTH_NTLM and NET_PROTO_IPV6 stay off — upstream's #undef agrees with FOG's own header on both.

The gate

tools/check-linked-objects.sh reads the linker map files after buildipxe.sh and compares the objects pulled into each shipped binary against a committed baseline. CI runs it between the build and the release step, so a tag that would publish drifted binaries fails before publishing.

The linked object list rather than the headers, deliberately: an option can be lost by a #define becoming a comment or by an #undef in a platform block hundreds of lines away, so no textual header diff tells you what the binary contains — which is how these survived people reading the headers. GH-958 was the inverse case, where the #define was absent so REQUIRE_OBJECT never fired and no console driver linked at all; an option-state audit would have called that header correct.

A diff is not automatically a bug. Bumping IPXEVER or enabling an option on purpose both move the baseline; the check exists so a human sees the move and commits it in the same PR.

Verification

• Full buildipxe.sh completes cleanly across BIOS, i386-efi, x86_64-efi and arm64-efi.
• nm on the linked BIOS binary: fbcon 0 → 18 symbols, vesafb 0 → 17. Registered URI openers go from {http, mtftp, tcp, tftm, tftp, udp, xfer} to that set plus https, ftp, nfs.
• Booted on a real legacy-BIOS PXE client: screen mode goes from 720x400 VGA text to 800x600 VESA with the FOG background rendered.
• Gate proven by reintroducing the framebuffer regression in a build tree — reports vesafb.o, fbcon.o, utf8.o removed and exits 1.
• undionly.kkpxe grows 91,079 → 101,190 bytes, almost all of it TLS.

Not verified: an end-to-end boot against an actual HTTPS FOG install (the HTTPS fix is proven at the binary level), and physical hardware rather than a VM.

🤖 Generated with Claude Code