メニュー
UEFI/OVMF reboot testing guidance. Load when adding or debugging UEFI boot paths in the e2e workflows.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/projectbluefin/testsuite --skill uefi-bootコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Task → skill router and hard-rule set for projectbluefin/testsuite. Load this first in every session, then load only the sub-skills your task needs.
How to write behave scenarios and step definitions for the testsuite repo. Load when editing .feature files or steps.py.
How to call and debug the reusable testsuite e2e workflow. Load when changing e2e.yml, action inputs, or consumer-repo wiring.
SOC 職業分類に基づく
SKILL.md を表示中
| name | uefi-boot |
| version | 1.0 |
| last_updated | 2026-07-20 |
| id | uefi-boot |
| one_line_purpose | Add or debug UEFI/OVMF reboot test paths. |
| entry_point | docs/skills/test-authoring/uefi-boot/SKILL.md |
| category | test-authoring |
| mcp_compliance_level | partial |
| status | active |
| dependencies | [] |
| tags | ["uefi","ovmf","boot"] |
| description | UEFI/OVMF reboot testing guidance. Load when adding or debugging UEFI boot paths in the e2e workflows. |
| metadata | {"type":"pattern","audience":"agents","maturity":"stable"} |
Load when: working on migration tests that require VM reboots, modifying the QEMU boot pipeline, or debugging UEFI/systemd-boot issues in CI.
The existing e2e.yml uses direct kernel boot (-kernel/-initrd/-append). This extracts vmlinuz and initramfs at disk-setup time and passes them directly to QEMU. The VM always boots the same kernel — rebooting after bootc switch still boots the original deployment because QEMU re-uses the same kernel args.
Migration tests need the VM to boot the new deployment after bootc switch + reboot. UEFI boot via OVMF + systemd-boot solves this: systemd-boot reads BLS (Boot Loader Specification) entries from the disk and picks the highest-priority entry, which is the staged deployment after a switch.
| Partition | Type | Mount point | Contents |
|---|---|---|---|
| p1 | EFI System | /boot/efi | EFI/BOOT/BOOTX64.EFI (systemd-boot fallback binary), EFI/systemd/systemd-bootx64.efi |
| p2 | xbootldr | /boot | loader/loader.conf, loader/entries/*.conf (BLS entries), kernel + initramfs per deployment |
| p3 | Linux filesystem (ext4) | / | ostree root (deployments, /var, etc.) |
BLS entries live in p2 (/boot/loader/entries/), not p1.
Use OVMF_CODE_4M.fd (4MB pflash variant). The standard 2MB OVMF_CODE.fd works for simple UEFI boot but systemd-boot on Fedora writes more EFI variables than fit in the 2MB variable store.
On ubuntu-latest (GHA runner), install the ovmf package:
sudo apt-get install -y --no-install-recommends ovmf
Files:
/usr/share/OVMF/OVMF_CODE_4M.fd — read-only firmware code/usr/share/OVMF/OVMF_VARS_4M.fd — writable variable store template# Copy VARS to a writable per-VM location (pflash needs read-write access).
cp /usr/share/OVMF/OVMF_VARS_4M.fd ./ovmf_vars.fd
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-cpu host \
-m 4096 \
-smp 4 \
-drive if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
-drive if=pflash,format=raw,unit=1,file=./ovmf_vars.fd \
-drive if=none,id=disk,file=disk.raw,format=raw,cache=unsafe,aio=threads,discard=unmap \
-device virtio-blk-pci,drive=disk \
...
Key points:
unit=0 (read-only) = firmware codeunit=1 (writable) = EFI variable store — must be a per-VM copy, not the system templateEFI/BOOT/BOOTX64.EFI| Aspect | Direct kernel boot | UEFI boot (OVMF) |
|---|---|---|
| QEMU flags | -kernel vmlinuz -initrd initramfs.img -append "root=UUID=..." | -drive if=pflash,... (two pflash drives) |
| Kernel args | Passed via -append | Written in BLS entries by bootc |
| Reboot behavior | Always boots same kernel | systemd-boot picks highest-priority BLS entry |
| Extra packages | None | ovmf (apt) |
| Boot time | Faster (~30s to SSH) | Slightly slower (~45-60s — UEFI firmware init + systemd-boot menu timeout) |
| Kernel extraction | Required (copy vmlinuz/initramfs from disk) | Not required (systemd-boot reads from xbootldr) |
| ostree boot.N symlink workaround | Required | Not required (bootc sets up BLS entries correctly) |
systemd-boot defaults to a short menu timeout. In CI, set timeout 0 in loader/loader.conf to skip the boot menu entirely (no human interaction in CI). If loader.conf is missing, systemd-boot auto-boots the default entry after a brief pause.
After bootc switch <target>:
/boot/loader/entries/ with a higher sort keyThis is the core mechanism that migration tests validate.
--help before using.systemd.mask=... in -append. With UEFI boot, masking must be done on-disk (symlink to /dev/null in the deployment's /etc/systemd/system/) — which e2e.yml already does.Modern bootc/ostree images write Boot Loader Specification (BLS) entries (/boot/loader/entries/*.conf) regardless of whether the physical distribution targets GRUB 2 (like Bluefin / Bluefin LTS) or systemd-boot (like Dakota).
Core Virtualization Rule: In the QEMU pipeline, always run loopback installation with --bootloader systemd.
The spike is implemented in .github/workflows/spike-uefi-boot.yml. Run it via Actions → "Spike: UEFI Boot" → Run workflow. It:
ublue-os/bluefin:stable to disk with --bootloader systemdbootc switch to projectbluefin/bluefin:stable