2025 Is The Year of the Rolling Release Linux Desktop
About The Project
Just like every year before, 2025 is the year of the Linux desktop. With Kubernetes solidifying itself as the de facto platform for container deployment, and Valve’s Arch Linux based Steam Deck, Linux continues its dominance in corporate environments, and our personal lives. I believe an investment in learning the internals of Linux will pay dividends for career progression, and it’s also a lot of fun to use. There’s never been a better time to adopt Linux as your “daily driver” and 2025 is the year to do it!
Now the real question is do you want an Operating System, or do you want an adventure?
Allow me to sell you on the idea of rolling release distributions.
Rolling release distributions deliver the latest and greatest in packages and kernels at the risk of instability. However, viewing this risk as an “opportunity” changes the conversation. Rather than thinking “Oh no my OS is broken” think, “oh yes, now I get troubleshoot and learn!”.
After all, you learn more by doing than simply following along with some tutorial. Debugging sessions are time well spent and pay dividends on future problem triage if you make an active effort to document what you did along the way.
Now, how does one document debugging sessions? How about a blog?! Arch Cloud Labs acts as a CV, a repository for troubleshooting notes, and general braindump for things I’ve done over the past five years, and 2025 is a great time to start your own adventure dear reader!
Back to the point at hand, lets explore some common challenges and opportunities of rolling release distributions!
Exploring New Kernel Features
A common reason to use rolling release distributions are to have access to the latest features that packages have to offer. This also includes new features the Linux kernel has. However, if your kernel is unstable, it can be frustrating dealing with crashes when you’re trying to explore some kind of new features. Luckily, with `QEMU , it’s easy to bootup a Linux environment with a kernel of your choice prior to upgrading your host’s kernel.
Upon fetching and building a kernel, you can use qemu-system-$arch to boot a live environment. The code snippet below boots an x86_64 image with the kernel of your choice, accelerated by KVM and with all output displayed on the console. Without theenable-kvm, the kernel will still boot but at a significant performance decrease. If you can, you should always use -enable-kvm.
qemu-system-x86_64 -m 2G \
-kernel KERNEL_IMG_GOES_HERE \
-drive file=./test-hd.img,format=raw \
-nographic \
-enable-kvm
Equally as important as the kernel is the drive you’re booting with your live environment. Denoted as test-hd.img in the QEMU code snippet above, this is a Debbootstrapped-generated “hard drive” for experimentation with Linux kernels. Using Debootstrap, one can customize the packages to boot with your new kernel image. The steps below outline a fairly straightforward approach in creating a disk image for your test kernel environment.
$> sudo debootstrap --arch=amd64 stable rootfs http://deb.debian.org/debian/
$> sudo chroot rootfs
# shell commands executed in the chroot below
$> echo "debian-qemu-syzbot" > /etc/hostname
$> echo "127.0.0.1 localhost" > /etc/hosts
$> apt-get update -y
$> apt-get install -y vim tmux rsync openssh-server
With the root filesystem (rootfs) created, a QEMU disk image needs to be made to be booted with QEMU. This is easily accomplished with the following steps to create a raw disk image of 10 GB (allocated at once), create an EXT4 filesystem on the image, mount it, and finally copy over the rootfs structure.
$> qemu-img -f raw test-hd.img 10G
$> mkfs.ext4 test-hd.img
$> mkdir -p tmpdir
$> sudo mount test-hd.img ./tmpdir;
$> cd ./tmpdir;
$> sudo cp -a ../rootfs/* .
If all goes well and you execute the previously mentioned qemu command, you should be presented with a booted environment.
Booting from ROM..
[ 0.000000][ T0] Linux version 6.12.0-test (Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian)
[ 0.000000][ T0] Command line:
[ 0.000000][ T0] KERNEL supported cpus:
[ 0.000000][ T0] Intel GenuineIntel
[ 0.000000][ T0] AMD AuthenticAMD
[ 0.000000][ T0] BIOS-provided physical RAM map:
[ 0.000000][ T0] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000][ T0] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000][ T0] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000][ T0] BIOS-e820: [mem 0x0000000000100000-0x000000007ffdefff] usable
[ 0.000000][ T0] BIOS-e820: [mem 0x000000007ffdf000-0x000000007fffffff] reserved
[ 0.000000][ T0] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
[ 0.000000][ T0] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[ 0.000000][ T0] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ 0.000000][ T0] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000][ T0] printk: legacy bootconsole [earlyser0] enabled
....truncated....
The Debbootstrap steps shown above are for x86_64, but you can actually substitute them for other architectures should you so choose too do so. Additionally, QEMU has built-in ability to monitory memory usage and trace syscalls. I recommend browsing the man page to understand its full capabilities and how they might aid you in your Linux journey.
Recovering from Broken Packages
With a methodology for messing around with new kernel releases identified, let’s discuss broken packages.
Living in the rolling release world means you’ll occasionally have packages that no longer function as expected.
Sometimes it’s a shared object and other times a new bug emerges in a network utility! Within /var/cache/pacman/pkg numerous compressed files of currently installed packages are saved. This directory can be configured in /etc/pacman.conf
$> ls
7zip-24.09-3-x86_64.pkg.tar.zst
7zip-24.09-3-x86_64.pkg.tar.zst.sig
aalib-1.4rc5-18-x86_64.pkg.tar.zst
aalib-1.4rc5-18-x86_64.pkg.tar.zst.sig
aardvark-dns-1.13.1-1-x86_64.pkg.tar.zst
aardvark-dns-1.13.1-1-x86_64.pkg.tar.zst.sig
abseil-cpp-20240722.0-1-x86_64.pkg.tar.zst
abseil-cpp-20240722.0-1-x86_64.pkg.tar.zst.sig
acl-2.3.2-1-x86_64.pkg.tar.zst
acl-2.3.2-1-x86_64.pkg.tar.zst.sig
adobe-source-code-pro-fonts-2.042u+1.062i+1.026vf-2-any.pkg.tar.zst
adobe-source-code-pro-fonts-2.042u+1.062i+1.026vf-2-any.pkg.tar.zst.sig
adwaita-cursors-47.0-1-any.pkg.tar.zst
adwaita-cursors-47.0-1-any.pkg.tar.zst.sig
adwaita-icon-theme-47.0-1-any.pkg.tar.zst
adwaita-icon-theme-47.0-1-any.pkg.tar.zst.sig
adwaita-icon-theme-legacy-46.2-3-any.pkg.tar.zst
adwaita-icon-theme-legacy-46.2-3-any.pkg.tar.zst.sig
As a practical example, I’ll show how to downgrade Hugo, the markdown templating engine I use for Arch Cloud Labs. Hugo updates frequently, and sometimes deprecates layout functionality that I use on this site. Rather than update templates (which I don’t particular have an interest in doing), I simply can rollback the package with pacman -U.
➜ pkg ls | grep -i hugo
hugo-0.139.2-1-x86_64.pkg.tar.zst
hugo-0.139.2-1-x86_64.pkg.tar.zst.sig
hugo-0.139.3-1-x86_64.pkg.tar.zst
hugo-0.139.3-1-x86_64.pkg.tar.zst.sig
hugo-0.139.4-1-x86_64.pkg.tar.zst
hugo-0.139.4-1-x86_64.pkg.tar.zst.sig
hugo-0.139.5-1-x86_64.pkg.tar.zst
hugo-0.139.5-1-x86_64.pkg.tar.zst.sig
hugo-0.140.0-1-x86_64.pkg.tar.zst
hugo-0.140.0-1-x86_64.pkg.tar.zst.sig
hugo-0.140.1-1-x86_64.pkg.tar.zst
hugo-0.140.1-1-x86_64.pkg.tar.zst.sig
hugo-0.140.2-1-x86_64.pkg.tar.zst
hugo-0.140.2-1-x86_64.pkg.tar.zst.sig
➜ pkg sudo pacman -U hugo-0.139.2-1-x86_64.pkg.tar.zst
loading packages...
warning: downgrading package hugo (0.140.2-1 => 0.139.2-1)
resolving dependencies...
looking for conflicting packages...
Packages (1) hugo-0.139.2-1
Total Installed Size: 48.52 MiB
Net Upgrade Size: -0.70 MiB
:: Proceed with installation? [Y/n]
After rolling back to a stable version, you can ignore these specific packages from being updated further by modifying /etc/pacman.conf and adding a package to HoldPkg. Something worth noting is that the Kernel itself has long term support (LTS) releases and one can simply install that on their host OS to have a more stable experience while still benefiting from the latest in userland packages. While I demonstrated this on Arch Linux, the methodology is similar on other distributions. Consult the man page for the package manager in your distribution to find the equivalent commands for your distribution.
Getting Involved In The Community - Wikis & Packages
Rolling release distributions have a vibrant community of developers, system administrators, and enthusiastic end users who likely have encountered the same problems you have, and solved them. Both Gentoo and Arch have excellent wikis that outline everything from installation to package troubleshooting. Be sure to venture into these wikis and even associated forums to learn from others that have gone before you and stand on the shoulders of giants. Eventually you’ll be contributing to these resources and improving the knowledge within the community by helping others resolve issues.
Another great opportunity to contribute to these rolling release Linux distribution communities is by maintaining packages.
Adopting orphaned packages (packages that don’t currently lack a maintainer) is an excellent way to learn more about the process of developing, maintaining software released in Linux distributions, as well as working with community members when things go wrong.
Currently there are 11,215 orphaned packages just awaiting someone to adopt them and maintain them for the community.
Just another example of an opportunity to stretch those professional development muscles in the world of Arch Linux.
Beyond The Blog
Rolling release Linux desktops are all too often associated with instability, but that’s not necessarily true. Choosing Long Term Support (LTS) kernels and understanding how to debug, recover and restore packages make rolling release distributions a joy to use.
With a new year upon us many will seek to advance their careers by spending money on books, training courses, etc… While this is all well and good , there’s a lot that can be done for free with minimal equipment. I’ve blogged at length on how beneficial homelabbing has been to me, and I hope it has the same impact to you. Now go forth and install Arch, Gentoo, Linux from Scratch or something else and start your 2025 off on an adventure of Linux internals!
Thank you for reading, here’s to a healthy and prosperous 2025!