Debian Forums Cache - User contributions [en]

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

2026-10-22T13:56:25Z

Morgwai: Re-import from the forum: minor wording 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 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 Sid or experimental packages just a few days after a tag is created in kernel.org's stable repo and propagates them to <code>trixie-backports</code> on a semi-regular basis. 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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''INSTRUCTIONS META'''

<ul><li> The examples below are based mostly on 7.0~rcX versions, the instructions were also tested on 7.3~rcX 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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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 7.0~rc7:
<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.
* Disable unused flavors and feature-sets.

-- $(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 strings.

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

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should [https://www.kernel.org/category/signatures.html verify it manually] using the detached signature available on kernel.org at the corresponding <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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> Starting with 7.2, built packages depend on <code>linux-base</code> versions from <code>trixie-backports</code>, so [https://backports.debian.org/Instructions/ add it to your apt sources] if you haven't done so before and then install the newer version:
<pre>sudo apt install -t trixie-backports linux-base</pre>

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

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using some [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-10-17T23:01:20Z

Morgwai: improve the note on Sid/experimental vs backports packages

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 Sid or experimental packages just a few days after a tag is created in kernel.org's stable repo and propagates them to <code>trixie-backports</code> on a semi-regular basis. 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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''INSTRUCTIONS META'''

<ul><li> The examples below are based mostly on 7.0~rcX versions, the instructions were also tested on 7.3~rcX 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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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 7.0~rc7:
<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.
* Disable unused flavors and feature-sets.

-- $(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 strings.

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

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should [https://www.kernel.org/category/signatures.html verify it manually] using the detached signature available on kernel.org at the corresponding <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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> Starting with 7.2, built packages pre-depend (!) on <code>linux-base</code> versions from <code>trixie-backports</code>, so [https://backports.debian.org/Instructions/ add it to your apt sources] if you haven't done so before and then install the newer version:
<pre>sudo apt install -t trixie-backports linux-base</pre>

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

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using some [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-10-12T18:00:44Z

Morgwai:

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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''INSTRUCTIONS META'''

<ul><li> The examples below are based mostly on 7.0~rcX versions, the instructions were also tested on 7.3~rcX 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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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 7.0~rc7:
<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.
* Disable unused flavors and feature-sets.

-- $(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 strings.

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

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should [https://www.kernel.org/category/signatures.html verify it manually] using the detached signature available on kernel.org at the corresponding <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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> Starting with 7.2, built packages pre-depend (!) on <code>linux-base</code> versions from <code>trixie-backports</code>, so [https://backports.debian.org/Instructions/ add it to your apt sources] if you haven't done so before and then install the newer version:
<pre>sudo apt install -t trixie-backports linux-base</pre>

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

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using some [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-10-08T21:10:04Z

Morgwai: Re-import from the forum: use linux-base from trxie-backports

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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''INSTRUCTIONS META'''

<ul><li> The examples below are based mostly on 7.0~rcX versions, the instructions were also tested on 7.3~rcX 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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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 7.0~rc7:
<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.
* Disable unused flavors and feature-sets.

-- $(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 strings.

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

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should [https://www.kernel.org/category/signatures.html verify it manually] using the detached signature available on kernel.org at the corresponding <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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> Starting with 7.2, built packages pre-depend (!) on <code>linux-base</code> versions from <code>trixie-backports</code>, so [https://backports.debian.org/Instructions/ add it to your apt sources] if you haven't done so before and then install the newer version:
<pre>sudo apt install -t trixie-backports linux-base</pre>

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

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

Chroot utility

2026-10-04T20:40:59Z

Morgwai: formatting

'''[https://manpages.debian.org/man/chroot chroot] is an utility that changes which folder is considered the root of the filesystem hierarchy by its child processes, so that it is impossible for them to access the parent folder of the new root, even though it physically exists on the disk.'''

= Common use-cases =

<ul>
<li>Fast switching to another environment (distro, version, flavor, package mix etc) for the purposes of testing, building, debugging etc.</li>
<li>Repairing a broken Linux installation by connecting its primary drive as an external device (for example using an USB enclosure) to some other working system and performing operations from within the system being repaired.</li>
<li>Historically <code>chroot</code> was also used to increase the security of network services running on a given machine: if an attacker managed to trick a service to an [https://en.wikipedia.org/wiki/Arbitrary_code_execution arbitrary code execution], he would still not have access to the whole filesystem of the machine (he would remain in a so called ''chroot jail''). This however does not prevent the attacker from using the machine's network interfaces to further penetrate the internal network, moreover on Linux and some other UNIXes, escaping a "chroot jail" is relatively easy. As a result, for security-related purposes <code>chroot</code> was replaced by virtual machines and containers.</li>
</ul>
'''Note: <code>chroot</code> utility is intended mostly for an occasional, ad-hoc usage.''' If you regularly need to switch to different environments, then consider more robust systems that automate setting up and offer greater flexibility, such as [https://wiki.debian.org/Schroot schroot] or [https://wiki.debian.org/Podman Podman].

------
------

= Basic setup and usage =

''Unless explicitly stated otherwise, all commands in the below subsections require `root` privileges.''

== Create or provide a file hierarchy of a Linux system ==

In the subsequent sections, '''<code>${chrootFolder}</code>''' will refer to the root folder of a file hierarchy created or provided as described below.

<ul>
<li>In case of switching to existing installations, it boils down to mounting their root filesystem at a target folder of your choice.</li>
<li>In case you want to create a fresh Debian image, you can use utilities such as <code>mmdebstrap</code>, for example to create a clean environment to build deb packages: <pre>
mmdebstrap --skip=output/dev,output/mknod --variant=buildd \
trixie "${chrootFolder}" http://deb.debian.org/debian</pre></li>
</ul>

== Mount virtual filesystems ==

As of 2026 these are <code>proc</code>, <code>sysfs</code>, <code>udev</code> and "children" of the latter 2 of which there are too many and which also tend to die off or spawn way too often. Fortunately, <code>mount</code> has <code>--rbind</code> option that allows to bind an already mounted filesystem together with all its children to an additional target folder. Of course [https://wiki.debian.org/systemd#Known_Issues_and_Workarounds systemd decided to break some basic functionality], so you additionally need to use either <code>--make-rslave</code> or <code>--make-rprivate</code> flag to enforce the proper behavior (see [https://manpages.debian.org/man/mount_namespaces man mount_namespaces] for details).
<pre>
mount -t proc proc "${chrootFolder}/proc"
mount --rbind --make-rslave /sys "${chrootFolder}/sys"
mount --rbind --make-rslave /dev "${chrootFolder}/dev"
</pre>
In case you are wondering: <code>proc</code> has 1 child also: <code>binfmt_misc</code>, which is used for registering binary executable handlers/interpreters, which does not make sense in a <code>chroot</code> (the absolute path of a given interpreter needs to be provided, which is inaccessible from a <code>chroot</code>-ed context), therefore no point in binding it.

== Copy the DNS resolver config ==

<pre>
cp /etc/resolv.conf "${chrootFolder}/etc/"
</pre>

== Perform a chroot switch ==

This usually boils down to <pre>
chroot "${chrootFolder}"
</pre>
...which will start an interactive login shell of <code>root</code> user inside the <code>chroot</code>-ed environment, so that you can interactively perform whatever tasks you need.

For non-interactive tasks, you can instead provide an alternative command and its args: <pre>
chroot "${chrootFolder}" /root/myScriptToBeExecutedInChroot.sh myArg1 myArg2
</pre>
<code>/root/myScriptToBeExecutedInChroot.sh</code> is a path inside the <code>chroot</code>-ed hierarchy.

== Cleanup ==

After the <code>chroot</code> process exits, you need to unbind / <code>umount</code> all the virtual filesystems bound / mounted previously. Fortunately <code>umount</code> also has <code>--recursive</code> / <code>-R</code> flag to help with this: <pre>
umount -R "${chrootFolder}/dev"
umount -R "${chrootFolder}/sys"
umount -R "${chrootFolder}/proc"
</pre>
If <code>${chrootFolder}</code> is a mount point of an external drive and you want to <code>umount</code> it also, you can replace all the above commands with the below single one: <pre>
umount -R "${chrootFolder}"
</pre>

------
------

= Additional notes and scenarios =

== Running X11 GUI apps ==

Running X11 GUI apps from within a <code>chroot</code>-ed environment and displaying them on host's X11 server works using standard mechanisms: just export the value of <code>DISPLAY</code> env var from the host in the <code>chroot</code> and make sure the host X server will allow connections (for example using <code>xhost</code> utility).

== Running Systemd services ==

Systemd services will generally refuse to run in a <code>chroot</code>-ed environment. Use [https://wiki.debian.org/nspawn systemd-nspawn] instead of <code>chroot</code> if you need to run Systemd services.

== Foreign architectures ==

If <code>qemu-user-binfmt</code> is installed, it is possible to <code>chroot</code> to a filesystem for any foreign arch it supports.

== Modifying boot data ==

If you want to modify the boot data of another system whose drive you <code>chroot</code>-ed into (this includes for example running <code>update-grub</code>, <code>update-initramfs</code>, installing a new kernel or firmware + kernel modules for boot-critical devices etc), you need to mount its <code>/boot</code> hierarchy. This may include the following:<ul>
<li><code>/boot</code> itself is sometimes a separate partition, most commonly on systems using some disk encryption scheme.</li>
<li>On UEFI systems (which includes most of modern x86 and ARM hardware), their ESP partitions are mounted at <code>/boot/efi</code>.</li>
</ul>

It is usually most convenient to mount these filesystems right after performing a <code>chroot</code> switch.

After performing a <code>chroot</code> switch, check which filesystem are present by running <code>grep /boot /etc/fstab</code>. Below is an example output from a system with both <code>/boot</code> and <code>/boot/efi</code> entries: <pre>
UUID=7a307683-255a-4bac-937f-95aa2af2ca17 /boot ext4 defaults 0 2
UUID=4D18-6163 /boot/efi vfat umask=0077 0 1
</pre>
If <code>/etc/fstab</code> entries use UUIDs as in the example above (which is the default on most modern distros) or unique <code>PARTLABEL</code>s or <code>LABEL</code>s, then all you need to do is to point <code>mount</code> to their corresponding mount-points: <pre>
mount /boot
mount /boot/efi
</pre>
On some older systems, instead of UUIDs or labels, device nodes may be used in <code>/etc/fstab</code>, like for example <code>/dev/sdaX</code> etc. In such case you need to figure out what device node currently corresponds to a given filesystem. Most commonly, it will be another partition on the same physical drive as the root filesystem of that external system.

After you are done with your <code>chroot</code> work, these filesystems may be <code>umount</code>-ed either from within the <code>chroot</code> or after exiting.

Chroot utility

2026-10-04T20:39:13Z

Morgwai: formatting

Chroot utility

2026-10-04T20:14:10Z

Morgwai: copy my last version from debian wiki

'''[https://manpages.debian.org/man/chroot chroot] is an utility that changes which folder is considered the root of the filesystem hierarchy by its child processes, so that it is impossible for them to access the parent folder of the new root, even though it physically exists on the disk.'''

= Common use-cases =

'''Note: <code>chroot</code> utility is intended mostly for an occasional, ad-hoc usage.''' If you regularly need to switch to different environments, then consider more robust systems that automate setting up and offer greater flexibility, such as [https://wiki.debian.org/Schroot schroot] or [https://wiki.debian.org/Podman Podman].

<ul>
<li>Fast switching to another environment (distro, version, flavor, package mix etc) for the purposes of testing, building, debugging etc.</li>
<li>Repairing a broken Linux installation by connecting its primary drive as an external device (for example using an USB enclosure) to some other working system and performing operations from within the system being repaired.</li>
<li>Historically <code>chroot</code> was also used to increase the security of network services running on a given machine: if an attacker managed to trick a service to an [https://en.wikipedia.org/wiki/Arbitrary_code_execution arbitrary code execution], he would still not have access to the whole filesystem of the machine (he would remain in a so called ''chroot jail''). This however does not prevent the attacker from using the machine's network interfaces to further penetrate the internal network, moreover on Linux and some other UNIXes, escaping a "chroot jail" is relatively easy. As a result, for security-related purposes <code>chroot</code> was replaced by virtual machines and containers.</li>
</ul>

= Basic setup and usage =

''Unless explicitly stated otherwise, all commands in the below subsections require `root` privileges.''

== Create or provide a file hierarchy of a Linux system ==

In the subsequent sections, '''<code>${chrootFolder}</code>''' will refer to the root folder of a file hierarchy created or provided as described below.

<ul>
<li>In case of switching to existing installations, it boils down to mounting their root filesystem at a target folder of your choice.</li>
<li>In case you want to create a fresh Debian image, you can use utilities such as <code>mmdebstrap</code>, for example to create a clean environment to build deb packages: <pre>
mmdebstrap --skip=output/dev,output/mknod --variant=buildd \
trixie "${chrootFolder}" http://deb.debian.org/debian</pre></li>
</ul>

== Mount virtual filesystems ==

As of 2026 these are <code>proc</code>, <code>sysfs</code>, <code>udev</code> and "children" of the latter 2 of which there are too many and which also tend to die off or spawn way too often. Fortunately, <code>mount</code> has <code>--rbind</code> option that allows to bind an already mounted filesystem together with all its children to an additional target folder. Of course [https://wiki.debian.org/systemd#Known_Issues_and_Workarounds systemd decided to break some basic functionality], so you additionally need to use either <code>--make-rslave</code> or <code>--make-rprivate</code> flag to enforce the proper behavior (see [https://manpages.debian.org/man/mount_namespaces man mount_namespaces] for details).
<pre>
mount -t proc proc "${chrootFolder}/proc"
mount --rbind --make-rslave /sys "${chrootFolder}/sys"
mount --rbind --make-rslave /dev "${chrootFolder}/dev"
</pre>
In case you are wondering: <code>proc</code> has 1 child also: <code>binfmt_misc</code>, which is used for registering binary executable handlers/interpreters, which does not make sense in a <code>chroot</code> (the absolute path of a given interpreter needs to be provided, which is inaccessible from a <code>chroot</code>-ed context), therefore no point in binding it.

== Copy the DNS resolver config ==

<pre>
cp /etc/resolv.conf "${chrootFolder}/etc/"
</pre>

== Perform a chroot switch ==

This usually boils down to <pre>
chroot "${chrootFolder}"
</pre>
...which will start an interactive login shell of <code>root</code> user inside the <code>chroot</code>-ed environment, so that you can interactively perform whatever tasks you need.

For non-interactive tasks, you can instead provide an alternative command and its args: <pre>
chroot "${chrootFolder}" /root/myScriptToBeExecutedInChroot.sh myArg1 myArg2
</pre>
<code>/root/myScriptToBeExecutedInChroot.sh</code> is a path inside the <code>chroot</code>-ed hierarchy.

== Cleanup ==

After the <code>chroot</code> process exits, you need to unbind / <code>umount</code> all the virtual filesystems bound / mounted previously. Fortunately <code>umount</code> also has <code>--recursive</code> / <code>-R</code> flag to help with this: <pre>
umount -R "${chrootFolder}/dev"
umount -R "${chrootFolder}/sys"
umount -R "${chrootFolder}/proc"
</pre>
If <code>${chrootFolder}</code> is a mount point of an external drive and you want to <code>umount</code> it also, you can replace all the above commands with the below single one: <pre>
umount -R "${chrootFolder}"
</pre>

= Additional notes and scenarios =

== Running X11 GUI apps ==

Running X11 GUI apps from within a <code>chroot</code>-ed environment and displaying them on host's X11 server works using standard mechanisms: just export the value of <code>DISPLAY</code> env var from the host in the <code>chroot</code> and make sure the host X server will allow connections (for example using <code>xhost</code> utility).

== Running Systemd services ==

Systemd services will generally refuse to run in a <code>chroot</code>-ed environment. Use [https://wiki.debian.org/nspawn systemd-nspawn] instead of <code>chroot</code> if you need to run Systemd services.

== Foreign architectures ==

If <code>qemu-user-binfmt</code> is installed, it is possible to <code>chroot</code> to a filesystem for any foreign arch it supports.

== Modifying boot data ==

If you want to modify the boot data of another system whose drive you <code>chroot</code>-ed into (this includes for example running <code>update-grub</code>, <code>update-initramfs</code>, installing a new kernel or firmware + kernel modules for boot-critical devices etc), you need to mount its <code>/boot</code> hierarchy. This may include the following:<ul>
<li><code>/boot</code> itself is sometimes a separate partition, most commonly on systems using some disk encryption scheme.</li>
<li>On UEFI systems (which includes most of modern x86 and ARM hardware), their ESP partitions are mounted at <code>/boot/efi</code>.</li>
</ul>

It is usually most convenient to mount these filesystems right after performing a <code>chroot</code> switch.

After performing a <code>chroot</code> switch, check which filesystem are present by running <code>grep /boot /etc/fstab</code>. Below is an example output from a system with both <code>/boot</code> and <code>/boot/efi</code> entries: <pre>
UUID=7a307683-255a-4bac-937f-95aa2af2ca17 /boot ext4 defaults 0 2
UUID=4D18-6163 /boot/efi vfat umask=0077 0 1
</pre>
If <code>/etc/fstab</code> entries use UUIDs as in the example above (which is the default on most modern distros) or unique <code>PARTLABEL</code>s or <code>LABEL</code>s, then all you need to do is to point <code>mount</code> to their corresponding mount-points: <pre>
mount /boot
mount /boot/efi
</pre>
On some older systems, instead of UUIDs or labels, device nodes may be used in <code>/etc/fstab</code>, like for example <code>/dev/sdaX</code> etc. In such case you need to figure out what device node currently corresponds to a given filesystem. Most commonly, it will be another partition on the same physical drive as the root filesystem of that external system.

After you are done with your <code>chroot</code> work, these filesystems may be <code>umount</code>-ed either from within the <code>chroot</code> or after exiting.

Main Page

2026-10-04T19:28:57Z

Morgwai: add link to chroot page

= 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)
* [[chroot utility]]

== 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 the latest mainline or rebuild Sid kernel packages for Trixie

2026-09-29T09:43:35Z

Morgwai: Re-import from the forum: minor version 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> '''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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''INSTRUCTIONS META'''

<ul><li> The examples below are based mostly on 7.0~rcX versions, the instructions were also tested on 7.3~rcX 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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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 7.0~rc7:
<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.
* Disable unused flavors and feature-sets.

-- $(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 strings.

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

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should [https://www.kernel.org/category/signatures.html verify it manually] using the detached signature available on kernel.org at the corresponding <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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 7.2-1~exp1, 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.

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-09-18T02:08:10Z

Morgwai: Re-import from the forum: link to kernel.org verification procedure

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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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>.

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should [https://www.kernel.org/category/signatures.html verify it manually] using the detached signature available on kernel.org at the corresponding <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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.

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-09-16T15:46:05Z

Morgwai: Re-import from the forum: add a warning regarding kernel.org prepackaged tarballs

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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is also a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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>.

'''NOTE:''' while it is technically possible to instead download a prepackaged tarball from kernel.org, using the above command is preferred as it automatically verifies signatures found in the git repo, decreasing the risk of supply-chain attacks. If you decide to download a prepackaged tarball, you should verify it manually using the corresponding detached signature available on kernel.org under <code>[pgp]</code> link. Bear in mind also that the contents of a prepackaged tarball will be slightly different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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.

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-09-13T16:09:38Z

Morgwai: Re-import from the forum: link to the original

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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example of a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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>.

Alternatively, you can instead download a prepackaged tarball from kernel.org, but bear in mind that its contents will be somewhat different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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.

This article was imported from [https://forums.debian.net/viewtopic.php?p=841583#p841583 the forum] using [https://forums.debian.net/viewtopic.php?p=845208#p845208 lazy sed magic].

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

2026-09-13T15:31:11Z

Morgwai: Re-import from the forum: some more disclaimers in the intro

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>

Last but not least, if it ain't broken, don't mess with it, especially in case of your main computer or production systems: the default kernel provided by Trixie works very well in most configurations and receives timely upgrades from the Security Team. You shouldn't change it unless you have a very clear reason (support for a very recent hardware is the most common example for a good reason: this is usually covered by kernels from <code>trixie-backports</code>).

Having mentioned the above disclaimers, building and replacing a kernel is a very good exercise for users interested in learning the internals of a Debian OS. However like all exercises, it should be performed in a controlled, isolated environment: a [https://wiki.debian.org/libvirt virtual machine] or a spare computer behind a firewall or completely disconnected from the internet.

'''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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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>.

Alternatively, you can instead download a prepackaged tarball from kernel.org, but bear in mind that its contents will be somewhat different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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-11T17:44:31Z

Morgwai: Re-import from the forum: note on using the kernel Salsa for rebuilding Sid/experimental

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>
Note: it is generally possible to instead also checkout from the kernel Salsa the tag corresponding to the desired <code>unstable</code>/<code>experimental</code> release and then proceed almost identically as for building the latest mainline, but it's way less convenient.
</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>.

Alternatively, you can instead download a prepackaged tarball from kernel.org, but bear in mind that its contents will be somewhat different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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-11T14:38:54Z

Morgwai: Re-import from the forum: note on kernel.org source tarballs, better space estimates

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

Alternatively, you can instead download a prepackaged tarball from kernel.org, but bear in mind that its contents will be somewhat different than what the above command would produce as it skips a few files not meeting Debian's free software guidelines (DFSG, mainly some Nvidia related stuff).

</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 50GB of temporary space and produces a bit less than 4GB 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-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]]