Debian rolling release

19 April – 5 May 2026

FreeBSD etc.

Until into well into 2021, I used FreeBSD as the operating system (OS) for my web and e‑mail server. One reason why I switched to Linux was just because I could. That was after freeing myself from the birthtime lock-in. The other reason was FreeBSD’s version upgrade policy.

A minor version is supported for one year and a few months, which is reasonable. But every time a new minor version was released, about three months later the previous one expired. My busy work and bad planning often resulted in feeling pressured to upgrade at short notice. I didn’t like that.

Ubuntu with its five-year LTS version (LTS = Long-Term Support) was a relief. I also used Debian, and eventually Alpine Linux became my OS of choice for the server. It has a rolling release model with fast and efficient upgrades. I never managed to get Alpine Linux working with a Desktop Environment (DE), which even for me as a command line lover, is a minimum requirement for a daily driver.

Arch Linux has rolling release too. But I never got to terms with it, neither for the server VPS (Virtual Private Server), nor with a DE.

Debian!

In August 2019, I said goodbye to Microsoft Windows for good, and made the bold step towards Linux. Should have done that earlier. Still glad about that decision every day. I started with Linux Mint 18.3 Sylvia, and in a gradual quest for lightness, I arrived at Bunsenlabs Boron, based on Debian 12 Bookworm.

I experimented with Bunsenlabs Carbon RC3 (Release Candidate 3), but I didn’t like it. That made me experiment with Fluxbox, and I finally managed to get that running on top of just Debian Linux.

Debian Trixie 13 was just out, but I wanted to get rid of forced major version upgrades, once and for all. I decided to start using Debian as a rolling release Linux. It is possible, though not recommended, because of the risk of inconsistencies, or late security fixes.

Sources

So I set the Debian 14 Forky repositories to be my source for updates and upgrades, but with Debian 13 Trixie as an alternative because I found that Veracrypt for Trixie required libfuse2t64, which wasn’t available in Forky. Not yet or not anymore, I don’t know.

By the way, “sources” here is not to be interpreted as in ‘source code’, so it doesn’t imply there is a need to compile anything. Source is more like origin here, a repository mirror, a place where you get things from, largely libraries and executables.

Traditionally, the sources for Debian are defined in
/etc/apt/sources.list In newer Debians, apt has a new keyword, so you can run
sudo apt modernize-sources This will back up sources.list to sources.list.bak, and create a new
/etc/apt/sources.list.d/debian.sources with the sources in a more modern format.

I changed the actual names Forky and Trixie to ‘testing’ (not Sid) and ‘stable’. So when in a few years Forky will be released, my laptops will automatically upgrade to Debian 15 Duke, with Debian 14 Trixie as a back-up. I use a Dutch mirror, and the standard American one, for the unlikely case either ever goes out of business. So this is what I have now:

# Modernized from /etc/apt/sources.list
Types: deb deb-src
URIs: http://ftp.nl.debian.org/debian http://deb.debian.org/debian
Suites: testing
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Modernized from /etc/apt/sources.list
Types: deb deb-src
URIs: http://security.debian.org/debian-security/
Suites: testing-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Modernized from /etc/apt/sources.list
Types: deb deb-src
URIs: http://ftp.nl.debian.org/debian http://deb.debian.org/debian/
Suites: testing-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

# Include also stable, needed for Veracrypt
Types: deb deb-src
URIs: http://ftp.nl.debian.org/debian http://deb.debian.org/debian/
Suites: stable
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Upgrading

I could have used unattended-upgrades. It was already installed, but I found it didn’t even work, producing some silly warning about Python and Go.

unattended-upgrade-shutdown[837]:
/usr/share/unattended-upgrades/unattended-upgrade-shutdown:250:
PyGIDeprecationWarning:
GLib.unix_signal_add is deprecated; use GLibUnix.signal_add instead

I don’t like that. Rather use my own simple script then, for the ages old and still viable Bourne shell, and start it via root’s crontab, @reboot and periodically. Looks like this:

#!/bin/sh

# Note: this script is intended to be run as root, usually from crontab
LOGFILE=/var/log/RH-auto-update-upgrade.log
export DEBIAN_FRONTEND=noninteractive

sh -c '
echo "Apt update, upgrade, autoremove; and timeshift"
date
echo
echo Update
apt-get update
echo
echo Upgrade
apt-get -y upgrade
echo
echo Autoremove
apt-get -y autoremove

echo
echo Timeshift
timeshift --check
' > $LOGFILE 2>&1

Addition 6 June 2026

Date of the change: 30 May 2026. Where I first had:
timeshift --create
I know have:
timeshift --check

That works well after in the config file
/etc/timeshift/timeshift.json
you set schedule_daily, schedule_weekly and schedule_monthly to the value "true" instead of "false".

That enables timeshift to arrange things such, that after a while there will always be some daily, weekly and monthly back-ups, instead of getting a timeshift snapshot at every reboot, which will often be too much. I tend to reboot my daily driver laptop (not my website and e-mail server) several times a day, because waking up from a suspend doesn’t always work well.

Instead of using the command line program timeshift and changing config settings with a text editor, you can also use the graphical timeshift-gtk if you prefer. Both require root rights, so prepend sudo.