I actually implemented something on an embedded linux product once: a busybox initramfs that you could boot into "recovery mode," then along with dropbear, SSH into a completely in-memory system and re-flash the entire system image without having to pop out an SD card or connect a cable for DFU.
The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!
These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!
I've implemented something very similar for upgrading headless Linux mobile robots. One nice property of this approach is that the in-memory installer environment and associated scripts can be common between USB-based install media and a remotely-triggerable kexec type installer.
At first, it surprised me there wasn't more standard tooling out there for this kind of thing, but as I got more into it, I realised how specific to our particular needs my solution had become, and I could see how it would be hard to offer something generic that would be a good fit for a wide range of use-cases without being super-bloated.
The recovery mode could even be initiated remotely, so you could re-flash a device without ever touching it. Of course you have to be careful, if the re-flash failed you could be SOL :) Apparently I need to go back and improve it so we can re-flash without rebooting!
These days you can use things like containers (Balena also looks very cool) to achieve a similar goal in possibly a "safer" way. But the idea of being able to re-flash the entire system while running it felt sort of like changing the engine of a car while driving it down the freeway!