Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions docs/config/microshift-edge.ks
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
lang en_US.UTF-8
keyboard us
timezone UTC
text
reboot

# Configure network to use DHCP and activate on boot
network --bootproto=dhcp --device=link --activate --onboot=on

# Partition the disk with hardware-specific boot partitions, adding an LVM
# 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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🗄️ 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.

reqpart --add-boot
part pv.01 --grow
volgroup rhel pv.01
logvol / --vgname=rhel --fstype=xfs --size=10240 --name=root

# Lock root user account
rootpw --lock

# Deploy the ostree commit embedded in the edge-installer ISO
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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎯 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
Comment on lines +29 to +31

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🔒 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.


# Import Red Hat public keys to allow RPM GPG check (not necessary if a system is registered)
if ! subscription-manager status >& /dev/null ; then
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-*
fi

# Make the KUBECONFIG from MicroShift directly available for the root user
echo -e 'export KUBECONFIG=/var/lib/microshift/resources/kubeadmin/kubeconfig' >> /root/.bash_profile

# Configure systemd journal service to persist logs between boots and limit their size to 1G
sudo mkdir -p /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/microshift.conf <<EOF
[Journal]
Storage=persistent
SystemMaxUse=1G
RuntimeMaxUse=1G
EOF

# Make sure all the Ethernet network interfaces are connected automatically
# by removing autoconnect option from the configuration files
find /etc/NetworkManager -name '*.nmconnection' -print0 | while IFS= read -r -d $'\0' file ; do
if grep -qE '^type=ethernet' "${file}" ; then
sed -i '/autoconnect=.*/d' "${file}"
fi
done

# Work around bootupd not installing the EFI grub.cfg during ostree deployment.
# Without these files the UEFI firmware loads grubx64.efi but GRUB drops to a
# shell because it cannot find its configuration.
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
Comment on lines +61 to +64

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🩺 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.


%end
120 changes: 83 additions & 37 deletions docs/contributor/rhel4edge_iso.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,24 @@
# Install MicroShift on RHEL for Edge
To test MicroShift in a setup similar to the production environment, it is necessary to create a RHEL for Edge ISO installer with all the necessary components preloaded on the image.

The official [Embedding in a RHEL for Edge image](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) documentation covers the full procedure for building an installer ISO from released MicroShift RPMs. This document describes a modified workflow for building from **locally compiled** RPMs, which is necessary when testing changes that have not been released.

The procedures described in this document require the following setup:
* A `physical hypervisor host` with the [libvirt](https://libvirt.org/) virtualization platform, to be used for starting virtual machines that run RHEL for Edge OS containing MicroShift binaries
* A `physical hypervisor host` running RHEL with the [libvirt](https://libvirt.org/) virtualization platform and at least 50GB of free disk space
* Packages: `libvirt`, `virt-install`, `virt-viewer`, `qemu-kvm`
* A `development virtual machine` set up according to the [MicroShift Development Environment](./devenv_setup.md) instructions, to be used for building a RHEL for Edge ISO installer
* An active RHEL subscription is required for building images

## Build RHEL for Edge Installer ISO
Log into the `development virtual machine` with the `microshift` user credentials.

Follow the instructions in the [RPM Packages](./devenv_setup.md#rpm-packages) section to create MicroShift RPM packages.
Log into the `development virtual machine` with the `microshift` user credentials.

### Prerequisites
Execute the `scripts/devenv-builder/configure-composer.sh` script to install the tools necessary for building the installer image.

Execute the `scripts/devenv-builder/configure-composer.sh` script to install `osbuild-composer` and its dependencies.
```bash
~/microshift/scripts/devenv-builder/configure-composer.sh
```

Download the OpenShift pull secret from the https://console.redhat.com/openshift/downloads#tool-pull-secret page and save it into the `~/.pull-secret.json` file.

Expand All @@ -20,17 +27,54 @@ Make sure there is more than 20GB of free disk space necessary for the build art
~/microshift/scripts/devenv-builder/cleanup-composer.sh -full
```

### Building Installer
> TODO: The `image-builder/build.sh` script has been deprecated.
> This section will be rewritten in the context of [USHIFT-4299](https://issues.redhat.com/browse/USHIFT-4299).
### Build MicroShift RPMs

Follow the instructions in the [RPM Packages](./devenv_setup.md#rpm-packages) section or run:
```bash
cd ~/microshift
make rpm
```

The RPMs are placed under `_output/rpmbuild/RPMS/`.

### Create a Local RPM Repository

Create a local repository from the built RPMs so that `osbuild-composer` can resolve them as a package source. This replaces the released MicroShift RPMs that the [official procedure](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#adding-microshift-repos-image-builder_microshift-embed-in-rpm-ostree) obtains from CDN.

```bash
BUILDDIR=~/microshift/_output/image-builder
mkdir -p "${BUILDDIR}/microshift-local"
cp ~/microshift/_output/rpmbuild/RPMS/*/*.rpm "${BUILDDIR}/microshift-local/"
createrepo "${BUILDDIR}/microshift-local"
chmod -R a+rX "${BUILDDIR}/microshift-local"
```

Register it with `osbuild-composer`:
```bash
cat <<EOF | sudo tee /tmp/microshift-local.toml
id = "microshift-local"
name = "MicroShift Local RPM Repo"
type = "yum-baseurl"
url = "file://${BUILDDIR}/microshift-local/"
check_gpg = false
check_ssl = false
system = false
EOF

sudo composer-cli sources add /tmp/microshift-local.toml
```

### Build the Image

With the local RPM source registered, follow the official documentation starting from [Adding MicroShift repositories to image builder](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#adding-microshift-repos-image-builder_microshift-embed-in-rpm-ostree) through [Download the ISO and prepare it for use](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#microshift-download-iso-prep-for-use_microshift-embed-in-rpm-ostree). The procedure is identical — `osbuild-composer` will resolve `microshift` packages from the local repository instead of CDN.

Use `rhel/9/x86_64/edge` as the ostree ref in all `composer-cli compose start-ostree --ref` commands. This must match the ref in the [`microshift-edge.ks`](../config/microshift-edge.ks) kickstart.

### Disk Partitioning
The `kickstart.ks` file is configured to partition the main disk using `Logical Volume Manager` (LVM). Such partitioning is required for the data volume to be utilized by the MicroShift CSI driver and it allows for flexible file system customization if the disk space runs out.
The [`microshift-edge.ks`](../config/microshift-edge.ks) file is configured to partition the main disk using `Logical Volume Manager` (LVM). Such partitioning is required for the data volume to be utilized by the MicroShift CSI driver and it allows for flexible file system customization if the disk space runs out.

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)
Comment on lines 76 to +77

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎯 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.

Suggested change
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.

* Boot partition is allocated on a 1GB volume
* The rest of the disk is managed by the `LVM` in a single volume group named `rhel`
* System root partition is allocated on a 10GB volume (minimal recommended size for a root partition)
Expand All @@ -41,63 +85,65 @@ By default, the following partition layout is created and formatted with the `XF

As an example, a 20GB disk is partitioned in the following manner by default.
```
$ lsblk /dev/sda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 200M 0 part /boot/efi
├─sda3 8:3 0 800M 0 part /boot
└─sda4 8:4 0 19G 0 part
$ lsblk /dev/vda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 600M 0 part /boot/efi
├─vda2 252:2 0 1G 0 part /boot
└─vda3 252:3 0 18.4G 0 part
└─rhel-root 253:0 0 10G 0 lvm /sysroot

$ sudo vgdisplay -s
"rhel" <19.02 GiB [10.00 GiB used / <9.02 GiB free]
"rhel" 18.41 GiB [10.00 GiB used / 8.41 GiB free]
```

> Unallocated disk space of 9GB size remains in the `rhel` volume group to be used by the CSI driver.
> Unallocated disk space of 8GB size remains in the `rhel` volume group to be used by the CSI driver.

## Install MicroShift for Edge

Log into the `physical hypervisor host` using your user credentials. The remainder of this section describes how to install a virtual machine running RHEL for Edge OS containing MicroShift binaries.

Start by copying the installer image from the `development virtual machine` to the host file system.
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 ~/

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🗄️ 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.md

Repository: 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 $(whoami). ${BUILDID}-installer.iso [1][2][3][4]

Citations:


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.

scp microshift@<dev-vm-ip>:/home/microshift/microshift/docs/config/microshift-edge.ks ~/
```

Run the following commands to create a virtual machine using the installer image.
Run the following commands to create a virtual machine using the installer image. The `--boot uefi` flag is required because the ostree image uses `bootupd` for bootloader management, which only supports UEFI. The `--location` flag extracts the installer kernel from the ISO for direct boot, and `--initrd-inject` embeds the kickstart into the installer initrd.
```bash
VMNAME="microshift-edge"
NETNAME="default"
sudo bash -c " \
cd /var/lib/libvirt/images/ && \
virt-install \
--name ${VMNAME} \
ISOFILE="${HOME}/microshift-installer.$(uname -m).iso"

sudo virt-install \
--name "${VMNAME}" \
--vcpus 2 \
--memory 3072 \
--disk path=./${VMNAME}.qcow2,size=20 \
--network network=${NETNAME},model=virtio \
--memory 4096 \
--boot uefi \
--disk path="${HOME}/${VMNAME}.qcow2,size=50" \
--network network="${NETNAME}",model=virtio \
--events on_reboot=restart \
--cdrom ./microshift-installer-*.$(uname -m).iso \
--location "${ISOFILE}" \
--initrd-inject "${HOME}/microshift-edge.ks" \
--extra-args "inst.ks=file://microshift-edge.ks" \
Comment on lines +127 to +128

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎯 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:


🌐 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:


🌐 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:


🌐 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:


🌐 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:


🌐 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:


🌐 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:


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.

Suggested change
--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.

--noautoconsole \
--wait \
"
--wait
```

Watch the OS console to see the progress of the installation, waiting until the machine is rebooted and the login prompt appears.

Note that it may be more convenient to access the machine using SSH. Run the following command to get its IP address and use it to remotely connect to the system.
```bash
sudo virsh domifaddr microshift-edge
sudo virsh domifaddr "${VMNAME}"
```

Log into the system using `redhat:redhat` credentials and run the following commands to configure MicroShift access.
Log into the system using `redhat:redhat` credentials (as configured in [`microshift-edge.ks`](../config/microshift-edge.ks)) and run the following commands to configure MicroShift access.
```bash
mkdir ~/.kube
sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
```
Comment on lines 142 to 144

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🔒 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.

Suggested change
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.


Finally, check if MicroShift is up and running by executing `oc` commands.
Verify that MicroShift is up and running.
```bash
oc get cs
oc get pods -A
```