Updating an identical rootfs with swupdate breaks update cycle

On an A/B rootfs partitioned image, updating the rootfs with the same IMAGE_UUID in /etc/os-release breaks the update cycle. By that, the next boot boots kernel 2, but rootfs 1 instead of kernel 2 and rootfs 2. The next update with swupdate then overwrites the currently mounted partition, hence breaks the OS.

It is also not possible to recover from this situation by just updating again. Detecting these situations in advance is also not trivial, as different hashes of the partition not necessarily mean that the IMAGE_UUID is different as well.

The underlying issue is the selection of the next rootfs mountpoint based on the IMAGE_UUID. This is simply not a trustful source of information as it just provides info about the data in the partition, but not about the location of the partition on disk. Instead, just the partition UUID should be used to select the next rootfs. This is reasonable, as the next kernel is also selected based on the partition.

However, this requires writing the partition UUID to an EFI variable (the next kernel + initrd itself do not know about the corresponding rootfs). Instead, in the initrd the EFI variable should be read and the corresponding partition should be mounted (based on the partition UUID in the GPT). This also makes it possible to switch between A/B without even doing an update at all (e.g. due to a fs corruption).