HowTo build latest mainline kernel packages for Trixie

From Debian Forums Cache
Jump to navigation Jump to search

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

NOTE: 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"). This HowTo is intended mostly for folks that 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. If you want to try the very latest stable release, 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. In case of Sid and Experimental packages, it's usually more recommended to rebuild them with Trixie's gcc-14 (see point 2) rather than pulling half of a system of dependencies from Sid.

The examples below are based on 7.0~rcX versions, the instructions were also tested on 7.1 and should be mostly applicable to later mainline 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)"
  1. 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 ~2MB in case of --depth=1). Next, cd into the cloned repo's folder: all commands from the remaining points are supposed to be issued in that folder.
  2. Replace c_compiler in debian/config/defines.toml from Sid's and Forky's gcc-15 to Trixie's gcc-14.
  3. 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).
  4. Decide for your suffix of Debian-release part of the package version. The suffix must be of the form [a-z]+${SEQUENTIAL_NUMBER} and the SEQUENTIAL_NUMBER must be increased each time you build the packages for a given upstream version. For example I use morgwai1, then morgwai2 and so on. Export your suffix for example as VERSION_SUFFIX and then create a new entry in debian/changelog for the desired upstream kernel version with the target suite set to UNRELEASED. For example in case of 7.0~rc7: 
    cat - debian/changelog >changelog-new <<EOF
linux (7.0~rc7-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) <${USER}@$(hostname)>  $(date -R)

EOF
mv changelog-new debian/changelog

    (at this stage, dch usually cannot be used as debian/control has not been generated yet)

  5. ABI name management:
    • For new features testing purposes, it is often useful to be able to install several "rcX" kernel packages along each other, but by default, ~rcX part is not included in the ABI name (and as a consequence neither in package names) of packages built for UNRELEASED suite. 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 builds 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 change your VERSION_SUFFIX.

  6. 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. 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).
  7. Starting with 7.1, debian/watch uses a new format not supported by tools in Trixie, so replace it with the version from 7.0.x: 
    git checkout debian/7.0/trixie-backports -- debian/watch

    If you cloned the repo with --depth, then get it using curl or wget instead: 

    wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.0/trixie-backports/debian/watch

    Next, fetch the kernel sources from the kernel.org repo and create a corresponding orig.tar.xz file in the parent folder: 

    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.

    Finally, extract the kernel source form the orig.tar.xz and "merge" it into the debianization: 

    debian/rules orig

    This will generate debian/control and apply all the patches from debian/patches. 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. Otherwise you need decide whether to rework such patch or if it concerns features you don't use, in which case you can remove it also.

  8. 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 export DEB_BUILD_PROFILES="nodoc noudeb". Note that applying some of the profiles may modify your kernel config (for example pkg.linux.nokerneldbg and pkg.linux.nokerneldbginfo).
  9. 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.

    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.

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

  10. Install the packages built in the parent folder, 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 secure-boot or sign it for example using sbsign.

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

Retrieved from "https://cache.forums.debian.net/index.php?title=HowTo_build_latest_mainline_kernel_packages_for_Trixie&oldid=288"