Hi everyone. Today Steam had issues starting FFXIV. I rolled back but since Firefox now uses profiles that are not backwards compatible I reasoned I could update my rolled back snapshot to 20260315 but instead libsystemd0 was removed before dracut could run.
Log:
No, it’s not zypper that is breaking anything; it’s the updated packages. It’s never the tool that does the update, it’s always the updated packages and their dependencies.
You are shooting the messenger.
Many errors
error while loading shared libraries:
libsystemd.so.0: cannot open shared object file: No such file or directory
In that zypp history. Check if the symlink is still correct; it might point to nowhere. On my Slowroll, I have:
sh@meteor:~> ls -l /usr/lib64/libsystemd*
lrwxrwxrwx 1 root root 15 Feb 27 16:14 /usr/lib64/libsystemd.so -> libsystemd.so.0
lrwxrwxrwx 1 root root 20 Feb 27 16:14 /usr/lib64/libsystemd.so.0 -> libsystemd.so.0.41.0
-rwxr-xr-x 1 root root 1148336 Feb 27 16:14 /usr/lib64/libsystemd.so.0.41.0
sh@meteor:~> file /usr/lib64/libsystemd.so.0
/usr/lib64/libsystemd.so.0: symbolic link to libsystemd.so.0.41.0
sh@meteor:~>
Probably on your machine that file command shows “broken symbolic link”.
That snippet of /var/log/zypp/history in the pastebin is too incomplete to be useful. At least include the command line of that file that caused those actions.
There is no operation for libsystemd0 in the snippet.
Also be advised that you can now visualize it with Myrlyn in a human-readable way (in particular without all those hex numbers that just clutter the display).
Yes, I know zypper is just following instructions and it isn’t a zypper bug.
Ok, I managed to retrieve from /var/log/zypp/history:
dup deleted systemd-32bit which then caused the rest of the issues. 
Why you have that and not the normal 64 bit package systemd I don’t know! 
Try rolling back, installing systemd and removing systemd-32bit. 
In addition to what @pavinjoseph wrote: If the dependency resolver proposes a solution where it wants to downgrade packages to the 32bit version or worse, the i586 version, something is very, very wrong; don’t do it. Those are the solver’s desperate attempts to keep things running (well, kind of) when things are already going downhill.
This might be caused by other packages that the solver would actually prefer being locked or conflicting with other packages that you selected manually, or a consequence of previous decisions where you selected a less than ideal solution to a dependency problem; like when you get a list of dependency problems, and you try to solve them one by one.
More often than not, the best solution is not do do that package upgrade that started that whole chain of problems, or not to deinstall that package that you thought you wanted to get rid of. Better leave that quagmire before it sucks you in completely.
For some older packages you might legitimately need a 32bit package or two; like those old Brother printer drivers from 2012. But not for your important system base components like systemd.
The good news is that it’s relatively easy to fix this: Search for 32bit (in “Contains” mode!) in Myrlyn, sort the package list by status (click on the column with the status icon) so the installed packages are at the top of the list, make some notes and search the regular versions for them and install them instead. It might make sense to uncheck “ Autocheck” (menu “Dependencies”) temporarily for that step to avoid getting drowned in lots of dependency problems and then check manually (“Dependencies” → “Check Now”).
HTH
The last zypp history filtered for “systemd”:
That zypper dup replaced your systemd. Here it actually replaced 32 bit versions with the 64 bit versions which is generally a good thing.
Other 32 bit versions. Not sure if that was a good move.
This is what I’m getting in my rolled-back system:
sudo zypper verify
[sudo] password for root:
Loading repository data…
Reading installed packages…The following package is going to be upgraded:
curlThe following 14 NEW packages are going to be installed:
jq libgdbm6 libgdbm_compat4 libICE6-32bit libjq1 libnettle8 libnettle8-32bit libsratom-0-0-32bit libthai0-32bit libusb-1_0-0-32bit p11-kit policycoreutils-python-utils python313-mysqlclient shadowThe following 15 packages are going to be REMOVED:
build-mkbaselibs libfreetype6-32bit libgcc_s1 libncurses6-32bit libngtcp2-16 libstdc++6 libstdc++6-pp libsystemd0 libsystemd0-32bit ncurses-utils pam pam-extra systemd-32bit terminfo-screen
zypper-log1 package to upgrade, 14 new, 15 to remove.
Package download size:
| 2.5 MiB overall package size
832.4 KiB | - 1.7 MiB already in cachePackage install size change:
| 9.2 MiB required by packages that will be installed
-1.9 MiB | - 11.1 MiB released by packages that will be removed
Some of the dependencies of installed packages are broken. In order to fix these dependencies, the following actions need to be taken:Backend: classic_rpmtrans
Continue? [y/n/v/…? shows all options] (y):
Normal dup still wants to delete systemd-32bit
why the resolver wants to remove libsystemd0 it shouldn’t be removed
that’s should be ok after seeing you history i think the problem it wants to delete the systemdlib the 64 and 32
for troubleshooting purpose could try to lock libsystemd0
could you update with adding debug resolver argument --debug-solver
Could it be a race condition? Zypper removes systemd and then tries to upgrade but since it removed sudo it can’t install anything after that?
so it worked ?
i don’t see any errors
oh that’s was the test case
i didn’t notice
the test case is folder not just a file
if you can upload it as a archive (that’s before locking systemdlib)
you can try normally upgrading(dup) after locking the systemdlib
the idea i want to know the offending package
@lavadrop There’s a couple of things you can do:
sudo rpm --rebuilddb, then sudo zypper ref -f and sudo zypper dupzypper lr -dThis is not a phenomenon I’m seeing ( multiple machines, nor reports ), hence my suggestions
No. Systemd and sudo are unrelated. And even if they were not, zypper doesn’t need sudo anymore for the current program run; it’s just used to elevate zypper to run with root privileges. zypper dup runs for a while, but while it does, it doesn’t need sudo (or even systemd), even though it uses a separate external rpm command for each package.
Doesn’t Steam use 32 bit libraries? Maybe that’s the root cause why you even get them installed. I am not sure, but I read about this: Leap 16.0 doesn’t install with 32 bit support, so users had difficulties to get Steam to run. Please correct me if I am wrong.
The resulting system in my 4 failed upgrades has always ended up without libPAM and sudo.
Yes, not only does steam require 32-bit libraries, streaming with Steam Link requires Mesa-libva32bit for hardware accelerated HEVC.
From packman, of course.