Bugzilla – Bug 1219562
zypper dup killed zypper: can't open librpm.so.9
Last modified: 2024-07-15 07:40:16 UTC
After not updating my TW VM for two weeks (last zypper dup: 2024-01-17), today's 'zypper dup' destroyed the package management stack: (all commands entered as root) # zypper dup -y --download-only (worked without any problem, downloaded 3181 packages) # zypper dup -y ( 330/3181) Installing: openssl-3-3.1.4-3.2.x86_64 ...........................................................................................[error] Installation of openssl-3-3.1.4-3.2.x86_64 failed: Error: Subprocess failed. Error: RPM failed: Command exited with status 1. Abort, retry, ignore? [a/r/i] (a): a Warning: %posttrans and %transfiletrigger scripts are not executed when aborting! Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. # zypper dup -y zypper: error while loading shared libraries: librpm.so.9: cannot open shared object file: No such file or directory # ldconfig # zypper dup -y zypper: error while loading shared libraries: librpm.so.9: cannot open shared object file: No such file or directory
Created attachment 872449 [details] Complete shell session with the 'zypper dup' command
> balrog-tw-dev:~ # ls -l /usr/lib64/librpm* > lrwxrwxrwx 1 root root 15 Oct 9 08:35 /usr/lib64/librpm.so -> librpm.so.9.3.0 > lrwxrwxrwx 1 root root 16 Feb 2 16:06 /usr/lib64/librpm.so.10 -> librpm.so.10.0.1 > -rwxr-xr-x 1 root root 519240 Feb 2 16:06 /usr/lib64/librpm.so.10.0.1 > lrwxrwxrwx 1 root root 20 Oct 9 08:35 /usr/lib64/librpmbuild.so -> librpmbuild.so.9.3.0 > lrwxrwxrwx 1 root root 17 Oct 9 08:35 /usr/lib64/librpmio.so -> librpmio.so.9.3.0 > lrwxrwxrwx 1 root root 18 Feb 2 16:06 /usr/lib64/librpmio.so.10 -> librpmio.so.10.0.1 > -rwxr-xr-x 1 root root 207576 Feb 2 16:06 /usr/lib64/librpmio.so.10.0.1 > lrwxrwxrwx 1 root root 19 Oct 9 08:35 /usr/lib64/librpmsign.so -> librpmsign.so.9.3.0 > lrwxrwxrwx 1 root root 20 Feb 2 16:06 /usr/lib64/librpmsign.so.10 -> librpmsign.so.10.0.1 > -rwxr-xr-x 1 root root 22496 Feb 2 16:06 /usr/lib64/librpmsign.so.10.0.1 > balrog-tw-dev:~ # file /usr/lib64/librpm* | grep broken > /usr/lib64/librpm.so: broken symbolic link to librpm.so.9.3.0 > /usr/lib64/librpmbuild.so: broken symbolic link to librpmbuild.so.9.3.0 > /usr/lib64/librpmio.so: broken symbolic link to librpmio.so.9.3.0 > /usr/lib64/librpmsign.so: broken symbolic link to librpmsign.so.9.3.0 > balrog-tw-dev:~ # rpm -qa | grep -i librpm > balrog-tw-dev:~ #
> balrog-tw-dev:~ # rpm -qa | grep -i rpm > python310-rpm-4.18.0-6.1.x86_64 > python311-rpm-4.18.0-6.1.x86_64 > deltarpm-3.6.3-2.7.x86_64 > rpm-config-SUSE-20240118-1.2.noarch > rpm-build-4.18.0-6.2.x86_64 > rpm-devel-4.18.0-6.2.x86_64 > build-mkdrpms-20240111-1.1.noarch > python-rpm-generators-20231220.98427f3-1.1.noarch > rpm-build-perl-4.19.1-2.2.x86_64 > python-rpm-packaging-20210526+a18ca48-1.9.noarch > python-rpm-macros-20231220.98427f3-1.1.noarch > rpm-4.19.1-2.2.x86_64 > ruby3.2-rubygem-gem2rpm-0.10.1-21.1.x86_64 > rpmdevtools-8.10-7.11.noarch > systemd-rpm-macros-24-1.5.noarch > balrog-tw-dev:~ # ls -l /usr/lib64/librpm*10* > lrwxrwxrwx 1 root root 16 Feb 2 16:06 /usr/lib64/librpm.so.10 -> librpm.so.10.0.1 > -rwxr-xr-x 1 root root 519240 Feb 2 16:06 /usr/lib64/librpm.so.10.0.1 > lrwxrwxrwx 1 root root 18 Feb 2 16:06 /usr/lib64/librpmio.so.10 -> librpmio.so.10.0.1 > -rwxr-xr-x 1 root root 207576 Feb 2 16:06 /usr/lib64/librpmio.so.10.0.1 > lrwxrwxrwx 1 root root 20 Feb 2 16:06 /usr/lib64/librpmsign.so.10 -> librpmsign.so.10.0.1 > -rwxr-xr-x 1 root root 22496 Feb 2 16:06 /usr/lib64/librpmsign.so.10.0.1 > balrog-tw-dev:~ # rpm -qf /usr/lib64/librpm*10* > rpm-4.19.1-2.2.x86_64 > rpm-4.19.1-2.2.x86_64 > rpm-4.19.1-2.2.x86_64 > rpm-4.19.1-2.2.x86_64 > rpm-4.19.1-2.2.x86_64 > rpm-4.19.1-2.2.x86_64 There was a dependency conflict involving rpmbuild, and I chose the option to remove rpmbuild. Not sure if that is related.
I can easily go back to the previous snapshot of my VM, but for the moment I'll leave it as it is in case you need more information.
Created attachment 872451 [details] output of 'rpm -qa' (gzipped)
Created attachment 872452 [details] /var/log/zypper.log (gzipped)
Created attachment 872453 [details] /var/log/zypp/history (gzipped)
They broke the openssl-3 package by a directory<->symlink change: >..............................[done] error: unpacking of archive failed on > file /etc/ssl/engdef.d;65bfeefd: cpio: File from package already exists as > a directory in system > error: openssl-3-3.1.4-3.2.x86_64: install failed > error: openssl-3-3.1.4-2.1.x86_64: erase skipped Unfortunately there's also a major rpm update, which breaks the stack. Most reports tell that at least rpm on the command line still works. If packages were downloaded in advance, libzypp/zypper and their dependencies should be below /var/cache/zypp/packages and could be installed with rpm. Reassigning: Defined in project: security bugowner of openssl : meissner@suse.com
It is unfortuinate you pressed abort instead of ignore, then it would have installed the rest. its a openssl-3 package issue i think.
(In reply to Marcus Meissner from comment #9) > It is unfortuinate you pressed abort instead of ignore, then it would have > installed the rest. > > its a openssl-3 package issue i think. Yes, a directory changed to a symlink. That should really be avoided, but if it's unavoidable it needs to be done in a %pre script. It's unfortunate that this breaks RPM though. Shouldn't zypper try to keep zypper/libzypp/rpm transactions closer together? openssl-3 isn't in the dep chain.
(In reply to Marcus Meissner from comment #9) > It is unfortuinate you pressed abort instead of ignore, then it would have > installed the rest. That was probably due to the '-y' in 'zypper dup -y'.
> If packages > were downloaded in advance, libzypp/zypper and their dependencies should be > below /var/cache/zypp/packages and could be installed with rpm. OK, that seemed to work: > cd /var/cache/zypp/packages > rpm -Uhv ./download.opensuse.org-oss/x86_64/libzypp-17.31.28-1.5.x86_64.rpm ./download.opensuse.org-oss/x86_64/zypper-1.14.68-1.3.x86_64.rpm ./download.opensuse.org-oss/x86_64/libzypp-devel-17.31.28-1.5.x86_64.rpm ./download.opensuse.org-oss/x86_64/libsolv-devel-0.7.28-1.3.x86_64.rpm ./download.opensuse.org-oss/x86_64/libsolv-tools-0.7.28-1.3.x86_64.rpm -> zypper works again Now executing another zypper dup (without -y')
After fixing the update stack manually and restarting 'zypper dup', the update ran without any complaint, and the system fell on its feet. I now have all the latest packages, including openssl-3-3.1.4 which triggered the problem. But I am not so sure if the average user can also recover from this problem.
Incase it helps anyone else, I also needed to install libsolv-tools and my rpm's were hiding in Backup sudo rpm -Uhv Backup/x86_64/libsolv-tools-0.7.28-1.3.x86_64.rpm Backup/x86_64/libzypp-17.31.28-1.5.x86_64.rpm
(In reply to Simon Lees from comment #15) > Incase it helps anyone else, I also needed to install libsolv-tools and my > rpm's were hiding in Backup `Backup` should the alias of providing repo. Most repos in /var/cache/zypp/ have per-repo subdirs based on the repos alias.
(In reply to Michael Andres from comment #16) > (In reply to Simon Lees from comment #15) > > Incase it helps anyone else, I also needed to install libsolv-tools and my > > rpm's were hiding in Backup > > `Backup` should the alias of providing repo. Most repos in /var/cache/zypp/ > have per-repo subdirs based on the repos alias. Yep I forgot that I added and enabled a secondary "Backup" repo that doesn't use my local package cache.
Ping.
Submitted: https://build.opensuse.org/request/show/1144562 https://build.opensuse.org/request/show/1144566 I added scripts to migrate/rename conflicting directories so this issue should no longer be possible.
This is an autogenerated message for OBS integration: This bug (1219562) was mentioned in https://build.opensuse.org/request/show/1144625 Factory / openssl-3
*** Bug 1219797 has been marked as a duplicate of this bug. ***