I run two Turing Pi 2 boards (both v2.5.2, RK1s) as a home Kubernetes cluster, and the
stock BMC firmware kept getting in my way: a TLS certificate that had already expired,
a firmware page that froze, mDNS taking the whole board down once, and no way to update
the BMC without worrying about the nodes.
So I forked it. It's still the Turing Pi firmware (bmcd, the web UI, the tpi CLI, the
Buildroot image), just with the things I needed:
– Updates that undo themselves: a new image boots on trial and is kept only if the
board comes back right. On my board A: 26 updates, 1 automatic rollback, 0 trips to
the rack.
– Update the BMC without touching your nodes: node power state is adopted live across
the reboot.
– Flash a module straight from the SD card, no upload through the browser.
– A serial console to every module in the web UI.
– Temperature, fan and governor on the overview page.
– A certificate that does not rot: renew it from the UI, EC keys.
– One page over every board if you run more than one (a small fleet UI).
– Metrics on their own port, an OpenAPI description of the board's API, and a CLI
that works.
Try it before you flash anything: https://turingpi.xyz has a live demo built from
data captured off real hardware, stock and fork side by side.
Install / upgrade from stock: https://turingpi.xyz/guides/install/
What is still broken, on purpose written down: https://turingpi.xyz/reference/known-faults/
Roadmap you can vote on: https://turingpi.xyz/roadmap/
Code: https://github.com/excavador-turing
Caveats, because they matter: two boards, both mine, both v2.5.2. Flashing firmware is
a real operation; read the install page, keep the stock image handy, and the rollback
only helps you if the new image boots at all. If something breaks, GitHub Issues is
where I'll see it fastest.
Happy to answer anything about how the A/B update works or what changed under the hood.
Source: r/turingpi · by /u/opwerm