7

I'm developing a Buildroot OS for the Raspberry Pi, and my workflow requires very frequent re-flashing of the SD card to test new iterations. The process of removing the SD card from the Pi, flashing it on a Windows PC and then re-inserting it takes a lot of time. I would like to write a script that uses the currently running OS on the Rpi (accessed over SSH) to

  1. Download the new SD image
  2. Flash it to the SD, overwriting all existing OS files
  3. Reboot into the new OS

Step 2 is where I'm stuck. Is it possible for an operating system to overwrite itself?

Jeremiah Rose
  • 249
  • 4
  • 11

6 Answers6

11

To overwrite itself, your operating system must run fully in RAM and neither read nor write from SD card after booting. piCore/TinyCore is probably one of the few Linux OS which can do that.

flakeshake
  • 6,244
  • 1
  • 16
  • 35
6

As pointed out elsewhere, dd-ing over a running OS is never a good idea. An alternative (and the usual way you'd develop embedded systems) is to have your OS image served from a network drive and the target board perform a network boot. This speeds up the initial development and you only need to write out the SD cards as you get closer to completion and need to test on actual hardware.

There's a write up on setting the PI3B and PI3B+ to boot from a server on the Foundation pages: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

Roger Jones
  • 1,484
  • 8
  • 14
3

Use an SD card large enough to hold multiple partitions

The SD card should hold a boot partition (0) and three OS partitions (1-3).

The boot loader on the boot partition would examine the partition labels to determine what to load. Suppose the labels are:

0: BOOT
1: OS-0004!
2: OS-0002
3: OS-0003

The loader knows to load the OS from partition 1, as it's the last label when they're sorted. And the first OS label is partition 2, to which it writes the update

2: OS-0005_

This is now the last label, but the underscore flag tells the loader it's the first attempt to boot from it. It changes the label to indicate it's doing a test boot right before it chains to it:

2: OS-0005? If the OS successfully boots and passes its own sanity checks, it updates the label one more time, as well as the label of the previous OS partition: 1: OS-0004 2: OS-0005!

If it fails, the next time it tries to boot, it will see the ? flag and revert to load from partition 1, whereupon the update will start over.

Monty Harder
  • 131
  • 2
2

Use with caution

This works for me because I am using a read-only root filesystem with a custom Buildroot OS. This script hasn't been tested on Raspbian yet, but will probably work.

#!/bin/bash
set -e
echo "Copying image to RPi..."
sshpass -p PASSWORD scp /PATH/TO/SDCARD.img USER@RPI:/tmp/sdcard.img
echo "Flashing image to /dev/mmvblk0 on RPi..."
sshpass -p PASSWORD ssh USER@RPI 'nice -20 sudo sh -c "sync && dd if=/tmp/sdcard.img of=/dev/mmcblk0 conv=fdatasync && reboot -f"'

This should be run on the host computer (not the RPi) and does the following:

  1. Copies the SD image to the RPi via scp
  2. Logs into the RPi via ssh
  3. Syncs all pending OS write operations to SD card
  4. Sets priority to -20 to prevent other processes from running
  5. Flashes the image to the SD card followed by a fdatasync
  6. Performs a hard reset

Limitations:

  • If data is written to the SD card by another process while the script is running, the SD may become corrupted. In a few days of active use, I haven't encountered this yet - but I am not using Raspbian.
  • Make sure you only use this script for development/testing, not for upgrading your OS or any other data-sensitive applications.
  • Could use some improvements to further prevent other processes from accessing the SD card - suggestions welcome.

To use:

  1. Copy the above script into a flash.sh file on your host PC
  2. Fill in your settings for password, username, SD image etc
  3. Make it executable with chmod a+x flash.sh
  4. Install sshpass and ssh on host: sudo apt install sshpass openssh
  5. Make sure ssh login is working on the RPi
  6. Run ./flash.sh
Jeremiah Rose
  • 249
  • 4
  • 11
2

Here a rough approach:

  1. Replace /sbin/init with upgrade tool.
  2. Tell init to re-exec itself.
  3. Kill all other remaining processes (for example with kill -9 -1)
  4. Use pivot_root and chroot to replace the root filesystem.
  5. If necessary exec the next stage to drop references the old root.
  6. Recursively unmount the old root.
  7. Write the new image.
  8. Reboot.
Timothy Baldwin
  • 121
  • 1
0

I've been thinking about something similar for testing development/deployment from a fresh install of Raspbian. My current thinking is a dual sd-card, usb-drive set up. So on each boot, the pi first boots into the sd-card, flashes a fresh install to the usb drive, and then chroots into the usb-drive to start the os.

Though as this is only text, i've only thought about it conceptually while manually flashing sd card's with other devices. So I guess I should start looking into implementation..

Benjamin Collins
  • 101
  • 3