[mobileoverlord]

With rootfs.image.verity on, the root hash reaches the kernel only as avocado,roothash in the rebuilt boot FIT, and the FIT is only rebuilt around this runtime's initramfs. On a machine that ships the FIT template and kernel but whose runtime built no initramfs, the FIT assembly was skipped without a message: the device booted the feed's FIT, without the hash, unverified.

What

• Before the FIT gate, a FIT machine with a rootfs root hash and no project initramfs fails the build with an error naming both fixes (install the initramfs packages, or turn rootfs verity off).
• Without verity, a runtime with no initramfs still leaves the feed's FIT alone.

#316 adds the same guard for kernel.cmdline_extra at the same spot; whichever merges second keeps both checks.

Testing

What	Result
verity_without_an_initramfs_fails_instead_of_booting_unverified (fails with the guard removed)	pass
cargo fmt --check, cargo clippy --all-targets --all-features -D warnings, full cargo test	pass
cargo check --all-targets --target x86_64-pc-windows-gnu	pass

[Copilot]

🟢 Approval recommended

The guard closes the identified verification bypass, preserves non-verity behavior, and has focused regression coverage.

No open issues 🎉

What changed in this PR

Prevents FIT-based runtime builds from silently booting without rootfs verification when no project initramfs is available.

Changes:

• Rejects this configuration with an error explaining both remedies.
• Adds regression coverage for rejection with verity enabled and unchanged behavior without verity.

File	Description
src/​commands/​runtime/​build.rs	Adds the pre-assembly guard and regression test.

_{Review effort: Balanced}

[jetm]

No blocking findings. I checked that the refusal fires only when the FIT sources exist, no initramfs image is set and a rootfs root hash is present, so a build without verity or with an initramfs that rebuilds the FIT is unaffected. The guard and the rebuild branch read the same AVOCADO_ROOTFS_ROOTHASH and AVOCADO_INITRAMFS_IMAGE variables, and the message names both fixes. I did not run the tests. No inline comments; a few minor notes were left off.