HowTo build the latest mainline or rebuild Sid kernel packages for Trixie

In essence, this HowTo summarizes the invaluable insights from @Aki (from this thread) and @stevepusser (from this thread) and the general info from the kernel handbook (mainly chapter 4).

WHICH KERNEL VERSION TO USE

A given moment's latest mainline kernel is usually not ready for a general use, especially during "rcX" versions as their names clearly suggest ("release candidate"). A notable scenario that does require the latest mainline is if you need to post logs to LKML or bugzilla.kernel.org where discussions/questions/bug-reports regarding anything older than the latest mainline will almost always be ignored. Note however that before posting a new issue there, you should test if the problem is present on several kernel series (at least the latest mainline and the latest stable and preferably also some LTS) across several distros and mention this fact in your report.

In most other cases, you should generally stick with the latest stable release at most: check Debian's official trixie-backports, sid and experimental suites (in that order) : the Kernel Team usually publishes packages just a few days after a tag is created in kernel.org's stable repo. Mind the following in such case:

Kernels from trixie-backports can be installed right-away in most cases, however currently the notable exception is if you use Debian-packaged Nvidia drivers.
In case of packages from unstable and experimental suites, it's usually more recommended to first rebuild them for Trixie (as described below) rather than pulling half of a system of dependencies from Sid.
Kernels from experimental suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
NONE OF THE ABOVE SUITES IS FORMALLY COVERED BY THE DEBIAN SECURITY TEAM, so you should watch kernel security announcements yourself.
If you use any firmware-* packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.

INSTRUCTIONS META

The examples below are based mostly on 7.0~rcX versions, the instructions were also tested on 7.2 and should be mostly applicable to later versions as well, at least in the near future.
The env var ARCH used in some commands below refers to the primary architecture of your system (like amd64 or arm64), it can be exported for convenience with
```
export ARCH="$(dpkg --print-architecture)"
```
If you plan to publish your packages somewhere, you can export DEBEMAIL to contain your public email.

(RE)-BUILDING PROCEDURE

Obtain the closest possible debianization:
- In case of building the latest mainline:
  Clone debian/latest branch of the Linux kernel debianization from the Kernel Team's Salsa. Consider limiting history depth with --depth to reduce the transfer size from hundreds of MB even down to ~3MB in case of --depth=1, for example:
```
git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux
```
- In case of rebuilding from unstable/experimental:
  - IF you have the given suite configured, download and extract the source package using apt source, for example:
```
apt source linux=7.2.2-1~exp1
```
  - OTHERWISE download the source package files (.dsc, .debian.tar.xz and .orig.tar.xz) for example from Snapshot repository, then extract and merge it with
```
dpkg-source -x linux*.dsc
```
Next, cd into the resulting linux*/ folder: all commands from the remaining points are supposed to be issued in that folder.
Replace c_compiler in debian/config/defines.toml from Forky's / Sid's gcc-15/gcc-16 to Trixie's gcc-14.
Starting with v6.19, the build process by default does not produce linux-image-${ABI}-*, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off enable_signed in debian/config/${ARCH}/defines.toml file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).
Decide for your local suffix of "Debian release" part of the package version. The suffix must consist of lowercase letters only, followed by a sequential local release number that must be increased each time you modify your debianization for a given upstream version / base release. For example, I use morgwai1, then morgwai2 and so on. Export your suffix together with the local release number as VERSION_SUFFIX: it will be useful later.
- In case of building the latest mainline:
  Create a new entry in debian/changelog for the desired upstream kernel version with:
  - "future" Debian release (the number after a dash) set to 1,
  - "local pre-release" (the part after a tilde) set to your VERSION_SUFFIX,
  - target suite set to UNRELEASED.
  So for example in case of the upstream version 7.0~rc7:
```
export UPSTREAM_VERSION="7.0~rc7"
cat - debian/changelog >changelog-new <<EOF
linux (${UPSTREAM_VERSION}-1~${VERSION_SUFFIX}) UNRELEASED; urgency=medium

  * New upstream release candidate.
  * Packaging changes for Trixie.

 -- $(getent passwd ${USER} |cut -d : -f 5 |cut -d , -f 1) <${DEBEMAIL:-${USER}@$(hostname)}>  $(date -R)

EOF
mv changelog-new debian/changelog
```
  Mind dashes (-) vs tildes (~) in the version string.
- In case of rebuilding from unstable/experimental:
  Use dch --local followed by your local release suffix without the local release number (1 will be appended automatically), for example in my case:
```
dch --local morgwai
```
  If later you want to build a subsequent local release of the same "base" unstable/experimental release, use
```
dch -i
```
  This will increase just your local release number (remember to update your VERSION_SUFFIX var accordingly and the ABI name: see the next point).
  In both cases, dch will create a template entry in debain/changelog and open your EDITOR to fill just a description of changes: you can enter for example something like "Packaging changes and rebuild for Trixie". dch may complain about missing DEBEMAIL var: in case of a local build, just ignore it.
ABI name management:
- By default, neither upstream's minor version nor "rcX" part is included in the ABI name (and as a consequence neither in package names) of packages built for UNRELEASED suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove abi_version_full = false line from the [[debianrelease]] section for UNRELEASED suite in debian/config/defines.toml file.
- If you also want to be able to install along each other packages for several releases of the same upstream version, include your VERSION_SUFFIX in abi_suffix in the same section, for example:
```
sed -e "s#abi_suffix = '+unreleased'#abi_suffix = '+${VERSION_SUFFIX}'#" debian/config/defines.toml >defines-new.toml
mv defines-new.toml debian/config/defines.toml
```
  Unfortunately, you need to update it each time you increase the local release number in your VERSION_SUFFIX.
By default, packages for all feature-sets (the default and rt and cloud) and flavors (like arm64-16k) are built, which is rarely needed, probably only by the maintainers when publishing the official packages. Of course it also causes the build to take n times longer and use n times more temporary space. To disable unneeded feature-sets / flavors, edit debian/config/${ARCH}/defines.toml and remove their corresponding [[flavour]] sections (usually at the top of a given file).
Starting with v7.1, debian/watch uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
```
wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch
```
In case of building the latest mainline only: fetch the kernel sources from the kernel.org repo and create a corresponding .orig.tar.xz file in the parent folder with the below command:
```
uscan --download-current-version --vcs-export-uncompressed
```
Note that the stable kernel tree sometimes lags with syncing "-rcX" tags from Linus, so soon after a creation of a such, you may need to use his tree instead in debian/watch.
Run
```
debian/rules orig
```
In case of rebuilding, the above is necessary to regenerate debian/control as some package names contain the ABI name.
In case of building the latest mainline, this may be the most tricky part: it will extract the kernel source from the .orig.tar.xz, "merge" it into the debianization, generate debian/control and apply all the patches from debian/patches/ folder. It may happen that some of the patches cannot be applied cleanly due to changes in the involved parts of the source code. Sometimes a patch may be already applied in the latest upstream version (this is common situation for security patches), in which case you can simply remove it from debian/patches/ and its mention from debian/patches/series file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.
Several build profiles are defined, described in debian/README.source. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least noudeb and nodoc and if you also want to skip "binary" packages with kernel sources, then add pkg.linux.nosource:
```
export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"
```
Note that applying some of the other profiles may modify your kernel config (for example pkg.linux.nokerneldbg and pkg.linux.nokerneldbginfo).
At this point you are ready to start the build process using 1 of the standard Debian ways:
- EITHER install all the build deps and build binary packages directly on your system:
```
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
```
  (Also check Aki's ccache guide)
- OR build a source package first with
```
dpkg-source --build .
```
  ...and then use for example sbuild to build binary packages in a clean chroot-ed environment or build and publish them on OBS.
  Note: if dpkg-source complains about leftover Python caches, just remove the __pycache__ folder it will point and repeat the above command.
The build process may take from 10 minutes to several hours depending on your hardware. A fresh build (empty ccache) of the default amd64 feature-set of 7.1 takes about 1.5h on OBS, uses a bit less than 60GB of temporary space and produces a bit less than 6GB of ccache.
If for whatever reason you want to restart the build/configuration process from scratch, the command debian/rules maintainerclean will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run debian/rules orig: useful when you want to build a new upstream version).

INSTALLING THE BUILT PACKAGES

Since the release 7.2-1~exp1, built packages depend on linux-base versions not available in Trixie. This package contains scripts called by kernel's postinst / prerm scripts and fortunately does not depend on any other stuff not available in Trixie, so the easiest way is to just install this single one from Sid:
- IF you have unstable suite configured, then simply
```
sudo apt install linux-base/unstable
```
- OTHERWISE download the latest version say from Snapshot repo and install the .deb file directly, for example currently version 4.17:
```
wget https://snapshot.debian.org/archive/debian/20260902T143423Z/pool/main/l/linux-base/linux-base_4.17_all.deb
sudo apt install ./linux-base_*_all.deb
```

Install the packages built in the parent folder (in case of using dpkg-buildpackage), usually at least the below:

sudo apt install \
  ../linux-base-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-binary-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-image-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-modules-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb

If you intend to build any modules with dkms (for example Nvidia drivers), then also these:

sudo apt install \
  ../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
  ../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb

FLAVOR on x86_64 machines is the same as ARCH (amd64), in case of ARM it may be either arm64 or arm64-16k, depending on what was left in debian/config/arm64/defines.toml in point 6.

Remember that the kernel is unsigned, so you need to either disable your secure-boot or sign the image manually, for example using sbsign.

At this point your system should be ready to reboot to the new kernel.

HowTo build the latest mainline or rebuild Sid kernel packages for Trixie

Navigation menu

Search