Pi 4B “Factory Reset” Strategy Ideas

[johntomko1]

Hello,

Some backstory, I’m using a Pi in a device that closes off access to the Pi itself. In case something goes wrong and I want to “reset” the SD card image, I can’t remove the card to re-image it.

On a previous version of the device, I used a Pi 3A+, an exposed push-button, and GPIO boot mode selection to decide whether to boot from an SD card or an inserted USB device. The SD card had the operational software, the USB drive had a copy of the SD card’s image and would do nothing but dd it to the SD card and shut down.

I’d like to upgrade to a Pi4, but on the Pi4 both USB boot and GPIO boot are not options. So my idea is:

A push button that, once the SD card boots, can read a GPIO pin to decide if the button is pushed or not. If it is, I can read from a mounted USB device that’s storing a copy of the SD card’s file system and “copy” everything from the USB drive to the SD card. The problem is that if something causes the SD card to not boot properly, I can’t actually reset like I could before by switching to an entirely different device.

Any thoughts on how to make an inaccessible SD card “unbrickable?” Or is that about as close as I‘m going to get?

[fruitoftheloom]

Hello,

Some backstory, I’m using a Pi in a device that closes off access to the Pi itself. In case something goes wrong and I want to “reset” the SD card image, I can’t remove the card to re-image it.

On a previous version of the device, I used a Pi 3A+, an exposed push-button, and GPIO boot mode selection to decide whether to boot from an SD card or an inserted USB device. The SD card had the operational software, the USB drive had a copy of the SD card’s image and would do nothing but dd it to the SD card and shut down.

I’d like to upgrade to a Pi4, but on the Pi4 both USB boot and GPIO boot are not options. So my idea is:

A push button that, once the SD card boots, can read a GPIO pin to decide if the button is pushed or not. If it is, I can read from a mounted USB device that’s storing a copy of the SD card’s file system and “copy” everything from the USB drive to the SD card. The problem is that if something causes the SD card to not boot properly, I can’t actually reset like I could before by switching to an entirely different device.

Any thoughts on how to make an inaccessible SD card “unbrickable?” Or is that about as close as I‘m going to get?

You will be trying to overwrite a running Operating System, best to wait until 4B USB Boot is released.

[Botspot]

You may be able to do something similar to what NOOBS does: it has its own dedicated partition, so if the main OS gets corrupted, just press shift during boot and you can reinstall the main OS.

[hippy]

The 4B doesn't support USB booting yet but does support network booting so you should be able to do the same 'factory reset' with a laptop rather than USB memory stick. No idea how though.

Or just set use of a 4B aside until USB boot is implemented.

[RonR]

Or just set use of a 4B aside until USB boot is implemented.

Or boot to and run Raspbian from a USB device now on any Raspberry Pi (including the 4B): Running Raspbian from USB Devices : Made Easy

[RonR]

A push button that, once the SD card boots, can read a GPIO pin to decide if the button is pushed or not. If it is, I can read from a mounted USB device that’s storing a copy of the SD card’s file system and “copy” everything from the USB drive to the SD card. The problem is that if something causes the SD card to not boot properly, I can’t actually reset like I could before by switching to an entirely different device.

Any thoughts on how to make an inaccessible SD card “unbrickable?” Or is that about as close as I‘m going to get?

In addition to the problem already mentioned (you can't overwrite the SD card your running on), your approach assumes that the SD card is still healthy enough to boot and run. SD card corruption often results in the Raspberry Pi failing to boot at all. I would suggest that running from a USB flash drive and using the SD card only for recovery is a more reliable approach. It would work something like this:

Create your SD card to do what it normally does. In addition, have it monitor a GPIO pin for a button closure. If a button closure is detected, execute the following:

Code: Select all

yes | sdc-boot /dev/mmcblk0p2

Then run usb-boot to replicate the SD card to a USB flash drive. Reboot and you'll be running from the USB flash drive.

If you want to reconstruct the USB flash drive, press the button and the Raspberry Pi will reboot into the SD card. Log in via SSH and run usb-boot again, reboot, and you're starting fresh.

If you don't have network access to the Raspberry Pi or would like to totally automate the process, do the following instead of using usb-boot:

Boot the SD card and run image-backup and image-set-partuuid to create /media/backup.img:

Code: Select all

image-backup -i /media/backup.img
image-set-partuuid /media/backup.img random

Create the following script and make it executable:

Code: Select all

#!/bin/bash

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

dd bs=4M if=/media/backup.img of=/dev/sda
sync
yes | sdc-boot /dev/sda2

Insert the script pathto/name as the line just before the 'exit 0' in /etc/rc.local.

The next time you boot the SD card and each time you press the button, the USB flash drive will be reconstructed and booted.

Both of these methods have been tested and verified to work.

For maximum reliability, you should power the Raspberry Pi from a UPS with accompanying shutdown software should the UPS near exhaustion (NUT is an excellent candidate).

[dickon]

(you can't overwrite the SD card your running on)

No, but you can rewrite it from an initrd, so it isn't an entirely stupid thing to think about.

Assuming you can load the GPU's OS files, the kernel, and an initrd from that SD card -- not a given, what with wear-levelling -- then that's probably the approach I'd take: check the GPIO pin status in the initrd, and attempt to mount a USB stick with a rescue script of some sort from it if it's pressed.

A boot order of SD then network might be worth a shot, too, depending on how the fallback works: it'll need some testing, and may not be suitable for the environment.

[kerry_s]

maybe you can use the new net boot(pxe?) that way you can just setup the sd card, set it to read only overlay, then that should prevent any need to fiddle with the actual device.
just use the forum search, i didn't bother to read into it so it's not in my history.

just thinking.

[dickon]

PXE != netboot[0]. Aside from that, there's a good reason to wonder what the actual problem is: if it's an appliance, then an RO filesystem (or even initrd) with a tmpfs RW overlay for logs and whatnot might be better. Removes all writes to the SD card -- massively prolonging its life -- and makes upgrades simple.


[0][1] 'PXE' is the 'Preboot Execution Environment', which is an Intel-designed mess designed to present a standardised network card boot ROM to a normal x86 BIOS to allow for the network booting of DOS. It uses DHCP and TFTP, but that's because the rest of the world netboots using DHCP / BOOTP / RARP or whatnot (these days DHCP exclusively), and TFTP to load images into RAM. Nothing not-x86 feels the need to do the BIOS-specific bits, and hence 'PXE'. Funny, that.

[1] This is a simplified overview.

[procount]

@Johntomko1. As Botspot said:

You may be able to do something similar to what NOOBS does: it has its own dedicated partition, so if the main OS gets corrupted, just press shift during boot and you can reinstall the main OS.

A better solution to NOOBS would be to use PINN, as it includes VNC and SSH support so you can access it remotely over a network.
As stated by botspot, it runs in a separate partition to your main OS, so it also guards against your main BOOT partition becoming corrupted as well as your ROOT partition getting corrupted. (It will not guard against your SD card becoming totally unreadable, but that's the same as your existing solution which requires to read the firmware and config.txt files).

PINN can restore a whole OS from a USB stick, so you can easily restore an OS image to return to a factory reset condition.
It can also backup an OS, so you could have the choice of which backup you want to restore.
It supports a GPIO push button on GPIO3, so you can set it to normally boot into your OS, but if/when it fails, you can press the push button on boot to enter PINN and then choose to restore/replace your OS with another one. If your PI is connected to the internet, you could restore your backup from a website instead of a local USB drive.

The above does require some user interaction to choose the OS to restore.
However, PINN has a "silentinstallnewer" feature that will automatically reinstall an OS if a new version is found to exist on the next reboot. So to force a reinstall of the OS back to factory defaults, it is only necessary to update the date of the factory default OS image and reboot. This works best if the factory OS image as stored on the network/internet since the date is readily accessible.

[dividuum]

Some backstory, I’m using a Pi in a device that closes off access to the Pi itself. In case something goes wrong and I want to “reset” the SD card image, I can’t remove the card to re-image it.

My OS has a similar optional feature: Holding a configurable GPIO button results in the data partition being reformatted. That essentially results in a factory reset in my case. The prerequisite for that is that the complete OS itself is read-only and separate from any mutable user data. I my case the complete OS is build around that and root is on a squashfs. A similar setup should be possible with Raspbian as well: Configure the OS and add the required logic to mount an overlay FS that saves the "upper" part on an extra partition before completely botting up. On every boot, some custom code would check if the GPIO button is pressed and in that case will wipe or reformat the "upper" part of the overlay FS. This essentially results in a factory reset. As the main OS is separate and thanks to overlayfs can be read-only, it should be mostly unaffected by FS corruption due to power loss or similar. Of course if the SD card breaks, that won't help, but neither would copying from USB.