I have posted before about how I have ventured from the relatively “safe” confines of the Ubuntu world to the wild west of OpenSUSE’s Tumbleweed, a rolling-release, bleeding-edge distro. In the Ubuntu world, I often bristled at having to tolerate bugs or issues that had actually been fixed by the devs of the various packages, but where those fixes had not yet made it to the distro I was using. Over time, as the two-year replacement cycle of the Ubuntu LTS version wore on, I would find myself replacing more and more packages from the LTS distro with those from newer Ubuntu releases, or those from the “Sid” unstable dev branch of Debian, which often was not very easy to accomplish.
That was when I decided I wanted to try a distro that rolled out all of the newest stuff as soon as it was declared stable by its devs, and the one that I landed on was OpenSUSE Tumbleweed.
Rolling-release distros have a reputation for being unstable and having dependency issues at times, but I had to experience it to see how it compared to those same issues I was causing for myself by trying to graft in bits from Ubuntu’s short-term releases or Sid.
The first issue that appeared was not a surprise, as I had the same thing happen when I tried Fedora some time ago. I use Veeam for my backups, and it (more specifically, the veeamsnap module it needs to perform image backups) typically lags behind the newest Linux kernel by several versions. With Ubuntu, this is fine; Ubuntu’s own kernel releases are also several versions behind the mainline, so it matches Veeam well.
With a more cutting-edge distro, though, the kernels are generally released to the distro’s users as soon as they are released by the mainline kernel team. This meant that from the moment I installed Tumbleweed, it was incompatible with Veeam, and that has not changed since I have been using Tumbleweed. Veeam is working on a new replacement for veeamsnap called blksnap, but it is not compatible with existing Veeam, and won’t be released as a complete product until Veeam Agent 6.0 arrives, which is supposed to be near the end of 2022.
There have been some others.
I noticed that in Vivaldi, the browser’s integration with KDE Plasma (specifically, the file load/save dialogs) stopped working. Chromium browsers use the XDG desktop portal to use whatever file load/save dialogs are native for the desktop environment, and they do a far better job of it than Firefox, whose support for the XDG portal is incomplete. As such, I use patched versions of Firefox to bypass the desktop portal, which is easy with OpenSUSE, as they are the maintainers of the patch set in question, and the Firefox version in their repos is already patched. It is my guess that the portal would have stopped working with Firefox too, if I was using it.
I had to roll back a Timeshift snapshot to restore the older versions of the XDG desktop portal packages. While Ubuntu will generally keep at least one older version of pretty much every package that is updated, OpenSUSE discards the old one as soon as the new one arrives… so if there is a problem, you cannot roll back unless you, the user, supply the thing you are going to roll back to.
I rolled it back and locked the versions at their currents so they don’t get updated to the non-working versions again.
This kind of thing was not unknown in Ubuntu… there were newer versions that caused issues there too, but rolling back was usually easier. I did still have to lock them to keep them from updating, and that means manually monitoring them and trying out any subsequent versions that come along to see if they fix the bug.
Yesterday, I saw that the new 6.0 Linux kernel was available from OpenSUSE, so I went to do a Timeshift snapshot before proceeding. I had a bunch of old snapshots that were no longer necessary, so I highlighted them and pressed Delete.
It began deleting the old snapshots, but then the program just force-closed, with nary an error message.
I tried again, and the same thing happened. Then again, then again.
Eventually I did get those unwanted versions deleted, but when I tried to create the new snapshot, it crashed yet again.
I tried the command-line version of Timeshift to create a snapshot, and it worked flawlessly.
I found this reference to the error:
https://github.com/linuxmint/timeshift/issues/69#issue-1393211652
That’s it exactly. A bleeding-edge distro that has the newest glib2 version crashes, while non-rolling distros like Ubuntu don’t. Is the bug in glib2 or Timeshift, though? No way to know. It could be either one.
So with my new snapshot squared away, I allow the updater to install kernel 6.0, then reboot.
And it boots to a command line, not the graphical interface. I soon discover the X server is not starting, which typically indicates an issue with the graphics driver. This was on my Xenia 15, which uses the proprietary nVidia driver.
I go to the nVidia web site and look up the newest version of the driver. It’s 515.73, while the version I am using (from OpenSUSE) is 515.63. The nVidia driver is not in OpenSUSE’s main distro, as that apparently would create some kind of issue with the non-free license of the driver, but they do have an addon repo that you can easily add. I did this long ago, but I want to check to make sure there is not another one that has superseded the one I already added, just in case.
I start the Yast package manager tool, then select the Repositories option under Configuration, and then press Add, then tick the radio button for Community Repos, and hit Next. It’s supposed to show a list of community repos, but it shows… nothing. The dialog is present, but the fields are not populated with any community repos at all.
As best I can tell, the nVidia driver repo is still set up and working, but the version it gives me is one behind the upstream. Could that be why the X server did not start?
I searched for info on the 515.73 driver, and I find a reference to it now being compatible with kernel 6.0. Well, there we go, I guess… OpenSUSE served up a kernel version that is too new for the nVidia driver version their community distro serves up. Now I know that this is not their official repo, but if this is as close to “official” as one can get for the nVidia driver, I would hope that there is some level of synergy between what is offered in the main repo and the nVidia one.
I used the command line Timeshift once again to roll back to the previous snapshot, and not surprisingly, everything worked fine again.
These issues are not insurmountable for me… while I am far from being a Linux expert, I know enough to be able to comprehend and remediate these problems (which I have), though I have no idea where the list of community repos went (it is missing on the XPS as well). This is the kind of thing one hears about in reference to any rolling distro, like Fedora Rawhide, OpenSUSE Tumbleweed, Arch, Manjaro, and so on. If they were not such sticklers about only having the newest version of every package in the repo, it would be much easier to deal with the breakage that does sometimes occur, but apparently the Tumbleweed maintainers are almost ideologically opposed to this idea. It’s a rolling distro with the cutting edge stuff, so you will get the cutting edge stuff, period, full stop.
Jury’s still out (for me) on whether the Ubuntu way or the Tumbleweed way is the better way.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
I thought Mint was based on Ubuntu how can it be Mint if it is based on another OS?? 
