Building the firmware went fine. The target device is a CM4 that is running Nerves, happily.
Could it be a partition resize or something?
lawik@monolith:~/nervescloud/contain$ ./upload.sh nerves-7170.local
Path: ./_build/nerves_containers_rpi4_dev/nerves/images/contain.fw
Product: contain 0.1.0
UUID: 5b76be06-ce28-55b8-b55f-d71226ae873f
Platform: rpi4
Uploading to nerves-7170.local...
fwup: Please check the media being upgraded. It doesn't look like either the A or B partitions are active.
I don’t know how to dig in and do what it is asking me to do. Check the media
My first step would be checking nerves_fw_active in Nerves.Runtime.KV as well as consulting fdisk to see if there are partitions as expected on the device.
The rpi4fwup.config still uses partition offsets to determine whether it’s running off the A or B partition. See this line for requiring that the partition offset be the B partition’s offset for a partition A update to happen.
One way to fix this is to use something else to determine which partition is active. For example, you could delete that line and add this instead to check the U-Boot environment variable that Nerves.Runtime.KV sees (also make the corresponding change for upgrading the a partition):
However, before you do this, make sure that your new A or B partitions don’t overlap with the old ones. If they do, you could be overwriting the partition that you’re running off of to perform the update.
It’s pretty tricky to deploy firmware updates that enlarge root file systems. Hopefully you don’t have to do this on remote devices. If I had to do this on a lot of devices, I’d looks to see how much can be done with the padding between filesystems. If the partitions are back-to-back with no room to grow (like the default rpi4 ones), then I’d look into ways to avoid growing them. If there were no way, then I think that’s I’d create a firmware with an initramfs that knows how to move everything. I’d use an initramfs so that Linux won’t have mounted the root or data partitions that would be moved.