Bugzilla – Bug 1221322
cannot open yast software management app, caller yast.rb:186:in `import_pure'
Last modified: 2024-07-15 12:06:38 UTC
Created attachment 873462 [details] y2log when trying to open yast software management app i get this error: ` Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: /usr/lib64/ruby/vendor_ruby/3.3.0/yast/yast.rb:186:in `import_pure' Details: component cannot import namespace 'Pkg' ` I attached the log. Also "sudo zypper dup" doesnt work, with error: ` sudo zypper dup [sudo] password for root: zypper: error while loading shared libraries: libabsl_log_internal_check_op.so.2308.0.0: cannot open shared object file: No such file or directory ` Restarting does not help.
If any of the needed shared libs is not available, that's clearly not a YaST problem. I suspect that one of the recent package updates went wrong, and one of the library packages could not be installed at all or not correctly. Now the challenge is to find out which one, and what exactly happened.
On my Leap 15.5 with all the latest YaST packages from YaST:Head (the development project), I have libabsl_log_internal_check_op.so.2308.0.0 which belongs to package libabsl2308_0_0-20230802.1-150400.10.4.1.x86_64 from Wed Feb 21 19:00:27 2024, as "rpm -qa --last | grep libabsl" tells me. Please check ldd /usr/bin/zypper (no root permissions needed) if it complains about any missing shared libary; I suspect that it does.
The exact error from the first unsuccessful attempt to start "yast2 sw_single": > 2024-03-11 11:14:35 <3> 2024-03-11 11:14:33 <1> > localhost.localdomain(22495) [Ruby] bin/y2start(<main>):22 > y2base called with ["sw_single", "qt", "-name", "YaST2", "-icon", "yast"] > ... > 2024-03-11 11:14:35 <3> localhost.localdomain(22495) [liby2] > Y2PluginComponent.cc(loadPlugin):234 > error loading plugin /usr/lib64/YaST2/plugin/libpy2Pkg.so.2: > libabsl_log_internal_check_op.so.2308.0.0: > cannot open shared object file: No such file or directory
This was the last recent working YaST start a few days earlier, also with "yast2 sw_single": > 2024-03-02 11:41:58 <1> localhost.localdomain(6758) [Ruby] bin/y2start(<main>):22 > y2base called with ["sw_single", "qt", "-name", "YaST2", "-icon", "yast"] This went without a problem. Unfortunately, it was 9 days earlier; a lot of things may have happened during that time. What is that thing anyway? Let's check: > % rpm -qi libabsl2308_0_0 > Name : libabsl2308_0_0 > Version : 20230802.1 > Release : 150400.10.4.1 > Architecture: x86_64 > Install Date: Mi 21 Feb 2024 19:00:27 CET > Group : Unspecified > Size : 1835905 > License : Apache-2.0 > Signature : RSA/SHA256, Di 13 Feb 2024 13:10:44 CET, Key ID 70af9e8139db7c82 > Source RPM : abseil-cpp-20230802.1-150400.10.4.1.src.rpm > Build Date : Di 13 Feb 2024 13:10:06 CET > Build Host : h01-ch3c > Relocations : (not relocatable) > Packager : https://www.suse.com/ > Vendor : SUSE LLC <https://www.suse.com/> > URL : https://abseil.io/ > Summary : C++11 libraries which augment the C++ stdlib > Description : > Abseil is a collection of C++11 libraries which augment the C++ > standard library. It also provides features incorporated into C++14 > and C++17 standards. > Distribution: SUSE Linux Enterprise 15 "Abseil" (to descend with a rope in mountaineering); very witty. Somebody tried to be funny. Ha ha. zypper.log: > 2024-03-09 15:20:36 command root@localhost.localdomain 'zypper' 'dup' > 2024-03-09 15:20:49 remove libabsl2308_0_0 20230802.1-3.1 x86_64 ... > 2024-03-09 15:21:40 install libabsl2401_0_0 20240116.1-1.1 x86_64 https-download.opensuse.org-9bff3fb4 06f9...2809 So package libabsl2308 was removed during a "zypper dup", and package libabsl2401 was installed instead. Notice that in this case, the number is part of the package name, not just the version number of the same package. The reasoning for that is that programs on your system might need the older version (as this bug report shows), so you might want to have several versions installed. But 'zypper dup' chose to remove the older one and keep just the newer one. I don't see it in that log, but zypper might have prompted you about a dependency conflict and what to do. Or a depencency might be missing; when I mark libabsl2308 for deletion on my Leap 15.5, I get a dozen dependency conflicts about vlc (the video player) and libprotobuf-lite25, but none about zypper or libzypp.
I am not sure if this is a problem on the libzypp side or of that libabsl. But if this 'zypper dup' replaced one version with another while the old one was still required, there might be a missing 'requires' dependency somewhere. I didn't see any complaint that libzypp or zypper wouldn't work anymore when I tried to remove it. It was just the 'vlc' video player that caused any complaints, and that is a package that users might or might not have installed. -> libzypp maintainers. And to preempt that question: yast2-pkg-bindings (the package part of YaST) just uses libzypp, and of course it relies on the dependencies of libzypp being set up correctly. The source package for libabsl is 'abseil-cpp' with those maintainers: % osc maintainer -e abseil-cpp Defined in project: devel:microos bugowner of abseil-cpp : rbrown@suse.com maintainer of abseil-cpp : lnussel@suse.com, kukuk@suse.com, rbrown@suse.com, fvogt@suse.com, dcermak@suse.com, -
Now, what can you do to get your system up and running again? Right now your package and update stack is wrecked; libzypp and thus zypper and "yast2 sw_single". But the plain "rpm" command is still working, to it might be an option to download the libabsl2308_0_0 package manually and install it manually with "rpm -Uhv --force". Or, since you are using Btrfs, go back to a snapshot where it still works.
On my TW VM: > ldd /usr/bin/zypper | grep absl | sed -e 's/^[ \t]/> /' > libabsl_log_internal_check_op.so.2308.0.0 => /lib64/libabsl_log_internal_check_op.so.2308.0.0 (0x00007fc401a15000) > libabsl_log_internal_message.so.2308.0.0 => /lib64/libabsl_log_internal_message.so.2308.0.0 (0x00007fc401a09000) > libabsl_log_internal_nullguard.so.2308.0.0 => /lib64/libabsl_log_internal_nullguard.so.2308.0.0 (0x00007fc4022e6000) > libabsl_raw_hash_set.so.2308.0.0 => /lib64/libabsl_raw_hash_set.so.2308.0.0 (0x00007fc401a04000) > libabsl_hash.so.2308.0.0 => /lib64/libabsl_hash.so.2308.0.0 (0x00007fc4019ff000) > libabsl_cord.so.2308.0.0 => /lib64/libabsl_cord.so.2308.0.0 (0x00007fc4019ea000) > libabsl_synchronization.so.2308.0.0 => /lib64/libabsl_synchronization.so.2308.0.0 (0x00007fc4019d8000) > libabsl_strings.so.2308.0.0 => /lib64/libabsl_strings.so.2308.0.0 (0x00007fc4019bc000) > libabsl_throw_delegate.so.2308.0.0 => /lib64/libabsl_throw_delegate.so.2308.0.0 (0x00007fc4019b5000) > libabsl_examine_stack.so.2308.0.0 => /lib64/libabsl_examine_stack.so.2308.0.0 (0x00007fc401310000) > libabsl_log_internal_format.so.2308.0.0 => /lib64/libabsl_log_internal_format.so.2308.0.0 (0x00007fc40130a000) > libabsl_log_internal_proto.so.2308.0.0 => /lib64/libabsl_log_internal_proto.so.2308.0.0 (0x00007fc401305000) > libabsl_strerror.so.2308.0.0 => /lib64/libabsl_strerror.so.2308.0.0 (0x00007fc4012fe000) > libabsl_log_internal_log_sink_set.so.2308.0.0 => /lib64/libabsl_log_internal_log_sink_set.so.2308.0.0 (0x00007fc4012f8000) > libabsl_log_internal_globals.so.2308.0.0 => /lib64/libabsl_log_internal_globals.so.2308.0.0 (0x00007fc4012f3000) > libabsl_log_globals.so.2308.0.0 => /lib64/libabsl_log_globals.so.2308.0.0 (0x00007fc4012ed000) > libabsl_time.so.2308.0.0 => /lib64/libabsl_time.so.2308.0.0 (0x00007fc4012d9000) > libabsl_base.so.2308.0.0 => /lib64/libabsl_base.so.2308.0.0 (0x00007fc4012d1000) > libabsl_raw_logging_internal.so.2308.0.0 => /lib64/libabsl_raw_logging_internal.so.2308.0.0 (0x00007fc4012cc000) > libabsl_city.so.2308.0.0 => /lib64/libabsl_city.so.2308.0.0 (0x00007fc4012c7000) > libabsl_low_level_hash.so.2308.0.0 => /lib64/libabsl_low_level_hash.so.2308.0.0 (0x00007fc4012c2000) > libabsl_cordz_info.so.2308.0.0 => /lib64/libabsl_cordz_info.so.2308.0.0 (0x00007fc4012bb000) > libabsl_cord_internal.so.2308.0.0 => /lib64/libabsl_cord_internal.so.2308.0.0 (0x00007fc4012aa000) > libabsl_crc_cord_state.so.2308.0.0 => /lib64/libabsl_crc_cord_state.so.2308.0.0 (0x00007fc4012a1000) > libabsl_cordz_functions.so.2308.0.0 => /lib64/libabsl_cordz_functions.so.2308.0.0 (0x00007fc40129c000) > libabsl_kernel_timeout_internal.so.2308.0.0 => /lib64/libabsl_kernel_timeout_internal.so.2308.0.0 (0x00007fc401296000) > libabsl_stacktrace.so.2308.0.0 => /lib64/libabsl_stacktrace.so.2308.0.0 (0x00007fc401291000) > libabsl_malloc_internal.so.2308.0.0 => /lib64/libabsl_malloc_internal.so.2308.0.0 (0x00007fc40128a000) > libabsl_spinlock_wait.so.2308.0.0 => /lib64/libabsl_spinlock_wait.so.2308.0.0 (0x00007fc401283000) > libabsl_strings_internal.so.2308.0.0 => /lib64/libabsl_strings_internal.so.2308.0.0 (0x00007fc40127d000) > libabsl_symbolize.so.2308.0.0 => /lib64/libabsl_symbolize.so.2308.0.0 (0x00007fc4011da000) > libabsl_str_format_internal.so.2308.0.0 => /lib64/libabsl_str_format_internal.so.2308.0.0 (0x00007fc4011c1000) > libabsl_log_sink.so.2308.0.0 => /lib64/libabsl_log_sink.so.2308.0.0 (0x00007fc4011bc000) > libabsl_time_zone.so.2308.0.0 => /lib64/libabsl_time_zone.so.2308.0.0 (0x00007fc4011a1000) > libabsl_int128.so.2308.0.0 => /lib64/libabsl_int128.so.2308.0.0 (0x00007fc40119a000) > libabsl_cordz_handle.so.2308.0.0 => /lib64/libabsl_cordz_handle.so.2308.0.0 (0x00007fc401194000) > libabsl_crc32c.so.2308.0.0 => /lib64/libabsl_crc32c.so.2308.0.0 (0x00007fc40118e000) > libabsl_exponential_biased.so.2308.0.0 => /lib64/libabsl_exponential_biased.so.2308.0.0 (0x00007fc401189000) > libabsl_debugging_internal.so.2308.0.0 => /lib64/libabsl_debugging_internal.so.2308.0.0 (0x00007fc401180000) > libabsl_demangle_internal.so.2308.0.0 => /lib64/libabsl_demangle_internal.so.2308.0.0 (0x00007fc40113b000) > libabsl_crc_internal.so.2308.0.0 => /lib64/libabsl_crc_internal.so.2308.0.0 (0x00007fc401135000) When I try to remove all libabsl* packages: > # zypper rm "libabsl*" > Reading installed packages... > Resolving package dependencies... > > The following 81 packages are going to be REMOVED: > PackageKit PackageKit-backend-zypp PackageKit-branding-openSUSE autoyast2 > autoyast2-installation cockpit-packagekit libabsl2308_0_0 > libprotobuf-lite25_1_0 libyui-ncurses-pkg-devel libyui-ncurses-pkg16 > libyui-qt-pkg16 libzypp libzypp-devel patterns-base-base > patterns-base-basesystem patterns-base-enhanced_base > patterns-base-sw_management patterns-base-x11 patterns-base-x11_enhanced > patterns-desktop-imaging patterns-devel-C-C++-devel_C_C++ > patterns-devel-base-devel_basis patterns-kde-devel_qt5 patterns-xfce-xfce > patterns-xfce-xfce_basis patterns-yast-yast2_basis patterns-yast-yast2_desktop > purge-kernels-service snapper-zypp-plugin yast2 yast2-add-on yast2-apparmor > yast2-auth-client yast2-auth-server yast2-bootloader yast2-control-center > yast2-control-center-qt yast2-country yast2-firewall yast2-installation > yast2-iscsi-client yast2-journal yast2-ldap yast2-mail > yast2-metapackage-handler yast2-network yast2-nfs-client yast2-nfs-server > yast2-nis-client yast2-ntp-client yast2-online-update > yast2-online-update-configuration yast2-online-update-frontend yast2-packager > yast2-pam yast2-pkg-bindings yast2-printer yast2-proxy yast2-samba-client > yast2-samba-server yast2-scanner yast2-security yast2-services-manager > yast2-slp yast2-snapper yast2-sound yast2-storage-ng yast2-sudo yast2-support > yast2-sysconfig yast2-tftp-server yast2-tune yast2-update yast2-users yast2-vm > yast2-vpn yast2-widget-demo zypper zypper-aptitude zypper-lifecycle-plugin > zypper-needs-restarting > > The following 14 patterns are going to be REMOVED: > base basesystem devel_C_C++ devel_basis devel_qt5 enhanced_base imaging > sw_management x11 x11_enhanced xfce xfce_basis yast2_basis yast2_desktop > > 81 packages to remove. > After the operation, 53.3 MiB will be freed. > Continue? [y/n/v/...? shows all options] (y): Notice that this includes 'libzypp'. So dependencies are set up somehow.
By lucky coincidence, that TW VM was last updated with 'zypper dup' on 2024-03-06, so I have your scenario just prior to that 'zypper dup' that caused the problems. When I use "yast2 sw_single" to search for libabsl, I find both: [x] libabsl2308_0_0 [ ] libabsl2401_0_0 I can mark the newer one, libabsl2401_0_0, for installation without a problem; then I'd get both which is okay since they bring different shared libs with different so-names and version numbers. [x] libabsl2308_0_0 [+] libabsl2401_0_0 But when I now mark the older one for removal, I get a dependency conflict about libprotobuf-lite25. One of the solutions is to remove that one; but when I do that, I get in the installation summary: [-] libabsl2308_0_0 [-] libprotobuf-lite25_1_0 [+] libabsl2401_0_0 [u] libzypp [+] libprotobuf-lite25_2_0 So simply wants to upgrade libzypp; that shouldn't do any harm.
Doing a 'zypper dup' on that TW VM works without a problem, and zypper / libzypp / yast2 sw_single work just fine afterwards. It updates 361 packages and removed some; it left me with: > # rpm -qa | egrep '(zypper|libzypp|libabsl|libprotobuf)' | sort > libabsl2401_0_0-20240116.1-1.1.x86_64 > libprotobuf-c1-1.5.0-1.5.x86_64 > libprotobuf-lite25_2_0-25.2-10.1.x86_64 > libprotobuf-lite3_21_12-21.12-1.5.x86_64 > libzypp-17.31.31-1.3.x86_64 > libzypp-devel-17.31.31-1.3.x86_64 > zypper-1.14.68-1.4.x86_64 > zypper-aptitude-1.14.68-1.4.noarch > zypper-lifecycle-plugin-0.6.1601367426.843fe7a-3.8.noarch > zypper-log-1.14.68-1.4.noarch > zypper-needs-restarting-1.14.68-1.4.noarch Notice the newer libabsl2401_0_0 and libprotobuf-lite25_2_0, just like in the "yast2 sw_single" case.
After a "zypper ref" and pre-downloading the packages with "zypper dup -dRy": > # zypper dup > Loading repository data... > Reading installed packages... > Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. > Computing distribution upgrade... > . > The following 40 items are locked and will not be changed by any action: > Available: > baloo5-file kernel-firmware kernel-firmware-all ... > ... > ... > The following 349 packages are going to be upgraded: > ImageMagick Mesa Mesa-KHR-devel Mesa-dri Mesa-gallium Mesa-libEGL-devel Mesa-libEGL1 Mesa-libGL-devel Mesa-libGL1 > Mesa-libglapi0 Mesa-libva MozillaFirefox MozillaThunderbird PackageKit PackageKit-backend-zypp > PackageKit-gstreamer-plugin PackageKit-gtk3-module branding-openSUSE checkmedia chkstat cifs-utils cmake cmake-doc-qhelp > cmake-full cmake-gui cmake-man cockpit cockpit-bridge cockpit-networkmanager cockpit-packagekit cockpit-storaged > cockpit-system cockpit-ws cpp13 dirmngr engrampa engrampa-lang expat fontconfig fontconfig-devel gcc13 gcc13-c++ > gcc13-info gdmflexiserver gettext-runtime gettext-tools ghostscript ghostscript-x11 gnome-themes-accessibility > gnome-themes-accessibility-gtk2 gpg2 graphviz graphviz-devel graphviz-gd graphviz-gnome graphviz-plugins-core grub2 > grub2-branding-openSUSE grub2-i386-pc grub2-i386-pc-extras grub2-snapper-plugin grub2-systemd-sleep-plugin gstreamer > gstreamer-plugins-bad gstreamer-plugins-base gstreamer-plugins-good gstreamer-plugins-good-gtk gtk2-engine-hcengine > gtk2-engine-murrine gtk2-metatheme-adwaita gtk2-theming-engine-adwaita gtk3-metatheme-adwaita hwdata java-11-openjdk > java-11-openjdk-headless kbd kbd-legacy kexec-tools kpartx libLLVM14 libLLVM15 libLLVM16 libLLVM17 > libMagickCore-7_Q16HDRI10 libMagickWand-7_Q16HDRI10 libQt5Pdf5 libQt5PdfWidgets5 libSDL-1_2-0 libSDL2-2_0-0 libSvtAv1Enc1 > libXaw3d8 libassuan0 libatkmm-1_6-1 libcdio19 libcdt5 libcgraph6 libclang-cpp14 libclang-cpp15 libclang-cpp16 > libclang-cpp17 libclang13 libdbusmenu-glib4 libdbusmenu-gtk3-4 libeconf0 libexiv2-28 libexpat-devel libexpat1 > libexttextcat libexttextcat-2_0-0 libfontconfig1 libgarcon-branding-openSUSE libgbm1 libgdata22 libgee-0_8-2 > libgiomm-2_68-1 libglibmm-2_68-1 libgstadaptivedemux-1_0-0 libgstallocators-1_0-0 libgstapp-1_0-0 libgstaudio-1_0-0 > libgstbadaudio-1_0-0 libgstbasecamerabinsrc-1_0-0 libgstcodecparsers-1_0-0 libgstcodecs-1_0-0 libgstcuda-1_0-0 > libgstfft-1_0-0 libgstgl-1_0-0 libgstisoff-1_0-0 libgstmpegts-1_0-0 libgstpbutils-1_0-0 libgstphotography-1_0-0 > libgstplay-1_0-0 libgstplayer-1_0-0 libgstreamer-1_0-0 libgstriff-1_0-0 libgstrtp-1_0-0 libgstrtsp-1_0-0 libgstsctp-1_0-0 > libgstsdp-1_0-0 libgsttag-1_0-0 libgsttranscoder-1_0-0 libgsturidownloader-1_0-0 libgstva-1_0-0 libgstvideo-1_0-0 > libgstvulkan-1_0-0 libgstwayland-1_0-0 libgstwebrtc-1_0-0 libgstwebrtcnice-1_0-0 libgvc6 libgvpr2 libkpathsea6 > liblab_gamut1 liblzma5 libmariadb3 libmediacheck-devel libmediacheck6 libmpath0 libopenjp2-7 libopus0 liborc-0_4-0 > libotr5 libpackagekit-glib2-18 libpathplan4 libpng16-16 libpoppler-cpp0 libpoppler-glib8 libprotobuf-c1 libpulse-devel > libpulse-mainloop-glib0 libpulse0 libpython2_7-1_0 libqt5-qtpdf-devel libqt5-qtwebengine libqt5-qtwebengine-devel > libraptor2-0 librdf0 libsigc-3_0-0 libstartup-notification-1-0 libstdc++6-devel-gcc13 libstorage-ng-lang > libstorage-ng-ruby libstorage-ng1 libsynctex2 libtextstyle0 libtracker-sparql-3_0-0 libunbound8 libwacom-data libwacom9 > libwrap0 libxatracker2 libxcb-composite0 libxcb-damage0 libxcb-dbe0 libxcb-devel libxcb-dpms0 libxcb-dri2-0 libxcb-dri3-0 > libxcb-glx0 libxcb-present0 libxcb-randr0 libxcb-record0 libxcb-render0 libxcb-res0 libxcb-screensaver0 libxcb-shape0 > libxcb-shm0 libxcb-sync1 libxcb-xf86dri0 libxcb-xfixes0 libxcb-xinerama0 libxcb-xinput0 libxcb-xkb1 libxcb-xtest0 > libxcb-xv0 libxcb-xvmc0 libxcb1 libxdot4 libxfce4panel-2_0-4 libxfce4ui-branding-openSUSE libxklavier16 libzypp > libzypp-devel mc mc-lang metatheme-adwaita-common mkfontscale multipath-tools openSUSE-release > openSUSE-release-appliance-custom ovmf patch patterns-kde-devel_qt5 perl perl-Authen-SASL perl-Crypt-SSLeay > perl-DBD-SQLite perl-DBI perl-File-Listing perl-HTTP-Cookies perl-HTTP-Message perl-IPC-Run3 perl-LWP-Protocol-https > perl-URI perl-X11-Protocol perl-X500-DN perl-XML-LibXML perl-XML-Parser perl-XML-SAX perl-XML-Twig perl-YAML > perl-YAML-LibYAML perl-base perl-libwww-perl permissions permissions-config plymouth-branding-openSUSE > polkit-default-privs poppler-tools postfix publicsuffix pulseaudio pulseaudio-bash-completion pulseaudio-module-bluetooth > pulseaudio-module-zeroconf pulseaudio-setup pulseaudio-utils pulseaudio-zsh-completion python python-base python-xml qemu > qemu-accel-qtest qemu-accel-tcg-x86 qemu-audio-spice qemu-block-curl qemu-block-nfs qemu-block-rbd qemu-chardev-spice > qemu-hw-display-qxl qemu-hw-display-virtio-gpu qemu-hw-display-virtio-gpu-pci qemu-hw-display-virtio-vga > qemu-hw-s390x-virtio-gpu-ccw qemu-hw-usb-host qemu-hw-usb-redirect qemu-hw-usb-smartcard qemu-img qemu-ipxe > qemu-ivshmem-tools qemu-ksm qemu-linux-user qemu-microvm qemu-ovmf-x86_64 qemu-pr-helper qemu-seabios qemu-skiboot > qemu-tools qemu-ui-curses qemu-ui-gtk qemu-ui-opengl qemu-ui-spice-app qemu-ui-spice-core qemu-vgabios qemu-x86 scout > system-user-pulse tar tar-rmt thunar-volman-branding-openSUSE typelib-1_0-Gst-1_0 typelib-1_0-PackageKitGlib-1_0 > unbound-anchor vim vim-data vim-data-common virtiofsd virtualbox-guest-tools wallpaper-branding-openSUSE wireplumber > wireplumber-zsh-completion xauth xdm xfce4-clipman-plugin xfce4-clipman-plugin-lang xfce4-notifyd-branding-openSUSE > xfce4-panel xfce4-panel-branding-openSUSE xfce4-panel-lang xfce4-panel-restore-defaults > xfce4-power-manager-branding-openSUSE xfce4-screensaver xfce4-session-branding-openSUSE xfce4-settings-branding-openSUSE > xfce4-taskmanager xfce4-taskmanager-lang xfce4-terminal xfce4-terminal-lang xfdesktop-branding-openSUSE > xfwm4-branding-openSUSE xmessage xxd xz xz-devel yast2-installation yast2-perl-bindings yast2-qt-branding-openSUSE > yast2-storage-ng yast2-trans yast2-trans-de > . > The following pattern is going to be upgraded: > devel_qt5 > . > The following product is going to be upgraded: > openSUSE Tumbleweed 20240304-0 -> 20240311-0 > . > The following 8 NEW packages are going to be installed: > libabsl2401_0_0 libgstanalytics-1_0-0 libgstinsertbin-1_0-0 libgstmse-1_0-0 libpoppler135 libprotobuf-lite25_2_0 > libwireplumber-0_5-0 virtualbox-kmp-default-7.0.14_k6.7.7_1-4.1 > . > The following 4 packages are going to be REMOVED: > libabsl2308_0_0 libpoppler134 libprotobuf-lite25_1_0 libwireplumber-0_4-0 > . > 349 packages to upgrade, 8 new, 4 to remove. > Overall download size: 0 B. Already cached: 671.7 MiB. After the operation, additional 2.8 MiB will be used. > Continue? [y/n/v/...? shows all options] (y): y > . > In cache libstorage-ng-lang-4.5.202-1.1.noarch.rpm (1/357), 181.0 KiB > In cache Mesa-KHR-devel-23.3.6-368.1.x86_64.rpm (2/357), 44.3 KiB > In cache Mesa-libglapi0-23.3.6-368.1.x86_64.rpm (3/357), 64.1 KiB > ... > ... > In cache libstorage-ng-ruby-4.5.202-1.1.x86_64.rpm (355/357), 1.3 MiB > In cache yast2-storage-ng-5.0.9-2.1.x86_64.rpm (356/357), 505.7 KiB > In cache yast2-installation-5.0.7-1.1.noarch.rpm (357/357), 241.7 KiB > . > . > Checking for file conflicts: ........................................................................................[done] > ( 1/361) Removing libprotobuf-lite25_1_0-25.1-9.4.x86_64 ...........................................................[done] > ( 2/361) Removing libabsl2308_0_0-20230802.1-3.1.x86_64 ............................................................[done] > ( 3/361) Installing: libstorage-ng-lang-4.5.202-1.1.noarch .........................................................[done] > ( 4/361) Installing: Mesa-KHR-devel-23.3.6-368.1.x86_64 ............................................................[done] > ( 5/361) Installing: Mesa-libglapi0-23.3.6-368.1.x86_64 ............................................................[done] > ... > ... > ( 32/361) Installing: libabsl2401_0_0-20240116.1-1.1.x86_64 .........................................................[done] > ... > ... > (190/361) Installing: libzypp-17.31.31-1.3.x86_64 ...................................................................[done] > ... > ... > (359/361) Installing: libstorage-ng-ruby-4.5.202-1.1.x86_64 .........................................................[done] > Updating /etc/sysconfig/storage ... > Updating /etc/sysconfig/storage ... > (360/361) Installing: yast2-storage-ng-5.0.9-2.1.x86_64 .............................................................[done] > Updating /etc/sysconfig/security ... > (361/361) Installing: yast2-installation-5.0.7-1.1.noarch ...........................................................[done] > %posttrans(java-11-openjdk-headless-11.0.22.0-3.1.x86_64) script output: > ++ /usr/bin/file --mime-type -b /var/lib/ca-certificates/java-cacerts > ++ stat -c %s /usr/lib64/jvm/java-11-openjdk-11/lib/security/cacerts > ++ /usr/bin/file --mime-type -b -L /usr/lib64/jvm/java-11-openjdk-11/lib/security/cacerts > %posttrans(kbd-2.6.4-3.1.x86_64) script output: > dracut[I]: Executing: /usr/bin/dracut --kver=6.7.6-1-default -f > dracut[I]: Module 'systemd-networkd' will not be installed, because command 'networkctl' could not be found! > dracut[I]: Module 'systemd-networkd' will not be installed, because command '/usr/lib/systemd/systemd-networkd' could not be found! > ... > ... > dracut[I]: Stored kernel commandline: > dracut[I]: resume=UUID=2c1b6f5f-7fae-45ac-9c8d-b92e1d7c76b3 > dracut[I]: root=UUID=89e85f7f-478e-4ee2-a3f7-012a81b9eab9 rootfstype=ext4 rootflags=rw,relatime > dracut[I]: *** Stripping files *** > dracut[I]: *** Stripping files done *** > dracut[I]: *** Creating image file '/boot/initrd-6.7.7-1-default' *** > dracut[I]: *** Creating initramfs image file '/boot/initrd-6.7.7-1-default' done *** > %posttrans(openSUSE-release-20240311-2801.1.x86_64) script output: > /etc/issue.d/cockpit.issue ignored, printed by agetty > Running post-transaction scripts ....................................................................................[done] > There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs. Notice that 'zypper' still works (and so does 'yast2 sw_single): > balrog-tw-dev:~ # zypper dup > Loading repository data... > Reading installed packages... > Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. > Computing distribution upgrade... > > The following 40 items are locked and will not be changed by any action: > Available: > baloo5-file kernel-firmware kernel-firmware-all ... > ... > Nothing to do.
I don't know what went wrong in your case. I would have thought that it would break just the same on my TW VM; but it didn't.
The broken virtiofsd package (#1220592) fails to install. CLASSIC_RPMTRANS offers to abort/retry/ignore. Choosing ignore to see if at lest the remaining packages can be installed is often a better choice. But the transaction was aborted before zypper was updated as well. To fix the system they may need to download and install these packages manually (e.g. with curl and rpm): libprotobuf-lite25_2_0 libsolv-tools libzypp zypper Maybe missing additional dependencies as well.
> # 2024-03-09 15:23:09 virtiofsd-1.10.1-3.1.x86_64.rpm install failed > # rpm output: > # error: unpacking of archive failed on file /usr/libexec/virtiofsd;65ec70cd: > cpio: File from package already exists as a directory in system > # error: virtiofsd-1.10.1-3.1.x86_64: install failed > # error: virtiofsd-1.10.1-2.1.x86_64: erase skipped > # > # 2024-03-09 15:27:03 %posttrans and %transfiletrigger scripts are not executed when aborting! > # Commit was aborted. *** This bug has been marked as a duplicate of bug 1220592 ***
OK, good catch. But didn't we keep the package updates for the package/update stack closer together to avoid this kind of thing? I am aware that this only makes the risk smaller, it doesn't eliminate it. But having an update-the-update-stack step first and then update all the rest sounds a lot safer to me. Like in this case, with 361 packages to be upgraded and libzypp being somewhere in the middle of them (190/361), that leaves a lot of chances for some package to have some glitch, and it never gets to the point where libzypp would update itself, leaving a half-updated (=wrecked) update stack behind.
(In reply to Stefan Hundhammer from comment #14) > But didn't we keep the package updates for the package/update stack closer > together to avoid this kind of thing? The ordering is solely based on dependencies and disrupted by cyclic dependencies. It's not always easy 'to keep things together'. The preferred strategy for CLASSIC_RPMTRANS would be to try to continue on an error rather than to abort immediately. With SINGLE_RPMTRANS this happens automatically, because the librpm transaction is not interruptible at all. It will try to do as much as possible.
Hi, I just rolled back to one of previous snapshot and "sudo zypper dup" the issue no longer exists. You can close the bug if you want.
The latest libzypp no longer depends on protobuf.
*** This bug has been marked as a duplicate of bug 1227741 ***