My Raspberry PI has 2 identical (kind of) root partitions. I would like to be able to select the other root partition at boot time using a GPIO pin in case I brick it.
This answer does not address directly your question but it may solve your problem. After reading all suggested solutions it seems not to be simple task to have a save second boot option. A broken system may also affect the second boot option.
If you really want to have a fail safe system I simply would provide a second Raspberry Pi. This can be full tested and ready to run. It should not be a big problem to advise a person by phone to just swap the RasPis.
The odds of having a "bricked" system will be a product of the probability of a critical problem (P1) and the probability of the recovery mechanism not working as planned (P2). Designing a recovery mechanism lowers P2 (P2=1 if no recovery mechanism is in place), but at the same time it could increase P1 as your setup becomes more complex. As such, a recovery mechanism is only beneficial if the product P1*P2 becomes lower in the end.
As such, you should try to minimize P1 as much as possible before you even start thinking about recovery. Using a good SD card with enough spare space (I'd go for as much as 100% reserve, i.e. if your system takes up 10 GB, I'd use at least a 32 GB SD card). Make sure journaling is enabled on the root partition. Make sure there are no optional boottime activities which could prevent the system from booting (e.g. entries in
fstab without the
nofail option). If the network connection is via WiFi, I'd consider having two NICs (e.g. built-in adapter + USB dongle). If there are multiple wireless networks to connect to, I'd configure all of them (with priorities) in your
wpa_supplicant.conf. Only then I would consider working on the recovery features.
If there's someone around your Pi who you could ask to to "fix" is as long as the fix doesn't involve anything complicated, then a spare SD card could be an option. Asking someone to swap it with the one in the Pi over the phone is not much more complicated than pushing a button. This has the advantage of lowering P2 without increasing P1.
Another idea: you could write a pair of SystemD units: the first one runs as early as possible (right after
local-fs.target) and edits
cmdline.txt to use the spare root, and the second one runs at the end (after
multiuser.target, or perhaps even inside a "graceful shutdown" script you'd have to call manually) and rolls back the changes. That way, if a critical problem appears between the two, you'll get into your spare system on the next reboot. Enabling the watchdog could facilitate the transition, or you could just ask your remote proxy person to reset the system. However, I would only implement something like this after an extensive testing proving that the system works like a clock, in both normal scenarios and in cases of failure.
This doesn't answer your question directly but may be a good workaround for you. A Raspberry pi 4B can easily be made to boot from a flash drive. Once setup that way, if you leave the original SD card in, it will boot to the SD in the event that booting from the flash drive fails. I've only tested this on a 4B but some literature clams that a 3B will do it as well.
Its been possible for a while to configure the boot order of the PI.. So you can tell it the order of SD, USB and Network boot.
In the case of boot order you could remotely change the boot order than then reboot.
In the case of network boot what the PI boots is decided by server your connecting to over the network. At which point its up to you what root filesystem you mount.
Which means in either case you could control what gets to be boot and root.
The network boot instructions canoe found here..
As a bonus I notice there is a 'Wake on GPIO' boot loader option so might be a segway into your original ask.