- Prepatch (RC) kernels: these "release candidate" kernels are pre-releases of the mainline kernel that are intended for developers and Linux enthusiasts.  They contain new features and must be tested before they are put into a stable release.
- Mainline: the mainline tree is where all new features are introduced and where new development occurs. Every 2-3 months, a new mainline kernel is released.
- Stable: After a mainline kernel is released, it is classified as stable. Bug fixes for the stable kernel are backported from the mainline tree. On approximately a weekly basis, stable kernel updates are released. Normally only a few bug fix kernel releases are available before the next mainline kernel is released.
- Long-term (LTS): At any time there are usually several "long-term maintenance" kernel releases available. Bug fixes are backported for older kernels, but these are focused on the most important issues and releases are not very frequent (particularly for older trees).
- Distribution kernels: A number of Linux distributions provide long-term maintenance kernels, which are sometimes not based on those maintained by kernel developers. This is the case for Debian upon which Kicksecure ™ is based. 
Interested readers can refer to The Linux Kernel Archives to see the prepatch, mainline, stable and long-term kernels that are currently available.
For the vast majority of Kicksecure ™ users, there is simply no reason to change from the distribution kernel that is in use.
The general expert consensus is that while LTS kernels have less hardening features and not all bug fixes are backported, they have less attack surface and potentially less chance of having new bugs. In comparison, stable kernels have more hardening features and all known bug fixes to date, but a higher attack surface and a greater potential for new bugs.  The grsecurity development team has also noted that the majority of Linux kernel vulnerabilities are those that have most recently been introduced (released) in newer versions.  
The developer who is responsible for stable Linux kernel releases (Greg Kroah-Hartman), has also confirmed this viewpoint. His recommendation of what kernel should be used (ranked from best to worst) is as follows:  
- Supported kernel from your favorite Linux distribution.
- Latest stable release.
- Latest LTS release.
- Older LTS release that is still being maintained.
In Debian's case, it is noted that the distribution kernel is not based on the latest stable upstream kernel release, but they still ensure that any necessary bug fixes are applied on a regular basis.
Kicksecure ™ developers have also noted there is a risk of instability and breakage when utilizing kernels from Debian backports.  For instance, this had previously resulted in Qubes breakage  and caused mismatches in the kernel image versus kernel headers.
One possible exception to the recommendation in this section concerns Kicksecure-Qubes users, since the
dom0 kernel applies to all qubes by default. To benefit from a number of recent security developments (such as Linux Kernel Runtime Guard (LKRG)), the use of in-VM kernels is a prerequisite.
Sometimes updated kernel versions can cause issues. This has only been an issue for major kernel upgrades such as when performing instructions below. This has never been an issue when performing standard ("everyday") updates.
- host freeze
segmentation faults in many applications
SIGSEGVerrors in all chromium based browsers
- broken sdwdate
- broken swap-file-creator
- broken update and upgrades with bizarre unusual otherwise never seen errors such as
Hash Sum Mismatch
- Tor Browser was reported to have crashed inside VirtualBox with
Segmentation fault (core dumped).
- msgcollector issue was reported
error_text: ‘exit_code: 0 | text: Failed to set up inotifywait! inotifywait_folder: /run/msgcollector | wait_exit_code: 141’
Installation of Newer Kernels
Kicksecure ™: No preparation is required.
Kicksecure ™ for Qubes
Kicksecure ™ for Qubes: A Qubes VM kernel is required.
- Follow the Qubes OS Installing kernel in Debian VM instructions.
- Ensure the Qubes VM kernel is functional before proceeding -- Qubes VM kernel issues should be raised at Qubes support and not in Kicksecure ™ forums.  
- Reboot dom0 with Qubes VM kernel. This is because Qubes VM kernel might break unrelated things such as the USB VM. 
- Once the Qubes VM kernel is functional, proceed with the following instructions.
linux-image-$(dpkg --print-architecture) linux-headers-$(dpkg --print-architecture) can be installed from Debian backports. This is non-ideal, see footnote. 
1. Boot Kicksecure ™ (
2. Add the current Debian stable backports codename
bullseye-backports to Debian apt sources.
Note: this applies to Kicksecure ™ 18.104.22.168. Later Kicksecure ™ versions may use a codename different to
In Kicksecure ™ (
kicksecure-16) Template, run.
Alternatively, users who like Onionizing Repositories can set the .onion mirror.
3. Update the package lists.
4. Install the select software.
The procedure is now complete.
On occasion it is necessary to undo this configuration, for example when upgrading from Debian
bookworm.  To proceed, run.
These steps can be repeated for any other host operating system installations or other VMs.
- These must be compiled from source.
- To tell if you are running a distribution kernel, in a terminal run:
uname -r. If anything appears after the dash, then a distribution kernel is in use. At the time of writing, Debian is utilizing the following distribution kernel:
- See also: Debian wiki Kernel FAQ.
- He also notes that an unmaintained kernel release should never be used.
- See: https://github.com/QubesOS/qubes-issues/issues/4443
- Qubes feature request: Simplify and promote using in-vm kernel
- As experienced firsthand by Kicksecure ™ developer Patrick Schleizer.
- Past Debian issue: linux-image-amd64 vs linux-headers-amd64 Debian buster-backports version mismatch bpo.2 vs bpo.3
- Users should Prefer Packages from Debian Stable Repository, but using backports is better than manual software installation or using third party package managers since this prefers APT. To contain the risk,
- Most often this step applies before attempting major Kicksecure ™ upgrades; upgrade instructions are also made available at that time (see Stay Tuned).