Skip to content

Conversation

@mvo5
Copy link
Contributor

@mvo5 mvo5 commented Dec 2, 2025

When install print-configuration is run some options (notably the kargs) are currently filtered out. This makes sense because in general bootc install to-filesystem takes care of them.

However with the recent work in image-builder/osbuild to use bootc containers directly as inputs to build ISOs [0],[1] we would like to get access to the kernel args too because when constructing a bootable ISO we also want to add the bootc container kargs.

[0] https://github.com/orgs/osbuild/discussions/45
[1] osbuild/images#1906

@github-actions github-actions bot added the area/install Issues related to `bootc install` label Dec 2, 2025
@bootc-bot bootc-bot bot requested a review from jmarrero December 2, 2025 12:24
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces an --all flag to the install print-configuration command, allowing it to output all configuration options, including those usually filtered out like kernel arguments. The changes are well-implemented and straightforward. My main feedback is to suggest adding a unit test to ensure the new flag is parsed correctly, which will help with future maintenance.

/// At the current time, the only output key is `root-fs-type` which is a string-valued
/// filesystem name suitable for passing to `mkfs.$type`.
PrintConfiguration,
PrintConfiguration(crate::install::InstallPrintConfigurationOpts),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

While the change itself is correct, it would be beneficial to add a unit test to verify the parsing of the new --all flag for the install print-configuration subcommand. This ensures future changes don't accidentally break this functionality.

You could add a new test function in the tests module of this file, similar to test_parse_install_args. For example:

#[test]
fn test_parse_print_configuration() {
    // Default, no --all
    let o = Opt::try_parse_from(["bootc", "install", "print-configuration"]).unwrap();
    let o = match o {
        Opt::Install(InstallOpts::PrintConfiguration(opts)) => opts,
        o => panic!("Expected print-configuration opts, not {o:?}"),
    };
    assert!(!o.all);

    // With --all
    let o = Opt::try_parse_from(["bootc", "install", "print-configuration", "--all"]).unwrap();
    let o = match o {
        Opt::Install(InstallOpts::PrintConfiguration(opts)) => opts,
        o => panic!("Expected print-configuration opts, not {o:?}"),
    };
    assert!(o.all);
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests are good, but we can't really do this in unit tests because it operates on ambient data.

We can do it in tests-integration/src/container.rs though I think.

@cgwalters
Copy link
Collaborator

cc #1827 - I think image builder actually wants that because we do want to capture kargs from kargs.d, not just the install config (which is scoped to day 1 only).

Copy link
Collaborator

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing DCO


Though on the structure of things, I would also say that (as you may know) my real preference here is that we cut over how we build the ISO to itself be a bootc image even at a deeper level. For example...one idea here is that on EFI platforms we use a UKI, and when we do that we'd end up rendering the kargs into that instead in which case they don't need to be provided out of band.

kargs: Vec<String>,
}

let config_d = std::path::Path::new("/run/bootc/install/");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine, though I guess probably what we really need here is a workflow that combines container build + test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, it would be nice to have a combined build+test here. I can remove this part of the code again, its a bit unnecessary because the default container already has some kargs I can test for. I wanted to make this is a test-as-example thing so wanted to include the code that writes the toml but maybe I was overthinking it :) Either way is fine with me!

mvo5 added 2 commits December 4, 2025 10:42
When `install print-configuration` is run some options (notably
the kargs) are currently filtered out. This makes sense because
in general `bootc install to-filesystem` takes care of them.

However with the recent work in image-builder/osbuild to use
bootc containers directly as inputs to build ISOs [0],[1]
we would like to get access to the kernel args too because
when constructing a bootable ISO we also want to add the
bootc container kargs.

[0] https://github.com/orgs/osbuild/discussions/45
[1] osbuild/images#1906

Signed-off-by: Michael Vogt <[email protected]>
This adds a simple integration test for
```
$ bootc install print-configuration --all
```
in the container tests.

Thanks to Colin for suggesting this.

Signed-off-by: Michael Vogt <[email protected]>
@mvo5 mvo5 force-pushed the print-config-all branch from 67f07dc to 714091f Compare December 4, 2025 09:42
@cgwalters cgwalters merged commit 136593a into bootc-dev:main Dec 5, 2025
38 of 41 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/install Issues related to `bootc install`

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants