Chapter 12. Managing kernel arguments in bootc systems
You can customize the boot process of your Red Hat Enterprise Linux bootc systems by managing kernel arguments. By configuring these parameters, you can tune performance and ensure hardware compatibility by applying settings during the image build or installation phase.
You can use bootc to configure kernel arguments. By default, bootc uses the boot loader configuration files stored in /boot/loader/entries. This directory defines arguments provided to the Linux kernel. The set of kernel arguments is machine-specific state, but you can also manage the kernel arguments by using container updates. The boot loader menu entries are shared between multiple operating systems, and boot loaders are installed on one device.
Currently, the boot loader entries are written by an OSTree backend.
12.1. Adding support to inject kernel arguments by using bootc Copy linkLink copied to clipboard!
The bootc tool uses generic operating system kernels. You can add support to inject kernel arguments by adding a custom configuration, in the TOML format, in /usr/lib/bootc/kargs.d.
Prerequisites
- You created a container image.
Procedure
Add support to inject kernels, for example:
# /usr/lib/bootc/kargs.d/10-example.toml kargs = ["mitigations=auto,nosmt"]-
Optional: You can also make these kernel arguments architecture-specific by using the
match-architectureskey. For example:
# /usr/lib/bootc/kargs.d/00-console.toml
kargs = ["console=ttyS0,115200n8"]
match-architectures = ["x86_64"]
12.2. Modifying kernel arguments by using bootc install configurations Copy linkLink copied to clipboard!
To modify kernel arguments by using the bootc install configurations, you can customize the startup behavior of your Red Hat Enterprise Linux deployments. These parameters enable specific hardware settings or performance optimizations that persist through system updates and reboots.
You can use the bootc install command with the --karg option to inject kernel arguments during installation time in the following ways:
- Adding kernel arguments into the container image.
-
Adding kernel arguments by using the
bootc install --kargcommand.
Use the kernel arguments on Day 2 operations, by adding the arguments and applying them on a switch, upgrade, or edit.
Prerequisites
- You created a container image.
Procedure
Create files within
/usr/lib/bootc/kargs.dwith kernel arguments.$ sudo tee /usr/lib/bootc/kargs.d/console.kargs << EOF console=tty0 console=ttyS0,115200n8 EOFFetch the container image to get the OSTree commit.
$ podman pull quay.io/<your_org>/<your_bootc_image>:latestUse the OSTree commit to return the file tree.
# bootc install to-filesystem --karg=root=<UUID>=<uuid of /mnt> --imgref $self /mntNavigate to the
/usr/lib/bootc/kargs.dkernel arguments directory.cd /usr/lib/bootc/kargs.dRead each file within the kernel arguments directory.
$ find /usr/lib/bootc/kargs.d -name ".kargs" -exec cat {} \;*Push the contents of each
kargsfile into a file containing all the neededkargs.$ CONSOLIDATED_KARGS="/tmp/all-kargs.txt"Pass the
kargsto thestage()function.$ bootc kargs --append="$KARGS_STRING"Apply the kernel arguments to switch, upgrade, or edit during operations.
$ bootc switch --transport=registry quay.io/<your_org>/<your_bootc_image>:latest
12.3. Injecting kernel arguments in the Containerfile Copy linkLink copied to clipboard!
Inject kernel arguments into your Red Hat Enterprise Linux Containerfile to configure boot parameters during the image build process. Embedding these settings ensures that specific kernel options are consistently applied to any system provisioned from the container image, eliminating the need for post-deployment configuration.
Prerequisites
- You created a container image.
Procedure
Inject kernel arguments:
FROM registry.redhat.io/rhel10/rhel-bootc:latest RUN mkdir -p /usr/lib/bootc/kargs.d RUN cat <<EOF >> /usr/lib/bootc/kargs.d/console.toml kargs = ["console=ttyS0,115200n8"] match-architectures = ["x86_64"] EOF RUN cat <<EOF >> /usr/lib/bootc/kargs.d/01-mitigations.toml kargs = ["mitigations=on", "systemd.unified_cgroup_hierarchy=0"] match-architectures = ["x86_64", "aarch64"] EOF
12.4. Injecting kernel arguments at installation time Copy linkLink copied to clipboard!
You can use boot install with the --karg to inject kernel arguments during installation time. As a result, the kernel arguments become the machine-local state, that is, they became the persistent configuration unique to that specific machine.
Prerequisites
- You created a container image.
Procedure
Inject kernel arguments:
# bootc install to-filesystem --karg=root=<UUID>=<uuid of /mnt> --imgref $self /mnt
12.5. Adding install-time kernel arguments by using bootc-image-builder Copy linkLink copied to clipboard!
Use the bootc-image-builder to add install-time kernel arguments to Red Hat Enterprise Linux bootc images. Defining the kernel parameters by using the customizations.kernel.append to configure hardware-specific settings or console outputs required during the initial povisioning process.
Prerequisites
- You created a container image.
Procedure
Add kernel arguments with
bootc-image-builderby using the following customization:{ "customizations": { "kernel": { "append": "mitigations=auto,nosmt" } } }
12.6. How kernel arguments change after the installation with kargs.d Copy linkLink copied to clipboard!
The changes that you make to kargs.d files and include in a container build are applied after the installation, and the difference between the set of kernel arguments is applied to the current boot loader configuration. This preserves any machine-local kernel arguments.
You can use any tool to edit the /boot/loader/entries files, which are in a standardized format. The /boot file has read-only access to limit the set of tools that can write to this filesystem.
12.7. Editing kernel arguments in bootc systems Copy linkLink copied to clipboard!
To perform machine local changes, you also can edit kernel arguments on a bootc system or an rpm-ostree system, by using the rpm-ostree kargs command. The changes are made through the user/lib/bootc/kargs.d path, which also handles Day 2 changes, besides the first boot changes.
Prerequisites
- You created a container image.
Procedure
Append a kernel argument, for example:
# rpm-ostree kargs --append debug Staging deployment... done Freed: 40.1 MB (pkgcache branches: 0) Changes queued for next boot. Run "systemctl reboot" to start a rebootCheck the help for more information:
# rpm-ostree kargs --helpThe following are the options that you can use to add, modify or remove kernel arguments.
rpm-ostree kargs- --append=KEY=VALUE
-
Appends a kernel argument. It is useful with, for example,
console=that can be used multiple times. You can use an empty value for an argument. - --replace=KEY=VALUE=NEWVALUE
-
Replaces an existing kernel argument. You can replace an argument with
KEY=VALUEonly if one value already exists for that argument. - --delete=KEY=VALUE
- Deletes a specific kernel key-value pair argument or an entire argument with a single key-value pair.
- --append-if-missing=KEY=VALUE
- Appends a kernel argument. Does nothing if the key is already present.
- --delete-if-present=KEY=VALUE
- Deletes a specific kernel key-value pair argument. Does nothing if the key is missing.
- --editor
- Uses an editor to modify the kernel arguments.
12.8. Integrating third-party drivers in image mode for RHEL Copy linkLink copied to clipboard!
To ensure that drivers persist across updates, include your third-party kernel modules directly in the container build process. This way, networking and security drivers remain available across image updates, upgrades, and reboots.
To use filesystem, networking, or security modules not included in the default RHEL kernel, you can use the image mode for the RHEL workflow. Unlike the traditional package mode, where drivers are installed on a live system by using dnf, image mode treats the filesystem as immutable.
To include your custom drivers, you can use a multi-stage build. Use the rhel-bootc image as your builder stage to install your third-party kernel modules and compile your source code. This guarantees the driver is compatible with the kernel in the resulting bootable image.
Prerequisites
-
You wrapped your
.kofile in an RPM to handle dependency mapping by automatically usingdepmodduring the container build.
Procedure
On your build host, compile your driver and build the RPM package.
Verify the spec and build the package:
$ cat SPECS/hello.specBuild the driver RPM:
$ rpmbuild -ba SPECS/hello.spec
Create the
Containerfileto append the driver into the operating system image. Use therhel-bootcbase image. The following is an example:# Copy the pre-built RPM into the build context COPY rpms/hello-<version>-<release>.el10.<arch>.rpm /tmp/Alternatively, you can fetch it from a network location.
# Install the RPM. # The %post scripts in the RPM triggers 'depmod' automatically inside the image. RUN dnf install -y /tmp/hello-<version>-<release>.el10.<arch>.rpm && \ dnf clean all && \ rm /tmp/hello-<version>-<release>.el10.<arch>.rpm- Build and run your container image. See Building a container.
Verification
Reboot the system:
$ sudo rebootConfirm the kernel module is available on the system:
$ sudo uname -r <kernel_version> $ sudo ls -l /lib/modules/<kernel_version>/extra/ total 12 -rwxr-xr-x. 1 root root 8512 Jan 1 1970 hello.koEnsure that the module dependencies are calculated before the image is finalized, otherwise
modprobemight fail on the first boot.$ sudo depmod -a <kernel-version>Confirm that you can load the module:
$ sudo modprobe /lib/modules/<kernel_version>/extra/hello.ko $ sudo lsmod | grep hello hello 12288 0 $ sudo rmmod hello $ sudo dmesg ..snip.. [ 84.738633] hello: loading out-of-tree module taints kernel. [ 84.738684] hello: module verification failed: signature and/or required key missing -tainting kernel. [ 84.740548] Hello, world! [ 138.206978] Goodbye!