There is a lot of excitement around atomic updates, touting the stability, reliability and the option to hop back to a previous version if the update is somehow broken. I have not been able to experience a failed update on any of my Bazzite machines but that is the story. I love the concept. It takes all the fiddling for a non-tech user out of the equation, really producing a more product like feel to the Linux experience. This is very likely the direction that commercial, home user, Linux will be that no one will care how it is powered, the architecture that supports it, etc. All they care about is that they can sit down, write their paper, browse the web and play games and just use their computer.
Bottom Line Up Front: Although not perfect (but what is?), the automatic update mechanism that I can set in in KDE Plasma to install the system updates at reboot just might be the best of both worlds between atomic and traditional updates when paired with the openSUSE BTRFS + Snapper COW system. I not only get the fun and flexibility of traditional Linux but I also get something like the update reliability of Atomic updates. This is now my preferred method for being a better sysadmin to my machines.
Why Atomic
In theory, I love the “Atomic” update delivery mechanism. It makes a lot of sense. Letting the operating system work for you, pulling down the updated software in the background while you are happily working away is a great way to operate. It is the time optimizer for you the user. Let the operating system perform all the tedious requirements invisible to the user. It downloads then hang onto the fresh software until you are at a point that you can reboot jump into your new beautifully refreshed operating system.
The great thing about this is when doing updates, you are not left with a machine in a dirty state where you are running processes, in memory that need to be restarted to take advantage of the updated libraries. This can often create an unstable situation as you are working, not always but it certainly is an issue which is why it is of great importance to reboot after doing updates. Atomic updates resolves this for you.
Why Not (Fully) Atomic
Installing new software with the transactional update mechanism requires reboot to start using it. While the mitigation for this is to use Flatpak and Homebrew software distribution channels, that doesn’t cover all possible use cases. With transactional updates, the package is layered on top of the base image. Layered packages persist across normal image updates as they are reapplied on top of the new image. However, this can and often does cause problems: dependency conflicts, slower updates, or the next core system image update failing until you remove the layered packages, using rpm-ostree uninstall.
Bazzite’s official stance is that they allow but strongly discourage using transactional updates and only recommend it for applications that cannot be run as a Flatpak, Distrobox conainer or Homebrew.
openSUSE MicroOS use the transacitonal-update with BTRFS snapshots to install system packages. Changes are applied on reboot here too but conflicts can arise in the same way they do with the Bluefin range of Linux OS options. One benefit of the openSUSE way is that a failed update will simply roll you back to the previous working snapshot.
These rigid software deployments do not work for everyone. Not everyone is good with a Distrobox for every little thing and for some use cases, this is considerably more bloated. Some people like a lean distribution but even those that tout the Atomic distribution as the way forward would likely agree with that argument.
In all reality the use of Flatpak, Homebrew and Distrobox for your applications is really a fine method that is likely good for most users at varoius degrees of Linux and operating system tweaking skill levels. These are all fun tools but like with any tool, people do have their favorite methods.
Happy Middle Ground
The solution, as I see it, that meets the important check-marks for the day-to-day life on my Linux machine is to utilize KDE Plasma’s integrated update mechanism that is built around PackageKit. Set specifically, it provides that atomic update-like mechanism but also provides the flexibility of the traditional Linux distribution where you can add and remove software at will. This method, by which you get the best of both worlds.
Within KDE Plasma’s system settings, there are a few options for you to adjust this mechanism specific your your particular tastes. Software updates can be set to Manual or Automatic, and what Automatic means in this case is that they will be downloaded as soon as they become available.
The frequency of the updates can be set to Daily, weekly or monthly. I do think that there is room for some fine tuning adjustments and as it appears, there is already discussion about this, initiated by my good friend Dale on the KDE community forums.
https://discuss.kde.org/t/ability-to-set-time-with-automatic-updates/48904/10
Here is the neat part, PackageKit allows you to select when you have the updates applied, after rebooting or immediately. After rebooting is interestingly compelling because you get a modern, user-friendly GUI experience. This is common to see on more commercial Linux systems and also what appears to be the default in Fedora. I know that for me personally, I have done updates the traditional way and failed to reboot leaving my system in a strange spot that has “bit” me later. Where openSUSE Tumbleweed really shines here is not only do you get the maximum stability feature of the “updates at reboot” but also with good safety characteristics thanks to BTRFS COW + offline application + Snapper snapshots, without forcing the full immutability model. So, essentially, I am getting that traditional desktop traditional desktop experience with maximum software flexibility along with the safeguards of applying updates at reboot and a snapshot that I can roll back into at boot time if there is a catastrophic update failure.
Using this mechanism, I absolutely get everything I want from an Atomic update mechanism along with the maximum flexibility that a traditional Linux system has given me from the start. Another case where openSUSE Tumbleweed allows me to have my cake and eat it too.
How the “After Reboot” Mechanism Actually Works
To understand this process here is how it works, specifically on openSUSE Tumbleweed, based on my limited understanding. There may be some errors here and I welcome the corrections. It should also be noted that the software technology does change as it is further refined so the further we get away from this, treat this process as more suspect.
Preparation (while system is running)
Discover along with PackageKit (zypp backend on openSUSE) checks repositories, resolves dependencies, and downloads packages. For Tumbleweed this effectively does a dup-style system upgrade under the hood. The difference is, it stages everything in /var/lib/PackageKit/ (or similar) and creates a marker/symlink at /system-update pointing to the prepared update. So, it goes through the process of downloading in its entirety first. This can be gigabytes of data, depending on the update size so it is imperative you have the available space on your storage medium to allow for this.
Upon reboot
Systemd sees the /system-update marker and boots into the special system-update.target instead of the normal graphical/multi-user target. A service, packagekit-offline-update.service, runs /usr/libexec/pk-offline-update. This performs the actual package installation/upgrade using the same zypp/libzypp engine that the zypper command uses. You often get a Plymouth progress screen during this phase.
Once done, the marker is cleaned up and the system continues with a reboot into the updated state. You will see the GRUB or Systemd boot menu and there will be a new read only snapshot in your list of the previous system from which you performed that update. You are presented with a clean, updated system with all the latest, packages with that fresh, new distribution smell to it.
Why “after rebooting” is recommended for maximum stability
Updates happen with far fewer processes running, minimizing risks such as locked files, in-use libraries, or partial states if something interrupts the process. Zypper is involved with this process, but indirectly. PackageKit on openSUSE uses the PackageKit-backend-zypp, so the heavy lifting (dependency resolution, transaction handling, RPM operations) goes through libzypp, the same core library that the zypper command-line tool uses. It’s not calling the zypper binary directly in most cases, but it’s the same engine.
Comparison to Full Transactional Updates
This is not the same as transactional-update (used by openSUSE MicroOS, Aeon, or the “Transactional Server” role). The transactional-update creates a new BTRFS snapshot, applies changes to that snapshot (while the running system stays on the old one), then switches the default boot entry on success. Very atomic and rollback-friendly by design.
The Plasma/PackageKit offline method is a hybrid: safer than pure live updates, thanks to the minimal boot environment + BTRFS COW (Copy On Write), but not as isolated as a full new-snapshot transactional update.
How it’s been Going
After a few weeks of testing using five different machines, here is the straight, unfiltered experience from using it. The short of it is, it’s good and I am going to stick with it, but this isn’t perfect and doesn’t work for all of my use cases.
My main machine, a Framework Laptop 13 with the Intel Core Ultra 7 155H, this is a near perfect experience. I started out by having the updates performed automatically, daily and after rebooting. This was fine except that it appeared that with multiple repositories that I have configured. I would have the updates appear more than once in a day and this annoyed me. The update process was distracting. The solution I am sticking with now is to do the update frequency weekly instead of daily. I am going to keep the setting for the system updates to be applied after rebooting. This is by far the best mechanism for this machine I rely on for my daily work.
Commodore 64x, an AMD Ryzen 7 5700G, this too will be set weekly to remove any of the update distraction that I would get from high frequency of Tumbleweed updates. Like the Framework Laptop, I am also keeping this on a weekly frequency. The daily was causing more confusion than anything else. I have not had any update issues on this machine since using this mechanism.
The three other machines I have been testing successfully, Lenovo Thinkpad P16s and two other Framework Laptop 13s all had similar experiences. I started out with daily but moved to weekly after a few days of it due to the almost annoying rate of notifications.
The one machine that will not get the automatic treatment, my Atari VCS, will not use this mechanism and it is not because I there is something inherently wrong with PackageKit but rather this system itself. The problem with this machine is that I am not able to modify the boot order so I have to interrupt the boot process twice in order to get back to the Plasma Desktop Environment. This just isn’t ideal.
Updates are not always automatic
Perhaps more testing is needed here but updates are just not always automatic. In both my daily and weekly testing, Discover will not do the updates in the background automatically, every time. This is not a huge deal, sometimes I just have to tell it to proceed to get them done and they will still get it done. Also, sometimes I am not always notified in the system tray that I can reboot into my updates. Also, not a big deal, I will be notified when I go to reboot, or if I select to put the system to sleep or something like that. The trouble there is, I don’t always use the menu for that function so I may not see it.
Ultimately, these are small potato issues, they are not a show stopper and may only be an issue because I am looking for a problem. For a regular user, this would be completely ignored. The fact is, the updates are happening and I am given the option to update on reboot but since I am seeking this out, I may not be experiencing the expected behavior as intended.
Verdict
For most openSUSE Tumbleweed desktop deployments, this is probably the best, most reliable implementation for someone that wants the benefits of rolling, traditional package management but without the need to go into terminal to do updates. One caveat is that you do need to ensure that you have set repository priority for Pacman higher than the official Tumbleweed repo to ensure you don’t get any update weirdness. I believe that is now default but check your repository listing accordingly:
zypper lr -d
You should see under priority of packman to be 70 instead of the default 99
The one machine that I am not doing this “hybrid atomic” update mechanism is the Atari VCS because of the limitations of boot order that I am stuck with on it. If I were using Tumbleweed on a gaming handheld, like a SteamDeck or One X Player, I would absolutely use this mechanism so that I don’t have to mess in the terminal on those machines. I would also add that comparing this experience to other “Atomic update” machines, I am much happier with this sort of flexibility.
I am confident that automatic updates should work on openSUSE Leap but I didn’t test it there, so your results may vary.
I want to point out one more small thing. I am comparing how this behavior is against an idealistic update mechanism that I have yet to experience in reality. If I compare this to the tradition terminal updates that I have been doing in Linux for the last 20+ years or the completely graphical method that I have been doing in Windows, this is still by far a superior system. Bazzite is great as it is purely Atomic in the updated but leaves me a bit disappointed in satisfying my need to tinker. I don’t want to say that this hybrid atomic update mechanism is perfect, not at all, but it is so nearly perfect and some minor tweaks could achieve that rank.
Final Thoughts
These are really fun times to be using openSUSE Tumbleweed. For the last 9 years it’s been my main way to run a Linux operating system and it is only getting better and better. The recent developments in Discover, PackageKit, and applying updates after a reboot makes this the perfect operating system that I would now feel comfortable deploying to any use. This has moved openSUSE Tumbleweed from being the OS for only tech savoy people to the OS for anyone, once a few settings are tweaked.
I have a couple servers I run that also act as hypervisors. I did not do a complete round of testing on these machines to know for sure if this would be best or not. I need some more time to see how they work in comparison to how it works on a pure desktop / laptop system. I can see some benefits but that was outside of the scope of this article. More to come on that in the not-so-near future.
On my main machines I use daily, specifically the Framework Laptop 13 and C64x, I will keep these on weekly automatic, apply when rebooting updates. This will afford me the best of all the worlds of updates. I can invoke at anytime the update in the terminal, sudo zypper dup, and use the computer as I have, but now I have another, automatic mechanism, that doesn’t work against me, but rather works with me. Sometimes, I get sloppy about updates, and I need that automation, now I have a mechanism I can trust but by chance it doesn’t work as expected, I can fall back to the terminal. This is such a beautiful arrangement and I am extremely grateful to each and every one of those fantastic developers and maintainers that have made this possible.
References
https://github.com/PackageKit/PackageKit/blob/main/docs/offline-updates.txt
https://discuss.kde.org/t/ability-to-set-time-with-automatic-updates/48904/10
https://github.com/openSUSE/transactional-update
Framework Laptop 13
C64x
Upgrading the Atari VCS with openSUSE Tumbleweed
https://get.opensuse.org/
https://bazzite.gg/
Leave a Reply