Debian Forums Cache - Recent changes [en]

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

Morgwai — Thu, 22 Oct 2026 13:56:25 GMT

Re-import from the forum: minor wording update

← Older revision		Revision as of 13:56, 22 October 2026
(3 intermediate revisions by the same user not shown)
Line 6:		Line 6:
	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.		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:		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].		<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> 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.
Line 139:		Line 139:
	'''INSTALLING THE BUILT PACKAGES'''		'''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:~~		<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:
	~~<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply~~		<pre>sudo apt install -t trixie-backports linux-base</pre>
	~~<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:		</li><li> Install the packages built in the parent folder (in case of using <code>dpkg-buildpackage</code>), usually at least the below:
Line 171:		Line 164:
	At this point your system should be ready to reboot to the new kernel.		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].		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].

Chroot utility

Morgwai — Sun, 04 Oct 2026 20:40:59 GMT

formatting

← Older revision		Revision as of 20:40, 4 October 2026
(One intermediate revision by the same user not shown)
Line 4:		Line 4:

	= Common use-cases =		= 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>		<ul>
Line 12:		Line 10:
	<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>		<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>		</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].


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


Line 18:		Line 20:

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


	== Create or provide a file hierarchy of a Linux system ==		== Create or provide a file hierarchy of a Linux system ==
Line 30:		Line 31:
	trixie "${chrootFolder}" http://deb.debian.org/debian</pre></li>		trixie "${chrootFolder}" http://deb.debian.org/debian</pre></li>
	</ul>		</ul>


	== Mount virtual filesystems ==		== Mount virtual filesystems ==
Line 41:		Line 41:
	</pre>		</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.		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 ==		== Copy the DNS resolver config ==
Line 48:		Line 47:
	cp /etc/resolv.conf "${chrootFolder}/etc/"		cp /etc/resolv.conf "${chrootFolder}/etc/"
	</pre>		</pre>


	== Perform a chroot switch ==		== Perform a chroot switch ==
Line 61:		Line 59:
	</pre>		</pre>
	<code>/root/myScriptToBeExecutedInChroot.sh</code> is a path inside the <code>chroot</code>-ed hierarchy.		<code>/root/myScriptToBeExecutedInChroot.sh</code> is a path inside the <code>chroot</code>-ed hierarchy.


	== Cleanup ==		== Cleanup ==
Line 74:		Line 71:
	</pre>		</pre>


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


	= Additional notes and scenarios =		= Additional notes and scenarios =


	== Running X11 GUI apps ==		== 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 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 ==		== 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.		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 ==		== 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.		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 ==		== Modifying boot data ==

Chroot utility

Morgwai — Sun, 04 Oct 2026 20:14:10 GMT

copy my last version from debian wiki

New page

'''[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

Morgwai — Sun, 04 Oct 2026 19:28:57 GMT

add link to chroot page

← Older revision		Revision as of 19:28, 4 October 2026
Line 20:		Line 20:
	* [[To install Firefox from Mozilla repo\|Installing Firefox from the Mozilla repository]] <small>(forum archive)</small>		* [[To install Firefox from Mozilla repo\|Installing Firefox from the Mozilla repository]] <small>(forum archive)</small>
	* [[Security Hardening for Debian Users: Protecting Against Targeted Attacks]] <small>(full paper)</small>		* [[Security Hardening for Debian Users: Protecting Against Targeted Attacks]] <small>(full paper)</small>
			* [[chroot utility]]

	== HowTo (guides) ==		== HowTo (guides) ==

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

Morgwai — Tue, 29 Sep 2026 09:43:35 GMT

Re-import from the forum: minor version and formatting updates

← Older revision		Revision as of 09:43, 29 September 2026
Line 6:		Line 6:
	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.		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:		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].		<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> 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.
Line 22:		Line 22:
	'''INSTRUCTIONS META'''		'''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.		<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		</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>		<pre>export ARCH="$(dpkg --print-architecture)"</pre>
Line 58:		Line 58:
	</li><li> target suite set to <code>UNRELEASED</code>.		</li><li> target suite set to <code>UNRELEASED</code>.
	</li></ul>		</li></ul>
	So for example in case of the upstream version ~~<code>~~7.0~rc7~~</code>~~:		So for example in case of the upstream version 7.0~rc7:
	<pre>		<pre>
	export UPSTREAM_VERSION="7.0~rc7"		export UPSTREAM_VERSION="7.0~rc7"
Line 66:		Line 66:
	* New upstream release candidate.		* New upstream release candidate.
	* Packaging changes for Trixie.		* 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)		-- $(getent passwd ${USER} \|cut -d : -f 5 \|cut -d , -f 1) <${DEBEMAIL:-${USER}@$(hostname)}> $(date -R)
Line 72:		Line 73:
	mv changelog-new debian/changelog		mv changelog-new debian/changelog
	</pre>		</pre>
	Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version ~~string~~.		Mind dashes (<code>-</code>) vs tildes (<code>~</code>) in the version strings.

	</li><li> '''In case of rebuilding from unstable/experimental:'''<br>		</li><li> '''In case of rebuilding from unstable/experimental:'''<br>
Line 138:		Line 139:
	'''INSTALLING THE BUILT PACKAGES'''		'''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:		<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		<ul><li> ''IF'' you have <code>unstable</code> suite configured, then simply
	<pre>sudo apt install linux-base/unstable</pre>		<pre>sudo apt install linux-base/unstable</pre>