A fixed address from the Network tab, and a clock that says why
The BMC's own address — DHCP or static, with gateway and resolvers — from the Network tab, applied then confirmed at the new address so a typo cannot strand the board. The Time card lists every source with chrony's own verdict, including the one that sent a reader to Discord: a name the board could not resolve. And two 2.4 boards now run this firmware, one upgraded from the factory image in NAND.
Firmware v2.35.0, 21 September 2026 — the first image to carry bmcd 2.38.0, BMC-UI 3.34.1, tpi 1.10.0. Every item below is the repository's own changelog entry, taken apart; the whole entry is a click away under each one.
New¶
The board's own address, from the Network tab¶
DHCP or a static address with its prefix, gateway, resolvers and search domain, beside the hostname.
The whole entry
The rules are the board's: it refuses what could never be reached (a gateway off the subnet, the network or broadcast address) and warns about what is merely unwise — a static address with no resolver, which is exactly the state the reporter's board was in. Apply puts the address on the bridge and keeps it only when a confirmation reaches the board at the new address; otherwise the old one comes back by itself after the window. The bridge is never brought down, so the modules' ports stay in it throughout. tpi network address does the same from a shell. Only a confirmed address is written to /etc/network/interfaces — in the same stanza this image ships and migrates, so nothing about boot changed.
The clock says why¶
The Time card, tpi ntp and GET ?type=ntp carry chrony's verdict on every source — selected, combined, excluded, unreachable, falseticker — and, when chrony has nothing at all, the configured names as unresolved.
The whole entry
That last state is what "no resolver" looks like from the outside, and it is what an empty chronyc sources had been hiding.
The board's own address, applied then confirmed at the new address¶
bmcd 2.38.0
GET/PUT /api/bmc/network/address, POST .../confirm, .../revert, .../validate, GET .../limits.
The whole entry
One document -- {"mode":"dhcp"} or {"mode":"static","address","prefix","gateway","dns","search"} -- the same shape as the switch and for the same reason: the address is how you reach the page you change it from. PUT answers 202; the address goes on the bridge, a window runs (30 s by default, 10-300), and unless a confirmation reaches the daemon at the new address the previous one is put back and last_revert says why. A confirmation from the board itself never used the address and is refused with 403. Only a confirmed document is written to /etc/network/interfaces -- the same v2.1 stanza the image ships and S00dsa migrates, so the boot path needs nothing new.
The bridge is never brought down. ifdown br0 would take the compute
modules' ports out of the bridge with it; the address is changed with ip
on a bridge that stays up, and udhcpc is stopped (it releases and flushes
on SIGTERM, which is what -R is for) or started the way ifup starts it.
The resolvers for a static address go into /etc/resolv.conf at apply, and
as an up hook in the stanza at boot -- this image has no resolvconf.
The board refuses what could never be reached: a gateway off the subnet,
the network or broadcast address, a prefix outside /8-/30. It warns, and
applies, what is merely unwise: no gateway, no resolver (so pool.ntp.org
never resolves). GET reports running, configured (what a reboot comes
back to), live (what the bridge actually has), and whether the file was
written by this daemon, by hand, or could not be read.
Asked for from the Discord on 2026-09-21 by a user who had set up the Split layout and then had to change the BMC's address over SSH.
GET ?type=ntp says what chrony thinks of each source¶
bmcd 2.38.0
sources: one entry per source from chronyc -c sources -- selected, combined, excluded, unreachable, falseticker or too_variable, stratum, how many of the last eight polls answered, the last offset, and whether it is one of the servers configured through this daemon.
The whole entry
Every field is chrony's own column. "Not synchronised" alone sent a user to Discord with nothing to act on; chrony always knows why.
The BMC's address, from the Network tab¶
BMC-UI 3.34.0
An Address card beside Hostname: what the bridge has now (the DHCP lease, or the fixed address), DHCP or Static as two pills, and for static the address with its prefix, the gateway, the resolvers and a search domain.
The whole entry
Every rule is the board's (POST /network/address/validate as you type); the card only checks that what was typed has the shape of an address. Apply and Try it work as they do for the switch: the address goes on the board and is not kept until a confirmation reaches it -- at the new address, which means this page, reloaded there -- or the board puts the old one back by itself. Needs bmcd 2.38.0; on an older daemon the card is not shown. Asked for from the Discord on 2026-09-21 by a user who had done it over SSH -- and whose board then had no resolver, which is the next item.
The Time card says what chrony thinks of each source¶
BMC-UI 3.34.0
Selected, combined in, excluded, unreachable, refused for reporting itself unsynchronised, or -- the case that actually happened -- unresolved: a name chrony was given and never managed to look up, because the board has no working resolver.
The whole entry
Stratum, how many of the last eight polls answered, the offset, and which ones are yours. When nothing is selected it says what the states mean. "NOT synchronised" alone sent a user to Discord with nothing to act on; his chronyc sources was empty. Needs bmcd 2.38.0.
tpi network address show | apply | confirm | revert¶
tpi 1.10.0
The BMC's own address from the command line: apply --dhcp, or apply --static 192.168.1.20/24 --gateway 192.168.1.1 --dns 192.168.1.1, applied and NOT kept until confirm reaches the board at the new address -- run it as a new invocation with --host <new address>.
The whole entry
A confirmation from a shell on the board is refused, as the switch's is. Needs bmcd 2.38.0.
tpi ntp prints what chrony thinks of each source¶
tpi 1.10.0
State (selected, combined, excluded, unreachable, falseticker), stratum, how many of the last eight polls answered, the offset -- and, when nothing is selected, one sentence on what unreachable and falseticker mean.
The whole entry
"NOT synchronised" on its own sent a user to Discord with nothing to act on.
Changed¶
- "Reset network" is now "Reset the switch chip". Which is what it does and always did; it never touched the address.
Fixed¶
- The Time and Hostname boxes are no longer blank on a second visit. To the tab; both cards seed from the query now. Reported from the same 2.4 board.
- A countdown that could not count. The switch card read the daemon's
{secs_since_epoch, nanos_since_epoch}as a date and showed NaN. -
The demo build was broken by a fixture that was not JSON. The capture script read the firmware version with a pattern that wanted a
v, the board it captured from reportedlocal, andcaptured.jsongot an empty field. BMC-UI 3.34.1The whole entry
v3.34.0 shipped it; the board bundle is unaffected, the demo could not build. The script now takes the version as it is.
-
The demo shows the switch and the Security tab. Both hid themselves on a daemon that answers 404 to
/api/bmc/network/switchand/api/bmc/access-- which is exactly what the demo answered, becausecapture-fixtures.shonly knew the legacy?type=reads. BMC-UI 3.33.0The whole entry
It captures the four path-style endpoints now (the switch document and its presets, the certificate the board serves, who may reach it), and the adapter serves them; every write on a path-style endpoint, and the validate call -- a judgement only the daemon can make -- is refused with the demo's own problem+json. The sanitiser learned what those captures carry: the board's name, the estate's domain, its CA name and two fingerprints; the leak guard hunts those too.
Fixtures re-captured from a board on firmware v2.33.0.
Every release of the firmware · the roadmap · follow by feed