Hey all,
If you're developing a distro, an embedded system or anything else that requires constant flashing of the system, the process of removing the SSD or SD card or toggling the rpiboot switches can become really old really fast. Or maybe your device is somewhere behind a panel or on top of a high cupboard and access is just annoying and cumbersome?
I began wondering would it be possible to actually flash a live system. Turns out that it is, and after quite a bit of iterating and a few dozen of device reflash rounds later, I've honed the approach enough to request brave testers. Just like you would change and airplane engine mid-flight, it's possible to:
1. Write a static busybox binary, a helper script and a compressed OS image to ramfs (/dev/shm)
2. Remount the existing root and boot filesystems read-only
3. Flash the rootfs using dd
4. (Optionally) Mount the new bootfs (with a bit of shenanigans) and write a custom firstrun.sh
5. Sync and reboot
And you've got a functional system! Or that's how the theory goes.
I've packaged this process into a single script that can either be run locally (swap the engine of your own airplane) or remotely (swap the engine of another airplane). There's even a streaming mode for devices with less than 4 GB of RAM: in those cases, the OS image is streamed over SSH or from an external drive, extracted and written in one go.
I've tested the flasher with various images (Trixie and Bookworm derivatives), mostly with our own CM5-based HALPI2 hardware, and while the flasher should be fairly reliable already, be mentally prepared that you might to pull out the device for manual reflashing...
See here (including the TL;DR): https://github.com/hatlabs/flash-live-system
If you decide to try the tool, I'd love to hear your feedback! Did it work and why not?![:-)]( "Smile")
Cheers,
Matti Airas
If you're developing a distro, an embedded system or anything else that requires constant flashing of the system, the process of removing the SSD or SD card or toggling the rpiboot switches can become really old really fast. Or maybe your device is somewhere behind a panel or on top of a high cupboard and access is just annoying and cumbersome?
I began wondering would it be possible to actually flash a live system. Turns out that it is, and after quite a bit of iterating and a few dozen of device reflash rounds later, I've honed the approach enough to request brave testers. Just like you would change and airplane engine mid-flight, it's possible to:
1. Write a static busybox binary, a helper script and a compressed OS image to ramfs (/dev/shm)
2. Remount the existing root and boot filesystems read-only
3. Flash the rootfs using dd
4. (Optionally) Mount the new bootfs (with a bit of shenanigans) and write a custom firstrun.sh
5. Sync and reboot
And you've got a functional system! Or that's how the theory goes.
I've packaged this process into a single script that can either be run locally (swap the engine of your own airplane) or remotely (swap the engine of another airplane). There's even a streaming mode for devices with less than 4 GB of RAM: in those cases, the OS image is streamed over SSH or from an external drive, extracted and written in one go.
I've tested the flasher with various images (Trixie and Bookworm derivatives), mostly with our own CM5-based HALPI2 hardware, and while the flasher should be fairly reliable already, be mentally prepared that you might to pull out the device for manual reflashing...
See here (including the TL;DR): https://github.com/hatlabs/flash-live-system
If you decide to try the tool, I'd love to hear your feedback! Did it work and why not?
Cheers,
Matti Airas
Statistics: Posted by hatlabs — Mon Mar 02, 2026 6:38 pm — Replies 2 — Views 95