The board says when it is not keeping your settings

A board that could not mount its settings volume used to start on temporary ones in silence, so every reboot looked like a factory reset. Now every page says so and why, and offers a plain Reboot and, where it is safe, a Repair; install v2.46.1, because the repair was never offered on a real board in this release.

Firmware v2.46.0, 31 October 2026 — the first image to carry bmcd 2.42.0, BMC-UI 4.3.0. Every item below is the repository's own changelog entry, taken apart; the whole entry is a click away under each one.

A reader's board kept forgetting its settings after every reboot. The kernel log showed UBIFS error (ubi0:2): ubifs_recover_leb: LEB 16 scanning failed: the flash volume that holds the board's settings had a damaged journal, so the board started on a temporary, in-memory copy instead -- and said nothing.

New

GET /api/bmc/storage says whether the board is keeping its settings

bmcd 2.42.0

It answers {state, reason, detail, backing, repairable, repair_blocker}.

The whole entry

state is persistent, temporary or unknown, and it comes from /proc/mounts, which is the authority: temporary is an overlay on / whose upper directory is under /tmp/safemode/, persistent is an overlay with any other upper directory (normally /mnt/overlay/upper). reason, only when temporary, is requested (KEY1), mount_failed, or unrecorded. Firmware 2.46.0 and later write the reason to /etc/safemode.reason (line 1 reason=..., the rest free text, which is returned as detail, trimmed and cut to 8 KiB). KEY1 always wins: if the kernel command line contains safemode (a substring match, as preinit tests it), the reason is requested whatever the file says. Otherwise it is the file's, and when the file is missing or unreadable (older firmware), unrecorded. backing is ubi (the built-in flash), mmc (the SD card) or unknown, from the device under the read-only root.

POST /api/bmc/storage/repair removes the settings volume and reboots

bmcd 2.42.0

The body must be {"confirm": true} sent as Content-Type: application/json (400 without the confirmation, 415 for any other content type, which also stops a page on another origin from triggering it with a form).

The whole entry

It runs ubirmvol /dev/ubi0 -N overlay (60 s at most) and answers 202 {"rebooting": true}; about two seconds later it reboots the BMC the way tpi reboot does, and preinit creates a fresh volume on the way up. The removal and the reboot are one detached piece of work: a client that disconnects while ubirmvol runs does not leave a board with its volume gone and no reboot to recreate it. This permanently erases what is on the volume: network configuration, certificates, node names, application data. It is not being loaded now, but it cannot be recovered afterwards. Try a plain reboot first, since a mount failure can be transient. It also reboots the BMC, which on a v2.4 board power-cycles the four compute modules. The board comes back as a factory unit: password turing, a new certificate. Same authentication as the other mutating endpoints.

Repair is offered only where it is safe, and decided again on every

request bmcd 2.42.0

repairable is true only when the state is temporary, the reason is mount_failed or unrecorded, the backing is ubi, a volume named exactly overlay exists under ubi0, and nothing is mounted at /mnt/overlay.

The whole entry

Otherwise repair_blocker says why in a sentence (KEY1 was held: reboot without it to use the saved settings; the settings are on the SD card; there is no volume to remove: reboot the BMC to recreate it), and POST answers 409 with the same sentence and runs nothing. A failed or timed-out ubirmvol is a 500 with what it printed, and nothing is rebooted. A second request while one is under way is refused; a refused request never counts as one.

The two storage endpoints answer on a board still on its factory password

bmcd 2.42.0

Everything else is still refused with 403 there.

The whole entry

A board that could not mount its settings volume is always on the factory password, because every reboot is a factory reset, so the page that has to tell its owner so is the one the gate shows; making them set a password first would have them set one that is lost at the next reboot. GET /api/bmc/storage and POST /api/bmc/storage/repair (each for its own method only) are therefore let through the gate. They are still authenticated, and the repair is still refused with 409 unless the board's own facts say it is on offer. This opens nothing new: the stock firmware's sshd has PermitRootLogin yes and PasswordAuthentication yes, so root / turing already gives a root shell, and from it ubirmvol. If SSH is ever hardened, this exemption must be revisited.

The log says it at startup

bmcd 2.42.0

One warning when the board is on the temporary layer, with the reason, so it is in the log even if nobody opens the interface.

A banner on every page when the board's settings will not survive a

reboot BMC-UI 4.3.0

A board whose settings storage could not be mounted runs on factory defaults, and everything looks normal until the next power cut puts back whatever you had changed, the password included.

The whole entry

The banner says so above every page, and on the page that asks for a first password, with the daemon's own detail under a "Details" disclosure and a link to the known faults page. A board started with KEY1 held (safemode) gets its own, shorter banner: saved settings are not loaded, reboot without KEY1 to use them. The question is asked once per page load, never polled.

A plain reboot, first

BMC-UI 4.3.0

The daemon only knows that the mount failed, and that can be a one-off, so the banner offers the Settings page's Reboot beside the repair and recommends trying it before anything else.

The whole entry

It is offered even where the repair is not, because the daemon's reason there ("there is no settings volume to remove; reboot the BMC to recreate it") points at it.

Repair settings storage, which erases what is saved on the volume

BMC-UI 4.3.0

Where the daemon says the volume that could not be mounted can be removed, the banner offers a button that asks first.

The whole entry

The settings saved on that volume (network configuration, certificates, node names, app data) are not loading now, but they are still there, and the repair erases them for good: they cannot be recovered. The board then comes back on factory settings (password turing). On a Turing Pi 2 v2.4 the reboot also power-cycles all four nodes, so shut them down first. After the confirmation the page waits for the board exactly as the Reboot button does. Where it cannot be repaired from here, the banner shows the daemon's reason instead. A refusal shows the daemon's own message. The request is sent as application/json, which the daemon requires.

The reboot dialog no longer tells v2.4 owners their nodes keep running;

on v2.4 they are power-cycled BMC-UI 4.3.0

A Turing Pi 2 v2.4 has no latch on its node power rails, which the BMC drives directly, so any BMC reboot power-cycles all four nodes; a v2.5 has latches and its nodes keep running.

The whole entry

The Settings reboot dialog and its note, the dialog that reboots to start a staged firmware, the banner's reboot and the repair dialog now choose their warning by the board revision, and say both when the revision is unknown.

The demo can show both banners: ?storage=broken (a settings volume that

could not be mounted, repairable) and ?storage=keyhold (KEY1 held at power-on); ?board=v2.4 shows a v2.4 revision for the reboot dialogs BMC-UI 4.3.0

The fixtures are written, not captured.

The generated API types are now from bmcd v2.42.0 (they were v2.36.0), and

the storage banner is typed from them BMC-UI 4.3.0

Unit tests for the banner's decisions (src/lib/api/storageView.test.mjs)

BMC-UI 4.3.0

Changed

• If the board's settings storage cannot be mounted, it now records why. The board still starts on temporary settings (every reboot is then a factory reset, as before), but it writes /etc/safemode.reason once it is running: the first line is reason=requested (KEY1 held at power-on) or reason=mount_failed, followed by what the mount step printed and the related ubi/ubifs/mtd kernel lines.

  The whole entry

  The file lives in memory and is gone after a reboot; a normal start writes nothing, so there is no extra flash wear. Failing to write the note never stops the boot. The reason is also printed on the serial console.

• The kernel log keeps 8x more. The in-memory kernel log grows from 16 KiB to 128 KiB, so the messages that explain a failed start (which come early and used to be pushed out by later chatter) are still there when you run dmesg.

  The whole entry

  The serial console during early boot now shows errors and worse (loglevel=4 prints levels below 4) instead of everything, matching the SD installer; the full log is still in dmesg. This only changes that early window: S93startup already sets the console level to 3 later in boot.

• mDNS (the .local name) now works on boards whose bridge is not br0. The name service is still bound to exactly one interface -- binding several was measured to cause a reload storm (825 reloads in 12 s) because the switch ports share one address.

  The whole entry

  It now picks that interface when it starts: br0 if there is one, otherwise the default route's interface if that is a bridge, otherwise the first bridge, otherwise a single plain default-route interface, otherwise br0 as before. A network split by hand into, for example, br-wan and br-lan is covered. If the default route only comes up after mDNS has started, the existing five-minute check moves it to the right bridge (at most about five minutes later).

• The web interface says when the board is not keeping its settings, and can repair it (bmcd 2.42.0, BMC-UI 4.3.0). A banner appears when the settings storage could not be mounted, or when safe mode was requested with KEY1 (the two reasons the firmware now records).

  The whole entry

  For a storage fault it offers "Repair settings storage": this permanently erases the settings volume and reboots the BMC into factory settings, so it asks for confirmation and suggests a plain reboot first. KEY1 always wins: a board held in safe mode by the button is reported as requested. The factory-password gate lets exactly these two storage requests through, so a board on the factory password can see the banner and repair itself.

Fixed

• The reboot dialog no longer tells v2.4 owners their nodes keep running. On a v2.4 board a BMC reboot power-cycles all four compute nodes; the dialog said otherwise. It now says to shut the nodes down first (BMC-UI 4.3.0).

---

Every release of the firmware · the roadmap · follow by feed