Skip to content

image-installer: apply kernel.append to installed system via kickstart (HMS-11181) - #2590

Open
swthakur wants to merge 1 commit into
osbuild:mainfrom
swthakur:image-installer-kernel-append-via-kickstart
Open

image-installer: apply kernel.append to installed system via kickstart (HMS-11181)#2590
swthakur wants to merge 1 commit into
osbuild:mainfrom
swthakur:image-installer-kernel-append-via-kickstart

Conversation

@swthakur

Copy link
Copy Markdown

Summary

  • Fixes customizations.kernel.append for classic image-installer ISOs.
  • Previously, these options were applied to the installer ISO boot cmdline.
  • Now they are applied to the installed system via kickstart bootloader --append.
  • Installer-only unattended ISO options remain on the ISO boot cmdline.

Why

Blueprint kernel append is intended for the installed system bootloader.
For image-installer, the OS payload is a liveimg tar (no disk partition table), so
org.osbuild.kernel-cmdline is not emitted for the payload. Kickstart is the correct path.

Changes

  • pkg/distro/generic/images.go: copy kernel options to Kickstart.KernelOptionsAppend, clear them from InstallerCustomizations.KernelOptionsAppend.
  • pkg/manifest/anaconda_installer_iso_tree.go: emit bootloader --append in makeKickstartStages.

Related to #2175 (previous attempt, closed unmerged).

customizations.kernel.append was being applied to the installer ISO
boot cmdline instead of the installed system. Route those options
through kickstart bootloader --append for image-installer, and keep
them off the ISO GRUB cmdline.
@swthakur
swthakur requested a review from a team as a code owner August 11, 2026 21:26

@supakeen supakeen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

So as I said elsewhere this needs some discussion. First: the implementation code-wise is mostly fine.

However this change would break our backwards compatibility guarantees that we give. I agree that it might make more sense that kernel.append applies to the to-be installed system and that perhaps we should have (if we don't already) an installer.kernel.append that only affects the installer.

But because the current behavior affects the installer users might be relying on it. Thus taking it away is a problem as it would break other users if we don't offer an alternative way of doing it, document it as a breaking change, and make sure people know about it.

Personally I'd go with:

  1. kernel.append affects the installed system.
  2. installer.kernel.append affects the installer.

Both in a single implementation, but I don't know how we handle the breaking of previous workflows correctly.

cc @achilleas-k / @ondrejbudai for your input on this 🙂

@supakeen supakeen changed the title image-installer: apply kernel.append to installed system via kickstart image-installer: apply kernel.append to installed system via kickstart (HMS-11181) Aug 12, 2026
@supakeen

Copy link
Copy Markdown
Member

Also related (in the same area of certain customizations not affecting the installer or the installed system): #2481, #2557.

@swthakur

Copy link
Copy Markdown
Author

Thanks — agreed on avoiding a silent breaking change; I previously raised a broader installer-customization RFE (RHEL-191772).
That RFE is about customizing the Anaconda installer environment itself (packages/files/drivers/boot menu), separate from installed-system customizations.

Your proposal fits as a focused first step:

  • customizations.kernel.append installed system
  • customizations.installer.kernel.append installer ISO boot cmdline

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants