Ubuntu 24.04

Ubuntu 24.04 LTS release notes

These release notes for Ubuntu 24.04 LTS (Noble Numbat) provide an overview of the release and document the known issues with Ubuntu and its flavors. For details of the changes applied since 24.04, refer to the following changelogs:

• 24.04.4
• 24.04.3
• 24.04.2
• 24.04.1 For the release schedule of Ubuntu 24.04 LTS and its point releases, refer to:
• Release schedule

Support lifespan

Ubuntu 24.04 LTS will be security maintained for 5 years until 31 May 2029. Users can choose to extend this to 10 years with Ubuntu Pro or 12 years with the Legacy add-on.

Upgrades

Users of Ubuntu 23.10 have been offered an automatic upgrade to 24.04 since shortly after the release. Users of 22.04 LTS will also start being offered the automatic upgrade now that 24.04.1 LTS has been released.

Changes since 22.04 LTS

If you’re upgrading from Ubuntu 22.04 LTS to 24.04 LTS, you get all the changes that happened in the six months since Ubuntu 23.10, as well as the changes in all the interim releases between 22.04 LTS and 24.04 LTS. For details, see the complete interim release notes: 22.10, 23.04 and 23.10. Finally, review the following changes since Ubuntu 23.10.

New features in 24.04 LTS

Year 2038 support for the armhf architecture

Ubuntu 24.04 LTS solves the Year 2038 problem that existed on armhf. More than a thousand packages have been updated to handle time using a 64-bit value rather than a 32-bit one, making it possible to handle times up to 292 billion years in the future.

Updated Packages

Linux kernel 🐧

Ubuntu 24.04 LTS includes the new 6.8 Linux kernel that brings many new features. Detailed changes are reported in the Noble Kernel Release Notes post.

systemd v255.4

The init system was updated to systemd v255.4. See the upstream changelog for more information about individual features.

Netplan v1.0 🌐

The network stack was updated to Netplan version 1.0. Supporting simultaneous WPA2 & WPA3, Mellanox VF-LAG for high-performance SR-IOV networking and VXLAN improvements. It also provides a stable libnetplan1 API and a new netplan status --diff sub-command to find differences between configuration and system state. For more information please see the Introducing Netplan v1.0 blog post.

Toolchain Upgrades 🛠️

• GCC 🐄 is updated to the 14, binutils to 2.42, and glibc to 2.39.
• Python 🐍 now defaults to version 3.12
• OpenJDK ☕ now defaults to LTS version 21
• LLVM 🐉 now defaults to version 18
• Rust 🦀 toolchain defaults to version 1.75
• Golang 🐀 is updated to 1.22
• .NET 8 is now default

OpenJDK

OpenJDK LTS 21 is the default in Ubuntu 24.04 LTS while maintaining support for versions 17, 11, and 8. OpenJDK 17 and 21 are also TCK certified, which means they adhere to Java standards and ensure interoperability with other Java platforms. A special FIPS-compliant OpenJDK 11 package is also available for Ubuntu Pro users.

.NET

With the introduction of .NET 8, Ubuntu is taking a significant step forward in supporting the .NET community. .NET 8 will be fully supported on Ubuntu 24.04 LTS and 22.04 LTS for the entire lifecycle of both releases. This enables developers to upgrade their applications to newer .NET versions before upgrading their Ubuntu release. Starting with 24.04 LTS the .NET support has also been extended to the IBM System Z platform. .NET 6 and .NET 7 packages with limited support are available via a PPA.

Apport

Apport added integration with systemd-coredump to handle crashes. Developers on Ubuntu can co-install systemd-coredump now and use coredumpctl to analyze crash data. Apport will continue to collect crash information and submit it to the Ubuntu Error Tracker and Launchpad.

Security Improvements 🔒

Unprivileged user namespace restrictions

In combination with the apparmor package, the Ubuntu kernel now restricts the use of unprivileged user namespaces. This affects all programs on the system that are unprivileged and unconfined. A default AppArmor profile is provided that allows the use of user namespaces for unprivileged and unconfined applications but will deny the subsequent use of any capabilities within the user namespace. A common use-case for unprivileged user namespaces is applications that construct their own sandboxes or work with styles of container workloads. As such, AppArmor profiles that allow the use of unprivileged user namespaces are also provided for common applications and frameworks that come from the Ubuntu archive, as well as popular third party applications like Google Chrome, Discord and others. This is a subsequent step towards trying to mitigate the larger attack surface presented by unprivileged user namespaces (the first being the introduction of this feature in Ubuntu 23.10 where it was not enabled by default). Whilst significant effort has been expended to try and identify all applications that may require such profiles, it is expected that there may be cases where additional profiles are required. In this case, there are several options if you run into problems:

• Confine your applications with an AppArmor profile. Because this can be potentially onerous, a new unconfined profile mode/flag has been added to AppArmor. This designates the profile to essentially act like the unconfined mode for AppArmor where an application is not restricted, and it allows additional permissions to be added, such as the userns, permission. Such profile for, e.g. Google Chrome, would look like the following, and it would be located within the /etc/apparmor.d/chrome file: abi <abi/4.0>, include <tunables/global> /opt/google/chrome/chrome flags=(unconfined) { userns, # Site-specific additions and overrides. See local/README for details. include if exists <local/chrome> } Alternatively, a complete AppArmor profile for the application can be created (see the AppArmor documentation).
• Launch your application in a way that doesn’t use unprivileged user namespaces, e.g. google-chrome-stable --no-sandbox. However, since this disables the use of an internal security feature within the application, this is not recommended. Instead, use the unconfined profile mode described above instead.
• Disable this restriction on the entire system for one boot by executing echo 0 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns. This setting is lost on reboot. This similar to the previous behaviour, but it does not mitigate against kernel exploits that abuse the unprivileged user namespaces feature.
• Disable this restriction using a persistent setting by adding a new file (/etc/sysctl.d/60-apparmor-namespace.conf) with the following contents: kernel.apparmor_restrict_unprivileged_userns=0 Reboot. This is similar to the previous behaviour, but it does not mitigate against kernel exploits that abuse the unprivileged user namespaces feature.

TLS 1.0, 1.1 and DTLS 1.0 are forcefully disabled

• for software using openssl this was the case since 20.04
• for software using gnutls, this is now enforced (with openconnect being a notable exception)

More consistent application of openssl and gnutls system configurations

Some libraries do not raise errors when their configuration is not accessible; this could happen when AppArmor does not allow access to the configuration files. Due to how widespread openssl and gnutls are, the AppArmor rules now grant access to their configuration files by default. Their system-wide configuration will therefore be followed better.

Deprecation and disablement of 1024-bit RSA APT repository signing keys

APT in 24.04 requires repositories to be signed with the RSA keys no smaller than 2048 bits, Ed25519, or Ed448. As work to resign old Launchpad PPAs with a stronger keys is still ongoing for some weeks, this is initially only a warning. Once Launchpad PPAs have been resigned, you will need to manually migrate any affected PPAs to new signing keys by removing and re-adding them to quiesce the warning. The final APT 2.8.0 release that converts the warning to an error should be published as a stable release update some time after the resigning is complete.

pptpd removed

• pptpd and bcrelay have been removed

OpenSSH with reduced dependencies

As per the XZ-utils backdoor, openssh in Ubuntu does not depend anymore on libsystemd, reducing the number of dependencies and making it less prone to future security issues.

Package security-hardening improvements

Packages are now built with security-hardening features which stop many undiscovered security vulnerabilities, rendering them unexploitable. The gcc compiler and dpkg now defaults to -D_FORTIFY_SOURCE=3 instead of -D_FORTIFY_SOURCE=2 which greatly increases buffer overflow detection and mitigation. dpkg now defaults to use -mbranch-protection=standard which mitigates code reuse attacks on arm64.

Performance ⚡

Performance Engineering tools

A set of performance engineering tools is installed by default on relevant Ubuntu systems. Additionally, a performance-tools metapackage has been created to assist in debugging performance and reliability issues. See specification for more details.

Default configuration changes ⚙️

As always there are many changes to defaults, mostly by newer versions of packages. But a few are worth spelling out if your former automation, configuration and tuning relied on those settings being one or the other way.

Apt priority of the proposed pocket

The proposed pocket is used as a staging area for software updates. These updates land in the proposed pocket before they are released to the wider public userbase. But in the past, if someone enabled the proposed pocket for testing they often got into trouble by getting their system flooded with everything that is in the proposed pocket. If just one of the packages in there was weirdly broken you’d have been broken by that as well - and it might have been unrelated to what you really care about and made your regular testing consume more effort and thereby less attractive. By changing the default priority, users are less likely to install potentially unstable updates unintentionally. Therefore the default apt priority of the proposed pocket was reduced from 500 to 100. This change already happened in Ubuntu Lunar, but Noble is the first Ubuntu LTS to pick it up and therefore there is much more time of consumption from the proposed pocket in front of it. With the change, users can now selectively install packages from the proposed pocket. This allows for more conscious selection and testing of updates. You can always see the new versions of the packages e.g. via apt-cache policy but they will no more auto-install. To install a package from proposed you’d now need to select from which pocket you want to install like apt install /-proposed The above helps a lot for the conscious testing of changes. But on the other hand having automation and people testing (almost) all new package versions regularly can provide great signal. Especially in canary setup with their very own workload it can prevent breaking these specific setup unintentionally as it might be different from what is tested elsewhere. Therefore in those situations if you want to go back to the old behavior of just getting everything from proposed all the time, you’d need to bump the apt pin priority back up to 500 so the versions from the proposed pocket compete on the same level with the rest of the Ubuntu Archive. To do that you could put the following in a file like /etc/apt/preferences.d/bump-proposed-prio:

Consider proposed all the time, set default priority 500 Package: * Pin: release a=noble-proposed Pin-Priority: 500

deb822 sources management

The sources configuration for Ubuntu has moved from /etc/apt/sources.list to /etc/apt/sources.list.d/ubuntu.sources in the more featureful deb822 format, aligning with PPAs that already migrated to deb822 last year. See the specification for more details. …