USHIFT-4299: Rewrite RHEL for Edge ISO contributor doc - #7161
Conversation
The previous version of rhel4edge_iso.md had a TODO placeholder where the build instructions should be, used the deprecated --cdrom approach for VM deployment, and referenced a nonexistent kickstart. This made the document unusable for building and deploying edge-installer ISOs. Rewrite the doc to reference the official Red Hat documentation for the standard image-builder workflow and cover only the local-RPM delta needed when testing unreleased changes. Add a new microshift-edge.ks kickstart for ostree deployments (separate from microshift-starter.ks which remains for DVD installs). Key changes validated by end-to-end testing: - Use --boot uefi (bootupd only generates UEFI bootloader configs) - Use --location + --initrd-inject instead of --cdrom - Add bootupd workaround in %post to install EFI grub.cfg - Update disk partitioning docs to match actual UEFI layout - Store ISO and disk images in ~/ instead of /var/lib/libvirt/images/ Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
openshift-ci-robot
added
the
jira/valid-reference
|
@copejon: This pull request references USHIFT-4299 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: copejon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
WalkthroughAdds a MicroShift Edge Kickstart configuration and updates the RHEL for Edge ISO guide. The guide now covers local RPM builds, repository registration, image creation, UEFI VM installation, and MicroShift verification. ChangesMicroShift Edge ISO
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Developer
participant LocalRepo
participant osbuild-composer
participant virt-install
participant MicroShift
Developer->>LocalRepo: Build RPMs and create repository metadata
Developer->>osbuild-composer: Register local repository and build Edge ISO
Developer->>virt-install: Inject Kickstart into UEFI installation
virt-install->>MicroShift: Install and configure MicroShift
Developer->>MicroShift: Run oc get cs and oc get pods -A
🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/config/microshift-edge.ks`:
- Around line 29-31: Remove the hardcoded password hash and unrestricted sudo
entry from the default redhat-user setup in the kickstart configuration. Replace
them with per-deployment credential provisioning, using a generated password or
injected SSH key, and ensure the documented redhat:redhat credential is removed
or updated to match the secure provisioning flow.
- Line 14: Update the Kickstart storage configuration around clearpart --all
--initlabel to target only the intended installation disk using --drives or
ignoredisk --only-use. Ensure the physical volume definition binds to that same
disk, and remove the unrestricted all-disk clearing behavior.
- Around line 61-64: Update the bootupd copy guard around the EFI configuration
files to also verify that /boot/grub2/bootuuid.cfg exists before executing
either cp command. Keep both copies protected by the condition, including the
existing directory and grub-static-efi.cfg checks.
- Line 27: Update the Kickstart post-install configuration around %post to
create /etc/crio/openshift-pull-secret with mode 0600 using the build-time pull
secret without committing its contents, and configure trusted firewall sources
10.42.0.0/16 and 169.254.169.1 through the Kickstart or equivalent blueprint
customization.
In `@docs/contributor/rhel4edge_iso.md`:
- Around line 142-144: Update the kubeconfig setup commands after copying
/var/lib/microshift/resources/kubeadmin/kubeconfig to ~/.kube/config by adding a
chmod go-r ~/.kube/config step, ensuring group and world read permissions are
removed.
- Around line 76-77: Correct the introductory filesystem description in the
partition layout section so it does not claim every listed partition is
formatted with XFS; accurately distinguish the EFI System Partition’s FAT
filesystem from the other partitions.
- Line 108: Update the RHEL 4 Edge ISO transfer instructions to use the actual
${BUILDID}-installer.iso filename produced by composer-cli, or explicitly
reference the preceding rename step that creates microshift-installer.$(uname
-m).iso; keep the scp and ISOFILE references consistent.
- Around line 127-128: Update the inst.ks argument in the documented ISO command
to use the single-slash local URI format file:/microshift-edge.ks, matching the
path where --initrd-inject places the Kickstart file.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: d213c63b-f58f-433f-a63f-2113bab76d9a
📒 Files selected for processing (2)
docs/config/microshift-edge.ksdocs/contributor/rhel4edge_iso.md
| # volume that contains a 10GB+ system root. The remainder of the volume will | ||
| # be used by the LVMS CSI driver for storing data. | ||
| zerombr | ||
| clearpart --all --initlabel |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Limit clearpart to the target disk.
clearpart --all erases every disk visible to Anaconda, including attached network storage. The guide describes a main disk, but this Kickstart does not select one. Restrict clearpart with --drives or ignoredisk --only-use, and bind the PV to the same disk. (docs.redhat.com)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/config/microshift-edge.ks` at line 14, Update the Kickstart storage
configuration around clearpart --all --initlabel to target only the intended
installation disk using --drives or ignoredisk --only-use. Ensure the physical
volume definition binds to that same disk, and remove the unrestricted all-disk
clearing behavior.
| ostreesetup --nogpg --osname=rhel --remote=edge --url=file:///run/install/repo/ostree/repo --ref=rhel/9/x86_64/edge | ||
|
|
||
| # Post install configuration | ||
| %post --log=/dev/console --erroronfail |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 3 'openshift-pull-secret|firewall-offline-cmd|10\.42\.0\.0/16|169\.254\.169\.1' .Repository: openshift/microshift
Length of output: 50379
Add MicroShift runtime prerequisites to the Kickstart.
docs/config/microshift-edge.ks currently renders only a user account and does not create /etc/crio/openshift-pull-secret with mode 0600 or add the trusted firewall sources 10.42.0.0/16 and 169.254.169.1. Render the pull secret during image build without committing it, and add the MicroShift firewall rules here or via an equivalent blueprint customization.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/config/microshift-edge.ks` at line 27, Update the Kickstart post-install
configuration around %post to create /etc/crio/openshift-pull-secret with mode
0600 using the build-time pull secret without committing its contents, and
configure trusted firewall sources 10.42.0.0/16 and 169.254.169.1 through the
Kickstart or equivalent blueprint customization.
| # Create a default redhat user, allowing it to run sudo commands without password | ||
| useradd -m -d /home/redhat -p \$5\$XDVQ6DxT8S5YWLV7\$8f2om5JfjK56v9ofUkUAwZXTxJl3Sqnc9yPnza4xoJ0 redhat | ||
| echo -e 'redhat\tALL=(ALL)\tNOPASSWD: ALL' > /etc/sudoers.d/microshift |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
Do not ship a fixed root-capable login.
The image embeds a known password hash and grants redhat unrestricted NOPASSWD: ALL access. The guide publishes the same redhat:redhat credential at Line 140. If SSH is enabled, any user who can reach the VM can obtain root access. Generate a per-deployment password or SSH key instead. (docs.redhat.com)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/config/microshift-edge.ks` around lines 29 - 31, Remove the hardcoded
password hash and unrestricted sudo entry from the default redhat-user setup in
the kickstart configuration. Replace them with per-deployment credential
provisioning, using a generated password or injected SSH key, and ensure the
documented redhat:redhat credential is removed or updated to match the secure
provisioning flow.
| if [ -d /boot/efi/EFI/redhat ] && [ -f /usr/lib/bootupd/grub2-static/grub-static-efi.cfg ]; then | ||
| cp /usr/lib/bootupd/grub2-static/grub-static-efi.cfg /boot/efi/EFI/redhat/grub.cfg | ||
| cp /boot/grub2/bootuuid.cfg /boot/efi/EFI/redhat/bootuuid.cfg | ||
| fi |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
Guard both bootupd source files.
The condition checks grub-static-efi.cfg but not /boot/grub2/bootuuid.cfg. Add a file check for the second source or handle its absence explicitly before running cp.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/config/microshift-edge.ks` around lines 61 - 64, Update the bootupd copy
guard around the EFI configuration files to also verify that
/boot/grub2/bootuuid.cfg exists before executing either cp command. Keep both
copies protected by the condition, including the existing directory and
grub-static-efi.cfg checks.
| By default, the following partition layout is created and formatted with the `XFS` file system: | ||
| * BIOS boot partition (1MB) | ||
| * It is required to boot ISO to systems with legacy BIOS while using GPT as the partitioning scheme. | ||
| * EFI partition with EFI file system (200MB) | ||
| * EFI System Partition with FAT file system (600MB) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Correct the filesystem description.
The paragraph says that all listed partitions use XFS, but the next bullet identifies the EFI partition as FAT.
Proposed wording
-By default, the following partition layout is created and formatted with the `XFS` file system:
+By default, `/boot` and the root logical volume use the `XFS` file system. The EFI System Partition uses the `FAT` file system:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| By default, the following partition layout is created and formatted with the `XFS` file system: | |
| * BIOS boot partition (1MB) | |
| * It is required to boot ISO to systems with legacy BIOS while using GPT as the partitioning scheme. | |
| * EFI partition with EFI file system (200MB) | |
| * EFI System Partition with FAT file system (600MB) | |
| By default, `/boot` and the root logical volume use the `XFS` file system. The EFI System Partition uses the `FAT` file system: | |
| * EFI System Partition with FAT file system (600MB) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/contributor/rhel4edge_iso.md` around lines 76 - 77, Correct the
introductory filesystem description in the partition layout section so it does
not claim every listed partition is formatted with XFS; accurately distinguish
the EFI System Partition’s FAT filesystem from the other partitions.
| Start by copying the installer image and kickstart from the `development virtual machine` to the host file system. Replace `<dev-vm-ip>` with the IP address of your development VM (run `sudo virsh domifaddr <vm-name>` on the hypervisor to find it). | ||
| ```bash | ||
| sudo scp microshift@microshift-dev:/home/microshift/microshift/_output/image-builder/microshift-installer-*.$(uname -m).iso /var/lib/libvirt/images/ | ||
| scp microshift@<dev-vm-ip>:/home/microshift/microshift/_output/image-builder/microshift-installer.$(uname -m).iso ~/ |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 4 'composer-cli compose image|microshift-installer.*iso|_output/image-builder' .Repository: openshift/microshift
Length of output: 6997
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== rhel4edge_iso relevant section =="
sed -n '80,140p' docs/contributor/rhel4edge_iso.md
echo
echo "== referenced official docs snippets (local web cache not available); search repo for image filename references =="
rg -n -C 5 'BUILDID|BUILD_ID|compose image|installer\.iso|installer.*iso|image\s+\${BUILDID}' .Repository: openshift/microshift
Length of output: 3582
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== rhel4edge_iso ISO generation section =="
sed -n '1,95p' docs/contributor/rhel4edge_iso.md
echo
echo "== references to ISO build path and filenames =="
rg -n -C 4 'compose image|installer\.iso|installer.*iso|image\s+\${BUILDID}|image\s+"\$'\''{BUILDID}'"'"'" .
echo
echo "== surrounding devenv_cloud references =="
sed -n '108,134p' docs/contributor/devenv_cloud.mdRepository: openshift/microshift
Length of output: 5815
🌐 Web query:
Red Hat Build of MicroShift 4.22 composer-cli compose image BUILDID generated installer ISO filename
💡 Result:
When using the Red Hat Build of MicroShift 4.22 with composer-cli to generate an installer ISO, the resulting filename follows the pattern ${BUILDID}-installer.iso [1][2][3][4]. In the standard Red Hat build of MicroShift documentation workflow, the variable ${BUILDID} is captured after starting the ostree build [5][6][7]. After the build process is complete, you download the resulting image using the following command [5][8][6]: sudo composer-cli compose image ${BUILDID} Once the file is downloaded, it is typically renamed or referenced by appending -installer.iso to the build ID [1][2][3][4]. For example, the official documentation frequently uses the command to change ownership of the file as ${BUILDID}-installer.iso: sudo chown
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.21/html-single/embedding_in_a_rhel_for_edge_image/index
- 2: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.18/html/embedding_in_a_rhel_for_edge_image/microshift-embed-in-rpm-ostree
- 3: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.13/html-single/installing/index
- 4: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.14/html/installing/microshift-embed-in-rpm-ostree
- 5: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.22/html/embedding_in_a_rhel_for_edge_image/microshift-embed-in-rpm-ostree
- 6: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.22/html/embedding_in_a_rhel_for_edge_image/microshift-embed-in-rpm-ostree-for-offline-use
- 7: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.22/html-single/running_applications/index
- 8: https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/4.22/html-single/embedding_in_a_rhel_for_edge_image/index
Copy the actual generated installer ISO path.
composer-cli compose image ${BUILDID} creates ${BUILDID}-installer.iso, not microshift-installer.$(uname -m).iso. Add/point to the rename step, or use the actual generated filename in the scp and ISOFILE references.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/contributor/rhel4edge_iso.md` at line 108, Update the RHEL 4 Edge ISO
transfer instructions to use the actual ${BUILDID}-installer.iso filename
produced by composer-cli, or explicitly reference the preceding rename step that
creates microshift-installer.$(uname -m).iso; keep the scp and ISOFILE
references consistent.
| --initrd-inject "${HOME}/microshift-edge.ks" \ | ||
| --extra-args "inst.ks=file://microshift-edge.ks" \ |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n -C 4 'initrd-inject|inst\.ks=file:' .Repository: openshift/microshift
Length of output: 6555
🌐 Web query:
Red Hat virt-install initrd-inject inst.ks file:/ks.cfg documentation
💡 Result:
The combination of --initrd-inject and --extra-args with inst.ks=file:/ks.cfg is a standard, supported method in virt-install for performing automated, unattended installations of Red Hat-based operating systems without requiring a network-hosted kickstart file [1][2][3]. Mechanism When you use --initrd-inject PATH, the virt-install utility takes the specified file (typically a ks.cfg kickstart file) from your local filesystem and injects it into the root directory of the initial ramdisk (initrd) that is fetched via the --location parameter [1][4]. Because the kickstart file is now embedded within the virtual machine's own boot environment, you must instruct the installer to look for it there using a local file path [5][6]. Syntax Example To perform this installation, you provide the local path to your kickstart file to --initrd-inject and point the installer to that internal path via the kernel command line arguments passed through --extra-args [1][3]: virt-install \ --name my-vm \ --location /path/to/install/tree/or/iso \ --initrd-inject /path/to/local/ks.cfg \ --extra-args "inst.ks=file:/ks.cfg" Key Notes - Path mapping: While --initrd-inject uses the absolute or relative path on your host machine, the argument in --extra-args must use file:/ followed by the filename as it exists in the root of the initrd [1][5]. - Compatibility: This method is highly reliable for RHEL and Fedora installations as it bypasses the need for network connectivity during the initial boot phase to fetch the configuration [1][2]. - Modern Syntax: While older versions of RHEL used ks=file:/ks.cfg, newer releases and documentation standardize on inst.ks=file:/ks.cfg [5][3]. Both are often accepted by Anaconda, but inst.ks is the current preferred convention [3]. - Verification: If the installation fails to pick up the configuration, you can troubleshoot by booting with rd.break=cmdline rd.shell to manually verify that ks.cfg is present in the root directory (/) of the installer environment [5].
Citations:
- 1: https://manpages.ubuntu.com/manpages/noble/man1/virt-install.1.html
- 2: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install
- 3: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_linux_virtual_machines/creating-virtual-machines
- 4: https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst
- 5: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_FilePath_KsCfg
- 6: https://developers.redhat.com/articles/2026/03/10/effortless-red-hat-enterprise-linux-virtual-machines-libvirt-and-kickstart
🌐 Web query:
virt-install man page file:// protocol initrd-inject inst.ks file://kickstart.ks
💡 Result:
The --initrd-inject option in virt-install is used to add a local file, such as a kickstart file, to the root of the initial ramdisk (initrd) fetched during the installation process [1][2][3]. This allows the installer to access the file as if it were on its local filesystem during the automated installation [4]. To use this feature, follow these steps: 1. Use --initrd-inject to specify the path to your local kickstart file [1][5]. 2. Use --extra-args to instruct the kernel to locate and use that injected file via the file:// protocol [1][4]. For example: virt-install --name my-vm --location /path/to/os --initrd-inject /path/to/kickstart.ks --extra-args "inst.ks=file:/kickstart.ks" [1][4] In this configuration, virt-install injects /path/to/kickstart.ks into the root of the initrd, and the installer kernel argument inst.ks=file:/kickstart.ks directs the installer to load it from the root of its filesystem [1][4]. Depending on the specific distribution and installer version, the kernel argument may be ks=file:/kickstart.ks or inst.ks=file:/kickstart.ks [1][4]. Important notes: - The file provided to --initrd-inject must be a local file path [1][6]. - This method is intended for use with --location, which fetches a bootable kernel/initrd pair to launch the installation [2][3]. - The kernel arguments (via --extra-args) are used to pass instructions to the installer; ensuring the path in file:// matches the filename (not the full host path) inside the initrd is critical [6][4].
Citations:
- 1: https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst
- 2: https://man.archlinux.org/man/virt-install.1
- 3: https://manpages.debian.org/unstable/virt-install/virt-install.1.en.html
- 4: https://www.fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg
- 5: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install
- 6: https://stackoverflow.com/questions/28151414/using-ks-cfg-with-virt-install
🌐 Web query:
site:docs.redhat.com virt-install --initrd-inject inst.ks=file://kickstart.ks
💡 Result:
The --initrd-inject option in virt-install is used to copy a local file, such as a kickstart configuration file, into the root directory of the initial RAM disk (initrd) used during the virtual machine's installation process [1][2]. This allows the installer to access the file locally as if it were on a filesystem [1][3]. To successfully use this feature, you must combine it with the --extra-args option to instruct the kernel to use that injected file [1][2]. Example Usage: # virt-install \ --name my-vm \ --memory 2048 \ --vcpus 2 \ --disk size=20 \ --location http://example.com/installation-tree \ --osinfo rhel10.0 \ --initrd-inject /path/to/local/kickstart.ks \ --extra-args="inst.ks=file:/kickstart.ks" Key Points: 1. --initrd-inject: Specifies the path to the local file on the host machine that you want to inject into the guest's initrd [1][2]. 2. --extra-args: Passes the kernel parameter inst.ks=file:/ to the installer, where is the name of the file inside the initrd [1][2]. Note that the path inside the initrd is relative to the root directory (e.g., file:/kickstart.ks) [1][2]. 3. Automation: This method is primarily used to automate unattended installations when using --location to point to a network installation tree [1][4]. Note: Depending on the OS version and specific installer requirements, older systems might use the ks= parameter instead of inst.ks= [1][3]. Modern Red Hat Enterprise Linux versions typically use inst.ks= [2][5].
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install
- 2: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_linux_virtual_machines/creating-virtual-machines
- 3: https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-virt_install-kickstart
- 4: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/virtualization_host_configuration_and_guest_installation_guide/sect-virtualization_host_configuration_and_guest_installation_guide-guest_installation-creating_guests_with_virt_install
- 5: https://docs.redhat.com/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/starting-kickstart-installations
🌐 Web query:
virt-manager virt-install file:// kickstart initrd-inject file://kickstart.ks
💡 Result:
The virt-install command uses --initrd-inject to inject a local file (such as a kickstart file) directly into the root of the initrd image retrieved via the --location option [1][2][3]. This allows you to perform an automated installation without needing to host the kickstart file on a network server [1][4]. To use this feature, you must pair --initrd-inject with the appropriate kernel argument in --extra-args to tell the installer (e.g., Anaconda) to look for the file on the local ramdisk using the file:// protocol [5][3]. Usage Example: virt-install --name my-vm --location /path/to/install/media --initrd-inject /path/to/kickstart.ks --extra-args "inst.ks=file:/kickstart.ks" [5][3] Key details: 1. --initrd-inject PATH: Specifies the path to the local file you want to inject into the installer's initial ramdisk [1][6]. 2. --extra-args "inst.ks=file:/...": Tells the installer to load the kickstart file from the injected location within the ramdisk [5]. Note that older distributions may use "ks=file:/..." instead of "inst.ks=file:/..." [2][3][7]. 3. Requirement: This method requires the use of --location, which enables direct kernel loading [1][4]. It cannot be used with standard CDROM/ISO boot methods unless those methods support direct kernel/initrd extraction via --location [1][2]. 4. Automation: This effectively avoids the need for external network infrastructure (like HTTP/FTP servers) for kickstart delivery [4]. virt-manager (the GUI) does not natively support the --initrd-inject functionality directly in its basic wizard interface in the same way; users typically use the command-line virt-install to achieve this specific automated deployment workflow [3][8].
Citations:
- 1: https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst
- 2: https://man.archlinux.org/man/virt-install.1
- 3: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-guest_virtual_machine_installation_overview-creating_guests_with_virt_install
- 4: https://developers.redhat.com/articles/2026/03/10/effortless-red-hat-enterprise-linux-virtual-machines-libvirt-and-kickstart
- 5: https://www.fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg
- 6: https://manpages.debian.org/bookworm/virtinst/virt-install.1
- 7: https://manpages.ubuntu.com/manpages/focal/man1/virt-install.1.html
- 8: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-creating_guests_with_virt_manager
🌐 Web query:
virtualization-testing Fedora QA virt-install initrd-inject inst.ks=file://kickstart.ks
💡 Result:
To perform an automated installation of Fedora using a Kickstart file with virt-install, you can inject the file directly into the initial ramdisk (initrd). This method is widely used in Fedora QA testing to automate installations without requiring a network-hosted Kickstart file [1][2]. The core mechanism involves two key virt-install options: 1. --initrd-inject PATH: This option copies the specified local Kickstart file (e.g., ks.cfg) into the root directory of the installer's initial ramdisk [3][4]. 2. --extra-args "inst.ks=file:/FILENAME": This kernel argument tells the Anaconda installer to locate and process the Kickstart file now present within the ramdisk [3][5]. Example Command The following command demonstrates this setup. Replace the --location URL with the appropriate path for your target Fedora version and ensure the kickstart file path is correct [1][2]: virt-install --name FedoraTest \ --ram 3000 --disk pool=default,size=10 \ --location http://dl.fedoraproject.org/pub/fedora/linux/releases/45/Everything/x86_64/os/ \ --initrd-inject ks.cfg \ --extra-args "inst.ks=file:/ks.cfg" Verification and Debugging If you need to verify that the file was successfully included or troubleshoot the installation: - Standard verification: The file presence is not typically visible via tools like lsinitrd because it is concatenated into the image [1][2]. - Debugging: You can add rd.break=cmdline rd.shell to your --extra-args to pause the boot process [1][2]. Once at the shell prompt, you can confirm the file exists at /run/install/ks.cfg [1][2]. - Automation: If your kickstart file is configured correctly with all necessary installation commands, the installer will proceed without prompting for user input [1][2]. Note that --location is required for this workflow because it fetches the kernel and initrd directly, allowing virt-install to modify them before booting the virtual machine [3][6].
Citations:
- 1: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_FilePath_KsCfg
- 2: https://www.fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg
- 3: https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst
- 4: https://www.mankier.com/1/virt-install
- 5: https://www.tomas.io/articles/try-fedora
- 6: https://developers.redhat.com/articles/2026/03/10/effortless-red-hat-enterprise-linux-virtual-machines-libvirt-and-kickstart
🌐 Web query:
Anaconda instks initrd ks.cfg file:// file:/ kickstart
💡 Result:
The inst.ks=file:/ boot option in Anaconda is primarily used to instruct the installer to read a kickstart file from the local file system, most commonly when that file has been embedded directly into the initial ramdisk (initrd) [1][2]. When using inst.ks=file:/<path>, the Anaconda installer reads the specified file directly from the file system without attempting to mount additional network or storage volumes [2]. Key considerations for this approach include: 1. Embedding in Initrd: To use a kickstart file located inside the initrd, you must first place the ks.cfg file into the root of the initrd image. This is often done using the cpio utility [1]. For example: echo ks.cfg | cpio -c -o >> initrd.img [1] Once embedded, you can point to it at the boot prompt using: inst.ks=file:/ks.cfg [1] 2. Path Resolution: If you specify the path, it is relative to the root of the file system as it appears to the running installer [2]. If the path component is omitted in some contexts, it may default to /ks.cfg [3]. 3. Alternative "file" usage: While file:/ is typically used for embedded initrd files, files located on already mounted media (such as a USB drive or other partitioned storage) are generally accessed by providing the path to their location in the filesystem (e.g., /run/install/ks.cfg) after the device is mounted by the installer [4]. 4. Troubleshooting: Because files embedded in the initrd are not easily visible via standard inspection tools (like lsinitrd), you can verify their presence by passing rd.break=cmdline rd.shell to the kernel command line at boot, which allows you to inspect the filesystem before the installation begins [1]. The kickstart file should be located at /run/install/ks.cfg if correctly processed [1].
Citations:
- 1: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_FilePath_KsCfg
- 2: https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-docs.rst
- 3: https://anaconda-autogenerated-dbus-docs.readthedocs.io/en/latest/boot-options.html
- 4: https://www.fedorafaq.com/en/how-to-install-fedora-using-kickstart-for-automated-installation/
🌐 Web query:
Red Hat Anaconda instks file:// protocol file://kickstart kickstart documentation
💡 Result:
The file:// protocol is a supported method for specifying the location of a Kickstart file in Red Hat Anaconda [1][2]. When using the inst.ks kernel boot option, the file:// prefix informs the installer to read the configuration file directly from the local file system [1][2]. This method is typically used when the Kickstart file is embedded within the installation environment's initial ramdisk (initrd) [3][2]. Key details regarding this usage: - Syntax: You provide the location via the inst.ks boot option, such as inst.ks=file:/path/to/ks.cfg or inst.ks=file:///path/to/ks.cfg [3][2]. - Mechanism: Unlike network protocols (HTTP, NFS, FTP), using file:// does not involve network mounts [2]. The installer reads the specified file directly from the filesystem [1]. - Implementation: In the Anaconda source code, the file handler checks if the path exists, copies it to a temporary location (/tmp/ks.cfg), and proceeds to parse the instructions [1]. - Common Use Case: This is frequently utilized in testing or automated environments where a custom Kickstart file is injected into the initrd image (e.g., using virt-install --initrd-inject or manual cpio operations) [3]. For general automated installations that do not require modifying the initrd, Red Hat documentation typically recommends alternative methods such as using inst.ks with network protocols (HTTP/NFS) [4][5][6] or placing the Kickstart file on a storage volume labeled OEMDRV [7][8][9]. The latter approach is the standard, documented way to provide a Kickstart file on local media without needing to modify the boot images [8][9].
Citations:
- 1: https://github.com/rhinstaller/anaconda/blob/master/dracut/parse-anaconda-kickstart.sh
- 2: https://github.com/pykickstart/pykickstart/blob/master/docs/kickstart-docs.rst
- 3: https://fedoraproject.org/wiki/QA:Testcase_Kickstart_FilePath_KsCfg
- 4: https://docs.redhat.com/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/starting-kickstart-installations
- 5: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/adding-the-kickstart-file-to-a-uefi-http-or-pxe-installation-source_rhel-installer
- 6: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/automatically_installing_rhel/adding-the-kickstart-file-to-a-uefi-http-or-pxe-installation-source_rhel-installer
- 7: https://anaconda-installer.readthedocs.io/en/latest/user-guide/kickstart.html
- 8: https://docs.redhat.com/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/semi-automated-installations-making-kickstart-files-available-to-the-rhel-installer
- 9: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automatically_installing_rhel/starting-kickstart-installations
Use the single-slash Kickstart URI for the injected initrd file.
--initrd-inject places microshift-edge.ks at the initrd root, so point inst.ks at that local filesystem path with file:/. The helper scripts use inst.ks=file:/<basename> for this workflow.
Proposed fix
- --extra-args "inst.ks=file://microshift-edge.ks" \
+ --extra-args "inst.ks=file:/microshift-edge.ks" \📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| --initrd-inject "${HOME}/microshift-edge.ks" \ | |
| --extra-args "inst.ks=file://microshift-edge.ks" \ | |
| --initrd-inject "${HOME}/microshift-edge.ks" \ | |
| --extra-args "inst.ks=file:/microshift-edge.ks" \ |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/contributor/rhel4edge_iso.md` around lines 127 - 128, Update the inst.ks
argument in the documented ISO command to use the single-slash local URI format
file:/microshift-edge.ks, matching the path where --initrd-inject places the
Kickstart file.
| mkdir ~/.kube | ||
| sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config | ||
| ``` |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Restrict the copied kubeconfig.
The source file contains administrative credentials. The redirection can create ~/.kube/config with group or world read permissions, depending on the user umask. Add chmod go-r ~/.kube/config after the copy. The official MicroShift procedure includes this permission step. (docs.redhat.com)
Proposed fix
mkdir ~/.kube
sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
+chmod go-r ~/.kube/config📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mkdir ~/.kube | |
| sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config | |
| ``` | |
| mkdir ~/.kube | |
| sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config | |
| chmod go-r ~/.kube/config |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/contributor/rhel4edge_iso.md` around lines 142 - 144, Update the
kubeconfig setup commands after copying
/var/lib/microshift/resources/kubeadmin/kubeconfig to ~/.kube/config by adding a
chmod go-r ~/.kube/config step, ensuring group and world read permissions are
removed.
|
@copejon: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
2 participants
Summary
docs/contributor/rhel4edge_iso.mdto replace the deprecated TODO placeholder with working build and deploy instructions, referencing official Red Hat docs for the standard image-builder workflow and covering only the local-RPM deltadocs/config/microshift-edge.kskickstart for edge-installer ISO deployments (separate frommicroshift-starter.kswhich remains for DVD installs)--boot uefifor VM deployment becausebootupdonly generates UEFI bootloader configs--cdromwith--location+--initrd-injectto properly inject the kickstart into the edge-installer ISO%postworkaround forbootupdnot installing the EFIgrub.cfgduring ostree deploymentWorkarounds
Two
bootupdintegration gaps require workarounds:--boot uefirequired onvirt-install:bootupd'sgen-metadatastage in osbuild only generates UEFI static configs (grub-static-efi.cfg), not BIOS boot code. A BIOS VM installs without error butbootupd-state.jsonshows"installed":{}and the VM cannot boot.%postcopies EFIgrub.cfg: Even with UEFI,bootupd installis never invoked during anaconda's ostree deployment. The EFI partition gets GRUB binaries (shimx64.efi,grubx64.efi) but not thegrub.cfgthat chainloads/boot/grub2/grub.cfg. The%postscript copiesgrub-static-efi.cfgandbootuuid.cfgfrom the installed system to the EFI partition.Test plan
--boot uefi+--location+--initrd-injecton hypervisorredhat:redhatcredentials worksactive🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation