I am working on a project where upgrades to the Raspberry PI will over HTTP, and the Raspberry PI will not be directly accessible (cannot just swap cards).

I would like to have a partition setup like so:

  • Partition 1- /boot (contains kernels for both partitions)
  • Partition 2- / (recovery partition)
  • Partition 3- / (primary partition)

When an upgrade goes bad and the Raspberry PI gets into a reboot loop, or hangs on boot, I'd like the user to be able to press a button, which triggers a GPIO line, which would cause the boot loader to boot into the recovery partition instead of the primary partition.

The recovery partition would never be upgraded, so this would be safe.

I see a couple of options:

  1. Always boot into the recovery partition, check GPIO, then boot into primary partition of no button pressed
  2. GPIO is checked by the boot loader directly

I'm basically trying to do something similar to what routers do, where if you hold in reset while it boots you can TFTP over a new image or something.

Is this possible with the Raspberry PI? If so, is there any documentation for doing this sort of thing?


I found this answer to this related question: Is it possible to dual boot from the SD card?

A comment on the above question led me here: http://www.berryterminal.com/doku.php/berryboot. This looks promising, but I'll have to research it more to see if I can get a GPIO read from it. If anyone has any experience with it, I'd be very interested.

  • Let us know how you get on with that, looks interesting :)
    – Jivings
    Commented Dec 4, 2012 at 8:12
  • 1
    I think I found a way to accomplish this by writing a simple 2nd stage bootloader, so I'll make sure to document it here if I get around to it. Still hoping for a simple solution though...
    – beatgammit
    Commented Dec 4, 2012 at 18:29
  • 1
    Unfortunately no, but I significantly reduced the chance of corruption using a RO filesystem: /boot (RO), / (RO), /var (RW), /home (RW). The initial problem was filesystem corruption when power is cut during boot. I'd still like like to write/find a 2nd stage bootloader though.
    – beatgammit
    Commented Nov 30, 2013 at 20:45
  • 1
    You could look at what the NOOBS (raspberrypi.org/archives/4100) bootloader for the Pi does. It might actually suit your purposes just to use it, as it provides for recovery partitions and installation.
    – Fred
    Commented Mar 7, 2014 at 8:11
  • 1
    I am suggesting ''against'' using a custom bootloader, but use hacks that runs after the system is started. It will be easier to implement and safer to debug. A faulty bootloader can fry your Pi. Commented Mar 24, 2014 at 5:19

3 Answers 3


If the error can happen any time after the system started, you can use a watchdog timer and some boot script.

The principle of this method is that whenever the system reboots without properly shut down, it goes to the recovery partition.

You need to write a script that runs every time the system starts and properly shuts down. Change /boot/cmdline.txt to recovery partition when the system starts, and changes back before properly shut down.

Then set up the watchdog timer. You can use the built-in one in the BCM2835 chip, or (if using a revision 2 board) construct your own using two GPIO pins, the reset header P6 and a 555 chip. When the critical program is started start the watchdog timer, and kick the dog periodically if the system is working properly. When the system fails the watchdog timer will be tripped and resets the processor, sends it to the recovery partition. This requires no user interaction as well and if using the built-in timer, no GPIO.

Using this method, you can also implement a reset button that will guarantee to send the system to recovery manually on a Rev. 2 board by installing a button to P6 header.

  • Your first answer is a bit closer to what I'd probably do, but I like the idea of using GPIOs in userspace and a watchdog. While I probably won't use any of the ideas wholesale, you've given me some good ideas. Thanks!
    – beatgammit
    Commented Mar 24, 2014 at 5:54

I have a way of doing this without hacking the kernel, that involves protecting the system from an untimely reboot:

  1. Download the upgrade image, checksum it and expand it into scratch space.
  2. Change /boot/cmdline.txt so that the next time the system boots it uses recovery partition as the root block device.
  3. Install the upgrade from the scratch space and verify that it is working.
  4. If the upgrade is working, change /boot/cmdline.txt back.
  5. If required, reboot.

A failed upgrade will cause the system to be booted into the recovery automatically. No GPIO needed.

  • The only issue here is (depending on the system) a fault may be detected hours after the update completes, at which point the user has no option to revert to the recovery partition.
    – user8894
    Commented Mar 18, 2014 at 9:12
  • 1
    @DanNixon I am posting another answer to resolve this new issue. Commented Mar 18, 2014 at 9:28

Also, there is a third possible solution, but it will require you to dissect initrd of some PC version of Linux distribution to figure out how the syscall pivot_init() works. I am not sure if the kernel of Pi have this syscall. If it does, this method is possible, no kernel hack is required as well, and it uses one GPIO.

To do that, you will need to write a custom init program in the production system. check if the GPIO is on. If so, pivot_root() to recovery. Then exec() the original init so that the system continues to boot. You can, in the production system, figure out a way to keep this GPIO-watching constructed init running side-by-side (PID=2) with the original init (PID=1) and keep an eye on the GPIO and reboot to recovery if the button is pressed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.