0.076
Update when you can afford downtime. The update should be painless but you know how it is: things go crazy when they shouldn't. Every time.
0.076
Update when you can afford downtime. The update should be painless but you know how it is: things go crazy when they shouldn't. Every time.
The upgrade itself is never a problem.
The real problem is when your server is running an old software that breaks after the update.
For example I had an old php/drupal site and it broke after upgrading debian because the upgrade also updated php to a newer version that is not supported by that old version of drupal.
Most of my infra is Debian, and I did it without serious incident:
#Update everything to latest
apt update && apt upgrade && apt full-upgrade && apt --purge autoremove
reboot
#Verify that debian_version is 12.x (STOP IF NOT 12!)
cat /etc/debian_version
#Check for any pinned or held packages
apt list '?narrow(?installed, ?not(?origin(Debian)))'
apt-mark showhold
#Swap bookworm for trixie in repo files
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*
#Carry out update
apt update
apt upgrade --without-new-pkgs -y
apt full-upgrade -y
reboot
#Verify that debian_version is 13.x
cat /etc/debian_version
#Modernize apt sources to v3
apt modernize-sources -y
And then maybe apt update to make sure the updates still work OK.
Sometimes you have to make changes to certain repos that don't have Trixie manifests, but that's easy enough to roll back.
apt modernize-sources -y
Thanks for this - I hadn't seen it yet in the docs I've been looking at.
No idea what it does, but it looks legit, so I'll run it!
Apt v3 comes with some quality-of-life stuff that apt has been direly missing for years, and one of those is apt sources that make sense to a human.
So the new apt source files have local key location, components, suites, and Uris.
The sources from the before-time just had a one-liner with a uri and some components.
Edit:also the modernize command makes a backup of the source files it touches.
I snapshot my machine, set it to go overnight, went to bed. Woke up, 24% done "Do you want to use the package maintainer's version?". Grr. Went smooth though.
Is it painful? I've upgraded several versions without difficulty. "third party" repositories are problematic so be sure you follow the guidelines about disabling them.
For the most part, it’s pretty painless. Unless you have a super complex setup you’ll be fine.
On a normal setup without leads or crazy customisation, it'll be a breeze 👍
I've found that dist upgrades themselves are fine, but it usually breaks something. Last time it was my janky WordPress installation which was using PHP 7.4. The wordpress version was up to date but it wouldn't use the installed 8.2 php and just broke. In the end I installed a fresh wordpress and copied the data over.
The fewer packages you have installed, the easier it is to upgrade. So if your stuff is containerized, upgrade should be mostly painless.
In my history at least, dist-upgrades have never themselves been a problem, not even when doing such things as a x86-to-x64 crossgrade upgrade (from Stretch to Buster, back in the time). The problem usually comes right after, with the first reboot, when something does not generate correctly in Grub or the new kernel's initramfs is lacking a specific module, or a given mariadb flag you were counting on is no longer added by default, or somesuch. So always have a rescue boot ready.
I've yolo'd every major upgrade from debian 8 to 13 without any backups of configs and survived... (dont do that though)
For most desktop systems where you're not dicking around with files in /etc, there is almost no pain ever
For servers, dealing with the "do you want to install the maintainers version of ____.conf", sucks.... trying to remember all the things i put in php.ini is a pain
Probably skill issue
Backup your data: the stuff you can't just reconstruct.
The go for it. Worst comes to worst: reconstruct the system and applications and reimport the data.
If you have capacity: do it in a VM first.
I updated NAS, VPS and Raspberry Pis not so long ago. All when smooth and without issue.
The official docs have everything, though not as well ordered and concise as they could be.
I’ve taken my server from 11 to 12 to 13. Only issue was 11->12 where backports caused some issue that I no longer remember the specifics of (never broke SSH link), so I just don’t fuck with backports anymore. You need to have your shit together for backports, from what I’ve gathered.
12->13 was abs smooth as butter. Extra 3rd party repos weren’t even an issue. One I had to leave “bookworm” because they didn’t have trixie entries; I found it had no trixie entry by looking at the repo itself - it just kept working no problem after the upgrade anyway.
And I have a “stretch” repo I took from 12 to 13 on another server (it’s mongoDB 4.4 for unifi, an abs shitshow of software those bozos cook up)
Anyway tldr docs are good narry a problem will occur.
This is why I've started running most services as containers inside of an LXC container in Proxmox
I migrated from Ubuntu to Debian, but my workloads were containerized. Went smoothly. But I had backups.
I recently upgraded my gaming pc from Bookworm to Trixie. It was fairly painless. Had to fiddle with some third party repos, but I anticipated that and read up on them beforehand.
I upgraded 50 boxes from 9 to 13 last week.
The two dovecot were the most work. Some guacd had trouble with file permissions and I had to manually install and enable a few php8.4 packages and manually apply powerdns db migration scripts.
Oh, powerdns renamed master/slave to primary/secondary, too.
I’ve done it twice so far (main server and a Raspberry Pi). Although I recall I had some package breakage with the main server (some changes in Podman that did not go well with the migration to pasta, the new rootless network stack), the process was mostly pain free and I could fix things remotely with SSH.
Make sure linux headers stay installed. Mine didn't for some reason and then zfs dkms didn't compile anymore. All I had to do was install it again, though, so the googling why it didn't compile was the hard part. The boot disk was luckily just ext.
Just be careful if you use Dovecot MDA, as it's configuration files format changed. There's a nice guide on dovecot's documentation covering this change.
I update my servers very promptly and have never had a problem with a version jump. Apt handles this well.
Annecdata here, but I didn't have any significant problems on like 5 servers. I recall there being one minor edge case, but I don't remember what it was (sorry). But other than that it was really easy. Even my nvidia drivers continued to work (for cuda, not GUI), which was really surprising. ZFS, docker, ssh, nfs, etc. all continued to work without any problems.
If you want to do a test run, create a 12 VM and install your same package list, then upgrade it and see what happens. That could take as little as an hour to do, but more likely a few hours if you want to really take time to inspect everything after the upgrade.
I'll probably follow the official documentation
I just apt update, apt upgrade, modify my apt sources to point at the new distro, repeat. If something breaks, I'll go fix it.
I wouldn't anticipate problems, though.
The first sentence gives away, that this is not a technical, but a psychological question. I think most of us know this feeling of this kind of urge, I'd say plan ahead, backup then upgrade. Or -depending on your usecase- a clean install and rebuild satisfies the urge even better. :) (no offense, I did this myself multiple times)
My desktop is on its third major version upgrade. I don't pay attention to breaking changes, and somehow I've still been made aware of the few packages that require something. Those packages usually include some kind of easy step by step or a script to migrate.
It's really quite a breeze to upgrade Debian.
I remember it being none, i modified my app source to pount to the newer release codebame, then apt update && apt upgrade. I had everything as a container on my minipc and no extreem modifications to the base OS to make my upgrades (both software and hardware) as easier as possible.
I backed up my configs, made snapshots, and rebuilt each VM from scratch. If I forgot to copy a cron script, i pulled it from the snapshot. It took a full Saturday, but it was a chance to apply everything ive learned the last 3 years and improve some architecture decisions I'd made when i was first learning. With proxmox, you can build a VM that has the basic things you'll change on every machine (networking, docker, automatic updates, ssh keys, monitoring) and clone it for each server you need.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| LXC | Linux Containers |
| NAS | Network-Attached Storage |
| SSH | Secure Shell for remote terminal access |
| VPS | Virtual Private Server (opposed to shared hosting) |
| ZFS | Solaris/Linux filesystem focusing on data integrity |
[Thread #149 for this comm, first seen 30th Oct 2026, 13:20] [FAQ] [Full list] [Contact] [Source code]
all 33 comments