Configuration backup/restore for sysupgrade on raspberry pi

I have 22.03 custom image for raspberry pi that seem to lose configuration after each sysupgrade, even if I set the options to backup existing configuration. This happens both with command line update and updates via luci.

I currently have 4 partitions on my SD card:

# block info
/dev/mmcblk0p1: UUID="757A-9C82" LABEL="boot" VERSION="FAT16" MOUNT="/boot" TYPE="vfat"
/dev/mmcblk0p2: UUID="e2400fca-65609b04-7f89a028-7717999d" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/mmcblk0p3: UUID="c4f41aa6-aafc-45ce-810e-e652972e85b1" LABEL="rootfs_data" VERSION="1.0" MOUNT="/overlay" TYPE="ext4"
/dev/mmcblk0p4: UUID="fa44f27c-a6ab-4db7-9afc-f535e39003f3" LABEL="data" VERSION="1.0" MOUNT="/data" TYPE="ext4"

Root is an overlayfs with the read-only part from the squashfs partition and the overlay from the ext4 one. This is mounted correctly.

I see that platform.sh is supposed to save sysupdate.tgz on the boot partition during the update (in /lib/update/do_stage2).

I replaced the reboot command in /lib/update/do_stage2 with a sleep 3600 to be able to check if the file is written on the sd card and it does (both with update from command line and from the webui).

When the system reboots /lib/preinit/79_move_config check if the file exists and moves it to /, then 80_mount_root extracts it over existing /, restoring the configuration.
I changed the mv command with a cp and then a mv (to check if file was actually processed) and it is moved.
I also renamed /etc/preinit to /etc/_preinit and added a custom preinit that logs messages to a file under /tmp:

#!/bin/sh

echo "4" > /tmp/debug_level

/etc/_preinit > /tmp/preinit.log 2>&1

I added mount, ls / and ls /boot commands to 80_mount_root to check what's actually mounted on my system, this is the output of preinit:

---
rootfs_data: clean, 48/65536 files, 26767/262144 blocks
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mmcblk0p3 on /overlay type ext4 (rw,relatime,nodelalloc,data=journal)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
---
bin
boot
data
dev
etc
lib
lib64
mnt
overlay
proc
rom
root
sbin
sys
tmp
usr
var
version.txt
www
---
COPYING.linux
LICENCE.broadcom
System Volume Information
bcm2710-rpi-3-b-plus.dtb
bcm2710-rpi-3-b.dtb
bcm2711-rpi-4-b.dtb
bootcode.bin
cmdline.txt
config.txt
distroconfig.txt
fixup.dat
fixup4.dat
fixup4cd.dat
fixup4x.dat
fixup_cd.dat
fixup_x.dat
kernel8.img
overlays
start.elf
start4.elf
start4cd.elf
start4x.elf
start_cd.elf
start_x.elf
sysupgrade.tgz.old
---

As you can see everything seems to be mounted correctly but sysupdate.tgz is not in / . On the other side the .old file has been created, and this is puzzling me...
I do:
[ -f "/boot/$BACKUP_FILE" ] && cp -f "/boot/$BACKUP_FILE" / && mv -f "/boot/$BACKUP_FILE" "/boot/$BACKUP_FILE.old"
so if the backup is there, the file must have been copied (I delete the backup copy after each test and I can confirm that /boot/sysupgrade.tgz was there before rebooting).

I try to reconnect and the ssh key under /etc/dropbear has changed and my wifi configuration is gone.

In 80_mount_root the copy is executed immediately after mounting rootfs:

do_mount_root() {
        mount_root
	boot_run_hook preinit_mount_root

It's there something erasing the overlay or remounting / in between?

I noticed that if I re-flash the same version I am already running the configuration is kept and the output of the preinit scripts shows that the sysupdate file is in the right place.
Is it possible that the whole preinit sequence is executed twice when the image has been changed?
That would explain why the file is renamed but not applied...

Ok, this seem to be the case...
I changed the mv instruction in 79_move_config to a cp and added an init.d script to remove the file from /boot/ at the end of the boot process and now my configuration is restored successfully every time.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.