Transactional updates on OpenSUSE Tumbleweed

It’s possible to use transactional or atomic updates on OpenSUSE Tumbleweed and leveraging the snapshot capabilities of btrfs. It’s actually quite simple; all you need to do is to install the command using zipper.

Prerequisites: the filesystem must be btrfs.
sudo zypper in transactional-update

This will install the command. Next you want to set up some, to prevent some potential issues.

# this systemd service is required to create RPM dirs in /var as TU does not mount /var in the new snapshot to maintain atomicity.
systemctl enable --now create-dirs-from-rpmdb.service

That’s basically it. Now if you run the command:

sudo transactional-update

The system will create a new snapshot, check for updates, install updates on that snapshot and set that snapshot to boot. If there are no updates, the snapshot is removed again.

Keep in mind, and this is important: any changes you make to the root filesystem will be gone after you reboot into the new snapshot.

This is expected behavior, but it does mean if you want or need to make changes you need to make sure you reboot first.

Why would you want this? If you need to apply a big update and you don’t want it to interrupt your work or avoid processes being restarted, you can apply the update on a new snapshot without it interfering or making changes in any way on the running system.

Is it necessary? Absolutely not. It is just another tool in the toolbox. It offers some of the advantages (atomic updates) of an immutable distribution, without having to have an immutable (read-only) filesystem.

OpenSUSE Tumbleweed, 6 months in

Well, here we are, 6 months after installing OpenSUSE Tumbleweed and still no urge to change. The only change I am longing for is the update to KDE Plasma 6, which should be coming soon now that it has officially been released.

Since there are basically no updates since my last post in December, there isn’t much to say. I did however made some changes. A couple of weeks ago, my GTX1080 decided to shit itself such that it triggers the short protection in the power supply so that’s out. Bit of a pain since everything is water cooled. I ended up replacing it with a Sapphire R9 390 Nitro which is an AMD based card. Raw speed is about half of that of the GTX1080, but at 50 euros it was cheap and being AMD means no more Nvidia issues on Linux as limited as they were for me. Main issue for me was that I had to manually recreate the initrd whenever a new driver version was released to make it work.

Routing of the watercooling soft tubing looks like crap now, but hey, its working again and at least I can use my machine again.

Changing from Nvidia to AMD was a bit of a pain as I had to remove all Nvidia related packages and I had to manually set the correct kernel parameters to make it work. After that it was painless and working just fine. Drivers are part of the kernel, so no more issues there. Test benchmarks suits show lower fps as to be expected, but also smoother and less jerky graphics. I don’t game that much, so I guess I’ll be fine for now. Would love me some 6700XT or something.

Tumbleweed keeps on rocking.

OpenSUSE: 4 months in

Maybe it is time for a little update, even if there is not much to say. After 4 months of running OpenSUSE Tumbleweed, I can honestly say I have not had a single moment where I’d thought I should maybe look for another distribution because XYZ is getting too annoying.

Of course it does have some annoyances. Some are with me, like running systemd-boot while it is not officially ready for primetime yet. Others are with OpenSUSE or my setup, like sometimes an update will bork the system and I have to do a snapper rollback. Fortunately, OpenSUSE makes this a 2 minute job and so far, rolling back the update and installing it again is all that is needed to fix the system and the update.

Other than that, I can’t even really think of anything. It just works. It runs, it runs fast, I have all the latest packages as you can expect using a rolling release and I just get to enjoy using my computer and play around with it. Both my desktop as well as my laptop.

It’s nice to be able to use the computers without this itch or little doubt that makes one go and look for greener pastures.

I’m still impressed, really impressed with OpenSUSE. More should be using it, it really is that good. And a bit of counterweight to the giants like Canonical and Redhat would be nice too.

Have a good one.

systemd-boot on OpenSUSE

I am weird sometimes, I know. Ever since I used Pop!OS, which uses systemd-boot as default boot manager, I have fallen in love with it. The simplicity and speed of systemd-boot versus the complexity and bulk of GRUB2 just won me over.

Mind you, GRUB2 is very good at what it does. It’s just that I don’t need all it does. All I need is to boot my machine, nothing more, nothing less. My laptop, on which I am typing this, only has OpenSUSE installed. No dual boot, nothing. My desktop boots OpenSUSE and FreeBSD at the moment, but they do so from seperate disks with their own bootloader. Nice and simple.

Neither need the features of GRUB2.

That said, changing the bootloader is tricky. It’d be nice if OpenSUSE would let you pick systemd-boot at install, so you don’t have to muck with it. However, since end of September, OpenSUSE officially supports systemd-boot.

So, I just had to have it, starting with my laptop.


Note: I do not use secureboot. Do not blindly follow this tutorial if you are using secure boot: it will break your system. You can do it, but it requires more steps then I will outline here.

First, check if /usr/lib/bootloader/systemd-boot exists. If it does, you’re good.

Remove all OpenSUSE entries from the EFI boot menu, and all others you do not need:

# efibootmgr --delete --label opensuse-secureboot

Do this for each entry you do not need or want. You can see what entries there are by just typinge efibootmgr without any options.

Next we want to update the configuration, so it knows we are going to use systemd-boot.

# vi /etc/sysconfig/bootloader 

Change from (probably) LOADER_TYPE="grub2-efi" to LOADER_TYPE="systemd-boot"

Install the systemd-boot utils to add support for snapshots. We are running OpenSUSE, we do want support for our automatic btrfs snapper snapshots.

# zypper in sdbootutil-snapper sdbootutil-rpm-scriptlets

If zypper complains that it needs to remove GRUB2 to do this, confirm by choosing the solution that will do so. It will both add all the files required for systemd-boot to function and remove all grub2 related files that you will not be using anymore.

Then we want to install our kernels, including snapshots so we can actually boot as we do not have a bootmanager installed right now!

# sdbootutil install
# sdbootutil add-all-kernels

Now we’re done. Systemd-boot is installed, GRUB2 is removed and we can reboot our system and enjoy a fast and less bloated setup. If you want to get to the boot menu to boot from a snapshot, just hold the spacebar while booting and it will pop up.

Issues / challenges

  • Initrd / ramdisk does not get updated after installation / update of kernel drivers, ie NVIDIA graphics drivers. This can be solved by manually generating a new initrd file and copying it to the appropiate location, replacing the old one but should really be done automatically. Bug is filed.

Interesting (or: first tiling windows manager experience)

The other night, I was playing around watching YouTube videos and was watching this one video from Brodie Robertson on how he was now using Hyprland as his daily driver. Usually, I just zone out to other tasks when the topic gets to a tiling window manager, as it is not for me: I have a ultrawide screen on my desktop, with a 3440×1440 resolution and trust me, you do not want to run console fullscreen.

But, as I was sitting with my laptop in my lap which obviously has a more common resolution display, I thought what the heck. Let’s see if OpenSUSE offers Hyprland in its repos and see what it’s all about.

Well, it was in the repos and to my suprise it didn’t suck. I mean, I still prefer a normal desktop for desktop tasks, but for managing my network and homelab from my laptop, where I pretty much live in (multiple) terminal sessions and a some of browser tabs on a different workspace, this works. And pretty good too, with great focus on what you need to achieve.

I like, again to my suprise

On a sidenote: does anyone know how to use tiling window manager on a ultrawide screen, where you do not want a single application to go fullscreen, but remain restricted to just part of the screen – let’s say a third of the screen. Or top/bottom half vertically and a third horizontally. Having essentially two screens side by side in a single panel is a dream from a screen real estate point of view, but its a nightmare for using a tiling window manager imo, especially if you take care organizing your windows.

No more Windows. FreeBSD instead.

No, I did not stop running OpenSUSE Tumbleweed. That’s still my daily driver. I did however wipe my Windows drive and installed FreeBSD instead. I have used FreeBSD quite a lot way back when, and since I hadn’t actually booted into Windows for months, I just decided to install FreeBSD on that drive so I could play with it again after I saw KDE is actively supporting FreeBSD for the desktop.

Installing FreeBSD is actually pretty straight forward. It uses an ncurses installer that was common on BSD and Linux alike 25 years ago, but today it’s basically only seen on FreeBSD and Slackware Linux. You can however use that GUI over SSH, so pretty convenient for server installs.

After answering a few simple questions like locale, disk and services you’re essentially done and prompted to reboot. Then comes the scare for the modern Linux user: FreeBSD boots into a command prompt. No GUI. Not installed.

Oops. 🙂

Seriously, not that complicated either. It’s just that you have consciously decide you want it, and what you want. That’s not a bad thing. Arch Linux users will understand.

To use KDE on FreeBSD, we need to install some things and configure a few others. To install:

pkg install --quiet --yes kde5 plasma5-sddm-kcm sddm xorg

If you are running an nvidia graphics card, do yourself a favor and also install:

pkg install --quiet --yes nvidia-xconfig

Then run the following commands to configure (as root):

sysrc dbus_enable="YES" && service dbus start
sysrc sddm_enable="YES" && service sddm start

The SDDM login screen should start and you should be able to login to KDE. Do make sure you choose X11 for session, not Wayland as Wayland is extremely buggy on FreeBSD at best.

If no GUI, try to reboot first and if that doesn’t work, check if you have an xorg.conf under /usr/local/etc/X11 as this should have been generated by the nvidia-xconfig utility, but without xorg config nothing will happen.

The end to distro-hopping?

Since I have moved to running Linux basically full time, I have ran Pop!OS, Fedora, Nobara, back to Fedora KDE Spin and now OpenSUSE Tumbleweed. All of them are good distributions and none have any real deal-breakers for me not to want to use them.

The fact that I really, really like Tumbleweed was not a given. Quite the contrary. OpenSUSE does it’s own thing, so it is a bit of a learning curve if you are used to Debian-based or RedHat-based distributions. It is one of the oldest distributions still operating today, which puts it in the same company as Debian and Slackware. The latter actually being the initial origins for (then) SUSE Linux.

But I digress. My experience with SUSE in the past (=20 odd years ago) was less than favorable to the point that I abandoned it and never really looked at it again until now. Installation was painless and it let you choose your desired desktop environment as part of the installation procedure. I run KDE, which is the first option and let it do its thing.

After install I was back in business. Mind you: I have /home on a seperate disk, so all I have to do when reinstalling or using a new distribution is to make sure that drive is mounted on /home and I have all my (program) settings back and my desktop just looks the same as before. Saves me time to set everything up the way I want again and no data loss when doing a reinstall.

Some observations after installing OpenSUSE Tumbleweed:

  • Using OpenSUSE means using BTRFS right: proper subvolumes upon install, snapper configured out of the box to create snapshots when installing software and updates and grub configured to be able to boot from previously created snapshots so you can rollback if something happens to go wrong. No more worried about effing up your system
  • YaST2 is a very useful tool. It let me configure and add my iscsi targets in 2 minutes tops and it connects automatically on boot again, whereas most other distributions make that a painful, manual task that requires workarounds to mount your drives after a reboot. I don’t really need a GUI tool to configure my systems, but this tool lets you configure all aspects of the system and sometimes it is just faster doing it once in the GUI than to do it manually.
    Note: the original YaST is the reason I quite SUSE years ago and never came back. Different story.
  • It has a huge repository of programs, including non-FOSS if you add the packman repos. And if you install opi (openSUSE Package Installer) you have the entire OBS (OpenBuild System) at your finger tips, including user repositories. Basically you have the OpenSUSE equivalent of Arch’s AUR.
  • Installation of proprietary drivers and codecs is easy and painless, as with most distributions. That said, I think OpenSUSE is the only distro where the Nvidia drivers come straight from a repo at Nvidia.
  • It’s (Tumbleweed) a rolling distribution, so always the latest software but it is better tested than something like Arch. This means less issues are likely to arise.

Some inconveniences I ran into:

  • Both my laptop and desktop were unable to load Wayland and had to use Xorg. This is not a big thing. This was caused by a SDDM bug where the SHELL variable got messed up if you use the fish shell as you login shell. This has been fixed by the KDE team in ’21/’22, but the fix was never backported to OpenSUSE by the OpenSUSE team. Workaround was to change the login shell to standard bash, and just tell the terminal app to start with the fish shell. Now I can run Wayland on my laptop, while still using Xorg on my desktop as it work just works better with Nvidia graphics. But it will run Wayland if I want to.

Other things I did after installing Tumbleweed are not OpenSUSE specific things, but more generic Linux optimizations I have made.

  • I used tuned with tuned-adm to select and set an appropriate tuning profile for my systems.
  • I have set up a couple scripts for my laptop to switch profiles and CPU modes depending on if the laptop is running on AC power, or battery.

When running on AC power:

# Set CPU governor to powersave
if [ -e /usr/bin/cpupower ]; then
	sudo cpupower frequency-set --governor performance
    sudo tuned-adm profile latency-performance
    echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    sudo tuned-adm profile latency-performance

When running on battery power:

# Set CPU governor to powersave
if [ -e /usr/bin/cpupower ]; then
	sudo cpupower frequency-set --governor powersave
	sudo tuned-adm profile powersave
	echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
	sudo tuned-adm profile powersave

These are set in KDE settings under power management, see screenshot:

  • On the desktop, I just set the tuned profile to latency-performance using tuned-adm. This is a profile that aims to prioritize latency over throughput, which is great for desktop use with a GUI.
  • I also set some sysctl parameters as outlined in another post.

Like I said, these are not Tumbleweed or OpenSUSE specific optimizations or even necessary, but it is how I prefer to set up my systems. I feel it helps me to squeeze out the most performance out of my systems, and in the case of the laptop, preserve battery life when needed.

When all is said and done, I really like OpenSUSE Tumbleweed. I like the bootable snapshots. I like having the latest versions of different software without having to wait for a next release. I like the tools provided to admin the system. It’s a good’un. I think I’ll keep it. Then again, I said that of Fedora. And Nobara. But I do think it is true this time.

Running redundant AdGuard@Home DNS servers on Synology

This is a quick post on how to run multiple instances of AdGuard@Home on a single Synology host using Docker.

Problem: you cannot easily, using Docker, run multiple instances of the same program - or different program - while listening on the same port.

Solution: do not use host or bridge networking, but put the container on the same network as the host using macvlan.

To achieve this, we need to do the following:


  1. Find the name of the network interface your Synology is using to connect to the network you want your Docker containers to be running on. This can be for instance eth0 for a single interface, or bond0 for when you use channel bonding. You can find this under Control Panel > Network > Network interface. In my case, this is bond0 which is what I will use in the examples below.

Configuring the interface

Now we have to configure the interface Docker can use. We do this by adding a bridge on top of the existing physical interface you use on your network.

  1. ip link add macvlan-br0 link bond0 type macvlan mode bridge
    This adds a bridge device on top of the physical interface with the name macvlan-br0
  2. ip addr add dev macvlan-br0
    This adds an IP address on the bridge device so the host has an IP address in the range will give to Docker
  3. ip link set macvlan-br0 up
    This will activate the virtual bridge device
  4. ip route add dev macvlan-br0
    This will add a route to the Docker network so it can be reached

You will have to put this in a script you can run at boot of your Synology device, as these settings will not retain over a reboot as we have to make them on the commandline and cannot make them in the Synology DSM.

# Set timeout to wait host network is up and running
sleep 60
# Recreate the host macvlan bridge
ip link add macvlan-br0 link bond0 type macvlan mode bridge
ip addr add dev macvlan-br0
ip link set macvlan-br0 up
ip route add dev macvlan-br0


Now that we have set up the host, we can continue creating a new network in Docker that can be used by our containers. To do this, type:

docker network create -d macvlan \
  --subnet= \
  --gateway= \
  --ip-range= \
  --aux-address 'host=' \
  -o parent=bond0 macvlan-br0

This will create a network in Docker on the subnet of your network in a dedicated range of IP addresses using your physical interface and virtual bridge device.

Do make sure the IP range you specify for Docker is not part of your DHCP scope, if you are also running DHCP or you will get IP conflicts. Docker does not use DHCP, and instead will just hand out IP addresses from this range in order to each container.

Now you can create your Docker containers as usual and configure them to use this network, instead of the standard host or bridge networks Docker uses by default. You can also assign this network to existing containers if you want.

Install container

To install AdGuard@Home on your Synology, open Docker, go to “Registry” and search for “adguard”

Double click to download the latest version.

When it is done downloading, you can go to the “Container” section, and hit create. A window will popup where you can select your freshly downloaded image.

Select it and click next to follow the instructions. Configure what you want, but make sure to select the macvlan network when you get to the screen to pick the network.

Congratulations! Test your new container that is now present on your local network.

Important note: if you are running the DNS server on your Synology for your local network, and you want to keep using that, make sure you configure your AdGuard as DNS for your clients, and add the following to your AdGuard DNS configuration under upstream servers:


This will instruct AdGuard to use the IP address you added to your bridge device at the beginning as the source for resolving domain.local hosts. 

The complete upstream section for me looks something like (I use Cloudfare DNS for internet, and Synology DNS for local addresses):

Do not use the real IP address of your Synology host; this is not reachable for Docker and will not work! Use the bridge device address instead.

New laptop, new Linux distro

I finally got fed up with my Macbook Pro as a Linux laptop. It was a 2012 model, no longer supported by Apple. But the quirky implementation of Nvidia discrete graphics on the Macbook wasn’t the best for reliable Linux operation. Mind you, Nvidia is always a bit of a challenge, but Apple being Apple certainly does not help in that regard.

Anyway, I am currently sporting a Lenovo T460 from 2016. Still not really a new laptop, but fast enough for Linux and most things I do with it. It has a i5 6300U from the Skylake family of processors, 8GB memory (for now, supports up to 32GB) and a 1TB SSD. For graphics it used the Intel 520

For the OS, I am now running Nobara Linux 37. This is a Fedora derivative with tweaks for performance and gaming. While I am not a gamer, the improvements do help making it a snappy experience. Contrary to my desktop computer, I am now using the KDE version.

Current Nobara 37 desktop on my laptop

Getting used to KDE after having used Gnome for a long time can cause some frustrations. Not because what you want isn’t possible (typically quite the opposite) but because you cannot find it or know where to look. Where Gnome is has more of a ‘our way or the highway’ mentality and is more concerned with their vision than how the users are perceiving or using it, KDE is all about customization and providing the user with the ultimate choice. If you can dream it, KDE can probably be configured to do it. And that can be a bit overwhelming. It has so many options, sometimes you just have no idea where to look to achieve something.

So far, I am very happy. Both with the laptop, as well as Nobara Linux and KDE. I may have to switch my desktop to the same configuration soon… Now that I am getting the hang of KDE again, I remember why it was my default and go to desktop environment in the past, and the quirks and annoyances from Gnome seem to be more and more stuff I don’t really want to deal with no more. You shouldn’t have to hack together your environment around the limitations imposed by its maintainers. It’s Linux, not Windows or MacOS…

Upgraded laptop to Fedora 36

Fedora 36 with a few extension to make it the way I like it.

Upgrade was smooth as is to be expected with Fedora and everything is running smooth. Libadwaita is not as bad as I thought it to be, and it actually looks really good. I wish they had taken the time and effort to create a GTK3 theme for applications that are not libadwaita aware, but fortunately someone else did. It does look horribly inconsistent without. Bad move.

Other than this, I do not miss the theming at the moment now that I added some transparency in the top bar and dock.