Support for pinned kernel versions

[oglok]

Describe the bug While building Fedora, the updates repo only contains the latest kernel for that specific distro version. We would like to be able to pin older kernels, in case there is some custom package built against it, hw incompatibility, etc.

Environment

• OS version (/etc/os-release and /etc/redhat-release): [root@fedoravm image-builder]# cat /etc/os-release NAME="Fedora Linux" VERSION="37 (Server Edition)" ID=fedora VERSION_ID=37 VERSION_CODENAME="" PLATFORM_ID="platform:f37" PRETTY_NAME="Fedora Linux 37 (Server Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:37" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f37/system-administrators-guide/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=37 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=37 SUPPORT_END=2023-11-14 VARIANT="Server Edition" VARIANT_ID=server
• osbuild-composer version (rpm -qi osbuild-composer) [root@fedoravm image-builder]# rpm -qi osbuild-composer Name : osbuild-composer Version : 71 Release : 1.fc37 Architecture: aarch64 Install Date: Wed 11 Jan 2023 05:00:26 PM CET Group : Unspecified Size : 17586 License : ASL 2.0 Signature : RSA/SHA256, Wed 28 Dec 2022 10:28:30 AM CET, Key ID f55ad3fb5323552a Source RPM : osbuild-composer-71-1.fc37.src.rpm Build Date : Wed 28 Dec 2022 10:17:19 AM CET Build Host : buildvm-a64-36.iad2.fedoraproject.org Packager : Fedora Project Vendor : Fedora Project URL : https://github.com/osbuild/osbuild-composer Bug URL : https://bugz.fedoraproject.org/osbuild-composer Summary : An image building service based on osbuild Description :

A service for building customized OS artifacts, such as VM images and OSTree commits, that uses osbuild under the hood. Besides building images for local usage, it can also upload images directly to cloud.

It is compatible with composer-cli and cockpit-composer clients.

To Reproduce Steps to reproduce the behavior: Example blueprint:

[root@fedoravm image-builder]# cat fedora-nx-blueprint.toml

name = "microshift"
version = "*"

[[packages]]
name = "crio"
version = "*"

[[packages]]
name = "cri-tools"
version = "*"

[[packages]]
name = "runc"
version = "*"

[[packages]]
name = "lvm2"
version = "*"

[[packages]]
name = "chrony"
version = "*"

[[packages]]
name = "nvidia-jetson-sidecar"
version = "*"

[[packages]]
name = "nvidia-jetson-sidecar-kmod"
version = "*"

[[packages]]
name = "nvidia-container-toolkit-base"
version = "*"

[[packages]]
name = "kernel"
version = "6.0.18"

[customizations]

[[customizations.user]]
name = "redhat"
password = "$6$ajRiXQp00l5gVTW6$lajGTqDcPO5t4zmXaDi81vpKlb9tWgYzN3tnVs6OxrX2uEpc1VHno/up/53fG3Nd.xkeVLpmBd.7dw0JgHu1p/"

First of all, the kernel 6.0.18 is not found because the rpm has been updated in the Fedora Updates repo. I had to add the fedora-update-archive repo as a source to be able to install it.

composer-cli sources info FedoraUpdatesArchive
check_gpg = true
check_ssl = false
id = "FedoraUpdatesArchive"
name = "FedoraUpdatesArchive"
rhsm = false
system = false
type = "yum-baseurl"
url = "https://fedoraproject-updates-archive.fedoraproject.org/fedora/37/aarch64/"

The resulting image (type image-installer) contains both kernels, the latest one and the pinned one.

Expected behavior A clear and concise description of what you expected to happen.

I'd expect to have the resulting image with only the pinned version of the kernel.

Additional context Add any other context about the problem here.

[achilleas-k]

Thanks for writing this up. The way this behaves will cause even bigger issues for ostree-based image types. The compose will fail if it finds multiple kernels (or more specifically, multiple kernel module directories) installed.

[oglok]

@cgwalters, is this an expected behavior? is there a workaround or configuration to be able to pick a specific kernel version? Thanks in advance!

[cgwalters]

Today, osbuild does all the fetching and dependency resolution itself. See discussion in https://github.com/osbuild/osbuild/issues/1134

The "you can have one kernel" thing is deeply baked into the ostree design. So osbuild would need to ensure that exactly one preferred kernel is passed in today. (Or of course as the above issue alludes, long term deduplicating logic here would help ensure this, because rpm-ostree has some specific logic around kernels, and actually supports things like lockfiles and pinning specific versions that isn't being used here)