1. Introduction
Although less often than software, hardware changes very rapidly in the world of information technology. New devices and updated versions of existing ones get developed with a high frequency. However, as the core of an operating system (OS), it’s the role of the kernel to support any major changes and enable the use of hardware. This creates a dynamic of catching up, which may translate into the need for constant core updates.
In this tutorial, we’ll explore a specific way for Debian-based Linux distributions like Ubuntu to expand kernel hardware support without reducing stability. First, we consider the hardware support structures of two major distributions. After that, we go through different packages that comprise the kernel of a Debian-based system. Next, we delve into specific features for using newer kernel versions. Finally, we understand how to apply the main feature in practice.
We tested the code in this tutorial on Debian 12 (Bookworm) and Ubuntu 22 (Jammy Jellyfish) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.
2. Kernel Hardware Support
As mentioned, the Linux kernel provides support for basic hardware communication. While drivers and kernel modules can increase the number of devices we can handle, built-in code is usually better, more stable, and faster.
Because of this, there are kernel updates that roll out on a given schedule, depending on the release:
- interim kernel: updates, for example, every 6 months
- LTS (Long-Term Support) kernel: update period depends on the distribution version
For example, Ubuntu versions have a set scale for major LTS updates:
+----------------------------------------------------------------------------------------+
22.04 LTS | | | | | #######|########|########|########|########|# |
Jammy Jellyfish | | | | | SSSSSSS|SSSSSSSS|SSSSEEEE|EEEEEEEE|EEEEEEEE|E |
20.04 LTS | | | | #######|########|########|########|########|# | |
Focal Fossa | | | | SSSSSSS|SSSSSSSS|SSSSEEEE|EEEEEEEE|EEEEEEEE|E | |
18.04 LTS | | | #######|########|########|########|########|# | | |
Bionic Beaver | | | SSSSSSS|SSSSSSSS|SSSSEEEE|EEEEEEEE|EEEEEEEE|E | | |
16.04 LTS | | #######|########|########|########|########|# | | | |
Xenial Xerus | | SSSSSSS|SSSSSSSS|SSSSEEEE|EEEEEEEE|EEEEEEEE|E | | | |
14.04 LTS |SSSSSSSS|SSSSSSSS|SSSSEEEE|EEEEEEEE|EEEEEEEE|E | | | | |
Trusty Tahr +--------+--------+--------+--------+--------+--------+--------+--------+--------+-------+
2014 2016 2018 2020 2022 2024 2026 2028 2030 2032
S > LTS [S]tandard security maintenance, Ubuntu Main (5 years)
E > LTS [E]xpanded security maintenance, Ubuntu Main (5 years)
# > LTS E[#]panded security maintenance, Ubuntu Universe (10 years)
Debian has a similar LTS support schedule structure for major releases:
+----------------------------------------------------------------------------------------+
12 Bookworm | | | | | SSSSSSS|SSSSSSEE|EEEEEE##|########|########|## |
11 Bullseye | | | | SSSSSSS|SSSSSSEE|EEEEEE##|########|########|## | |
10 Buster | | | SSSSSSS|SSSSSSEE|EEEEEE##|########|########|## | | |
9 Stretch | | SSSSSSS|SSSSSSEE|EEEEEE##|########|########|## | | | |
8 Jessie | SSSSSSS|SSSSSSEE|EEEEEE##|########|########|## | | | | |
+--------+--------+--------+--------+--------+--------+--------+--------+--------+-------+
2015 2017 2019 2021 2023 2025 2027 2029 2031 2033
S > LTS [S]tandard security maintenance, Debian Main (3 years)
E > LTS [E]xpanded security maintenance, Debian Main (2 years)
# > LTS E[#]panded security maintenance, Debian Main (5 years)
Although kernel updates can contain fixes and other important features, changes and enhancements to hardware support are one of the primary differences between major releases.
Because of this, interim kernels sometimes get released with the specific goal of greater hardware support despite a shorter support window. With this in mind, it’s often recommended to avoid such kernels, if not required. On the other hand, if we do need bleeding edge features, best practices suggest we should update to an LTS kernel that includes the same features as soon as it’s available.
3. Kernel Packages
In Debian-based systems, there are different packages around the kernel:
- linux-source-
: kernel source tarball - linux-manual-
: kernel manual pages - linux-doc-
: kernel documentation - linux-support-
- : metadata for preparing and building core packages - linux-headers-
- : common or feature-specific headers for building modules-common[-featureset] - linux-image[-featureset]-flavor: binary kernel image and pre-built binary modules
- linux-modules-
- : additional kernel modules
Here, we have both kernel version and ABI (Application Binary Interface) integer as identifiers.
In addition, although not part of the kernel itself, we might want to get some firmware packages such as linux-firmware or firmware-linux-free.
To bundle the correct versions and flavors of connected and co-dependent packages, Debian-based Linux distributions use so-called metapackages. Metapackages are similar to lists of actual packages.
For example, when it comes to the kernel base, Ubuntu uses the linux-generic package, which points to two other metapackages:
After that, we have more specific versions until we reach the actual package to install, which depends on different factors like the general OS version.
4. Hardware Enablement (HWE)
The idea behind HardWare Enablement (HWE) is wider hardware support in exchange for a shorter kernel support window. While HWE is a specific feature, it can be achieved via different means:
- specific package in regular repositories
- backport repositories
In short, backports are packages from the future, i.e., more recent releases of packages than the ones meant for the current distribution version.
Let’s look at both solutions for both Debian and Ubuntu.
4.1. On Ubuntu
Similar to linux-generic, Ubuntu compiles linux-generic-hwe, a metapackage that leads to more recent kernel releases regardless of the OS version.
To achieve this, Ubuntu maintains a separate rolling release cycle for the special linux-generic-hwe kernel. On each point release, this HWE kernel gets packaged, acceptance-tested, and made available.
Similarly, Ubuntu backports provide a way to use bleeding-edge kernel packages that will be part of newer OS releases. In Ubuntu, backports are a separate repository and support for that is limited.
4.2. On Debian
Although the Ubuntu linux-generic-hwe package is convenient and should theoretically work on other APT distributions as well, the only native solution for Debian is Debian backports.
When it comes to Debian, backports are testing-version packages that have undergone less rigorous quality control. For this reason, support for backports extends to only one year after a new LTS release.
Since the whole feature comes from Debian, backports are also a repository in this distribution.
4.3. Considerations
Naturally, due to the more superficial tests, linux-generic-hwe and backports can introduce bugs that might make it unsuitable for the enterprise. Thus, most users without specialized hardware that need stability above all, employ the General Availability (GA) kernel instead. On Ubuntu, that’s usually the linux-generic package.
Of course, some environments use custom-built kernels, which comprise mainly stable components but include device-specific modifications as well. The negative side of using a custom kernel combination is the lack of support and update cycle.
Since we already know about backports, let’s explore the HWE-specific solution.
5. Manage HWE on Ubuntu
As we saw, Ubuntu provides the separate linux-generic-hwe package for the HWE additions, also called an HWE stack.
Let’s understand how we can check for support, install, and uninstall HWE on an LTS platform.
5.1. Check HWE Installation and Support Status
Importantly, it’s better to avoid changing from OEM kernels. For example, we can check for OEM drivers via ubuntu-drivers from the ubuntu-drivers-common package:
$ ubuntu-drivers list-oem
If any do show up, kernel modifications aren’t recommended.
To check the general support on our platform, we can use the official hwe-support-status tool:
$ hwe-support-status
Your Hardware Enablement Stack (HWE) is supported until June 2027.
In this case, we see that HWE is already installed and is supported until the given month.
5.2. Install HWE
It’s fairly simple to install HWE with APT:
$ apt install --install-recommends <HWE_PACKAGES>
In this case, we replace HWE_PACKAGES with the respective package or packages, depending on the version:
- 22.04–23.10: linux-generic-hwe-22.04
- 20.04–22.10: linux-generic-hwe-20.04
- 16.04–18.04: linux-generic-hwe-“$(lsb_release -r -s)”
Notably, desktop versions at and before version 18.04 also require an additional installation for the graphics components:
$ apt install --install-recommends xserver-xorg-hwe-"$(lsb_release -r -s)"
Before this version, installation can be a bit more complex for desktops. After version 18.04, all related components are part of the linux-generic-hwe metapackage.
5.3. Uninstall HWE
Since we can’t run the OS without a kernel, removing HWE means we revert to the GA or another kernel.
Generally, this means we just install the respective kernel package:
$ apt install --install-recommends linux-generic
Of course, custom kernels may require further actions, but the above should be enough to stop using HWE.
Separately, we might still require third-party or specific drivers that HWE included, e.g., for our audio or video card:
$ apt install --install-recommends linux-modules-nvidia-<NNN>-generic
In this case, we install NVIDIA drivers.
This step might vary but could be important, depending on the reasons for the removal of HWE. For example, support for the NVIDIA drivers and GA kernel could be better for stability reasons.
6. Summary
In this article, we talked about the hardware enablement feature of Ubuntu and Debian-based systems.
In conclusion, although there is the alternative of backports, HWE provides a specific way to employ newer kernel versions before their official LTS release.