The settings-storage repair is offered on a real board

In v2.46.0 the Repair button never appeared, because the board's root device shows as /dev/root and the daemon could not tell where it had booted from. Found on our own board right after flashing v2.46.0 and fixed the same day; the v2.46.0 post has the rest.

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

Fixed

• The settings-storage repair added in v2.46.0 is now offered on a real board. Bmcd 2.42.0 never offered it, because the board's root device shows up as /dev/root and bmcd could not tell what it was backed by (backing: unknown). bmcd 2.42.1 resolves it from the kernel's root= argument.

  The whole entry

  Nothing else changed.

• The settings-storage repair was never offered on a real board: the root device shows as /dev/root, which 2.42.0 did not resolve. On the board the kernel mounts the read-only image itself, so /proc/mounts says /dev/root /mnt/rom erofs ... and /dev/root is not a device node. bmcd 2.42.1

  The whole entry

  GET /api/bmc/storage therefore reported backing: "unknown", and with it repairable: false, even on a board that had lost its settings. When the mount source of the read-only root is /dev/root (or is not a device node at all, as for a root that is the overlay), the kernel's own root= from /proc/cmdline is resolved instead: a MAJOR:MINOR such as 254:0 through /sys/class/block/*/dev (which names it ubiblock0_1), or a /dev/<name> as it stands. ubiblock* is ubi and mmcblk* is mmc, as before. Whatever cannot be resolved (PARTUUID=, PARTLABEL=, a device sysfs does not list, no root=) stays unknown, and an unknown backing still does not offer the repair.

---

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