-1

I have a RPi 4B - it is installed in a 3D printer. The image I am using has two partitions - bootfs (256 MiB) and rootfs (remaining space). There is ~4MB of unallocated space at the start, not sure if this is used for anything (Boot sectors or something maybe?) I am trying to find a way to back up and restore without having to use Belena Etcher - the reasons being:

  1. Some of my SD cards that are ostensibly the same size report different sizes (Samsung=59.68GB, Sandisk=59.48GB), so Belena will not clone from the larger to the smaller
  2. I do not want to be limited to SD cards of the same size. If needs be, I want to be able to shrink rootfs down so I can backup from a 64GB to a 32GB card
  3. I want to be able to store backups on the HDD of my Windows PC, and not solely rely on SD to SD clones - Ideally I want to be able to compress the images

So, I am currently using an Ubuntu VM in Virtualbox to clone the partitions. Initially, I did have success - I used a combination of GParted (To create / resize partitions etc) and Gnome Disk (To backup / restore images) I am in the process of doing some updating and tweaking of my printer's OS - I got the first few steps done, and in that process I did some backups and reverted back to them OK once or twice, so I know it CAN work, and I have a high confidence that all the SD cards that I am using are good, as they did work within the last few days.

However, now this process has stopped working and I am not sure why. What happens is, that when I boot up the Pi, it freezes just after detecting the USB devices. The screen looks like this: screenshot of failed boot

Any idea what is wrong and why this card will not boot?

Also, as a follow-on question, I would welcome any suggestions for a good workflow to backup and restore. My ideal requirements are:

  1. Should be able to back up / restore solely by ejecting the SD card and manipulating it on my windows PC (Having to use a linux VM is fine). I do not want to have to plug in a keyboard to the Pi, as it is buried inside an enclosure. I have an SD card extender which has a really thin ribbon cable that will fit through the vents, allowing me to access the SD card slot without taking the printer apart, but this would be much harder to do with USB and HDMI.
  2. Ideally the images should be about the size (or less) of the used space on the card If this used compression, it should be able to do this on the shared folder on the VirtualBox machine - ie not using the VM's virtual disk, but using the underlying physical disk. I do not want to have to keep a >64GB virtual disk for the VM. I did find pisafe, but it seems to use pishrink and it's readme says that doing this has known issues.
  3. I should be able to vary the size of SD cards. Currently my working image is on a 64GB card (Although only <32GB is partitioned, the rest is unallocated). I would like to be able to use either 32GB or 64GB cards, as needed

1 Answers1

0

I worked this one out for myself, but many thanks to @Milliways for his input - he was bang on the money, although his script would not work in all instances for me.

The root cause is indeed that when you restore the cloned images, so long as you use the same SD card, things will work, because the Disk ID is the same, and so the derived PARTUUIDs remain the same. Once you flash to another SD card however, the partitions will have a new PARTUUID, and the PARTUUID for bootfs and rootfs are referenced in various files within the image, and so do not match.

So to lay it out for anyone stumbling onto this thread later: Once you have restored the partitions, find your new PARTUUIDs:
sudo blkid
Find your disks in the output, eg:

/dev/sdb1: LABEL="bootfs" UUID="9E81-4F92" TYPE="vfat" PARTUUID="d52ac8d6-01"
/dev/sdb2: LABEL="rootfs" UUID="cf2895ca-6dc2-4797-8040-f76ba1508f41" TYPE="ext4" PARTUUID="d52ac8d6-02"

Edit /cmdline.txt in the bootfs partition, it will look like this:
console=tty1 root=PARTUUID=a14fe19f-02 rootfstype=ext4 fsck.repair=yes rootwait
So in this case, I need to replace a14fe19f with d52ac8d6

Edit /etc/fstab in the rootfs partition. It will look something like this:

proc            /proc           proc    defaults          0       0
PARTUUID=a14fe19f-01  /boot           vfat    defaults          0       2
PARTUUID=a14fe19f-02  /               ext4    defaults,noatime  0       1

Again, I need to replace a14fe19f with d52ac8d6, but twice this time

WRT the best workflow issue, I am still working on it. In terms of dumping / restoring an image (Without any compression), so far, kde-partitionmanager has been working well for me. I prefer it over the gparted / gnome disk option as it merges the functionality of both into one.

I am also investigating qt-fsarchiver, which seems to be capable of backing up and restoring compressed images, but I have had mixed results with that