composefs: bootc status/upgrade/switch use the first ESP on the disk instead of the one the system booted from (dual-boot with Windows) #2554

Symptom

On a dual-boot machine (Windows + bootc composefs, systemd-boot), every storage-touching verb fails:

$ sudo bootc status
error: Status: Prepending custom prefix to EFI and BLS entries: Getting sorted Type1 boot entries: No such file or directory (os error 2)

The system itself boots fine from the correct ESP.

Environment

• bootc 1.16.9, composefs backend, systemd-boot 257.13 (Debian 13 trixie)
• UEFI, Secure Boot disabled
• One NVMe disk, GPT, two ESPs:

NAME        FSTYPE      PARTTYPENAME                 SIZE   PARTUUID
nvme0n1p1   vfat        EFI System                   100M   e5ff1c7b-ad03-4765-b4b8-508d7c0ac2bc   <- Windows/HP ESP (EFI/Boot, EFI/HP, EFI/Microsoft)
nvme0n1p2               Microsoft reserved           16M
nvme0n1p3   ntfs        Microsoft basic data         276.1G
nvme0n1p4   ntfs        Windows recovery environment 743M
nvme0n1p5   vfat        EFI System                   1G     124d3e1f-7290-4cba-8cd1-cbfe0532c383   <- Linux ESP (EFI/systemd, EFI/Linux, loader/entries)
nvme0n1p6   crypto_LUKS Linux root (x86-64)          199G

bootctl status confirms systemd-boot was loaded from p5:

Partition: /dev/disk/by-partuuid/124d3e1f-7290-4cba-8cd1-cbfe0532c383
   Loader: └─/EFI/systemd/systemd-bootx64.efi

p5 contains the expected bootc layout (loader/entries/bootc_debian-13-1.conf, EFI/Linux/bootc_composefs-<digest>/{vmlinuz,initrd}), matching the booted composefs= karg. p1 has no loader/ directory.

Trace

$ sudo RUST_LOG=trace bootc status
...
TRACE exec: "lsblk" "-J" "-b" "-O" "/dev/nvme0n1"
TRACE exec: "findmnt" "-J" "-v" "--output=SOURCE,TARGET,MAJ:MIN,FSTYPE,OPTIONS,UUID"
DEBUG find_mount_target_by_source: no mount found for source /dev/nvme0n1p1; ...
error: Status: Prepending custom prefix to EFI and BLS entries: Getting sorted Type1 boot entries: No such file or directory (os error 2)

bootc selects /dev/nvme0n1p1 (the Windows ESP). Mounting p5 at /boot, /sysroot/boot or /sysroot/boot/efi beforehand does not change the outcome.

Root cause

Device::find_partition_of_esp_optional() in crates/blockdev/src/blockdev.rs returns the first partition with the ESP type GUID. With more than one ESP on the disk, that is not necessarily the one in use. This still appears to be the case on main.

Related

• bootc install to-filesystem uses the wrong efi partition #1929: the same first-ESP selection affects bootc install to-filesystem. lib/install: Use mounted ESP for install to-filesystem #1953 addresses that by using the mounted /boot/efi, but it only covers the install path, not runtime status/upgrade/switch.
• composefs: bootc status/upgrade/switch fail with "Type1 boot entries: No such file or directory" on non-EFI systems that use BLS layout #2375: same error message, different cause (non-EFI boot).

Suggested fix

On a running UEFI system, prefer the ESP identified by the LoaderDevicePartUUID EFI variable (set by systemd-boot and other loaders implementing the Boot Loader Interface), and fall back to the first ESP only when that variable is absent. Optionally also honour an ESP mounted at /boot, /efi or /boot/efi.

Workaround

Changing the Windows ESP's partition type away from "EFI System" would presumably make bootc pick p5 (as reported in #1929), but that risks breaking Windows boot, so it isn't a real option for dual-boot users.