The rpi4 fwup.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):

require-uboot-variable(uboot-env, "nerves_fw_active", "b")

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.

Hope that helps.