mward4/OpenPXE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 40 Wiki Activity

40 Releases 41 Tags

RSS Feed
  • v0.4.62 d729a7ae2f
    Compare

    v0.4.62 — PXE logo compositor & cache-bust UI assets Pre-Release

    mward4 released this 2026-05-26 00:53:30 -04:00 | 39 commits to main since this release

    OpenPXE v0.4.62

    The buildable companion to v0.4.61. Same cache fix and PXE-logo
    compositor; the iPXE-rebuild-with-PNG-support stage from v0.4.61 has
    been walked back and queued for a follow-up release once it can be
    validated on native x86_64 hardware.

    Why v0.4.62 exists

    v0.4.61 ships in source with an ipxe-build Dockerfile stage that
    compiles iPXE from source with IMAGE_PNG enabled. That stage hits
    intermittent cc1: internal compiler error: Segmentation fault when
    cross-emulating x86_64 gcc under QEMU on arm64 build hosts. No
    v0.4.61 image was ever published as a result.

    v0.4.62 keeps everything else from v0.4.61 (the actual fix the
    operator reported, plus the compositor code) and rolls the iPXE
    build stage back to the boot.ipxe.org fetch path. The compositor at
    /branding/pxe-logo is wired and ready — when the iPXE-rebuild stage
    lands in a follow-up release (on native x86_64 hardware), no other
    code change is needed. The operator's logo will start painting in the
    PXE menu the moment the underlying iPXE binaries grow PNG support.

    The actual fix: v0.4.6 UI changes land in your browser

    Operators who pulled v0.4.6 didn't see the v0.4.6 UI changes — the
    top-right user menu, the IdP logo URL field, the realigned account
    form. The version chip in the footer correctly read "v0.4.6" because
    it's dynamic, but app.js and app.css live at fixed URLs that
    browsers happily reused from before the upgrade.

    Fixed in v0.4.62:

    • index.html now appends ?v=<openpxe-version> to every asset URL
      (app.css, app.js, logo.svg). Every release ships brand-new asset
      URLs.
    • Cache-Control: no-cache, must-revalidate on every asset handler.
      index.html itself is no-cache so the browser learns about the new
      ?v=… value on the next page load.

    Net effect: v0.4.62 → next release upgrades, and any prior upgrade
    once you're on v0.4.62, will land in the browser on the next page
    load. No hard refresh required.

    PXE-logo compositor (ready, waiting for PNG-enabled iPXE)

    Even though the operator's logo can't paint in the PXE menu yet
    (boot.ipxe.org's binaries omit IMAGE_PNG), the server-side
    compositor that prepares the logo for that paint is in place:

    • New openpxe-iso-store::pxe_logo::compose_pxe_logo decodes any
      raster the operator uploads (PNG / JPEG / WebP / GIF), downscales
      to fit a 600×200 bounding box, and pastes it horizontally centered
      with a 64-pixel top margin onto a transparent 1024×768 canvas.
      Returns PNG bytes.
    • GET /branding/pxe-logo returns that composed PNG. SVG uploads
      still 404 here (iPXE can't rasterize SVG); the WebUI's top-left
      mark continues to read directly from the SVG upload.

    The follow-up release will swap the boot.ipxe.org fetch for a
    make-from-source stage with IMAGE_PNG enabled, at which point
    this endpoint goes live without any code change.

    What stayed from v0.4.6

    The ASCII OpenPXE wordmark in render_menu is back for v0.4.62. It
    paints on every iPXE build regardless of PNG support — it's the
    correct fallback for the binaries we currently ship. When the real
    image paints, it'll be retired in the same release.

    Container image

    • gitea.milesward.dev/mward4/openpxe:0.4.62
    • gitea.milesward.dev/mward4/openpxe:latest

    linux/amd64; static-musl /openpxe binary unchanged. Image size
    ~98 MB.

    Quality

    • 142 tests passing (unchanged from v0.4.61): the compositor
      tests still run; the menu test asserts the ASCII banner is present.
    • cargo clippy --workspace --all-targets clean.

    Compatibility

    • Existing deployments upgrade in place. No data-file format
      changes; all of auth.json, branding.json, sso.json,
      hosts.json, meta.json continue to read identically.
    • The v0.4.61 git tag stays where it is — broken Dockerfile,
      reference-only. Pull v0.4.62 (or :latest) for a working image.
    Downloads