Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#2,554 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@Johan-Liebert1 已经在做这个了。

开始于 2026年10月8日。

  • #2555 来自 @Johan-Liebert1 —— 未关闭

评估

这个 Issue 还没有评估数据。

描述

triaged

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

  • #1929: the same first-ESP selection affects bootc install to-filesystem. #1953 addresses that by using the mounted /boot/efi, but it only covers the install path, not runtime status/upgrade/switch.
  • #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.

主要语言
Rust
星标
2.3k
派生
230
平均合并
2 天 19 小时
30 天内合并 PR
56

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

bootc-dev/bootc 的其他 Issue

查看 bootc-dev/bootc 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。