Once Again My System Is "Stuck" On An Old Snapshot

English Install/Boot/Login
1

I had this problem before but can’t remember how I fixed it.
My system is stuck on the 20250403 snapshot, whereas according to the history Web page openSUSE is on 20250415.
How can I force the system to correct itself and update to the current snapshot?
Note that I did not do anything such as put locks on any software or anything, the system just apparently got locked into this by itself.

2

What happens when you run a zypper dup? That’s how you update your TW system.

3

Never mind. I found the tumbleweed-cli command to switch to the latest snapshot and then did a zypper dup. I’m now on snapshot 20250414 which apparently is the latest.

I used this guy’s article to fix it:

Snapshot Control | More openSUSE Tumbleweed Awesomeness

1 Like
4

Actually, I see this morning that my system is now stuck on snapshot 20250414.

However, I had a talk with Google Gemini about this situation, and it explained everything to me, including exactly how to fix it by editing the repos which the tumbleweed-cli switch command had locked into the history repos rather than the regular repos.

I edited the repos and now zypper dup shows me an upgrade to the 20250417 snapshot.

The only thing I can’t figure out is how the system got itself in this state in the first place. The last time this happened, I believe it was because of a rollback I had to do after the broken Mesa update some months back. But this time I didn’t do anything with the repositories or any rollbacks or anything. So, weirdness…

Here is part of my conversation with Gemini which might help someone else who gets in this situation:

Troubleshooting Steps Summary:

  1. On the “stuck” PC, run sudo zypper lr -Eu and compare the enabled repositories and their URLs carefully with the working PC.
  2. Run sudo zypper clean --all.
  3. Run sudo zypper ref --force. Check for any errors during the refresh process.
  4. Run sudo zypper dup. Observe the output carefully. Does it say “Nothing to do”? Or does it list packages but encounter errors or conflicts?

By checking the repository configuration and ensuring the metadata can be refreshed correctly, you should be able to get the second PC updating to the latest Tumbleweed snapshot.

I then told it the difference between the two machines repositories which showed the history repos being in the repository name instead of the regular repositories and speculated that might be the cause, to which Gemini replied:

You are absolutely correct! Your analysis is spot on.

The presence of /history/20250414/ in the repository URLs is the definitive reason why your system is “stuck”. These URLs point zypper to a specific, archived snapshot of the Tumbleweed repositories from April 14th, 2025. When you run zypper ref, it successfully fetches the metadata for that specific date, and zypper dup correctly determines there’s nothing newer within that historical snapshot.

Did tumbleweed-cli switch cause this?

Yes, almost certainly. The tumbleweed-cli tool is designed precisely for this purpose – managing and switching between different Tumbleweed snapshots. Using tumbleweed switch <snapshot_number> or a similar command modifies your system’s repository files (in /etc/zypp/repos.d/) to point to the historical URLs corresponding to that snapshot. It’s a feature, often used for testing or rolling back temporarily, but it does lock you to that specific snapshot until you change the repositories back.

How to Reset it to Use the Proper Rolling Repositories

You need to change the repository URLs back to the standard, rolling Tumbleweed URLs that do not contain the /history/YYYYMMDD/ part. Here are a few ways to do this, pick the one you’re most comfortable with:

Method 1: Using YaST (Graphical or Text-based)

  1. Launch YaST: sudo yast2
  2. Navigate to “Software” ⇾ “Software Repositories”.
  3. You will see the list of your configured repositories. Select each repository that has /history/ in its URL (like the non-oss one you found, likely oss and maybe update too).
  4. For each selected repository, click “Edit”.
  5. Look for the “Repository URL” or similar field and manually delete the /history/20250414 part, leaving the standard Tumbleweed path (e.g., change http://download.opensuse.org/history/20250414/tumbleweed/repo/non-oss/ back to http://download.opensuse.org/tumbleweed/repo/non-oss/).
  6. Click “OK” or “Next” to save the changes for each repository.
  7. Exit YaST, saving changes if prompted. YaST might offer to refresh the repositories automatically.

Method 2: Using zypper commands (Command Line)

This involves removing the incorrect repos and adding the correct default ones.

  1. List current repos to get their aliases:sudo zypper lr(Note the aliases, e.g., repo-oss, repo-non-oss)
  2. Remove the history-based repos:sudo zypper rr <alias_of_oss_repo> <alias_of_non-oss_repo> # Add other history aliases if needed(Replace <alias_of_oss_repo> etc. with the actual aliases)
  3. Add the standard Tumbleweed repos back:`Bash# Main OSS Repository
    sudo zypper ar -cfp 90 ‘http://download.opensuse.org/tumbleweed/repo/oss/’ repo-oss

Non-OSS Repository

sudo zypper ar -cfp 90 ‘http://download.opensuse.org/tumbleweed/repo/non-oss/’ repo-non-oss

Optional but recommended: Main Update Repository

sudo zypper ar -cfp 90 ‘http://download.opensuse.org/update/tumbleweed/’ repo-update`

  • -c checks the URL.
  • -f enables auto-refresh.
  • -p 90 sets a standard priority (lower numbers are higher priority).

Method 3: Manual Editing (Command Line - Use with care)

  1. Navigate to the repository configuration directory: Bashcd /etc/zypp/repos.d/
  2. List the files: ls *.repo
  3. Edit each relevant .repo file (e.g., repo-oss.repo, repo-non-oss.repo) using a text editor like nano or vim with sudo: sudo nano repo-oss.repo
  4. Find the line starting with baseurl=.
  5. Carefully delete the /history/20250414 portion from the URL.
  6. Save the file and exit the editor.
  7. Repeat for all other Tumbleweed repository files that point to the history URL.

Method 4: Using tumbleweed-cli (If it has a revert option)

Check if tumbleweed-cli itself has an option to go back to the rolling/latest state. Try:

`man tumbleweed

or

tumbleweed --help`

Look for commands like tumbleweed revert, tumbleweed default, tumbleweed latest or tumbleweed switch --rolling. If such a command exists, it might be the simplest way. However, Methods 1 or 2 are guaranteed to work by directly fixing the URLs.

After Fixing the Repositories

Whichever method you choose, you must refresh the repositories to fetch the metadata from the correct, rolling URLs:

sudo zypper clean --all # Clear out old metadata sudo zypper ref --force # Force refresh from the corrected URLs

Now, run the distribution upgrade again:

sudo zypper dup

This time, zypper will compare your currently installed packages (from snapshot 20250414) against the metadata from the latest available Tumbleweed snapshot, and it should offer you a significant upgrade.

5

A word of caution - AI assistants can be very useful, but don’t follow anything they say unless you’re 100% sure they’re correct. They can and do hallucinate information, and blindly following their advice can lead to a nonfunctioning system.

tumbleweed-cli isn’t part of the Tumbleweed distribution - it’s an addon that uses archival repositories (as I recall) to let you revert to earlier snapshots.

It may or may not be functioning correctly. What you probably should do is raise an issue with the author of the tool to find out if there is a known issue.

6

It is. The package is included in the standard Tumbleweed repository. It is not installed or used by default, that’s correct.

7

Thanks for the correction - I must have been thinking of something else. Sure enough, and I even installed it (not sure why “cnf” didn’t find it on my installed system).

Still sounds like it might be an issue to report via bugzilla.o.o.

8

While tumbleweed-cli may be in the official repositories, I don’t believe it goes through any automated testing, a la openQA (or at least by a quick scan, I don’t see any tests written for it). And isn’t considered an “official tool” for system management.

That being said, filing a bugzilla ticket against tumbleweed for this tool is probably the correct thing to do here.

1 Like
9

What testing do you expect here? tumbleweed simply modifies repository definition to point to a specific Tumbleweed snapshot. Which did pass openQA testing you are talking about. I use it for all my installations simply because it allows me to quickly install some package for testing without risking the whole system update.

Of course, as soon as you are using repositories beyond the standard ones you will likely face issues if your current snapshot is too old, because external repositories usually track the current Tumbleweed. But that is not new, users get the same sort of issues with Packman without any tumbleweed-cli involved.

Sorry? If user used tumbleweed to stay on the 20250403 snapshot user needs to use tumbleweed to advance to the 20250415 snapshot. Where is the bug here?

10

openQA tests can be written for just about anything.

That wasn’t a criticism of the tool, it might be perfectly fine, I’ve never used it.

If you’re running into issues with a piece of software, in the official distributions, and you can’t sort out what the problem is on your own, filing a bug is the appropriate place.

I know this is shocking to people, but developers aren’t mind readers, nor do they monitor every communication platform, to see what people might be doing with their software. And filing a bugzilla ticket is generally going to be the way that the actual developers see an issue, and are able to decide if it’s something that needs to be fixed, or user error, or just a use case that the developer hadn’t considered, and might wish to look at including in their software.

2 Likes