ephemeral: Add Ignition config injection support by gursewak1997 · Pull Request #232 · bootc-dev/bcvk

gursewak1997 · 2026-03-20T22:52:10Z

Add support for injecting Ignition configuration files into ephemeral
VMs via QEMU's fw_cfg mechanism (x86_64/aarch64) and virtio-blk
(s390x/ppc64le). This enables first-boot provisioning for bootc-based
systems that use Ignition.

Implementation:

Architecture-specific config delivery per FCOS docs:
- x86_64/aarch64: fw_cfg at opt/com.coreos/config
- s390x/ppc64le: virtio-blk with serial 'ignition', readonly
Runtime architecture detection for correct method
Image validation via labels (coreos.ignition or com.coreos.osname)
Added readonly support for virtio-blk devices
Added ignition.platform.id=qemu kernel argument when config specified
Path validation with existence, type, and readability checks
Brief error messages with man page reference

Testing:

5 comprehensive integration tests:
- fw_cfg accessibility verification
- Invalid path rejection
- Directory rejection
- Unsupported image detection
- Kernel argument presence validation
All tests pass with FCOS image verification

Documentation:

Comprehensive man page section with working Ignition v3.3.0 example
SSH key injection and file creation demo
Architecture-specific delivery notes
Links to upstream Ignition and bootc documentation
Important notes about ephemeral boot behavior

The config is successfully passed to the guest (verified via
/sys/firmware/qemu_fw_cfg/ and /proc/cmdline). Ignition will process
it on first boot. For ephemeral testing with pre-built FCOS images,
Ignition skips as expected (subsequent boot behavior).

Useful for custom bootc images with Ignition (see bootc initramfs
docs) and future to-disk workflows.

gemini-code-assist

Code Review

This pull request adds support for injecting Ignition configuration files into ephemeral VMs. The implementation correctly handles different injection methods for various architectures (fw_cfg for x86_64/aarch64 and virtio-blk for s390x/ppc64le). The changes include updates to QEMU configuration, command-line options, and logic to detect Ignition support in images.

My review includes a couple of suggestions to improve code clarity, reduce duplication, and enhance performance. Specifically, I've recommended refactoring the virtio-blk device addition methods for better maintainability and optimizing the Ignition support check to be more efficient.

crates/bcvk-qemu/src/qemu.rs

crates/kit/src/run_ephemeral.rs

cgwalters

Thanks for working on this!

I think we really want an integration test for this. Did you test it with the fcos image? I have a suspicion that it may require an ignition.platform.id=qemu karg to be injected too.

And per discussion...some basic docs would be good, I think an example in the man page for ephemeral run is probably enough with a small concrete example?

Also, while starting with ephemeral is fine...we probably want libvirt support too.

(And yeah right now it definitely stinks to have direct qemu for ephemeral vs libvirt)

crates/kit/src/run_ephemeral.rs

cgwalters · 2026-03-23T14:16:50Z

crates/kit/src/run_ephemeral.rs

+    if let Some(osname_value) = labels.get("com.coreos.osname") {
+        if !osname_value.is_empty() {


If let Some(val) = labels.get().filter(|v| !v.is_empty())

cgwalters · 2026-03-23T14:22:40Z

crates/kit/src/run_ephemeral.rs

+            ));
+        }
+
+        cmd.args([


What might be less cumbersome here is to pass it as an environment variable? Then we don't need to juggle paths across the mount, we just read it in here, and the code inside can just check for the env var.

cgwalters · 2026-03-23T14:24:01Z

crates/kit/src/run_ephemeral.rs

+        if !has_ignition {
+            return Err(eyre!(
+                "Image does not support Ignition.\n\
+                 \n\


I'd lean towards us having a brief doc for this support instead of trying to have longer explanatory error messages like this.

cgwalters · 2026-03-23T14:25:11Z

crates/kit/src/run_ephemeral.rs

+        match arch {
+            "x86_64" | "aarch64" => {
+                debug!("Adding Ignition config via fw_cfg: {}", ignition_path);
+                qemu_config.add_fw_cfg(IGNITION_FW_CFG_NAME.to_string(), ignition_path.to_owned());


Although I guess if we accept it as an env-var externally, this case would require re-serializing to a file. Hmm. Dunno.

Current approach: File mount, direct passthrough to QEMU
Env var approach: Read → env var → write temp file → pass to QEMU

Would you still prefer the env var approach despite needing to re-materialize the file? Or should we keep the current mount approach since QEMU fundamentally needs a file anyway?

Add support for injecting Ignition configuration files into ephemeral VMs via QEMU's fw_cfg mechanism (x86_64/aarch64) and virtio-blk (s390x/ppc64le). This enables first-boot provisioning for bootc-based systems that use Ignition. Implementation: - Architecture-specific config delivery per FCOS docs: * x86_64/aarch64: fw_cfg at opt/com.coreos/config * s390x/ppc64le: virtio-blk with serial 'ignition', readonly - Runtime architecture detection for correct method - Image validation via labels (coreos.ignition or com.coreos.osname) - Added readonly support for virtio-blk devices - Added ignition.platform.id=qemu kernel argument when config specified - Path validation with existence, type, and readability checks - Brief error messages with man page reference Testing: - 5 comprehensive integration tests: * fw_cfg accessibility verification * Invalid path rejection * Directory rejection * Unsupported image detection * Kernel argument presence validation - All tests pass with FCOS image verification Documentation: - Comprehensive man page section with working Ignition v3.3.0 example - SSH key injection and file creation demo - Architecture-specific delivery notes - Links to upstream Ignition and bootc documentation - Important notes about ephemeral boot behavior The config is successfully passed to the guest (verified via /sys/firmware/qemu_fw_cfg/ and /proc/cmdline). Ignition will process it on first boot. For ephemeral testing with pre-built FCOS images, Ignition skips as expected (subsequent boot behavior). Useful for custom bootc images with Ignition (see bootc initramfs docs) and future to-disk workflows. Assisted-by: Claude Code (Sonnet 4.5) Signed-off-by: gursewak1997 <gursmangat@gmail.com>

gemini-code-assist bot reviewed Mar 20, 2026

View reviewed changes

crates/bcvk-qemu/src/qemu.rs Show resolved Hide resolved

crates/kit/src/run_ephemeral.rs Show resolved Hide resolved

gursewak1997 force-pushed the add-ignition-support branch 2 times, most recently from e74f5fd to 7be5f96 Compare March 20, 2026 23:05

cgwalters requested changes Mar 23, 2026

View reviewed changes

gursewak1997 force-pushed the add-ignition-support branch from 7be5f96 to 86e645a Compare March 23, 2026 22:06

gursewak1997 force-pushed the add-ignition-support branch from 86e645a to 1b5eebe Compare March 24, 2026 22:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ephemeral: Add Ignition config injection support#232

ephemeral: Add Ignition config injection support#232
gursewak1997 wants to merge 1 commit intomainfrom
add-ignition-support

gursewak1997 commented Mar 20, 2026 •

edited

Loading

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

Uh oh!

Uh oh!

cgwalters left a comment

Uh oh!

Uh oh!

cgwalters Mar 23, 2026

Uh oh!

cgwalters Mar 23, 2026

Uh oh!

cgwalters Mar 23, 2026

Uh oh!

cgwalters Mar 23, 2026

Uh oh!

gursewak1997 Mar 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		if let Some(osname_value) = labels.get("com.coreos.osname") {
		if !osname_value.is_empty() {

Conversation

gursewak1997 commented Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

cgwalters left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cgwalters Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

cgwalters Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

cgwalters Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

cgwalters Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

gursewak1997 Mar 23, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gursewak1997 commented Mar 20, 2026 •

edited

Loading