aarch64 image is missing /usr/lib/bootc/install/00-defaults.toml (and boot-test findings)

[hanthor]

While standing up an aarch64 boot gate (fork lab hanthor/dakota, context: PR #1190), bootc install to-disk from dakota:aarch64 (multirunner build of testing @ 6ca571f-era graph) failed with "No root filesystem specified" then "bootupd is required for ostree-based installs".

In-image diagnostics (run 29991003554):

• /usr/lib/bootc/install/ is empty — 00-defaults.toml (bootloader=systemd, root xfs) is not in the image, even though bluefin/bootc-install-config.bst is in bluefin/deps.bst with no arch conditional. With no config, bootc falls back to the bootupd path (binary also absent — expected for the sd-boot backend) and has no root fs type.
• mkfs.xfs is absent (btrfs/ext4/vfat present) — so even with the config present, the declared type = "xfs" cannot work on aarch64 (and possibly x86? worth checking whether xfsprogs is anywhere in the graph — the Justfile's own default is BUILD_FILESYSTEM=btrfs, contradicting 00-defaults.toml).
• Present and healthy: bootc 1.15.1, systemd-bootaa64.efi, btrfs-progs.

Questions for maintainers:

1. Why does the built aarch64 image lack the bootc-install-config output despite the element being in the graph? (x86 e2e installs work, so x86 images presumably have it — arch-dependent artifact merge issue? stale cached artifact?)
2. Should 00-defaults.toml switch to btrfs (matching BUILD_FILESYSTEM and what the image can actually mkfs), or should xfsprogs join the graph?

Workaround in the fork lab: bind-mounting an equivalent config (bootloader=systemd, root btrfs) into the install container — boot testing continues; will report whether the image boots through the U-Boot EFI chain once past install.

🤖 Generated with Claude Code

https://claude.ai/code/session_018bGymcRkVtV7DPToWDjZyZ

[github-actions]

Raptor Current — thanks for the report.

A maintainer will triage this and assign it to the right area. Once a fix ships in nightly, confirm it works on your machine:

ujust verify 1191

Your confirmation is what closes the loop.

[hanthor]

Update after more fork-lab iterations: injecting an equivalent 00-defaults.toml did not fix the install — bootc install to-disk still bailed with "bootupd is required for ostree-based installs". Root cause (bootc source, install.rs): Bootloader::Systemd is only implemented on the composefs-native install path; the ostree path hard-bails regardless of config. The working contract is the CLI-flag form your own generate-bootable-image recipe uses: --composefs-backend --bootloader systemd --wipe. With those flags the config file is moot for installs.

So the actionable remnants of this issue are:

1. /usr/lib/bootc/install/00-defaults.toml is still absent from the aarch64 image despite bluefin/bootc-install-config.bst being in the graph — worth understanding even if installs don't depend on it (the file's own comment claims x86 CI does).
2. type = "xfs" in that file contradicts both BUILD_FILESYSTEM=btrfs and the absence of xfsprogs in the image.

Will report the aarch64 U-Boot-chain boot verdict on the fork lab shortly.