Feature Request: Appendable Kickstart Modifications

[jrmcpeek]

Current state:

Per https://osbuild.org/docs/user-guide/blueprint-reference/#installer-kickstart

When using [customizations.installer.kickstart], no other installer customizations can be used.

Issue:

Because not all features are exposed via blueprint, and not all blueprint features work for all image types, needing to make modifications to the kickstart file is a common task.

However, for ease of maintenance and tool-based validation, using features exposted in the blueprint format is preferrable over making static modifications as a kickstart string.

What we find ourselves doing right now is configuring as much as we can in a blueprint, creating an image (unattended install iso in our case), and then using xorriso to inject a kickstart file with some modifications that we can't do through the blueprint - for example, custom partitioning.

Request:

Either change the behavior of the current [customizations.installer.kickstart] to operate as an appended, included kickstart file, or add a separate option that can work side-by-side with other installer customization.

This could look something like:

os-build.ks:

liveimg --url file:///run/install/repo/liveimg.tar.gz

# kickstart parts generated based on blueprint

%include custom-installer-contents.ks

Similar to the anaconda modules, we would expect that the custom kickstart section has no tooling validation, duplication checks, etc. - it would be on the image builder to ensure that the blueprint and custom section do not conflict.

Additionally, this would limit the generated parts of kickstart to:

• What is needed based on image type (such as liveimg)
• Entries based on blueprint customizations

Otherwise, items would not be added - the goal is that the combination of generated kickstart and included kickstart handle all responsibilities, with the custom kickstart part responsible for installation finalization.

Benefit:

This enables a blueprint-first approach for some advanced use cases, which allows us to put as much in the blueprint as possible, only what is necessary to kickstart customization, and provides an easy, cleaner path to moving items out of the kickstart customization to blueprint sections if/as the feature set there expands over time.