I'm trying (and failing so far) to figure out why my 19.07 based RaspberryPi installations loose all config data when sysupgrading to 22.03. The 19.07 setups are using sqashfs+f2fs already, not ext4. It is a custom build, but basically just fewer routing related packages and more IoT ones enabled in menuconfig.
I narrowed the problem down to the fact that the /boot partition increases from 20M to 64M. If I build the 22.03 image with a 20M boot partition (which is still just barely enough for bcm2708, but too small for bcm2709), the upgrade works.
I also found that it is not a 19.07 vs 22.03 issue, the same problem happens when I upgrade a 22.03 with 20M /boot to 64M /boot.
The relevant code seems to be in
/target/linux/bcm27xx/base-files/lib/upgrade/platform.sh, in particular the
platform_do_upgrade() function. It makes a distinction between partition table unchanged and changed. In the changed case, the entire image with all partitions is written as a whole, followed by an interesting comment and two partx statements:
# Separate removal and addtion is necessary; otherwise, partition 1 # will be missing if it overlaps with the old partition 2 partx -d - "/dev/$diskdev" partx -a - "/dev/$diskdev"
The comment exactly describes the case of an expanding /boot partition.
Curiously, sysupgrading from a 22.03 with 64M /boot down to a version with 20M /boot works without loosing the overlay backup. This is also a partition table change and triggers the same alternative code path in
platform_do_upgrade(), but apparently works.
It seems to me that
platform_copy_config() is failing to actually mount /boot after a /boot partition size increase, which would explain why the backup gets lost (including
platform_copy_config() is trying to extract and apply early from the backup so these are already there at reboot).
I totally fail to see what could prevent partx to fail to make /boot mountable in this case, and I haven't figured out a way to singlestep this to see what happens.
So any ideas how to approach this are very welcome!