Project:Distribution Kernel/Bumping kernels

From Gentoo Wiki
Jump to:navigation Jump to:search

The process of bumping Gentoo dist-kernel packages involves a few helpful scripts that are used to update the ebuilds and build binary kernel packages. The whole process of testing the kernels and building binpkgs is done in a Docker container, so that it can be reliably reproduced on different hosts, as well as done remotely. This document describes the bumping process.

When are dist-kernels bumped?

Dist-kernels are bumped after the Gentoo kernel team releases the new genpatches tarballs, i.e. after sys-kernel/gentoo-sources are bumped.

However, it is useful to monitor #gentoo-kernel (webchat) or upstream release feeds, and start preparing the build containers as described below.



At the moment, dist-kernel packages are built for amd64, arm64, ppc64le and x86 platforms. Normally, the arm64 and ppc64le builds are done using the relevant devboxes, so if you're planning on bumping the kernels, please request access to them. If you do not own a beefy amd64 box, you may want to also perform amd64 and/or x86 builds remotely.

The boxes used to build kernels do not need to be running Gentoo. They only need a running Docker daemon and your user needs to have permissions to use it.

Initial local box setup

On the development box, install the Docker client and helpful scripts used to bump kernels:

root #emerge --ask app-containers/docker-cli app-portage/mgorny-dev-scripts

Clone the scripts used to build packages, preferably in ~/git:

user $cd ~/git
user $git clone

Inside the repository, create a file called localconfig.bash and put the remote hosts used to build kernels inside. For example, for arm64/ppc64le devboxes you'd use:

FILE binpkg-docker/localconfig.bash

If you're also going to perform amd64/x86 builds remotely, add appropriate hosts with AMD64 and X86 suffixes.

Preparing the build images (optional)

When new kernels are released upstream but gentoo-sources are not ready yet, you can prepare the build images early. In binpkg-docker:

user $make build-amd64-kernel-deps
user $make build-arm64-kernel-deps
user $make build-ppc64le-kernel-deps
user $make build-x86-kernel-deps

This will create Docker images with the necessary tools and baseline gentoo.git checkout. To avoid conflicts, you should also update your local gentoo.git checkout at the same time and use it for base for the kernel bumps.

Bumping the kernels

Bumping source packages

If your binpkg-docker checkout is not in ~/git/binpkg-docker, you need to set BINPKG_DOCKER envvar to the correct path.

The kernel bumps are done using bump-kernels script from app-portage/mgorny-dev-scripts. The script is run inside gentoo.git and takes one or more pairs of arguments specifying the old and new versions respectively:

user $bump-kernels 5.16.{14,15} 5.15.{28,29} 5.10.{105,106} 5.4.{184,185}

The script will copy kernel ebuilds and then open your ${EDITOR} to edit them. You may need to update upstream config (CONFIG_VER and CONFIG_HASH), Gentoo config (GENTOO_CONFIG_VER) and genpatches offset (GENPATCHES_P, in case of sys-kernel/gentoo-kernel). For the latter, it is recommended to grep gentoo-sources to avoid missing an update, e.g.:

user $grep K_GENPATCHES sys-kernel/gentoo-sources/gentoo-sources-5.16.15.ebuild

Afterwards, the script will update the Manifest, perform signature verification (in case of sys-kernel/vanilla-kernel) and perform the commit. Once all kernels are committed, it will also create local.diff in the binpkg-docker checkout that will be used to build the kernels.

Building binary packages

It makes sense to run builds for different platforms on separate terminals to perform them in parallel.

Enter the binpkg-docker checkout and start the kernel builds.

user $make amd64-gentoo-kernel-{newest,lts,lts2,lts3}
user $make arm64-gentoo-kernel-{newest,lts,lts2,lts3}
user $make ppc64le-gentoo-kernel-{newest,lts,lts2,lts3}
user $make x86-gentoo-kernel-{newest,lts,lts2,lts3}
The listed commands assume building a complete set of kernels (newest + 3 LTS releases). Adjust the list if you're doing a partial kernel bump.

If you haven't prepared the build images yet, Docker will do that now. It will then apply the gentoo.git changes from local.diff (i.e. your bumps), build the kernels, test them and copy the resulting binary packages into ~/binpkg.

The src_test phase occasionally fails with kernel panic. If that happens, retry.

The resulting binary packages need to be copied to your devspace for distribution. To do so, use:

user $rsync-kernel-binpkgs

This will first rsync new kernel packages from kamaji and bogsucker to your ~/binpkg tree, then rsync this tree into

rsync-kernel-binpkgs hardcodes both hostnames and local paths. If you wish to use different hosts or different paths, you need to fork the scripts.

Once all kernels are built successfully, it is worthwhile to prune old containers and images immediately. If you forget to do that, the next builds will reuse existing images and will fail to apply the diff. To do so, you can use the convenience target that iterates over all Docker hosts and prunes tagged containers and images from them:

user $make prune

Bumping binary kernel packages

Enter gentoo.git once again and run bump-kernels-bin with the same arguments as the earlier bump-kernels call:

user $bump-kernels-bin 5.16.{14,15} 5.15.{28,29} 5.10.{105,106} 5.4.{184,185}

This script copies kernel packages from your ~/binpkg tree to your DISTDIR, and bumps sys-kernel/gentoo-kernel-bin. Note that you may need to sync GENPATCHES_P with the respective source package, and possibly update the binary package URLs.