A few questions about Tumbleweed

Hello, I am a casual PC user who has been using Tumbleweed for some time and has been generally pleased with my experience. Over the past 10 years in this community, opinions and recommendations on how to perform a safe system upgrade have been given perhaps hundreds of times. After 10 years, I can’t understand why Tumbleweed doesn’t show the safe system upgrade method out of the box, especially to new users, inform them about it, or even apply it in the operating system itself. I wanted to ask 3 questions to get the opinions of power users in this community on this issue.

  1. Why hasn’t YaST Software been made a suitable tool for upgrading Tumbleweed for 10 years?
  2. The documentation on doc.opensuse.org, including the documentation in the Welcome tool, is for Leap instead of Tumbleweed. Doesn’t this mislead casual newcomers into upgrading their systems? I think that if the correct information was written in this tool, it would have prevented many people from doing a system upgrade the wrong way. Tumbleweed doesn’t seem to have its own documentation anyway.
  3. If it is recommended not to use any GUI to perform a system upgrade, why, for example, in the setup of the Plasma and GNOME desktop environments, their GUIs are configured to perform a system upgrade? There are notifications directing users to those GUIs to upgrade, and even in GNOME system upgrades are automatically downloaded and installed. A little bit shorter: If GUIs are not recommended, why are they available pre-configured for system upgrades, and if GUIs are a safe method, why are they still not recommended?
1 Like

Tumbleweed is not really a distribution for beginners or occasional users, because the large number of upgrades - some of which come several times a day - means that it requires a lot of maintenance.

I know that I’m about to be put down again here:

I have been using SuSE/OpenSUSE since the beginning of 1998, and therefore Tumbleweed since it was introduced. And I have done all upgrades with Yast since then. The few times I had problems were after upgrades with the “zypper dup” command. I have been using my PC for several hours a day since 1998.

In addition, the “zypper dup” command has been modified under OpenSUSE anyway and does not run a “real” “zypper dup”.

Incidentally, I also upgraded from Plasma5 to Plasma6 initially under Plasma5 using Yast. This did not lead to the installation process crashing (unlike all those who carried out the installation via zypper dup under the GUI), because Yast excluded all packages from the upgrade from the outset that would have led to the running system crashing and did so for users of the “zypper dup” command.

I have to admit that I don’t know which program you are using to display upgrades under Plasma. I suspect that it is Discover in conjunction with packagekit. Discover has never worked properly, years ago packagekit regularly paralyzed the computer with its search for upgrades after starting the GUI.

I therefore permanently blocked packagekit and Discover in Yast years ago.

Your criticism that the packages are not removed from the basic installation from the outset is correct.

1 Like

@LyzyrdSkynyrd Becuase Tumbleweed is the base release for Leap and the openSUSE Development model is Factory (Tumbleweed after openQA) first.

If I want to package application X for Leap, I first have to submit to a development project, once there can submit to Factory, once there, when the next Leap snapshot is taken it will appear in Leap (assuming any supporting packages for build are also working…)

I run a very limited set of repositories, OSS, Update and a Local rpm repo. Many users run the likes of opi to add additional repositories, then there is packman.

Each has it’s own set of quirks and unfortunately can easily spiral into package conflicts when using zypper dup.

If you want to run a rolling release, consider the likes of Aeon or Kalpa? The system will take care of itself (it uses dup, well the transactional one) then you as the end user can run flatpaks or distrobox to supplement your needs at a user level.

2 Likes

Re. Item 3
The desktop GUIs are capable of updating TW because they implement a “dup” and not an “up”. This is a relatively new feature (maybe a year or so?), so if you are reading older posts you will read that you should never use them, and it was true at the time. You may also get the advice from those that have never tried the GUIs and believe the command line should always be used.

Personally, I like GUIs for most things by I prefer the command line for zypper updates.

1 Like

@doscott That all depends on the desktop environment is use, but zypper dup will in the majority of cases always work, better the devil you know, so to speak…

I use GNOME, Aeon and Hyprland, zypper dup has never let me down…

I see that, but Tumbleweed promises to be suitable for all users. Of course, it points out that some third-party kernel modules need to be compiled by users.

Who should try Tumbleweed?

Any user who wishes to have newer packages than are available in the openSUSE Leap repositories. This includes, but is not limited to, an updated Linux kernel, SAMBA, git, desktops, office applications and many other packages.

Also, Tumbleweed should appeal most to Power Users, Software Developers (who require the latest software stacks and IDEs) and openSUSE Contributors (who need a reliable platform that is as close to openSUSE Factory as possible while remaining usable).

Due to the Linux kernel being updated very frequently, users who rely on 3rd party kernel driver modules including graphic drivers should not use the Tumbleweed distribution unless they are familiar with updating these drivers from source on their own or they have supported hardware. For more details please refer to the “Third Party Drivers” section below.
opensuse.org/Portal:Tumbleweed

Until a few months ago, the portal also mentioned that YaST Software could be used for system upgrades, but this info is no longer available.


@malcolmlewis Okay, that’s true. But Tumbleweed is not even mentioned in the documentation. It would be good to point casual and new users to the Portal and other TW-related pages at the beginning, so that they are aware of some anecdotes about TW.

Likewise, it would have been useful to warn people at the very beginning if they want to use third-party repositories and not just the official ones.

I know that both of those variants of MicroOS are in pre-release. I’m a bit more familiar with the Fedora immutable distributions, and frankly, as a casual PC user, I find the design of those distributions a bit more strange. For virtualization or some other applications that require root privileges (VPN applications for example), additional settings in distrobox/toolbx are required. Which may not work as expected, plus distrobox is not a tool of openSUSE and we may have to wait for other people to take action to fix bugs.


Yes, I know what you’re talking about. I think in a distribution that is always up to date, the documentation, Portal page and other manuals should also be up to date. It says that no GUI should be used at the moment. Actually, there was a discussion in a thread about whether it should be the default to install a system upgrade via GUIs on reboot or shutdown.

I’m talking about the doc.opensuse.com page, and I actually meant the Welcome tool above. There is a link to the portal in Startup Guide/12.1 Upgrading the system

I came from years of Ubuntu and using apt, Fedora using dnf, and carried that also over to openSUSE with zypper dup. I heard somewhere dup was preferred with Tumbleweed and just stuck with it, and I prefer the idea of synchronizing packages with versions in the repo instead of just updating based on a newer version number (updates pulled from the repo won’t downgrade on the system by-default).

My understanding is that GUI package managers go through layers to get to the actual package manager anyway (GNOME/KDE GUI store → PackageKit → zypper/dnf/apt), and I have tons of experience of layers breaking that have me prefer not to go through them when possible :stuck_out_tongue:

If updating breaks, I can witness that as soon as it happens on command-line and also take care of it with active context. I’m left guessing with GUI, or have to go investigate through command-line any way.


I dislike GUI updating so much I make keyboard shortcuts just to update stuff through CLI :stuck_out_tongue: Here’s what I use on TW GNOME, and just press a keyboard key once a day:

kgx --command="sudo sh -c 'zypper clean --all && zypper refresh --force --services && zypper dist-upgrade --details --allow-downgrade --allow-name-change --allow-arch-change --allow-vendor-change && sync && flatpak update && sync && fstrim --all --verbose && sync && read -n '1' -s -r -p 'Done''"


Particularly on openSUSE for me, PackageKit for years has been the first annoyance within a minute of a fresh install because it prevents zypper from doing anything on command-line until it decides to get done (asking it to stop gracefully doesn’t work), which now has me running this first-and-foremost to obliterate it:

sudo systemctl stop 'packagekit' && sudo zypper remove 'PackageKit' && sudo zypper addlock 'PackageKit'

I don’t like being held-up, don’t know what PackageKit is doing for multiple minutes (zypper doesn’t take that long with wiped repo data), and don’t like it even refuses a graceful root request to stop.

1 Like

Tumbleweed’s zypper dist-upgrade suffers from solver defaults. Users may want to tweak them and perform non interactive upgrades:

Recommended packages are a great feature of zypper install --recommends. However using it with zypper dist-upgrade --recommends can have annoying side effects.

One decade of experience has shown that a more declarative approach to system maintenance minimizes the maintenance effort and makes Tumbleweed upgrades virtually hassle-free.

Host freiburg readily auto-upgrades without manual intervention:

root@freiburg: ~
# journalctl -q -u transactional-update.service -g Consumed
Apr 28 00:00:40 freiburg systemd[1]: transactional-update.service: Consumed 13.903s CPU time.
Apr 29 00:01:44 freiburg systemd[1]: transactional-update.service: Consumed 40.350s CPU time.
Apr 30 00:00:43 freiburg systemd[1]: transactional-update.service: Consumed 15.559s CPU time.
May 01 00:03:58 freiburg systemd[1]: transactional-update.service: Consumed 14.236s CPU time.
May 02 00:01:38 freiburg systemd[1]: transactional-update.service: Consumed 42.818s CPU time.
May 03 00:01:23 freiburg systemd[1]: transactional-update.service: Consumed 13.210s CPU time.
May 04 00:05:50 freiburg systemd[1]: transactional-update.service: Consumed 2min 23.386s CPU time.
May 05 00:01:42 freiburg systemd[1]: transactional-update.service: Consumed 49.137s CPU time.
May 06 00:01:01 freiburg systemd[1]: transactional-update.service: Consumed 12.371s CPU time.
May 07 00:01:39 freiburg systemd[1]: transactional-update.service: Consumed 40.767s CPU time.
May 08 00:01:26 freiburg systemd[1]: transactional-update.service: Consumed 25.369s CPU time.
May 09 00:01:18 freiburg systemd[1]: transactional-update.service: Consumed 47.053s CPU time.
May 10 00:03:04 freiburg systemd[1]: transactional-update.service: Consumed 38.364s CPU time.
May 11 00:01:40 freiburg systemd[1]: transactional-update.service: Consumed 55.580s CPU time.
May 12 00:01:51 freiburg systemd[1]: transactional-update.service: Consumed 1min 8.768s CPU time.
May 13 07:02:31 freiburg systemd[1]: transactional-update.service: Consumed 1min 20.888s CPU time.
May 14 07:11:43 freiburg systemd[1]: transactional-update.service: Consumed 38.589s CPU time.
May 15 00:00:30 freiburg systemd[1]: transactional-update.service: Consumed 4.017s CPU time.
May 16 09:23:25 freiburg systemd[1]: transactional-update.service: Consumed 2min 33.479s CPU time.
May 17 08:21:26 freiburg systemd[1]: transactional-update.service: Consumed 45.813s CPU time.
May 18 00:02:11 freiburg systemd[1]: transactional-update.service: Consumed 1min 22.050s CPU time.
May 19 00:03:58 freiburg systemd[1]: transactional-update.service: Consumed 1min 35.450s CPU time.
May 20 00:00:10 freiburg systemd[1]: transactional-update.service: Consumed 3.430s CPU time.
May 21 00:00:08 freiburg systemd[1]: transactional-update.service: Consumed 3.378s CPU time.
May 22 00:03:39 freiburg systemd[1]: transactional-update.service: Consumed 1min 45.379s CPU time.
May 23 00:02:27 freiburg systemd[1]: transactional-update.service: Consumed 1min 9.300s CPU time.
May 24 00:04:02 freiburg systemd[1]: transactional-update.service: Consumed 1min 24.667s CPU time.
May 25 00:03:22 freiburg systemd[1]: transactional-update.service: Consumed 1min 25.905s CPU time.
May 26 00:00:13 freiburg systemd[1]: transactional-update.service: Consumed 3.367s CPU time.
May 27 00:00:09 freiburg systemd[1]: transactional-update.service: Consumed 1.595s CPU time.
May 28 00:03:19 freiburg systemd[1]: transactional-update.service: Consumed 1min 779ms CPU time.
May 29 00:00:48 freiburg systemd[1]: transactional-update.service: Consumed 12.453s CPU time.
May 30 00:00:23 freiburg systemd[1]: transactional-update.service: Consumed 10.382s CPU time.
May 31 00:00:23 freiburg systemd[1]: transactional-update.service: Consumed 10.299s CPU time.
Jun 01 00:05:36 freiburg systemd[1]: transactional-update.service: Consumed 10.247s CPU time.

root@freiburg: ~
#