diff options
| author | uvok cheetah | 2026-02-21 17:01:51 +0100 |
|---|---|---|
| committer | uvok cheetah | 2026-02-21 17:01:51 +0100 |
| commit | b35b162f6a47f08b3abe1c97fbe219c9731bd9e5 (patch) | |
| tree | a1802b8b5706e38d43bd3124cf14cada5c4b2781 | |
| parent | a5e8846b7f0378975aca4cec3bdbba78dfd478ea (diff) | |
Add debian post
| -rw-r--r-- | _posts/2026-02-21-updating-my-servers-to-trixie.md | 45 |
1 files changed, 45 insertions, 0 deletions
diff --git a/_posts/2026-02-21-updating-my-servers-to-trixie.md b/_posts/2026-02-21-updating-my-servers-to-trixie.md new file mode 100644 index 0000000..e2853c2 --- /dev/null +++ b/_posts/2026-02-21-updating-my-servers-to-trixie.md @@ -0,0 +1,45 @@ +--- +layout: post +title: Updating my servers to Trixie +date: 2026-02-21 16:06 +0100 +--- + +It's about time. +Debian Trixie has been released in August 2025. I finally got around +to gather my motivation to execute the update. + +I have like 5 VPS, all running Debian. Still running Bookworm until recently. +So over the past two weeks, I upgraded the servers step by step, going with +the "least problematic" servers first. (Gut feeling). + +Turns out, my intuition was relatively right. +What confused me extremely is that the upgrade notes appear to have moved to +https://www.debian.org/releases/trixie/release-notes/upgrading.html. +Previously, iirc, it was always a chapter in the Debian Handbook. + +So, the pain points of Debian updates, for me, always is the config file +updates. Usually, I want to keep my changes, but use some of the +package maintainers changes. It's frustrating for me that Debian asks me for +a decision in the middle of an upgrade. I'd actually like an option, +"just continue with the upgrade, keeping my config, for now". Which +could be problematic for major upgrades with option deprecations I guess? +There probably is even some option for this (dpkg-reconfigure debconf?), +and I just haven't RTFM. As it happened in the past. + +The actual **major** pain point was indeed the last server. +I've been accumulating various questionable packages on this one, +for some reason, I installed ffmpeg in the past, which means there were +lot of X-related libraries pulled in. During the cleanup, I unwisely +must've fired off some purge command[1]… Which I acknowledged without +looking properly. The result was that my entire /etc/letsencrypt +directory was erased, as I used the distro-supplied certbot in the past. +I just removed the package at some point and installed certbot via pip. +So Debian/dpkg still thought that directory needed cleanup. Ooops. +So I spent yesterday evening, extremely frustrated, fiddling with the +nginx config manually, adding temporary fake certs/keys, so that nginx +would start at all, so that certbot could work, and I could re-add +the certificates again. + +Lesson learned: Read the fucking output before you hit enter. + +[1]: Via ansible, nonetheless. |
