|
|
Log in / Subscribe / Register

Debian 13 ("trixie") released

[Posted August 9, 2025 by jzb]

The Debian Project has released its latest stable version, Debian 13 ("trixie"), which will be supported through 2030. This release includes GNOME 48, KDE Plasma 6.3, Xfce 4.20, Linux 6.12, GCC 14.2, Python 3.13, and systemd 257.

This release contains over 14,100 new packages for a total count of 69,830 packages, while over 8,840 packages have been removed as "obsolete". 44,326 packages were updated in this release. The overall disk usage for "trixie" is 403,854,660 kB (403 GB), and is made up of 1,463,291,186 lines of code. [...]

With this broad selection of packages and its traditional wide architecture support, Debian once again stays true to its goal of being "The Universal Operating System". It is suitable for many different use cases: from desktop systems to netbooks; from development servers to cluster systems; and for database, web, and storage servers. At the same time, additional quality assurance efforts like automatic installation and upgrade tests for all packages in Debian's archive ensure that "trixie" fulfills the high expectations that users have of a stable Debian release.

Trixie adds riscv64 as an officially supported architecture, and drops i386 as a regular architecture. Users with i386 systems should not upgrade to trixie; the project recommends reinstalling them as amd64, or retiring the hardware. See the release notes and issues to be aware of before installing or upgrading to trixie.


to post comments

Live-blogging of the release process

Posted Aug 9, 2025 22:51 UTC (Sat) by fraetor (subscriber, #161147) [Link]

Its been fun to see the various steps of the release process being blogged in real-time over on https://micronews.debian.org/ today. It really makes me appreciate the provided web feed.

Great work everyone involved in the release! I look forward to upgrading my systems.

Undeclared serious bug (not) in "5. Known severe bugs"

Posted Aug 10, 2025 10:51 UTC (Sun) by alx.manpages (subscriber, #145117) [Link]

The page for issues to be aware of, in section "5. Known severe bugs":
<https://www.debian.org/releases/trixie/release-notes/issu...>

I think it would have been worth documenting the *serious* bug #1099130 affecting firefox:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099130>

which is about the terms of use possibly being incompatible with the DFSG.

Is upgrading from a desktop terminal supported?

Posted Aug 10, 2025 18:11 UTC (Sun) by Karellen (subscriber, #67644) [Link] (16 responses)

I've seen a few people on social media note that they started an upgrade from a desktop terminal (e.g. Konsole, Gnome terminal), and had it freeze part-way through⁰.

To me, this isn't particularly surprising, as I wouldn't have thought that desktop environments would react well to having most of their files removed and newer versions put in place while they're running. While currently in-use binaries continue to exist as long as they're executing, modern DEs tend to start and stop helper programs regularly.

However, I went to check the upgrade instructions and issues from the release notes and... I can't find any warnings about running the upgrade from a desktop? There are a number of warnings about performing the upgrade remotely, with suggestions to use screen/tmux, and other precautions to take, but that's it?

Are such upgrades supported? If not, am I missing where it's mentioned that they're not? If they aren't, should there be such a warning somewhere?

⁰ One example can be found (at the time of writing) at https://mastodon.online/@moftasa/115003337499575318 - but that poster isn't alone, even though I can't find some of the others now.

Is upgrading from a desktop terminal supported?

Posted Aug 10, 2025 19:33 UTC (Sun) by storner (subscriber, #119) [Link]

I've done this several times with the various Debian releases. Also with trixie yesterday.

Never had a problem with that.

Is upgrading from a desktop terminal supported?

Posted Aug 10, 2025 21:30 UTC (Sun) by kreijack (guest, #43513) [Link] (3 responses)

> Is upgrading from a desktop terminal supported?

I think that the most safer approach would be using screen or tmux to prevent issue if the console crashes.

Anyhow I found this

https://wiki.debian.org/DebianUpgrade

which basically suggests to create a copy of the system, upgrading it in a qemu session then committing the change. It seems to me a bit "over engineered", but it a lot safer. My only concern is the quality of the initramfs that would be build on the basis of the qemu hardware...

Personally I use the snapshot capability of btrfs. I take a snapshot of the filesystem before the upgrade. If the upgrade is successful, the snapshot is deleted. Otherwise if a crash happen during the upgrade and an emergency reboot is required, the snapshot is used as root.

It doesn't cover all possible cases, but has the advantage to be used in conjunction with --force-unsafe-io, increasing the speed of dpkg.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 0:29 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

Note that if you start things with `systemctl --user` units, you can get yourself into trouble if the unit that spawns tmux doesn't coordinate with the `systemd --user` instance and give it its own unit/slice. It will get torn down with the launching terminal. I hit this with `urxvt256cd` being restarted (to get new `xrdb` settings) killing my whole session before I made `tmux@.service` units.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 8:15 UTC (Mon) by hmh (subscriber, #3838) [Link] (1 responses)

Restarting user sections and terminals during upgrades is a bug (and I certainly don't mean release upgrades: it is a bug of it happens at any package upgrade).

If it still happens with the version in Trixie or sid, please report a bug.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 10:29 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I was more considering something like "gvfs libraries updated and $gnomeapp crashed because of some new background task cross-loading libraries" than explicit `systemctl --user restart` calls. The urxvt restart example was an explicit request on my part. But it did get me to improve my user session units better (the xrdb and daemon units need not be connected and `tmux` deserves its own unit).

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 4:46 UTC (Mon) by atai (subscriber, #10977) [Link] (4 responses)

I remember some Fedora notes saying doing OS updates or upgrades from the console, not a terminal on a desktop.

Sorry I do not have the link off hand.

The rational or warning should be valid across different distributions.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 8:23 UTC (Mon) by hmh (subscriber, #3838) [Link]

It is safer, yes. On the order of safety, you have Linux text console with tmux or screen, then the same over ssh, then on a Gui terminal with tmux or screen. Evidently doing it from. single user mode is safer than in standard mode as well.

But this does not mean it is required. It isn't supposed to be: it would have been described as such in the release notes otherwise.

There are also safer sets of apt upgrade steps, that can sidestep issues. One of those is documented as the "low on ram or disk space" instructions. But basically, you are almost always better off if everything that dpkg and apt needs is fully updated and committed before you get to the big mass of packages.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 8:31 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

It would be https://docs.fedoraproject.org/en-US/quick-docs/upgrading...

For the sake of discussion, live upgrading of Fedora release is describe in above docs. It works, but it's not tested by QA team, and thus is not supported.
Recommended way of upgrading Fedora is offline – when the packaging tools download new packages, system is rebooted to apply packages in a clean environment, and rebooted again with new version. It takes few minutes to do the dist-upgrade.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 15:02 UTC (Mon) by DemiMarie (subscriber, #164188) [Link]

Interestingly, this causes problems in Qubes OS. This is because an offline upgrade doesn’t start the Qubes OS guest agents, so dom0 thinks the guest is frozen and kills it mid,-upgrade.

Is upgrading from a desktop terminal supported?

Posted Aug 12, 2025 20:51 UTC (Tue) by bartoc (guest, #124262) [Link]

The usual way to do a fedora upgrade is by downloading all the packages and then having a systemd target that stops early on to install everything. It works similarly to windows update, except generally faster.

I'm not sure how kernel upgrades work, maybe the target will kexec into a new terminal after it's done.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 6:00 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

You should possibly write to debian-devel mailing list to report this. I don't think it's normal.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 9:26 UTC (Mon) by oskar (subscriber, #119514) [Link] (2 responses)

I run most of my updates from the desktop and have been doing if for years on multiple machines and have only had a few minor problems.
When running Testing or Unstable much of the OS is replaced regularly without issue.

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 9:42 UTC (Mon) by Karellen (subscriber, #67644) [Link]

Even on testing or unstable, most of the time you're not doing a major version upgrade of your desktop environment. I would be wary about the stability of running e.g. Gnome 43, while only having the binaries and libraries for Gnome 48 accessible in the filesystem. I suspect that that has not received extensive testing or any actual pronouncement of being a supported configuration from anyone, and would not be surprised if it resulted in crashes or freezes. Which you don't really want to happen, mid-upgrade, when that's where you're managing the upgrade from. Sure, it might work some of the time, or most of the time, but is that just luck?

Is upgrading from a desktop terminal supported?

Posted Aug 11, 2025 13:18 UTC (Mon) by dskoll (subscriber, #1630) [Link]

Same; I always upgrade either from the desktop or within an SSH session if the machine is headless. But I also do it in a screen session for extra safety.

The way Linux works, even if a program or shared library is replaced, it shouldn't affect running processes that hold a file descriptor to the original file open. The file's directory entry is removed, but its contents are not deleted until the last reference to its inode is closed.

Is upgrading from a desktop terminal supported?

Posted Aug 12, 2025 5:39 UTC (Tue) by alavaliant (subscriber, #104924) [Link]

For the record. I successfully upgraded 3 desktop machines to from Debian 12 to 13 while inside a logged in KDE Plasma session. All apt steps/package updates completed without issue and the desktop didn't hang while it was occurring. - Which has been my experience when upgrading the same machines from 11 to 12 etc in previous years.

The only issue I hit was trying to select to reboot from inside the login session didn't result in the machines successfully rebooting (I presume due to the number of low level system changes). The desktop session looked like some of it's processes terminated but not all of them. Possibly if I'd left them for a while the machines might have eventually rebooted. But I rebooted in each case after waiting a few minutes while nothing much seemed to be happening.

Is upgrading from a desktop terminal supported?

Posted Sep 29, 2025 18:26 UTC (Mon) by jmuc (subscriber, #84403) [Link]

For reference, I have upgraded my Dell laptop running fairly standard GNOME and suddenly the desktop crashed mid-upgrade, including the desktop terminal. Not a big problem, killed dpkg and apt from the serial console and continued from there with `dpkg --configure -a` / `apt-get -f install`. But next time I will run it in a tmux session.

Funnily enough I have read this conversion before, but thought it would not happen to me. As far as I can remember also has not happened for prior Debian upgrades, since Woody.

Mostly good and painless process

Posted Aug 11, 2025 14:24 UTC (Mon) by ajt (guest, #29568) [Link] (1 responses)

I've upgraded most of my desktop/laptop systems without a hitch and the upgrade worked perfectly fine over SSH and from a Konsole session.

I had one problem during the upgrade where an Ethernet cable came free and apt dropped some files it couldn't access which caused it to screw up. It didn't recover automatically and upgraded my laptop without the selected cursor pointer theme installed - which prevented Wayland/KDE from starting and X/KDE sulked but indicated the problem. Manually adding the cursor theme back and Wayland and X both start KDE without a problem.

A second problem I've hit which apparently is a know bug is that QT6 on which KDE runs has bugs with fractional scaling. So while I can do my main desktop screen at 110% or some such ratio and a smaller side screen at plain 100%, if I do that out of the box my display glitches, and the game kpat is unusable - other applications are impacted by different amounts. Switching back to X means I lose the ability to do different scaling which is a shame. Apparently you can manually set a QT parameter to alleviate most but not of the problems and I've found it removes 95% of them, but not all.

As long as you set QT_SCALE_FACTOR_ROUNDING_POLICY= to something other than PassThrough which is the default in KDE6 in Trixie, then it mostly works okay. It's not perfect but it's a lot better, e.g. RoundPreferFloor. I gather QT has fixed this but that code didn't make it into Trixie.

Mostly good and painless process

Posted Aug 19, 2025 12:21 UTC (Tue) by hmh (subscriber, #3838) [Link]

If you can somehow pinpoint the set of fixes for this, and open a bug in the Debian bug-tracking system, there is a non-zero chance of a fix being deployed to Debian stable.

It all depends on how much regression potential we're talking about, and a few reports of the "I have tested it and it works fine", and "I have run with these fixes for X months and observed no issues" can usually take care of regression worries.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds