Ubuntu LTS kernels will get one decade of fixes … still
Upstream policy change for LTS kernels Ubuntu doesn't use
Canonical has addressed customer concerns over the reduction in long term support (LTS) of its code – but there is no real change here, and you'll still need Ubuntu Pro to keep the rest of the OS patched.
An October 24 post penned by three Canonical staffers reiterates that, despite the Linux kernel team reducing the length of its long term support options, the Ubuntu vendor will continue to provide security updates for its LTS kernels for a decade after their release.
The post is a response to the furore caused by recent cuts in the number and lifetime of LTS kernels from the Linux kernel developers, as described by Linux Weekly News boss Jonathan Corbet at last month's Open Source Summit – and analyzed in The Register.
The Canonical post notes that a new Ubuntu LTS kernel is released every two years. That's true, but it could be seen as slightly disingenuous: there's a new Ubuntu LTS kernel because there's a new LTS release of the entire Ubuntu distribution every two years.
Each LTS kernel, like the entire distro, gets five years of support and updates. To get the ten years the authors describe, customers must subscribe to Canonical's Expanded Security Maintenance offering, which is part of its Ubuntu Pro coverage. As we described at the time, a year ago this became free of charge for up to five machines.
In any event Canonical, like other enterprise Linux vendors such as SUSE and Red Hat, doesn't generally use the upstream long term support kernels from the kernel development team.
|Ubuntu version||Launched||EOL date||Extended EOL||Original kernel||Current kernel|
|20.04||2020||Apr 2025||2030||5.4||5.15 LTS|
|22.04||2022||Jun 2027||2032||5.15 LTS||6.2|
To be fair, this is nothing unusual. Ubuntu's upstream distribution is Debian, but it comes from the rolling Debian "unstable" branch – codenamed Sid – which means that there's no one-to-one correspondence between them. Any given version of Ubuntu isn't based on a particular release of Debian.
Debian's current LTS release is version 10, which has kernel 4.19, which happens to be an LTS kernel. Debian 12 has kernel 6.1, also an LTS kernel, but don't jump to conclusions: Debian 11 had 5.1, which is not. Like Debian, enterprise distros such as SUSE and RHEL stick to the same kernel version throughout a product version's lifetime, backporting fixes and new functionality.
Ubuntu LTS releases, though, are a little different: they do receive updated kernels. The kernel present in an LTS version depends on which point release the users originally installed, and what updates they choose.
- Ubuntu unleashes Mantic Minotaur with 23.10 build
- Incus 0.1 is Canonical's LXD 'containervisor' with Ubuntu integration stripped out
- Ubuntu and Fedora clash in beta race, but who wears GNOME better?
- OpenZFS 2.2 is nearly here, and ZFSBootMenu 2.2 already is
Users of the original release of each Ubuntu LTS who install the hardware enablement stack will get newer kernels, as will fresh installations of the later point releases of each LTS. The upstream LTS kernels are versions 4.14, 4.19, 5.4, 5.10, 5.15 and 6.1. Of the current releases of Ubuntu, only 22.04 shipped with an LTS kernel: version 5.15. New installations of 22.04.3 get kernel 6.2 from Ubuntu 23.04 "Lunar" – a short term kernel release – and that in turn will be replaced in some future update.
So, while this ten-year support lifecycle is a good and reassuring thing, it's not a significant change to the existing policies. One of the takeaways of Mr Corbet's message was that it would be a good thing if enterprise distro vendors stuck to using upstream LTS kernels, rather than maintaining their own forks and backporting changes. This vulture's humble opinion is that that would be a very good thing.
Canonical's post clearly shows that it's proud of its kernel support efforts, which is entirely reasonable. We just feel that it could be prouder still if it coordinated its LTS kernel releases with Debian and the upstream kernel team, and they all worked together to pass those updates back upstream for everyone to share. ®
Is Canonical really a "vendor" if it gives its distro away for free? Does it matter?
Come to that, could this be why Canonical is willing to include ZFS, while SUSE, Red Hat and even Oracle itself won't – because Ubuntu is free? It is particularly noteworthy that Oracle adds Btrfs to its CentOS rebuild, but not ZFS, even though Oracle owns all of Sun's original Solaris code – including ZFS. One would think it could find some way to grant itself rights to things it already owns.