The Firmware page shows new releases, and the update badge installs them
A board's Firmware page used to say "Update available" and then list only old versions, and Upload .tpu could do nothing at all on a board without an SD card. The list now builds in 5 seconds instead of 170, the page keeps checking until it arrives, the badge installs the version it names, and Upload installs directly when there is no card.
Firmware v2.47.0, 1 November 2026 — the first image to carry bmcd 2.42.2, BMC-UI 4.4.0. Every item below is the repository's own changelog entry, taken apart; the whole entry is a click away under each one.
New firmware releases now show up in the Firmware page's list, the "Update available" badge installs what it names, an upload works on a board without an SD card, a board without a card stops showing an SD warning, and the (i) help links reach turingpi.xyz.
If your Firmware page does not show v2.47.0 (boards on v2.46.1 or earlier can
take minutes to list it): on the BMC over SSH run
tpi-selfupdate --tag v2.47.0 --reboot. It downloads the image, checks its
checksum, stages it and reboots; if the new image fails its health gate, the
board goes back to the previous one by itself. Or leave the Firmware page open
for about four minutes and reload. On a Turing Pi 2 v2.4 a BMC reboot
power-cycles the nodes; on a v2.5 they keep running.
The "Update available" badge installs the version it names (BMC-UI
Section titled “The "Update available" badge installs the version it names (BMC-UI”4.4.0)
Pressing it opens the same confirmation as the list's Install button, which says which source and repository it installs from.
The whole entry
If no configured source is the repository the update check named, the badge is information only and says why. It is disabled while an install, an upload or a flash runs, or an update is already staged.
The "Update available" badge installs the version it names
Section titled “The "Update available" badge installs the version it names”BMC-UI 4.4.0
It comes from the cheap update check, which knows of a release long before the catalogue has listed it.
The whole entry
Pressing it opens the same confirmation as the list's Install button, which says which source and repository it installs from and, when the list does not have the version yet, that too. The source is the GitHub source whose location is the repository the check named, and no other: another source listing the same version string does not count. If no configured source is that repository the badge is information only, with a line saying why. What the dialog shows is fixed when the badge is pressed and is what is sent, even if the list refreshes underneath; it never asks the updater to allow a downgrade unless the list says the version is older and the dialog says so. It is disabled while an install, an upload or a flash runs, or an update is already staged.
The demo can show both: ?card=none is a board with no SD card (as bmcd
Section titled “The demo can show both: ?card=none is a board with no SD card (as bmcd”2.42.2 reports it), and ?firmware=stale is a board running v2.44.0 whose update check offers
v2.46.1 and whose list does not have it (and says it is checking for the
first 25 seconds)
BMC-UI 4.4.0
Written changes to the captures, not captures.
The generated API types are now from bmcd v2.42.2 (they were v2.42.0); the
Section titled “The generated API types are now from bmcd v2.42.2 (they were v2.42.0); the”card question reads mounted from them instead of a local type
BMC-UI 4.4.0
-
The Firmware page keeps checking until the list arrives (BMC-UI 4.4.0). The page polled the catalogue for two minutes and then stuck on "checking the sources now" with a greyed-out Check now, until it was reloaded.
The whole entry
It now keeps asking while the daemon says it is refreshing, for up to eleven minutes (every 2 s at first, then every 5 s after 30 s and every 10 s after two minutes, and not at all while the tab is hidden). If it does give up it says "Still checking — the list may be out of date. Reload later." and Check now works again.
-
One slow or hung firmware source no longer costs the others (bmcd 2.42.2). Each source has its own 360 s deadline instead of the whole check being cut off after ten minutes with nothing kept.
The whole entry
A source that overruns reports
timed out after 360 sand the rest are cached as usual; the updater and itscurlare killed as a group, so hung downloads do not pile up on the board. When the only errors are slow sources (or a card that is inserted but not mounted), the retry waits 15 minutes instead of 2, so a slow board does not hammer GitHub's 60 requests an hour. Concurrent requests with nothing cached now share one refresh instead of each starting their own. -
Uploading a
.tputo a board with no SD card works (BMC-UI 4.4.0, bmcd 2.42.2). The dialog always asked to park the image on the card, and a card-less board refused with a toast and nothing else.The whole entry
When the board has no card the dialog now says so and installs directly, written to the spare slot and staged for the next boot, with the same reboot warning as the slots panel. With a card nothing changes. If the daemon still refuses, the reason stays in the dialog with "Install directly instead" beside it. The daemon's message no longer tells the web interface to "insert one, or upload without parking", and a successful park now shows up in the list straight away instead of up to 30 minutes later.
-
A board without an SD card no longer shows an SD warning (bmcd 2.42.2). The
SD cardsource answered an error when no card was mounted (or the card had nofirmwarefolder), which shortened the catalogue's cache to two minutes, kept it off the flash, and left "SD card: This source returned nothing usable" on the page for ever.The whole entry
It now reports nothing. A card that is there and unreadable, or inserted but not mounted (unsupported or damaged filesystem), is still reported.
GET /api/bmc/infoalso says whether the card is mounted (mountedon the "SD card" entry); the interface no longer draws an unmounted card as a second storage row. -
The (i) notes reach turingpi.xyz (BMC-UI 4.4.0). Every "Read more" link on the Firmware, Fan, Console and Nodes pages went to the dead docs host and ended in an error; they now go to
https://turingpi.xyz, and the two Console notes land on the right section. -
New releases never appeared in the Firmware page's list on a board. Listing the 44 releases of this repository took about three minutes on a real board (170 s for
tpi-selfupdate --list, measured 2026-11-01 on v2.46.1), and the page stops waiting after two, so the list came back without the GitHub source and the newest releases were never shown.The whole entry
tpi-selfupdatesplit the response on},{, which only exists in compact JSON; GitHub sends it pretty-printed (about 690 KB and 11,000 lines), so every line became its own piece and cost five forks, and the time grew with every release published. It is now oneawkpass over the whole response (0.12 s against 6.1 s before on a workstation, same 44 releases), and the same pass now readsprerelease, which sits on a line the old code never looked at, so a pre-release is finally listed as one. Output and ordering are unchanged.tests/listing.shnow runs against a trimmed copy of the real response (tests/fixtures/github-releases.json) and fails if a listing scales with the number of lines. -
The Grafana dashboard's description linked to the dead docs host.
dashboards/turingpi-bmc.jsonsent readers to the metrics catalogue atturing.excavador.xyz, which answers a Cloudflare 502; it now points athttps://turingpi.xyz/reference/metrics/.The whole entry
The dashboard is not part of the image.
-
A board with no SD card (or a card with no
firmwarefolder) kept retrying the whole firmware check every two minutes and showed a warning for it. TheSD cardsource answered "/mnt/sdcard/firmwareis not a directory" as an error, and any source error shortens the catalogue's cache from 30 minutes to 2 minutes and keeps it off the overlay, so a card-less board never kept a good catalogue across a reboot and the firmware page carried "SD card: This source returned nothing usable" for ever. bmcd 2.42.2The whole entry
A source on the card now reports nothing, and no error, when the card is not mounted (decided as
os_parkand the staging code decide it: the mount point has a different device from its parent) or when the card has nofirmwarefolder. A card that is there and unreadable (firmwareis a file, the folder will not open) is still an error, and so is a missing folder for a local source configured away from the card. So is a card the kernel sees (/dev/mmcblk0) that nothing has mounted, which now says "an SD card is inserted but not mounted (unsupported or damaged filesystem?)". A mount point that cannot be inspected at all is an error too, not "no card". The response shape is unchanged. -
The message for parking an image with no card said "Insert one, or upload without parking", which is a dead end in the web interface. It now says the image was not saved because no SD card is mounted (or, when the kernel sees a card that nothing mounted, that it is inserted but not mounted), and that installing directly is
tpi firmware uploadwithout--parkor the interface's install option. bmcd 2.42.2 -
An image parked on the card did not appear in the catalogue for up to 30 minutes. A successful park now marks the cached catalogue stale, so the next
GET /firmware/availablestarts a refresh. bmcd 2.42.2The whole entry
A fan-out already running when the park finishes cannot clear the mark, since it may have read the card before the image was there.
-
One hung firmware source discarded every other source's answer. The catalogue refresh waited for all sources and was cut off as a whole after 10 minutes, so a source that hung (a stuck
curlundertpi-selfupdate --list) cost the fast sources their results too: nothing was cached or persisted and the page kept the old listing. bmcd 2.42.2The whole entry
Each source now has its own 360 s deadline (the slowest fan-out on record is bmc-2 on 2026-09-12, about 230 s). A source that overruns reports
timed out after 360 sas its own error, and the others are cached and persisted as usual. The updater runs in its own process group; on the deadline the whole group (the script and itscurl) is killed while the script is still unreaped, so hung downloads do not pile up on the board, and output is read until both pipes close or the deadline, so acurlthat outlives its script cannot hold the check up either. A source whose blocking call never returned (a wedged read of a failing card) is skipped on the next check with "still busy from the previous check", rather than leaving another thread behind each time. When the only errors are such slow sources, or a card that is inserted but not mounted (which a retry in two minutes will not change), the retry waits 15 minutes instead of 2, so a slow but working board does not start itscurl-heavy listings every few minutes against GitHub's 60 requests an hour. The 10-minute limit on the refresh as a whole stays as the outer guard. -
Concurrent requests with nothing cached each started their own firmware check, and a park that landed as a check finished could go unnoticed. A request that finds the catalogue empty now waits for the one refresh (it does not start another), and answers when it completes as before; if nothing arrives within 10 minutes it answers an empty list with
refreshing: true. bmcd 2.42.2The whole entry
The stale mark and the check's result are now decided under the same lock.
-
GET /api/bmc/info(andopt=get&type=info) says whether an SD card is mounted. TheSD cardentry instoragegainsmounted, decided by the same mount-point test the park and staging code use (a mount point that cannot be inspected reads as not mounted). bmcd 2.42.2The whole entry
Before, a client could only guess, by noticing that the entry's sizes equalled the BMC's (
statvfson the empty/mnt/sdcardanswers for the volume underneath). Additive: theBMCentry has nomounted, theSD cardentry is present under the same rule as before, and its sizes are reported as before, so an older interface is unaffected. The sizes are not a statement about a card whilemountedis false; read the new field instead. -
The (i) notes still pointed at the dead docs host.
InfoNotebuilt every "Read more" link fromhttps://turing.excavador.xyz, which answers a Cloudflare 502 and will not be redirected, so each (i) on the Firmware, Fan, Console and Nodes pages led to an error. BMC-UI 4.4.0The whole entry
3.31.0 says it fixed this host and missed
InfoNote. It now useshttps://turingpi.xyz.The two Console notes also named the wrong page: their anchors live on
/why/a-console-to-every-module/, not on the feature page, so the link landed at the top instead of at the note. Every pathInfoNoteis given answers 200 onturingpi.xyz.ESLint now rejects the old host in any string or template literal under
src/, so a third copy cannot come back unnoticed. -
The firmware page no longer gives up on a slow catalogue and sticks. Seen on a board running v2.44.0: "Update available · v2.46.1" in the slots panel, a list with only v2.44.0, v2.1.0 and v2.0.5, "checking the sources now" that never changed and a greyed-out Check now, until the page was reloaded. BMC-UI 4.4.0
The whole entry
The page polled the catalogue for two minutes, on the strength of a 16 s refresh measured with one source; building the fork's release list alone takes 170 s on a real board, and the daemon allows a refresh ten minutes. It now keeps asking while the daemon says it is refreshing, for up to eleven minutes, backing off from every 2 s to every 5 s after 30 s and every 10 s after two minutes, and not at all while the tab is hidden. If it does give up it says "Still checking — the list may be out of date. Reload later." and Check now works again; pressing it starts a fresh eleven minutes.
-
Uploading a
.tputo a board with no SD card no longer fails with a toast and nothing else. The dialog always asked the daemon to park the image on the card, and a card-less board refuses ("/mnt/sdcard is not mounted…"). BMC-UI 4.4.0The whole entry
When the board has no card the dialog now says so and installs directly: written to the spare slot and staged for the next boot, confirmed with the same reboot warning (by board revision) as the slots panel's Reboot button. With a card nothing changes: the image is parked and appears in the list. From bmcd 2.42.2 the Info storage list says whether the card is mounted (
mountedon the "SD card" entry) and the dialog uses that exactly; before it, the dialog goes by whether that entry's size is the BMC's own volume. Where that is wrong, or unreadable, the daemon's refusal now stays in the dialog until dismissed, with "Install directly instead" beside it. A card that is not mounted is no longer drawn as a second storage row on the Info page (its sizes are the BMC's) nor given a usage line in the SD card picker. Upload errors in general persist in the dialog rather than only as a toast, and a finished upload refreshes the list and the slots panel (so "Next boot" shows what was staged). -
A refused install shows the daemon's reason after "Nothing has been staged." (already staged, unknown source), not only the generic line. BMC-UI 4.4.0
Every release of the firmware · the roadmap · follow by feed