Tumbleweed snapshots - usage notes

Here are some notes I wrote for myself concerning tumbleweed snapshots. I’m posting them here in case they may be of use to others. It represents the minimum amount of info I need to reference in order to manage tumbleweed snapshots on my desktop. The potential audience is probably best described as any experienced Linux/UNIX admin who’s used to a fair bit of DIY under the hood.

**Tumbleweed snapshots introduction
Tumbleweed-snapshots is a layer of repo management software and an associated history of official-release snapshots that logically sits above the normal tumbleweed official-release repo. The name tumbleweed-snapshots is a little confusing because it overloads the meaning of two existing terms: tumbleweed, and snapshot, just remember tumbleweed-snapshots is a separate repo system.

The tumbleweed-snapshots components are as follows:

  • Tumbleweed-snapshots history site
    : a mirror of recent official snapshots http://download.opensuse.org/history/ - Tumbleweed-snapshots quality review website
    : http://review.tumbleweed.boombatower.com/ - tumbleweed-cli
    : the package that installs the tumbleweed command for managing the installation of tumbleweed-snapshots. - Official openSUSE Tumbleweed release
    : source of releases mirrored to the history site.

The advantage of tumbleweed-snapshots is that it provides the facility for you to choose any recent official-snapshot as the basis for your tumbleweed installation. This allows you to stand back from the official bleeding edge by choosing safer releases. It also enables you to wait out periods of instability. The quality of the Official Releases held with the tumbleweed-snapshots can be reviewed by consulting the related openSUSE Tumbleweed Review website which posts a number of metrics.

Switching to the tumbleweed releases repositories

The tumbleweed-cli package installs the tumbleweed command which is used to manage a installation that uses tumbleweed-snapshots. The package is part of the standard tumbleweed distribution and can be installed by yast or zypper (which ever you prefer).

In order to use the tumbleweed-snapshot repos you need use the tumbleweed command to update your systems repos to point to the history site, this is accomplished by the init command:

tumbleweed init

The init changes all the repo URL’s in /etc/zypp/repo.d/ that with begin with a reference to


to now be a reference to the snapshot history repos and includes a variable that will resolve to the snapshotVersion to actually use:


The value of snapshotVersion is written to


Here’s the content of my current snapshotVersion file:


The init command also changes the local name of the repo in /etc/zypp/repos.d/*.repo to include the date of the snapshot used for the initial init. Here’s the content of my current /etc/zypp/repos.d/repo-oss.repo

name=repo-oss (20180917)

Note, the edit of the name field change is a one time thing done at init. Confusingly the name field in .repo won’t be updated if you use further commands to switch to different snapshots. So don’t worry if some of the feedback continues to refer to the original init snapshot date, even when you set it to a different one (the actual snapshot used is always the one listed in /etc/zypp/vars.d/snapshotVersion).

After updating the repo’s you can then proceed to use the tumbleweed command to install any of the available tumbleweed-snapshots listed at the review website.

**Managing tumbleweed-snapshots
After reviewing the history of snapshots at http://review.tumbleweed.boombatower.com/ , you can switch to a desired snapshot by issuing a tumbleweed switch command, for example:

tumbleweed switch 20181208

The switch command sets the target for the next zypper ref and zypper dup by updating /etc/zypp/vars.d/snapshotVersion. Aside from this change, nothing is actually done until you manually do a refresh and distribution-upgrade, for example:

zypper ref 
zypper dup

You can combine the switch, ref, and dup steps by using the –install option with the switch, for example:

tumbleweed switch --install 20181208

If you decide to abandon a switch before the install, you can revert the target version by issuing a revert command. Check whether the target is the correct by using tumbleweed status, for example:

tumbleweed status
latest   : 20181224
target   : 20181208
installed: 20181204

Revert to the desired/correct version by using tumbleweed revert, for example:

tumbleweed revert 20181204
tumbleweed status
latest   : 20181224
target   : 20181204
installed: 20181204

If you actually completed and installed a switch, you can revert both the switch and install by using –install option with a revert, for example:

tumbleweed status
latest   : 20181224
target   : 20181208
installed: 20181208

tumbleweed revert --install 20181204

Revert –install is equivalent of:

tumbleweed revert 20181204
zypper ref 
zypper dup

The main difference between switch and revert is that each option attempts to correctly update the history of what has been switched and reverted. The history can be seen with:

tumbleweed history

As far as I can tell, there doesn’t appear to be any technical implications if the history is incorrectly updated by using switch instead of update.

Tumbleweed stability score

The Tumbleweed Review website: http://review.tumbleweed.boombatower.com/ scores each official release. The scoring is done by some python code available here:

See: https://github.com/boombatower/tumbleweed-review/blob/master/src/score.py

Without going into detail the score is roughly computed as follows
score = 100 - ( bugs + emails + snapshot_score )


  • bugs
    is number of reported bugs / 10 - emails
    the number of thread references truncated to within the limits 3 to 25. - snapshot_score
    is a complicated counting/weighting of kernel and Mesa changes.

A good score would result if there were few reported bugs, not much email, and the kernel or Mesa were not heavily modified.

Releases status is determined by examining the score and release date according to the following short-circuit logic:

  • Pending: today - releaseDate < 7
  • Stable: score > 90
  • Moderate: score > 70
  • Unstable: otherwise

**External dependencies
I use a few other repos outside the tumbleweed-snapshot system such as packman. I sometimes find that my tumbleweed-snapshot dependencies can be out of alignment with these external repos. This raises dependency conflicts which I normally resolving by:

  • electing not to update a package,
  • electing to upgrade a package ignoring dependency breakages,
  • or by waiting a few days in which case the problem may go away.

Of course, such conflicts might be due to official tumbleweed changes, and not the fault of tumbleweed-snapshots.


Your post has been a great help with snapshots. There’s one thing I can’t find the answer to. A couple of years ago I downloaded and installed Tumbleweed from an ISO. I really loved it except for…the constant updates. I read about it and knew about the updates but I didn’t realize how many it actually was. As if you haven’t heard that 1,000 times.

Then came snapshots. Absolutely brilliant! You can be nearly on the bleeding edge, stable and not updating and breaking things.

I hopped off of the upgrade train on the 2019-12-28 snapshot.
It’s the “disk” part I don’t understand.

unique: 121 total: 62193 **disk: 1.0GiB

**I’m wanting to switch to the 2020-01-16 snapshot because it has Darktable 3.0.
I compiled it on Mageia but TW is a great way to monitor what’s coming down the pipe.

The 2020-01-16 snapshot says “disk: 2.4GiB”.
unique: 1474 total: 61758 **disk: 2.4GiB

**It’s here: https://review.tumbleweed.boombatower.com/2020/01/16/release.html

I know I can download a TW ISO but I don’t know if I can choose to download a ISO of the 99% stable 2020-01-16 snapshot.
What does the disk information mean? Can I download the ISO or packages to install that particular snapshot?
There’s a lot of photographers looking for a stable, near cutting edge, up to date distro. They’re mostly after the new Darktable and they want the updates as soon as possible. Some can compile but most can’t. I think TW with snapshots is exactly what they need. They’re mostly Windows users and they could jump ahead when new features come out. Darktable does have a Windows version but it’s not as stable and many have problems.

I want to make sure I give them correct information and get them going with as little hassle as possible.
Snapshots is so simple. Install it, get it going and lock onto a snapshot. Switch to a new snapshot when needed.

Thanks for the assistance.

I think (hope someone confirms) that disk is the total disk-space required by this snapshot (I guess it’s more a measure of download space, because it will mostly be overwriting existing files). I hadn’t really regarded the disk statistic as very interesting (I guess it might be if ISP data-caps are in force).

I had intended to do more to integrate my notes with the official TW-snapshot help or wiki. But for some reason that escapes me, some time ago I switched to plain TW (no snapshots). It has proved reliable enough for my purposes, so I haven’t returned to TW-Snapshots. But clearly the TW-Snapshots has a big role to play for for an examples such as the one you’ve stated. If anyone would like to pick up the ball and fold my notes into the official TW-Snapshot documentation, fell free.

Thank for the reply.

If you go to the history where the dates for the snapshots are, it has all of the packages etc. I just thought there may be a way to make a particular ISO. This would be a great addition if there isn’t currently a way to do it. Then people could pick a stable version based on user feedback and it’d be guaranteed to run as good as the other users say it did. Well, at least that’s a good theory. As I said, I think some photographers would love TW and being able to instruct them to download a particular ISO to match their snapshot would be perfect.

The snapshot history is all here:


I’m going to keep an eye out for methods of creating a ISO from a certain snapshot. Maybe someone will write a script or instructions on how to do it. I do believe you’re correct about the disk info. I think it’s the size of of changes from a base package list or something.

I’m going to email someone and ask for more details. I’ll report back.

My take on OP’s final note is that maybe is not a good idea to use tumbleweed-cli after all. The tool exists to dodge possible breakage by being on cutting edge (there’s openQA so it’s not bleeding edge). Only it requires more thinking/effort when it breaks external packages, which is likely to happen by design.

Breaking external packages is a big problem.

I’ve recently gone from supporting one TW desktop to two. I think this is where tumbleweed-cli might have a stronger role to play. After moving the second machine to TW I thought I’d just use my desktop as a the zypper dup vanguard. When my machine was stable I’d follow up and zypper dup the other. But by the time I’m happy that my desktop is OK, TW has moved on and I can no longer be sure that zypper dup on the other one will produce the same result. Tumbleweed-cli seems like a potential answer for this issue, although the external package issue is still a potential headache (depending on how many external packages are involved).

I assume that as soon as there’s an update to the external dependency, that’s the best moment to zypper dup. Is this assumption correct?

I think so. But different dependencies come from different repos, so depending on timing it might be a bit of a juggling act. A lull in TW releases, or during a series of relatively minor releases, might also be a good time to try (and cancel if you don’t like what you see).

The reality is, when faced with a dependency issue, I often choose some resolution almost arbitrarily, somewhat based on instinct, and just hope for the best. That’s because it’s my desktop and I can live with any fallout (which is typically nothing discernible). I’m a bit more careful with my other machine which is used by my partner.

The most critical dependency I have is aligning the TW release and proprietary nvidia repo. It’s mostly OK, but sometime I have to hold back on a TW kernel update or set the bootloader in yast to default to a previous kernel until I’m in the clear.

I looked at it, but I have not actually used it. From looking at it, I did learn about the history repos. So I went directly to one of the history repos to grab an older package. That didn’t actually solve my problem at the time, but it gave me the information that helped me find a solution.

Oops, I’m being too cryptic. Ethernet performance became really bad on one computer. But it was fine when running Leap, so not a hardware issue. Using the history repos, I downloaded an older kernel (from before the problem showed up). That did not fix the issue, which told me that I had to look elsewhere. So I switched from NetworkManager to “wicked”, and that did fix the issue. Then I cleaned out all of the configuration that NetworkManager was using for that connection. I went back to NetworkManager, and this time it worked properly.

My bad I shouldn’t have opened a new thread > https://forums.opensuse.org/showthread.php/539600-Tumbleweed-cli-switch
Hi, I recently discovered the magic world of opensuse and tumbleweed, and so far I’m excited. Every day I find a new tool, like opi which is even better than aur.
When I learned about tumbleweed-cli, Ι got excited about that rolling model!
But there is something that still confuses me.
I did a fresh TW install yesterday and quickly installed tumblewee-cli and did a

tumbleweed switch --install 20200314

which was the latest stable.
Today I did a new

tumbleweed switch --install 20200318

My question is, is there any further step should I do?

tumbleweed status

output is

latest: 20200322
target: 20200318
installed: 20200322

Does it means I am on 20200318 or not?

Thanks in advance, so happy being on opensuse’s wagon :smiley: