composefs & UKI: Staging an update, then switching to another image will leave the staged UKI in the ESP

[travier]

I'll have to reproduce this one to get the exact steps but I did something like the following on a composefs + uki system:

• I staged an update with bootc update
• Then I switched to another image using bootc switch
• Then I rebooted
• I got offered the staged update (which should have been cleaned up by the switch)
• Booting the "correct" switched image, bootc was no longer able to figure out the rollback deployment and failed on most commands (at least status)
  • here we should likely just pick one and move on and never fail
• I had to manually clean up 2 UKIs and 1 BLS entry to get back to a working system.

[Johan-Liebert1]

I tried out the steps and I'm unable to reproduce it. These are my steps

[root@fedora var]# bootc switch --transport containers-storage localhost/uki-1
[root@fedora var]# bootc status
[  577.146959] EXT4-fs (vda3): re-mounted 7e324f6d-5e20-4353-b7ab-9f2f0af8e090.
[  577.315226] loop1: detected capacity change from 0 to 29568
[  577.316142] erofs (device loop1): mounted with root inode @ nid 36.
  Staged image: containers-storage:localhost/uki-1
        Digest: sha256:5a8d063701aa67c6660381c52afe8c60a29d5f160f2519e9b76a99f0323b0d3b (amd64)
        Verity: 34a7f98afd6d14bc9983253a0b9c88a0a7b691c042ad03a1bcbf3dd464f4f1f115e11a6f96a57fa4671617abaae97186b0dfbab87f2c91109d48a882361b2d36
     Timestamp: 2026-04-28T04:53:29Z

● Booted image: localhost/bootc-uki-norootpass
        Digest: sha256:98c27fb3c246bb0030c0ddd26da4efe761e495249f24f0c2c955b1f228117c75 (amd64)
        Verity: a6622f82b5e2e3997a9857428f2c192b02073153a8beadc7fb4587be43c62d9ae182f10ed363c899b141fe908b0e3c21b045e95109d1fea183ac716f42061f87
     Timestamp: 2026-04-15T07:43:36Z
  /usr overlay: transient, read/write

[root@fedora var]# bootc switch --transport containers-storage localhost/uki-2
[root@fedora var]# bootc status
[  656.075952] EXT4-fs (vda3): re-mounted 7e324f6d-5e20-4353-b7ab-9f2f0af8e090.
[  656.245175] loop1: detected capacity change from 0 to 29568
[  656.246205] erofs (device loop1): mounted with root inode @ nid 36.
  Staged image: containers-storage:localhost/uki-2
        Digest: sha256:b117ef05dccd125ae62b16af173151b8351b03c46233179c6508db6b4950950d (amd64)
        Verity: 7d05417f659c3340b098b8a9d823e82e43964d065061000eef1fd489e72a4eb72ff9bc3f75cc2f8bae19e42d29863bfa56c55a5e73894e2e3fd2b8a5b5a24e4c
     Timestamp: 2026-04-28T04:55:44Z

● Booted image: localhost/bootc-uki-norootpass
        Digest: sha256:98c27fb3c246bb0030c0ddd26da4efe761e495249f24f0c2c955b1f228117c75 (amd64)
        Verity: a6622f82b5e2e3997a9857428f2c192b02073153a8beadc7fb4587be43c62d9ae182f10ed363c899b141fe908b0e3c21b045e95109d1fea183ac716f42061f87
     Timestamp: 2026-04-15T07:43:36Z
  /usr overlay: transient, read/write

On rebooting, I correctly boot into the deployment with verity 7d054...

does this happen after multiple upgrade/switch cycles? I did only try once

[travier]

Ah, one element that may matter, the first switch was from a F44 image to a F45 one, and then back to a F44 one. It's the F45 one that was left over.