Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの 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 件 担当者 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日 12時間
マージ済み PR（30日）
53

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

bootc-dev/bootc のほかの issue

bootc-dev/bootc の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。