Dependency cleanup (ponytail audit):
- Drop 14 unused dependency declarations across 7 crates; quick-xml and
x509-parser leave the tree entirely (SAML cert/XML work is handled by
bergshamra + roxmltree).
Fixes:
- introspect: drop the over-broad "microsoft" UTF-16 bulk-scan marker that
mislabeled Secure-Boot-signed non-Windows bootables (memtest86, signed
BSDs, firmware tools) as Windows — the string lives in their MS-signed
EFI loader's FAT long-filename entries. INTROSPECT_REV 3 -> 4 re-probes
existing local ISOs on startup so the bogus label clears on upgrade.
- upload: begin_upload now reclaims an abandoned <id>.partial instead of
rejecting the re-upload with "already uploading". Robust against browser
refresh, tab close, and dropped connections (the chunked protocol can't
resume a dead session anyway).
Features:
- Storage upload: multi-file + concurrent. Each dropped/selected .iso gets
its own progress row and uploads independently; a single page-leave guard
plus a pagehide keepalive-abort replace the old shared singletons.
- Operator API key (x-api-key): a persisted key authenticates /api/* exactly
like an operator session, for Postman/scripts. New core ApiKeyStore
(generated on first run, regenerable), accepted in require_auth alongside
the session cookie, surfaced in Settings -> Advanced with copy + regenerate
and a usage reference. GET /api/api-key + POST /api/api-key/regenerate.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Answers the operational question 'can a machine try all three boot
binaries in one go?' The protocol can't carry three NBPs in one cycle
(one boot file per DHCP round, the Secure-Boot refusal happens after
handoff with no error report, and the broken-NIC case specifically needs
the firmware itself to load builtin-driver iPXE — GRUB's network rides
the same broken firmware stack). What we CAN do is make the walk a
once-per-machine-ever event and give operators a way to skip it:
- Learned driver modes persist (<work_dir>/driver_modes.json). A MAC
that reaches the Shim rung, or confirms an iPXE handoff at Builtin,
is pinned to disk: immune to the 30-min TTL, reloaded at startup.
The file only carries exceptions — a healthy fleet never writes it.
Corrupt file starts empty (standard crash-cache policy).
- Boot rules gain an optional driver_mode pin (auto/firmware/builtin/
shim), consulted by the DHCP proxy BEFORE the escalation ladder:
'this OUI is a Secure Boot rack -> serve shim immediately' = zero
failed cycles. Mode-only rules coexist with target rules (a pin
doesn't shadow a later target match). Editor column on Hosts tab.
- grub.cfg now tries to chainload all-drivers iPXE before showing the
signed menu: with SB off the chainload succeeds and the client gets
the full iPXE feature set back in the SAME boot (self-healing for
mis-escalations, and the handoff then pins the working mode); with
SB on, shim's verifier refuses it inline — no reboot — and the
signed menu appears.
DhcpProxyServer now takes the escalation table + rules store from main
(persistence path comes from the configured work dir).
Validation: clippy clean, fmt clean, 299 workspace tests green (+9:
persistence round-trip across restart, Shim pin survives TTL, learned
Builtin survives TTL, corrupt-file recovery, default-mode-never-
persisted, rule-pin matching incl. unknown-mode tolerance and
pin/target coexistence, GRUB chainload-before-menu ordering, API
round-trip of the driver_mode field).
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Mirrors the worthwhile device-support wins from iVentoy 1.0.24→1.0.35 onto our
(very different) proxy-DHCP + iPXE-chainload architecture. iVentoy's other
changes are inapplicable (arm64-server / distro-display fixes live in its
injected Linux, which we don't have), niche (iSCSI), or closed-source
(Matrix Boot).
iPXE refreshed (mirrors 1.0.35 "Update iPXE")
- Pin the from-source build to ipxe/ipxe master @ 2026-06-09
(95ffbf4745553e8a207922389929e1943c0237c0) — newer NIC drivers + EFI fixes.
The pin also busts the cached ipxe-build Docker layer so the release
actually recompiles iPXE; build-ipxe.sh now shallow-fetches an exact SHA.
Automatic NIC driver fallback (mirrors 1.0.34 "driver/boot-file mode" — but
no operator toggle, per request)
- New DriverMode {Firmware, Builtin} in core; ClientArch::ipxe_bootfile_mode
maps each arch to either the firmware-net build (snponly/undionly, default)
or the all-drivers build (ipxe.efi/ipxe.pxe/ipxe-i386.efi/ipxe-arm64.efi).
- The DHCP proxy serves Firmware by default — byte-for-byte unchanged, so
hardware that boots today never regresses. A new DriverEscalation state
machine watches for the tell-tale failure: a MAC re-PXE-boots (fresh
firmware DISCOVER) without ever completing the iPXE-user-class handoff that
proves the firmware NIC stack worked. That MAC is automatically escalated to
iPXE's own NIC drivers, and the choice is sticky after a confirmed handoff
(debounced for the :67/:4011 same-boot pair, TTL-pruned, capped). It just
works — no settings, no UI.
- All-drivers binaries fetched per arch (ipxe.pxe + i386/arm64 native EFI;
x86_64 ipxe.efi already built from source with PNG); ipxe-assets embeds
*.pxe and logs availability per (arch, mode).
Core principles intact: DHCP-proxy-only, container-first, Rust-focused (the
logic is all Rust; only the iPXE fetch/build stays shell), Windows hard-rules
untouched (this never goes near Windows boot).
Validation: clippy clean; full workspace test suite green (core 99 incl. new
DriverMode tests, dhcp-proxy +4 escalation tests, http-api 31+68, iso-store
61, tftp 6, bin 2); fmt-clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
