Debian Forums Cache - User contributions [en]

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

2026-09-08T12:18:50Z

Morgwai: Re-import from the forum: formatting

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> '''NONE OF THE ABOVE SUITES IS FORMALLY COVERED BY THE DEBIAN SECURITY TEAM''', so you should watch [https://tracker.debian.org/pkg/linux kernel security announcements] yourself.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~3MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files (<code>.dsc</code>, <code>.debian.tar.xz</code> and <code>.orig.tar.xz</code>) for example from [https://snapshot.debian.org/package/linux/ Snapshot repository], then extract and merge it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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 <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix together with the local release number as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent local release of the same "base" <code>unstable</code>/<code>experimental</code> release, use
<pre>dch -i</pre>
This will increase just your local release number (remember to update your <code>VERSION_SUFFIX</code> var accordingly and the ABI name: see the next point).

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>.orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>.orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways:
<ul><li> ''EITHER'' install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

</li><li> ''OR'' build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> versions not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download the latest version say from [https://snapshot.debian.org/package/linux-base/ Snapshot repo] and install the <code>.deb</code> file directly, for example currently version 4.17:
<pre>
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
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-08T11:46:07Z

Morgwai: Re-import from the forum: disk space considerations

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> '''NONE OF THE ABOVE SUITES IS FORMALLY COVERED BY THE DEBIAN SECURITY TEAM''', so you should watch [https://tracker.debian.org/pkg/linux kernel security announcements] yourself.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files (<code>.dsc</code>, <code>.debian.tar.xz</code> and <code>.orig.tar.xz</code>) for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract and merge it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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 <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent local release of the same "base" <code>unstable</code>/<code>experimental</code> release, use
<pre>dch -i</pre>
This will increase just your local release number (remember to update your <code>VERSION_SUFFIX</code> var accordingly and the ABI name: see the next point).

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>.orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>.orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> versions not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download the latest version say from [https://snapshot.debian.org/package/linux-base/ Snapshot repo] and install the <code>.deb</code> file directly, for example currently version 4.17:
<pre>
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
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-07T09:12:38Z

Morgwai: Re-import from the forum: note on updating ABI name after dch -i

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> '''NONE OF THE ABOVE SUITES IS FORMALLY COVERED BY THE DEBIAN SECURITY TEAM''', so you should watch [https://tracker.debian.org/pkg/linux kernel security announcements] yourself.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files (<code>.dsc</code>, <code>.debian.tar.xz</code> and <code>.orig.tar.xz</code>) for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract and merge it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent local release of the same "base" <code>unstable</code>/<code>experimental</code> release, use
<pre>dch -i</pre>
This will increase just your local release number (remember to update your <code>VERSION_SUFFIX</code> var accordingly and the ABI name: see the next point).

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>.orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>.orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> versions not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download the latest version say from [https://snapshot.debian.org/package/linux-base/ Snapshot repo] and install the <code>.deb</code> file directly, for example currently version 4.17:
<pre>
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
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-06T13:31:27Z

Morgwai: Re-import from the forum: dch -i explanation fix

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> '''NONE OF THE ABOVE SUITES IS FORMALLY COVERED BY THE DEBIAN SECURITY TEAM''', so you should watch [https://tracker.debian.org/pkg/linux kernel security announcements] yourself.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files (<code>.dsc</code>, <code>.debian.tar.xz</code> and <code>.orig.tar.xz</code>) for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract and merge it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent local release of the same "base" <code>unstable</code>/<code>experimental</code> release, use
<pre>dch -i</pre>
This will increase just your local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>.orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>.orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> versions not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download the latest version say from [https://snapshot.debian.org/package/linux-base/ Snapshot repo] and install the <code>.deb</code> file directly, for example currently version 4.17:
<pre>
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
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-05T12:45:42Z

Morgwai: Re-import from the forum: add a security notice

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> '''NONE OF THE ABOVE SUITES IS FORMALLY COVERED BY THE DEBIAN SECURITY TEAM''', so you should watch [https://tracker.debian.org/pkg/linux kernel security announcements] yourself.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files (<code>.dsc</code>, <code>.debian.tar.xz</code> and <code>.orig.tar.xz</code>) for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract and merge it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>.orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>.orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> versions not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download the latest version say from [https://snapshot.debian.org/package/linux-base/ Snapshot repo] and install the <code>.deb</code> file directly, for example currently version 4.17:
<pre>
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
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-05T10:11:01Z

Morgwai: Re-import from the forum: new linux-base version

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files (<code>.dsc</code>, <code>.debian.tar.xz</code> and <code>.orig.tar.xz</code>) for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>.orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>.orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> versions not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download the latest version say from [https://snapshot.debian.org/package/linux-base/ Snapshot repo] and install the <code>.deb</code> file directly, for example currently version 4.17:
<pre>
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
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-02T18:08:24Z

Morgwai: Re-import from the forum: minor changelog entry command update for convenient copy-paste

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-09-01T05:26:12Z

Morgwai: Re-import from the forum: minor upstream reporting note and formatting updates

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-08-31T10:21:26Z

Morgwai: Re-import from the forum: improve some commands

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x linux*.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base/unstable</pre>
</li><li> ''OTHERWISE'' download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-08-31T10:16:02Z

Morgwai: Re-import from the forum: example coning command

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa]. Consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>, for example:
<pre>git clone --branch=debian/latest --depth=1 https://salsa.debian.org/kernel-team/linux</pre>
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x *.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point and repeat the above command.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base=4.16</pre>
</li><li> ''OTHERWISE'' download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-08-31T09:59:54Z

Morgwai: Re-import from the forum: minor wording and structure update

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''INSTRUCTIONS META'''

<ul><li> 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.
</li><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa] (consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>).
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x *.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>noudeb</code> and <code>nodoc</code> and if you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="noudeb nodoc pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base=4.16</pre>
</li><li> ''OTHERWISE'' download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-08-31T07:35:02Z

Morgwai: Re-import from the forum: minor grammar and editorial fixes

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''GENERAL META'''

<ul><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> 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.
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa] (consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>).
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
</li><li> ''OTHERWISE'' download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x *.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from Trixie's branch:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.1/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least
<pre>export DEB_BUILD_PROFILES="nodoc noudeb"</pre>
If you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="nodoc noudeb pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''EITHER'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base=4.16</pre>
</li><li> ''OTHERWISE'' download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-08-31T06:29:06Z

Morgwai: Re-import from the forum: minor grammar and editorial fixes

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''GENERAL META'''

<ul><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> 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.
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa] (consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>).
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, download and extract the source package using <code>apt source</code>, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
''...Otherwise:'' 
</li><li> Download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x *.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of the upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example in my case:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from 7.0.x:
<pre>git checkout debian/7.0/trixie-backports -- debian/watch</pre>
If you cloned the repo with <code>--depth</code>, then get it using <code>curl</code> or <code>wget</code> instead:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.0/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least
<pre>export DEB_BUILD_PROFILES="nodoc noudeb"</pre>
If you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="nodoc noudeb pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''Either'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base=4.16</pre>
''...Otherwise:''
</li><li> Download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable your secure-boot or sign the image manually, for example using <code>sbsign</code>.
</li></ol>

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

Main Page

2026-08-31T05:44:33Z

Morgwai: /* HowTo (guides) */ update kernel building title

= Welcome to the Debian Users Forum Cache. =

This wiki is dedicated specific member solutions from the [https://forums.debian.net Debian User Forums] and not to be confused with the larger man style documentation driven official [https://wiki.debian.org Debian Project Wiki].

Our works here are citable formats of some of our best threads, member contributions, guides, and information that can provide assistance on or offline.

== About ==
About:
* [[Debian Forums Cache:About|Debian Forums Cache]]
* [[Debian User Forums]]
* [[The Debian Project]]
* [[Forum jokes, lingo, and memorable quotes]]

== Guides (reference) ==

* [[Root, Sudo, and SU|Root, sudo, su, and su -]] (forum archive)
* [[Debian First Aid Kit]] (full paper)
* [[Fonts and Themes in Cinnamon Desktop]] (full paper)
* [[To install Firefox from Mozilla repo|Installing Firefox from the Mozilla repository]] (forum archive)
* [[Security Hardening for Debian Users: Protecting Against Targeted Attacks]] (full paper)

== HowTo (guides) ==
* [[MTR Network Diagnostics]] (full paper)
* [[WiFi Signal Strength and Sharing]] (forum archive)
* [[REFInd USB Drive (for emergency boot)]] (forum archive)
* [[Trixie iwd]] (forum archive)
* [[Debian Live USB with Persistence]] (full paper)
* [[HowTo build the latest mainline or rebuild Sid kernel packages for Trixie]]

== Licensing and Use ==
Licensing:
* [[Publish using CC International licencing and your Forum name]].
* [[Cache AI Use]]

HowTo build latest mainline kernel packages for Trixie

2026-08-31T05:42:58Z

Morgwai: Morgwai moved page HowTo build latest mainline kernel packages for Trixie to HowTo build the latest mainline or rebuild Sid kernel packages for Trixie: reflect expansion of scope in the title

#REDIRECT [[HowTo build the latest mainline or rebuild Sid kernel packages for Trixie]]

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

2026-08-31T05:42:58Z

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''GENERAL META'''

<ul><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> 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.
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa] (consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>).
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, you can download and extract using <code>apt source</code> instead, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
''...Otherwise:'' 
</li><li> Download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x *.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from 7.0.x:
<pre>git checkout debian/7.0/trixie-backports -- debian/watch</pre>
If you cloned the repo with <code>--depth</code>, then get it using <code>curl</code> or <code>wget</code> instead:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.0/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least
<pre>export DEB_BUILD_PROFILES="nodoc noudeb"</pre>
If you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="nodoc noudeb pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''Either'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base=4.16</pre>
''...Otherwise:''
</li><li> Download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable secure-boot or sign it manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-08-31T05:38:05Z

Morgwai: Re-import from the forum: include instructions for rebuilding

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook 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) 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 [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental 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:
<ul><li> Kernels from <code>trixie-backports</code> can be installed right-away in most cases, however currently the notable exception is if you use [https://wiki.debian.org/NvidiaGraphicsDrivers#trixie-550bpo Debian-packaged Nvidia drivers].
</li><li> In case of packages from <code>unstable</code> and <code>experimental</code> 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.
</li><li> Kernels from <code>experimental</code> suite may sometimes have integration issues with the rest of the OS, even if based on stable upstream releases.
</li><li> If you use any <code>firmware-*</code> packages, it is usually recommended to upgrade them to the versions from the same suite as the original kernel.
</li></ul>

'''GENERAL META'''

<ul><li> The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>export ARCH="$(dpkg --print-architecture)"</pre>
</li><li> 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.
</li><li> If you plan to publish your packages somewhere, you can export <code>DEBEMAIL</code> to contain your public email.
</li></ul>

'''(RE)-BUILDING PROCEDURE'''

<ol><li> Obtain the closest possible debianization:
<ul><li> '''In case of building the latest mainline:''' 
Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa] (consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>).
</li><li> '''In case of rebuilding from unstable/experimental:'''
<ul><li> ''IF'' you have the given suite configured, you can download and extract using <code>apt source</code> instead, for example:
<pre>apt source linux=7.2.2-1~exp1</pre>
''...Otherwise:'' 
</li><li> Download the source package files ("dsc", "debian.tar.xz" and "orig.tar.xz") for example from [https://snapshot.debian.org/package/linux/ Snapshot repository] and extract it with
<pre>dpkg-source -x *.dsc</pre>
</li></ul>
</li></ul>
Next, <code>cd</code> into the resulting <code>linux*/</code> folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Forky's / Sid's <code>gcc-15</code>/<code>gcc-16</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> 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. For example, I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix (together with the local release number) as <code>VERSION_SUFFIX</code>: it will be useful later.

<ul><li> '''In case of building the latest mainline:''' 
Create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with:
<ul><li>"future" Debian release (the number after a dash) set to <code>1</code>,
</li><li> "local pre-release" (the part after a tilde) set to your <code>VERSION_SUFFIX</code>,
</li><li> target suite set to <code>UNRELEASED</code>.
</li></ul>
So for example in case of upstream version <code>7.0~rc7</code>:
<pre>
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) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version string.

</li><li> '''In case of rebuilding from unstable/experimental:''' 
Use <code>dch --local</code> followed by your local release suffix '''without''' the local release number (<code>1</code> will be appended automatically), for example:
<pre>dch --local morgwai</pre>
If later you want to build a subsequent release of the same upstream version, use
<pre>dch -i</pre>
This will increase the local release number.

In both cases, <code>dch</code> will create a template entry in <code>debain/changelog</code> and open your <code>EDITOR</code> to fill just a description of changes: you can enter for example something like "''Packaging changes and rebuild for Trixie''".
<code>dch</code> may complain about missing <code>DEBEMAIL</code> var: in case of a local build, just ignore it.
</li></ul>

</li><li> ABI name management:
<ul><li> 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 <code>UNRELEASED</code> suite, which may cause conflicts with other kernel packages for the same major upstream version. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several releases of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
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
</pre>
Unfortunately, you need to update it each time you increase the local release number in your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) 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 <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with v7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from 7.0.x:
<pre>git checkout debian/7.0/trixie-backports -- debian/watch</pre>
If you cloned the repo with <code>--depth</code>, then get it using <code>curl</code> or <code>wget</code> instead:
<pre>wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.0/trixie-backports/debian/watch</pre>

</li><li> '''In case of building the latest mainline only:''' fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder with the below command:
<pre>uscan --download-current-version --vcs-export-uncompressed</pre>
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 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

</li><li> Run
<pre>debian/rules orig</pre>
In case of rebuilding, the above is necessary to regenerate <code>debian/control</code> 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 <code>orig.tar.xz</code>, "merge" it into the debianization, generate <code>debian/control</code> and apply all the patches from <code>debian/patches/</code> 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 <code>debian/patches/</code> and its mention from <code>debian/patches/series</code> file. Otherwise you need decide whether to rework such patch or, if it concerns features you don't use, just remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least
<pre>export DEB_BUILD_PROFILES="nodoc noudeb"</pre>
If you also want to skip "binary" packages with kernel sources, then add <code>pkg.linux.nosource</code>:
<pre>export DEB_BUILD_PROFILES="nodoc noudeb pkg.linux.nosource"</pre>
Note that applying some of the other profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''Either'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

''...OR'':
</li><li> build a source package first with
<pre>dpkg-source --build .</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code> complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point.
</li></ul>
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 <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).
</li></ol>

'''INSTALLING THE BUILT PACKAGES'''

<ol><li> Since the release <code>7.2-1~exp1</code>, built packages depend on <code>linux-base</code> version >= 4.16 that is not available in Trixie. This package contains scripts called by kernel's <code>postinst</code> / <code>prerm</code> 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:
<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
<pre>sudo apt install linux-base=4.16</pre>
''...Otherwise:''
</li><li> Download it and install from a <code>.deb</code> file:
<pre>
wget https://snapshot.debian.org/archive/debian/20260816T142939Z/pool/main/l/linux-base/linux-base_4.16_all.deb
sudo apt install ./linux-base_4.16_all.deb
</pre>
</li></ul>

</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
<pre>
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
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.

</li><li> '''Remember that the kernel is unsigned''', so you need to either disable secure-boot or sign it manually, for example using <code>sbsign</code>.
</li></ol>

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

2026-07-02T08:42:40Z

Morgwai: Re-import from the forum: tiny grammar improvement

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

2026-06-30T11:57:27Z

Morgwai: Re-import from the forum: note on applying and reworking patches

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

2026-06-29T11:07:40Z

Morgwai: Re-import from the forum: note on debian/control generation

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

2026-06-24T08:58:24Z

Morgwai: Re-import from forum after minor wording changes

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

2026-06-24T05:07:33Z

Morgwai: Re-import from forum after minor formatting changes

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

2026-06-24T03:13:08Z

Morgwai: Initial import

File:HowTo-build-latest-mainline-kernel-packages-for-Trixie v2.odt

2026-06-23T06:47:55Z

Morgwai:

Main Page

2026-06-23T06:23:16Z

Morgwai:

= Welcome to the Debian User Forum Cache. =

This wiki is dedicated specific member solutions from the [https://forums.debian.net Debian User Forums] and not to be confused with the larger man style documentation driven official [https://wiki.debian.org Debian Project Wiki].

Our works here are citable formats of some of our best threads, member contributions, guides, and information that can provide assistance on or offline.

== About ==
About:
* [[Debian Forums Cache:About|Debian Forums Cache]]
* [[Debian User Forums]]
* [[The Debian Project]]
* [[Forum jokes, lingo, and memorable quotes]]

== Guides (reference) ==

* [[Root, Sudo, and SU|Root, sudo, su, and su -]] (forum archive)
* [[Debian First Aid Kit]] (full paper)
* [[Fonts and Themes in Cinnamon Desktop]] (full paper)
* [[To install Firefox from Mozilla repo|Installing Firefox from the Mozilla repository]] (forum archive)
* [[Security Hardening for Debian Users: Protecting Against Targeted Attacks]] (full paper)

== HowTo (guides) ==
* [[MTR Network Diagnostics]] (full paper)
* [[WiFi Signal Strength and Sharing]] (forum archive)
* [[REFInd USB Drive (for emergency boot)]] (forum archive)
* [[Trixie iwd]] (forum archive)
* [[Debian Live USB with Persistence]] (full paper)
* [[HowTo build latest mainline kernel packages for Trixie]]

== Licensing and Use ==
Licensing:
* [[Publish using CC International licencing and your Forum name]].
* [[Cache AI Use]]