Today’s plan was simple: update the openSUSE Tumbleweed VM that runs in VMware Workstation on my Debian desktop. Ten days behind, one command, done. Instead I got three dependency “problems,” a wrong first theory, a round of whack-a-mole, and a small terminal mishap of my own making. Here’s the log.
Step Zero: Snapshot First
Before touching anything, I took a VMware snapshot of the VM (VM → Snapshot → Take Snapshot, named “pre-update 2026-09-29”). A snapshot is the undo button for the whole machine. If an update breaks the boot or the desktop, I can revert in seconds instead of troubleshooting.
It’s the same habit as taking an EBS snapshot before patching an EC2 instance, and under AWS’s shared responsibility model, patching the guest OS is the customer’s job either way.
Leap or Tumbleweed? It Matters
openSUSE comes in two very different forms, and each one updates differently:
- Leap is fixed-release, like Debian stable, and updates with
zypper up. - Tumbleweed is rolling-release and updates with
zypper dup(distribution upgrade).
Using the wrong command can leave you half-updated, so I checked:
ny2honolulu@localhost:~> cat /etc/os-release
NAME="openSUSE Tumbleweed"
VERSION_ID="20260919"
...Tumbleweed, on the snapshot from September 19. Tumbleweed doesn’t have version numbers. Each release is a dated snapshot of the whole distribution.
One openSUSE quirk surfaced right away. sudo asks for the root password, not your own. On Debian it’s your user password, so my first attempt failed out of habit:
[sudo] password for root:
Sorry, try again.Then sudo zypper refresh pulled fresh package lists from all five repositories, including Packman, the third-party repo that provides multimedia codecs openSUSE can’t ship for licensing reasons. Remember that one.
The Wall: Three Problems
ny2honolulu@localhost:~> sudo zypper dup
...
Computing distribution upgrade...
3 Problems:
Problem: 1: the installed phonon-vlc-qt6-0.12.0-2.13.x86_64 requires 'vlc = 3.0.23',
but this requirement cannot be provided
deleted providers: vlc-3.0.23-1699.10.pm.39.x86_64
not installable providers: vlc-3.0.23-7.14.x86_64[download.opensuse.org-oss]The .pm.39 in the version and the vendor packman.links2linux.de told me my VLC came from Packman. “Deleted providers” meant that exact Packman build no longer existed in any repository.
I cancelled with c. At this stage zypper is only planning, so nothing had been changed yet.
Wrong Theory, Right Tool
My first theory was that Packman is volunteer-run and usually rebuilds a few hours behind each new Tumbleweed snapshot, so it just hadn’t caught up yet.
Instead of guessing, I asked zypper to show every available VLC version and where each one comes from:
ny2honolulu@localhost:~> zypper se -s vlc
S | Name | Version | Repository
---+----------+----------------------+----------------------
i | vlc | 3.0.23-1699.10.pm.39 | (System Packages)
v | vlc | 3.0.24-1699.4.pm.1 | packman
v | vlc | 3.0.23-7.14 | Main Repository (OSS)(Trimmed. The real output listed every VLC subpackage.)
(System Packages) next to an installed package means the version on disk doesn’t exist in any enabled repo anymore. The real story was the opposite of my theory:
| Where | VLC version |
|---|---|
| Installed on my VM | 3.0.23 (old Packman build, now gone) |
| Packman | 3.0.24, ahead |
| openSUSE OSS | 3.0.23 |
Packman wasn’t behind. It was ahead. And phonon-vlc, the piece that lets KDE apps play media through VLC, comes from openSUSE and requires exactly vlc = 3.0.23. Packman’s 3.0.24 was too new for it, and my installed 3.0.23 build had been removed. The only 3.0.23 left anywhere was openSUSE’s own.
Two repositories moving at different speeds, with my system stuck in between.
Whack-a-Mole
The plan was to switch VLC to openSUSE’s build. zypper offers numbered solutions for each problem, so I reran dup and started answering:
- Problem 1 (
vlc): 3, install from vendor openSUSE - Problem 2 (
vlc-noX): 3 again - Problem 3 (
libvlc5): 1. The numbering changed, and here 3 meant “keep obsolete,” which would have left a mismatched library under the new packages.
Lesson inside the lesson: read the options on every prompt. zypper orders solutions differently for each problem, and muscle memory will eventually bite you.
After Problem 3, zypper recalculated and handed me three new problems. Now vlc-qt wanted matching, and vlc-codec-gstreamer was trying to go up to Packman’s 3.0.24 while everything else was going down to openSUSE’s 3.0.23.
That’s when I stopped answering prompts and cancelled again.
The Fix: Move the Whole Group at Once
When a dependency solver keeps offering one fix at a time for a group of packages that belong together, change the whole group in one move:
sudo zypper install --oldpackage --from download.opensuse.org-oss \
vlc vlc-noX vlc-qt libvlc5 libvlccore9 vlc-codec-gstreamer--from download.opensuse.org-osstakes these packages only from openSUSE’s OSS repo. That alias was sitting in square brackets in the original error messages.--oldpackageallows what looks like a downgrade.3.0.23-7.14looks “older” than3.0.23-1699.10.pm.39only because Packman uses bigger release numbers. It’s the same VLC version.- The six package names are every VLC package marked
i(installed) in the search output, except the phonon ones, which were already from openSUSE.
The summary was exactly what I wanted:
The following 6 packages are going to change vendor:
libvlc5 http://packman.links2linux.de -> openSUSE
libvlccore9 http://packman.links2linux.de -> openSUSE
vlc http://packman.links2linux.de -> openSUSE
vlc-codec-gstreamer http://packman.links2linux.de -> openSUSE
vlc-noX http://packman.links2linux.de -> openSUSE
vlc-qt http://packman.links2linux.de -> openSUSE
6 packages to downgrade, 2 new, 6 to change vendor.It showed no removals, two small new support libraries, and a 6.6 MiB download. Worth noting: Packman’s vlc-codecs add-on was never installed on this VM, so moving VLC to openSUSE cost me essentially nothing.
A few mirrors returned 404 during the download and zypper moved on to the next one. That’s harmless: every package is GPG-signature-checked against openSUSE’s key before installation, so a lagging or untrustworthy mirror can be slow, but it can’t slip in a tampered package.
The Real Upgrade
With VLC out of the way, sudo zypper dup ran clean:
(190/190) Installing: qt6-webengine-imports-6.11.2-2.1.x86_64 ....[done]190 packages, including Firefox 156, Mesa 26.2.3, Qt WebEngine 6.11.2, and a new SELinux policy. Tumbleweed now ships SELinux in enforcing mode by default, and the post-install scripts relabeled system files on the way through.
One package, util-linux, left a notice about new security hardening for non-root mount operations, aimed at closing TOCTOU (time-of-check to time-of-use) race conditions. It only affects unprivileged user mounts configured through special /etc/fstab options, so I checked:
ny2honolulu@localhost:~> grep -E 'user|nocanonicalize|subdir' /etc/fstab
ny2honolulu@localhost:~> echo $?
1Exit status 1 means grep ran fine and found no matches, so I’m not affected. TOCTOU deserves its own post, and it’s coming as a Concept Explainer.
Sidebar: The Paste That Made Files
After rebooting, I accidentally pasted some earlier terminal output, prompts and all, back into the terminal. It mostly produced “command not found,” but look at what the prompt contains:
ny2honolulu@localhost:~> cat /etc/os-release | grep VERSION_IDMy prompt ends in >, and in bash > means redirect output into a file. Bash read that line as: run a program called ny2honolulu@localhost:~ and send its output to a file named cat. Bash sets up redirections before it checks whether the command exists, so:
ny2honolulu@localhost:~> ls -l ~/cat ~/grep
-rw-r--r--. 1 ny2honolulu ny2honolulu 0 Sep 29 01:06 /home/ny2honolulu/cat
-rw-r--r--. 1 ny2honolulu ny2honolulu 0 Sep 29 01:06 /home/ny2honolulu/grepTwo empty files, created by accident. A quick rm cleaned them up. The sobering part is that > overwrites without asking. If a pasted line had ended in > .bashrc, that file would have been wiped. It’s the same mechanism behind pastejacking, where a webpage hides extra commands in text you copy. Only paste commands, never prompts, and read before you press Enter.
Verification and Cleanup
ny2honolulu@localhost:~> grep VERSION_ID /etc/os-release
VERSION_ID="20260924"September 19 → September 24. The snapshot is dated the 24th, not today, because Tumbleweed only publishes snapshots that pass openQA, openSUSE’s automated test system.
And the VM finally got a proper name. It had been running with no static hostname, which is why every prompt said localhost:
ny2honolulu@localhost:~> sudo hostnamectl set-hostname tumbleweed-vm
ny2honolulu@localhost:~> exec bash
ny2honolulu@tumbleweed-vm:~>With a lab full of VMs, “localhost” in a Wazuh alert tells you nothing.
What I Learned
- Snapshot before you update. It costs a minute and turns a disaster into a revert.
- Know your release model. On Tumbleweed it’s
zypper dup, notzypper up. zypper se -s <package>shows the truth. It lists every available version and which repo it comes from, and it proved my first theory wrong.- Change related packages as a group. One command beat six rounds of numbered prompts.
- Third-party repos are a trade-off. Packman is trusted and widely used, but every extra repo is another source of packages that install as root, and another vendor that can drift out of sync with the distribution.
>in a pasted prompt is a live redirection. Paste commands, not transcripts.
Next Up
- Delete the pre-update VMware snapshot after a day or two of normal use. Snapshots grow and slow down the disk over time.
- Keep an eye on Mesa. It’s still mixed-vendor:
Mesa,Mesa-libGL1andMesa-libEGL1come from Packman, whileMesa-driandlibvulkan_lvpcome from openSUSE. They’re the same version today, but that’s exactly the setup that caused the VLC conflict. If it bites, it’s the same fix. Update (Oct 20, 2026): It bit. See the follow-up: The Mesa Conflict I Saw Coming. - Concept Explainer on TOCTOU race conditions: why setuid programs like
mountare privilege-escalation targets, and what the util-linux hardening actually closes.