Ubuntu 26.04 LTS released [LWN.net]

Ubuntu 26.04 ("Resolute Raccoon") LTS has been released on schedule.

This release brings a significant uplift in security, performance, and usability across desktop, server, and cloud environments. Ubuntu 26.04 LTS introduces TPM-backed full-disk encryption, expanded use of memory-safe components, improved application permission controls, and Livepatch support for Arm systems, helping reduce downtime and strengthen system resilience. [...]

The newest Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity, and Xubuntu are also being released today. For more details on these, read their individual release notes under the Official flavors section:

https://documentation.ubuntu.com/release-notes/26.04/#official-flavors

Maintenance updates will be provided for 5 years for Ubuntu Desktop, Ubuntu Server, Ubuntu Cloud, Ubuntu WSL, and Ubuntu Core. All the remaining flavors will be supported for 3 years.

See the release notes for a list of changes, system requirements, and more.

to post comments

MATE?

Posted Apr 23, 2026 22:10 UTC (Thu) by atai (subscriber, #10977) [Link] (1 responses)

What happens to the Mate Desktop edition?

MATE?

Posted Apr 23, 2026 22:29 UTC (Thu) by jpeisach (subscriber, #181966) [Link]

Currently looking for new maintainers: https://discourse.ubuntu.com/t/ubuntu-mate-seeking-mainta...

Suggestion for bug report

Posted Apr 24, 2026 9:09 UTC (Fri) by mote (guest, #173576) [Link]

I caught this in the XUbuntu release notes:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/21...

If anyone has a login to this system and can post an update, as an Arch + Xfce + gcr4 user a solution, one needs to add the unit `gcr-ssh-agent.socket` to the user units for systemd (i.e., /etc/systemd/user/sockets.target.wants/gcr-ssh-agent.socket ). This unit is provided by the gcr4 package and does exactly what they're discovering, sets SSH_AUTH_SOCK on login to match the running gcr-ssh-agent.

rust-coreutils status

Posted Apr 24, 2026 12:37 UTC (Fri) by aragilar (subscriber, #122569) [Link] (30 responses)

Looks like Canonical issued a statement about the state of rust-coreutils in 26.04: https://discourse.ubuntu.com/t/an-update-on-rust-coreutil...

The number of security issues is a bit concerning, especially since this is an LTS release...

rust-coreutils status

Posted Apr 24, 2026 12:44 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (26 responses)

And worse, since a number were not trivially fixable, they had to revert to GNU coreutils for a few tools like cp, mv, rm. That's just totally odd to insist on a package when it's proven insecure by an audit at the time of release, instead of postponing its deployment.

rust-coreutils status

Posted Apr 24, 2026 18:43 UTC (Fri) by mmm (subscriber, #155993) [Link] (2 responses)

It does look a bit odd. Seems they ended up with rush-coreutils.

rust-coreutils status

Posted Apr 25, 2026 12:08 UTC (Sat) by rbranco (subscriber, #129813) [Link] (1 responses)

They also rushed sudo-rs because it's Rust so it must be more secure, right?

Except they ship both sudos and you're exposed to the CVEs in both.

rust-coreutils status

Posted Apr 27, 2026 15:19 UTC (Mon) by paulj (subscriber, #341) [Link]

I think we're much better off trusting in pixelbeat than in Rust. Padraig is an amazing coder and maintainer.

rust-coreutils status

Posted Apr 24, 2026 19:01 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

> And worse, since a number were not trivially fixable, they had to revert to GNU coreutils for a few tools like cp, mv, rm. That's just totally odd > to insist on a package when it's proven insecure by an audit at the time of release, instead of postponing its deployment.

I would have expected the LTS release to just ship with coreutils as well. Now the LTS is shipping with this odd state and I don't see the appeal. uutils will mature and likely become a good replacement at some point but I don't understand the rationale to do it now in this way. Perhaps someone involved in this can offer a different perspective.

rust-coreutils status

Posted Apr 24, 2026 23:49 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (9 responses)

I am not involved but I have a different perspective. They have not rushed these tools and they are currently in good shape.

They first shipped uutils in Ubuntu 25.10 though even then they kept quite a few that they did not consider ready on the GNU versions for 25.10. All but three of those GNU versions have been replaced by uutils in 26.04. There are few known security issues in 26.04, at least from uutils.

Here is what Canonical had to say about all this recently (the rest of these words are theirs):

Current status for 26.04 LTS

We shipped rust-coreutils as the default in Ubuntu 25.10 to maximise real-world testing ahead of the LTS. Based on the audit findings and remediation progress, here is where we stand for Ubuntu 26.04 LTS.

- We have included the latest upstream release 0.8.0 in Ubuntu 26.04, which incorporates the bulk of the security fixes.

- cp, mv, and rm continue to be provided by GNU coreutils in 26.04. These utilities have remaining open TOCTOU (time-of-check to time-of-use) issues (8 as of Apr 22, 2026) that need to be resolved before we are confident shipping them.

Our plan is to address the remaining issues as soon as possible and target Ubuntu 26.10 with 100% rust-coreutils.

rust-coreutils status

Posted Apr 25, 2026 9:54 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (8 responses)

> They first shipped uutils in Ubuntu 25.10 though even then they kept quite a few that they did not consider ready on the GNU versions for 25.10.

Only 6 months of exposure is just nothing for core tools like these, whose precise behavior has been studied and adopted by literally millions of scripts. Reinventing the wheel just to prove it can be done just brings bugs and deception. It would likely have been more efficient to invest just 10% of that effort improving (or even fixing or cleaning up if required) coreutils. Now we're going to have to deal with at least a decade of bugs or at least "different behavior".

rust-coreutils status

Posted Apr 26, 2026 21:00 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (2 responses)

> we're going to have to deal with at least a decade of bugs

Ok, I was not going to comment but this is just too much. I will counter with my own hyperbole (which I consider much more likely than the above).

"There will be fewer bugs in uutils by the time Ubuntu 26.10 ships than in GNU Coreutils at that time" - Me

If we are allowed to comment on old stories, I will come back and post the bug trackers and test coverage results for both projects when Ubuntu 26.10 ships. Feel free to do the same.

In the meantime, please humiliate me with posts from the Internet about all the uutils problems real users are running into in Ubuntu 26.04 so far. I mean, since uutils is so ridiculously low quality, there must be many dozens of such stories in wide circulation by now. Every news outlet must be flooded with them.

Ok, more seriously, the idea that uutils will be buggy for a decade is beyond unlikely in my view.

The problems is as bad as it is ever going to get right now. And things are not bad at all.

As you say, these utilities get used by millions of scripts. How many scripts do you think have been run with these utilities since they shipped in Ubuntu 25.10? How many are used by Canonical themselves? And there was a serious security audit. The bugs that are likely to impact large numbers of users will have been discovered. What is left at this point are issues that will be exposed by more niche use cases. But even these will not take 10 years to find and fix.

Ubuntu 26.04 will likely be the most used Linux distribution on earth within a month or two (this is not an endorsement, I do not use Ubuntu, but it is very popular). What will happen is that there will be a spike in discovered issues within the first month of release. Most will have already been reported. The most important of these bugs will be fixed very quickly. The rest will be addressed over the next six months or so.

The same thing happened when 25.10 shipped. There was a spike in known issues. The important ones were fixed so fast that stories about them came out after the patches. These new behaviours were then added to the GNU test suite that uutils uses to ensure compatibility. Which means that uutils is increasing the quality of the GNU coreutils project as well of course. But even with all these new tests, uutils is passing almost all of them now. With the launch of Ubuntu 26.04, there will again be a spike in discovered issues which will become new test cases. There will be a spike in issues but not a spike in the number of real users affected. And these issues will be addressed in the coming months. The number of failing tests will likely be close to zero by the time Ubuntu 26.10 is released.

You can see the process I am describing in the graph of uutils test results:
https://raw.githubusercontent.com/uutils/coreutils-tracki...

Which is to say, real users will encounter few problems with uutils in Ubuntu. Those that do will be exposed only to the small number of edge cases that apply to them. Which makes the overall experience pretty similar to any other package in an LTS release. Users that don't read press coverage about uutils may not even notice the change.

For perspective, here is the state of the Ubuntu rust-coreutils bug tracker right now:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils

rust-coreutils status

Posted Apr 30, 2026 11:58 UTC (Thu) by aragilar (subscriber, #122569) [Link] (1 responses)

I personally think you're too optimistic, those who are more likely to be hitting the edges of uutils tend to take the full 5 years to migrate. I've seen far too many critical bugs from "Ubuntuisms" (such as removing the networking stack as part of an upgrate, so I had to rebuild the networking via iproute2, and manually update similar machines) to trust Canonical's QA processes, and the uutils failures are just another example. At work we've been migrating away from Ubuntu as we replace machines, and anecdotally I've not seen new Linux users adopt Ubuntu. The steam deck (which is likely bringing in more Linux users than any other distro) is built on Arch, and so while Ubuntu currently has the largest mindshare among existing users, how long that remains the case is to be seen.

rust-coreutils status

Posted May 5, 2026 9:13 UTC (Tue) by taladar (subscriber, #68407) [Link]

The people on long-term support distros will be the ones who take 5+ years to migrate. While it is entirely plausible that they have some shell scripts so bad that they hit bugs that nobody else will that is pretty much on them and shouldn't keep everyone else back.

Meanwhile the SteamOS users probably will have a lot less variety since 95% of their shell scripting will be simple wrapper scripts around some game binaries to set some environment variables.

rust-coreutils status

Posted Apr 26, 2026 23:37 UTC (Sun) by andresfreund (subscriber, #69562) [Link] (1 responses)

I don't really buy that. Typical scripts have to deal with stuff like BusyBox and other unixs scripts as well...

rust-coreutils status

Posted May 1, 2026 11:46 UTC (Fri) by anton (subscriber, #25547) [Link]

In what way would such scripts be typical? I would be very surprised if many of my scripts work on Busybox. I use bash features and GNU-specific features without restraint, and Busybox is so limited that I curse because of that on every second command even when I know I work on Busybox. Experiences on, e.g., Solaris are similar.

Sure, when you have script portability as goal, you can work around the limitations, but for many of my scripts that is not the goal. So unless the rust-coreutils offer 100% drop-in compatibility, I will stay with GNU coreutils. And if Ubuntu does not offer them, there are other distros to choose from.

rust-coreutils status

Posted Apr 27, 2026 1:40 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> Reinventing the wheel just to prove it can be done just brings bugs and deception.

The problem is that coreutils are just bad. They are defined by their behavior, and that is increasingly arcane and full of Hyrum's law illustrations. We can just encase the coreutils in lucite and call it a day. Or we can try to document these behaviors, create test cases for them, and fix them if needed. Doing that with a memory-safe language is just a cherry on top.

Should Ubuntu have waited a release cycle and then had to support coreutils for 10 more years? Maybe.

rust-coreutils status

Posted Apr 27, 2026 15:47 UTC (Mon) by collinfunk (subscriber, #169873) [Link]

Well, a majority of the options and behavior are specified by POSIX. The rest we document in the texinfo documentation.

rust-coreutils status

Posted Apr 28, 2026 8:14 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

> Should Ubuntu have waited a release cycle and then had to support coreutils for 10 more years

You can use GNU coreutils in Ubuntu 26.04. So they will be supporting them for a long while yet.

That said, they are certainly going to want to stop shipping GNU coreutils for the next LTS. The goal will be to make uutils absolutely bullet proof before then (by 26.10 if possible).

rust-coreutils status

Posted Apr 24, 2026 23:38 UTC (Fri) by jmalcolm (subscriber, #8876) [Link] (11 responses)

They were already using GNU cp, mv, and rm in 25.10 so this was pretty much the plan all along.

In my view, despite commentary to the contrary, they are being quite cautious with this roll-out.

People have been using earlier versions of these tools in 25.10 and I seem to have missed all the news stories about things going wrong.

rust-coreutils status

Posted Apr 25, 2026 0:40 UTC (Sat) by pizza (subscriber, #46) [Link] (6 responses)

> People have been using earlier versions of these tools in 25.10 and I seem to have missed all the news stories about things going wrong.

I've had users reporting numerous build failures due to 25.10's uutils not being 100% compatible with GNU coreutils. I _think_ all of those issues are now resolved, though how much of that is upstream fixes vs our docs loudly proclaiming we won't provide any assistance or address bug reports if genuine GNU coreutils isn't used.

I swear, it's like we've taken a look back at the relative stability of the last two decades and went, "nah bro, hold my beer"

rust-coreutils status

Posted Apr 26, 2026 9:15 UTC (Sun) by ballombe (subscriber, #9523) [Link] (5 responses)

It is quite possible to do a high-quality fully compatible reimplementation of coreutils in rust, but this is not what the rust-coreutils dev set out to do. Given that any deviation from coreutils is a security bug waiting to be exploited,
the only 'advantage' of rust-coreutils is that it is not GPL, which let us question the real motivation of Canonical.

rust-coreutils status

Posted Apr 27, 2026 15:36 UTC (Mon) by dskoll (subscriber, #1630) [Link] (4 responses)

Yes, I was about to comment on the license change. In principle, rewriting the utilities in a memory-safe language and documenting / testing for the expected behavior is a good idea. But moving away from the GPL is unfortunate, in my opinion.

The GPL is losing ground just as tech giants and oligarchs are gaining power and IMO that doesn't bode well for the future of Free Software. For example: Look at the OS-based age-verification fiasco sweeping much of the world. If Linux distros were released under a MIT- or BSD-like license, they could start closing source and forcing age-verification on us and we'd have very little recourse.

rust-coreutils status

Posted Apr 28, 2026 10:09 UTC (Tue) by taladar (subscriber, #68407) [Link] (3 responses)

Who could do that? MIT and BSD allow just as much forking as GPL.

rust-coreutils status

Posted Apr 28, 2026 14:39 UTC (Tue) by dskoll (subscriber, #1630) [Link] (2 responses)

Anyone could do it. If the Linux kernel were MIT-licensed, a big company like Canonical or Red Hat could fork it but not release sources to the forked version. If it made enough changes or added enough features, then Ubuntu or Red Hat users would be locked in and unable to meaningfully make their own changes to the kernel.

Now, I'm not saying Canonical or Red Hat would do that. But the fact that Linux is GPL-licensed means they couldn't do it even if they wanted to.

rust-coreutils status

Posted Apr 30, 2026 10:52 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

That applies to huge projects like the Linux kernel but less so to projects like coreutils where a group of a few or even an individual maintainer could just write alternatives to pretty much any closed source patches someone could conceivable write on top of that closed code-base because the code base is not that large and doesn't contain any use-cases with highly proprietary or patented algorithms.

rust-coreutils status

Posted Apr 30, 2026 14:20 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Yes, in the case of coreutils, you are probably right, but I don't see what upside there is to changing the license away from GPL.

rust-coreutils status

Posted Apr 26, 2026 4:49 UTC (Sun) by cypherpunks2 (guest, #152408) [Link] (3 responses)

> I seem to have missed all the news stories about things going wrong.

It's not that things are going wrong within Ubuntu itself. I'm sure every script they ship has been extensively tested with rust-coreutils. The problem is that coreutils has to be compatible not just with any script Ubuntu ships, not even just with every script you could find in its repo, but with any script one could conceivably be expected to run on Linux, which includes ancient scripts, scripts from weird installers, those creepy self-extracting tarball scripts like makeself, build scripts for any conceivable project (and not just those that use standard, well-known build systems), and more.

Something as critical as coreutils needs to be bug-for-bug compatible or needs to go through many years of testing for all but the most trivial commands. You won't be seeing a flood of news stories about things going wrong because no one is going to lose their system because some cronjob blows up. It'll be a bunch of little confusing errors that crop up that make you wonder if there's a problem with that obscure script that you got for the installer of some fluid dynamics toolkit on some .edu site or the run script for the Linux port of some Japanese game emulator.

rust-coreutils status

Posted Apr 27, 2026 11:24 UTC (Mon) by moltonel (subscriber, #45207) [Link] (1 responses)

> any script one could conceivably be expected to run on Linux, which includes ancient scripts, scripts from weird installers, those creepy self-extracting tarball scripts like makeself, build scripts for any conceivable project (and not just those that use standard, well-known build systems), and more

If that's the criteria, then GNU coreutils fails just as quickly as Uutils. Reading its NEWS file [1] shows that every GNU release has some fix or change that can break weird old scripts. It's clear that uutils is not perfect, but thinking that GNU is perfect or that only perfect tools should be used is silly. It stifles potential improvements, both in GNU and in the wider ecosystem.

Uutils will keep improving, and will get less controversial as a GNU replacement. More corner cases, unexpected behaviors and bugs will be found and added to tests in both projects, benefiting all users. But there's always going to be some badly written scripts that only work with a particular coreutils version [2].

[1] https://github.com/coreutils/coreutils/blob/master/NEWS
[2] https://github.com/uutils/coreutils/issues/4849

rust-coreutils status

Posted Apr 28, 2026 10:06 UTC (Tue) by taladar (subscriber, #68407) [Link]

It is not about coreutils either. Do you know how many special cases scripts need just because e.g. Debian and RedHat name some folder in /etc/ slightly differently or put some file in /var/ in a different location?

What about the usr-merge? What about the move from sysvinit to systemd (with, in some distros, some other tool in between). Deprecation of certain protocols, changes in config file formats,...

Any minor change like this completely disappears in the larger noise of compatibility changes along those lines.

rust-coreutils status

Posted Apr 28, 2026 8:06 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

> coreutils has to be compatible...with any script one could conceivably be expected to run on Linux

We agree.

> Something as critical as coreutils needs to be bug-for-bug compatible

We agree.

> needs to go through many years of testing

We disagree.

You are not going to find the kinds of problems you are talking about through testing. Releasing uutils with Ubuntu 25.10 has already exposed it to an absolutely massive sampling of real scripts in the wild. And it is now working well with those. Releasing it in 26.04 will expose it to even more. As Ubuntu still deploys to something like a third of Linux desktops, you may be surprised by how quickly all those fluid dynamics toolkits and Japanese game installers will be encountered. Anything that isn't, is just not a big enough problem to worry about. All compatibility issues are bugs of course. But, as with all bugs, it is the number of people encountering issues that matters (once you get past the serious stuff).

We are not seeing stories about scripts not working. We are not reading blogs from developers talking about how 26.04 broke everything. We had about a week or so of that when 25.10 released. Problems remain for sure. But they are not major problems. And they will be fixed. The best way to find the kinds of problems you are trying to find is to let people use uutils for real life.

rust-coreutils status

Posted Apr 26, 2026 15:35 UTC (Sun) by HenrikH (subscriber, #31152) [Link]

Have any one done a similar security check on the GNU coreutils?

rust-coreutils status

Posted Apr 27, 2026 9:28 UTC (Mon) by gherkin (guest, #177675) [Link] (1 responses)

I always tend to find that 'LTS' for Ubuntu is a bit deceptive - people take it to mean that the release is more stable, when all it really means is that it will be supported for longer - and tends to gain stability over time.

But for the first six months of release are effectively no different than any other non-LTS release.

rust-coreutils status

Posted Apr 28, 2026 7:46 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

I mostly agree with you. It is an important point. Using kernel version 7.0 is a good example.

I do think they try to somewhat minimize the disruption with LTS releases though. Uutils itself is a good example. They first released them in 25.10 and there were certainly more issues then than now. From 25.10, they can see that most users are having a perfectly fine experience at this point and so they can ship uutils in an LTS.

You could argue that GNOME 50 being Wayland only in 26.04 is a big shift to introduce in an LTS. But they have been Wayland by default for a long time now.

authd

Posted Apr 24, 2026 16:01 UTC (Fri) by imphil (subscriber, #62487) [Link]

From the release notes (https://documentation.ubuntu.com/release-notes/26.04/summ...)
> authd, Ubuntu’s cloud authentication solution, is now available from an official Ubuntu repository and has a range of new features. Changes since 24.04 are detailed below:

Authd (https://documentation.ubuntu.com/authd/stable-docs/) looks like something I wanted for a while now to give users with a Google Workspace account access to remote development machines. Does anyone have experience with it? The snap thing looks a bit odd.

And the naming seems to be a bit confusing as well, given other projects that are also called authd (e.g., https://packages.fedoraproject.org/pkgs/authd/authd/). Has someone seen authd (the one by Canonical) on other distros as well?