yast2 not starting any more: loader error similar to already closed bug

https://bugzilla.suse.com/show_bug.cgi?id=937665 indicates it is resolved in 201505, but it fails in a very similar way on my system:

**revue:/tmp #** yast
Error loading language plugin /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: undefined symbol: _ZNK11SymbolEntry8toStringB5cxx11Eb
/usr/lib/YaST2/bin/y2base: symbol lookup error: /usr/lib64/YaST2/plugin/libpy2UI.so.2: undefined symbol: _Z16should_be_loggediRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
**revue:/tmp #** cat /etc/os-release
NAME=openSUSE
VERSION="20150909 (Tumbleweed)"
VERSION_ID="20150909"
PRETTY_NAME="openSUSE 20150909 (Tumbleweed) (x86_64)"

What are the best steps to bring it under attention again?

  • Will re-opening the existing 937665 give it proper attention?
  • Do I need to open a new issue?

Note I’m not sure when it started failing as I don’t run yast every time I’ve done a zypper dup.

–jeroen

Reopening the bug report will get the proper attention.

The problem is that this bug report wasn’t really a bug.
The reporter had incompatible libraries installed (he filed some more bug reports back then, where it turned out to be caused by self-compiled stuff in /usr/local/ IIRC).

AFAICT, there is no such problem in an up-to-date Tumbleweed system, and definitely not on a fresh installation.

To the OP:

  • Make sure your system is fully up to date, run “sudo zypper dup”. If you get conflicts, please post them.
  • Try to remove self-compiled stuff from /usr/local/ if applicable, in particular related to ruby

If the above doesn’t help, please post your repo list:

zypper lr -d

Follow Up

Agreed. I see that after the update the Yast gui was working. This is not a bug.
Tweaking with Ruby?

Thanks. I think I can rule that out, as I’ve very little in /usr/local: https://gist.github.com/jpluimers/45db52730c7ae7e6eedd

Below is the repo list. zypper dist-upgrade indicates it is up to date. A quite complete log of what I and I have configured the machine is at https://github.com/jpluimers/OpenSuSE.Tumbleweed.Server-Install

I don’t do ruby, but to make sure there is no conflict here are the versions of ruby and python guessing libpy2lang_ruby.so is a binding between the two:

revue:~ # ruby --version
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux-gnu]
revue:~ # python --version
Python 2.7.10

I keep the system up to date about every 1-2 weeks with zypper dist-upgrade.

What’s the easiest way to show which:

  • zypper patterns are installed
  • zypper packages are installed that are not in a pattern

A while ago, I had to kill a zypper dist-upgrade after it was finished hanging in a disconnected ssh session (I started zypper dist-upgrade, lost ssh connection, killed the job hours later). That’s where I learned to use tmux instead.

revue:~ # zypper repos --details --sort-by-priority
#                   | Alias                            | Name                       | Enabled               | GPG Check                  | Refresh | Priority | Type   | URI                                                                                    | Service
--------------------+----------------------------------+----------------------------+-----------------------+----------------------------+---------+----------+--------+----------------------------------------------------------------------------------------+--------
1 | download.opensuse.org-non-oss    | Main Repository (NON-OSS)  | Yes | (r ) Yes | Yes     |   99     | yast2  | http://download.opensuse.org/tumbleweed/repo/non-oss/                                  |        
2 | download.opensuse.org-oss        | Main Repository (OSS)      | Yes | (r ) Yes | Yes     |   99     | yast2  | http://download.opensuse.org/tumbleweed/repo/oss/                                      |        
3 | download.opensuse.org-tumbleweed | Main Update Repository     | Yes | (r ) Yes | Yes     |   99     | rpm-md | http://download.opensuse.org/update/tumbleweed/                                        |        
4 | openSUSE-20150508-0              | openSUSE-20150508-0        | Yes | ( p) Yes | No      |   99     | yast2  | cd:///?devices=/dev/disk/by-id/ata-VMware_Virtual_IDE_CDROM_Drive_10000000000000000001 |        
5 | repo-debug                       | openSUSE-Tumbleweed-Debug  | No  | ----     | Yes     |   99     | NONE   | http://download.opensuse.org/debug/tumbleweed/repo/oss/                                |        
6 | repo-source                      | openSUSE-Tumbleweed-Source | No  | ----     | Yes     |   99     | NONE   | http://download.opensuse.org/source/tumbleweed/repo/oss/                               |        

revue:~ # zypper dist-upgrade
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.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

Nothing to do.

Hm, why do you have git in there and don’t just use the version included in Tumbleweed?
Anyway, shouldn’t be related…

I don’t do ruby, but to make sure there is no conflict here are the versions of ruby and python guessing libpy2lang_ruby.so is a binding between the two:

revue:~ # ruby --version
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux-gnu]
revue:~ # python --version
Python 2.7.10

Well, that’s actually rather a conflict between yast2-ruby-bindings (and yast2-ycp-ui-bindings) and ruby/libruby (python is not used by YaST, unless you would write a module in python using the yast2-python-bindings…) or even libyui.
So please post the output of this as well:

rpm -qi yast2-ruby-bindings yast2-ycp-ui-bindings ruby libruby2_2-2_2 libyui6 libyui-qt6

Although the versions should be ok if “zypper dup” doesn’t have anything to do.

What’s the easiest way to show which:

  • zypper patterns are installed
zypper se -i -t pattern
  • zypper packages are installed that are not in a pattern

I don’t think there’s a way, but it shouldn’t matter.
If you mean, packages that are not in a repo, then it would be this:

zypper packages --orphaned

A while ago, I had to kill a zypper dist-upgrade after it was finished hanging in a disconnected ssh session (I started zypper dist-upgrade, lost ssh connection, killed the job hours later). That’s where I learned to use tmux instead.

Well, interrupting a running update is never a good idea.
Some packages will probably not have been updated yet causing mismatches and crashes (which might even prevent booting), although this should be fixed by another “zypper dup”.
But even if the installed versions match, some of the files might have not been replaced correctly and still present on your hard disk in an older version, or the hard shutdown might have caused changes to the files getting lost before they had been written back.

Maybe try to run “rpm -Va” to verify all installed packages.
This might take very long (and also show false problems), so you might try this first instead:

rpm -V yast2-ruby-bindings yast2-ycp-ui-bindings ruby libruby2_2-2_2 libyui6 libyui-qt6

Btw, I also noticed now that your crashes are actually completely different than the one in the bug report…

Thanks for all the help, I really appreciate that.

I’m providing as much info as I can, bear with me and note I’m not in a hurry: I’d rather sort this out for good than take shortcuts.

Indeed, those are https://github.com/tj/git-extras

Well, that’s actually rather a conflict between yast2-ruby-bindings (and yast2-ycp-ui-bindings) and ruby/libruby (python is not used by YaST, unless you would write a module in python using the yast2-python-bindings…) or even libyui.
So please post the output of this as well:
rpm -qi yast2-ruby-bindings yast2-ycp-ui-bindings ruby libruby2_2-2_2 libyui6 libyui-qt6
Although the versions should be ok if “zypper dup” doesn’t have anything to do.

Short version reveals package libyui-qt6 is not installed (longer is in https://gist.github.com/jpluimers/1a59d80eb393e0491714) which to me is odd as I expected that to be some sort of dependency.

revue:~ # rpm --query yast2-ruby-bindings yast2-ycp-ui-bindings ruby libruby2_2-2_2 libyui6 libyui-qt6
yast2-ruby-bindings-3.1.38-2.2.x86_64
yast2-ycp-ui-bindings-3.1.9-1.2.x86_64
ruby-2.2-1.1.x86_64
libruby2_2-2_2-2.2.3-1.2.x86_64
libyui6-3.2.0-1.1.x86_64
package libyui-qt6 is not installed

zypper se -i -t pattern

I also found out about

zypper packages --installed-only

I don’t think there’s a way, but it shouldn’t matter.
If you mean, packages that are not in a repo, then it would be this:
zypper packages --orphaned

I wasn’t expecting any, but there are. What should I do to resolve these?

revue:~ # zypper packages --orphaned
Loading repository data...
Reading installed packages...
S | Repository | Name         | Version    | Arch  
--+------------+--------------+------------+-------
i | @System    | libdns160    | 9.10.2-9.1 | x86_64
i | @System    | libpoppler52 | 0.33.0-1.3 | x86_64
i | @System    | libpoppler53 | 0.34.0-1.1 | x86_64
i | @System    | libpoppler54 | 0.35.0-1.1 | x86_64

Well, interrupting a running update is never a good idea.

I know, that’s why I waited for a much longer time than a normal zypper dist-upgrade would take. I try not too take too much risk at one time (:

Some packages will probably not have been updated yet causing mismatches and crashes (which might even prevent booting), although this should be fixed by another “zypper dup”.
But even if the installed versions match, some of the files might have not been replaced correctly and still present on your hard disk in an older version, or the hard shutdown might have caused changes to the files getting lost before they had been written back.

Maybe try to run “rpm -Va” to verify all installed packages.
This might take very long (and also show false problems), so you might try this first instead:
rpm -V yast2-ruby-bindings yast2-ycp-ui-bindings ruby libruby2_2-2_2 libyui6 libyui-qt6

I’ve time on my side, but lets to the short one first:

revue:~ # rpm -V yast2-ruby-bindings yast2-ycp-ui-bindings ruby libruby2_2-2_2 libyui6 libyui-qt6
package libyui-qt6 is not installed

Later: actually the verification took like a minute (probably as the system is mostly a text only plus some additions).
Apart from the /boot related files they are all changes I can account for. I think the /boot related files are because of scripts zypper runs after installing the kernel packages; is that right?

revue:~ # rpm --verify --all
S.5....T.  c /etc/samba/smb.conf
....L....  d /usr/share/man/man1/nosetests.1.gz
....L....  c /etc/pam.d/common-account
....L....  c /etc/pam.d/common-auth
....L....  c /etc/pam.d/common-password
....L....  c /etc/pam.d/common-session
/var/cache/squid/: cannot verify squid:root 0750 - not listed in /etc/permissions
/var/log/squid/: cannot verify squid:root 0750 - not listed in /etc/permissions
SM5....T.  c /etc/ssh/moduli
S.5....T.  c /etc/ssh/sshd_config
S.5....T.  c /etc/sudoers
.......T.    /usr/lib64/gconv/gconv-modules.cache
SM5....T.  c /etc/monitrc
S.5....T.  c /etc/ntp.conf
....L....  d /usr/share/man/man1/ftp.1.gz
S.5....T.  c /etc/default/grub
.........    /boot/.vmlinuz-4.1.6-3-default.hmac (replaced)
.........    /boot/vmlinux-4.1.6-3-default.gz (replaced)
.........    /boot/vmlinuz-4.1.6-3-default (replaced)
S.5....T.  c /etc/fonts/conf.d/10-rendering-options.conf
S.5....T.  c /etc/fonts/conf.d/58-family-prefer-local.conf
S.5....T.  c /etc/apparmor.d/local/usr.sbin.smbd-shares
SM5....T.  c /etc/fonts/conf.d/30-metric-aliases.conf
S.5....T.  c /etc/sysconfig/SuSEfirewall2
/usr/sbin/systemd-sysv-convert: line 62: /var/lib/systemd/sysv-convert/database: No such file or directory
No information found about service shadow found.
.M...U...    /var/cache/cups
..5....T.  c /etc/named.conf
S.5....T.  c /etc/apache2/default-server.conf
S.5....T.  c /etc/apache2/ssl-global.conf
S.5....T.  c /etc/sysconfig/SuSEfirewall2.d/services/apache2
/usr/sbin/suexec: cannot verify root:root 0755 - not listed in /etc/permissions
S.5....T.  c /etc/plymouth/plymouthd.conf
.M.......    /etc/cups
.M.......    /var/cache/man
S.5....T.  c /etc/etckeeper/etckeeper.conf

Btw, I also noticed now that your crashes are actually completely different than the one in the bug report…

That’s why I started out with ‘similar’ as it was the only one that came close enough to what I observed.

For now, I think it comes down to package libyui-qt6 is not installed. Searching for that in combination with yast reveals this issue, could it be what I’m bumping into? http://lists.opensuse.org/archive/opensuse-bugs/2015-08/msg02275.html

Those won’t cause a problem, they probably just won’t be used by anything.
You could try to just uninstall them to recover the disk space (which should be negligable).

Background:
Whenever a new incompatible library version is released, also the package name is “bumped” (it contains the so version in the name, i.e. 52, 53, and 54 in the case of libpoppler).
That’s done so that all those incompatible versions can be installed in parallel, and old applications that use/need an older version can still run.
You normally can only install one version of a particular package, so they need to have different names too. But that causes them to be left over after an upgrade. (also YaST/zypper cannot really decide whether you would still need them or not, especially for self-compiled stuff…)

For now, I think it comes down to package libyui-qt6 is not installed. Searching for that in combination with yast reveals this issue, could it be what I’m bumping into? http://lists.opensuse.org/archive/opensuse-bugs/2015-08/msg02275.html

Yes, probably.

Remove any other libyui-qtX you might have installed, and install libyui-qt6. Although you probably don’t have any installed, else it would have been listed as “orphaned”.

To be sure, post the list of all libyui* packages installed:

rpm -qa libyui*

You should have: libyui6, libyui-qt6, libyui-qt-graph6, and libyui-qt-pkg6

FYI, libyui-qt6 is a (strict) requirement of libyui-qt-pkg6, so you probably don’t have the latter installed either.
The main problem here is that those packages are only installed as part of the default patterns. There is a qt and ncurses version from either of them (and in earlier times there was a gtk version too), that makes the dependency chain a bit more complicated, as you shouldn’t necessarily need to have libyui-qt* installed to use YaST.

And to make things worse, yast2-control-center-qt still only recommends “libyui-qt5”…

Thanks, makes a lot of sense. Very similar to http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell where I’m used to (:

Yes, probably.

Remove any other libyui-qtX you might have installed, and install libyui-qt6. Although you probably don’t have any installed, else it would have been listed as “orphaned”.

Don’t take this the wrong way, as I’m assuming qt means Qt UI framework related stuff: why would a text-only system need qt stuff? I have ncurses versions of the libraries installed (see below), and without your help would never have guessed I’d need other versions

To be sure, post the list of all libyui* packages installed:
rpm -qa libyui*
You should have: libyui6, libyui-qt6, libyui-qt-graph6, and libyui-qt-pkg6

FYI, libyui-qt6 is a (strict) requirement of libyui-qt-pkg6, so you probably don’t have the latter installed either.

Like you already guessed:

revue:~ # rpm --query --all  libyui*
libyui6-3.2.0-1.1.x86_64
libyui-ncurses-pkg6-2.47.0-1.4.x86_64
libyui-ncurses6-2.47.2-1.2.x86_64

The main problem here is that those packages are only installed as part of the default patterns.

Which patterns are they part of? And more importantly: why doesn’t zypper update based on the patterns installed?

In the mean time, I found how to list the installed patterns:

revue:~ # zypper patterns --installed-only
Loading repository data...
Reading installed packages...
S | Name             | Version      | Repository | Dependency
--+------------------+--------------+------------+-----------
i | apparmor         | 20150828-2.1 | @System    |           
i | base             | 20150828-2.1 | @System    |           
i | console          | 20150828-2.1 | @System    |           
i | dhcp_dns_server  | 20150828-2.1 | @System    |           
i | enhanced_base    | 20150828-2.1 | @System    |           
i | file_server      | 20150828-2.1 | @System    |           
i | gateway_server   | 20150828-2.1 | @System    |           
i | mail_server      | 20150828-2.1 | @System    |           
i | network_admin    | 20150828-2.1 | @System    |           
i | sw_management    | 20150828-2.1 | @System    |           
i | yast2_basis      | 20150828-2.1 | @System    |           
i | yast2_install_wf | 20150828-2.1 | @System    | 

I also found out how to phrase installed packages in zypper ways. Funny the two commands give such widely different output format:

zypper search --installed-only --type package https://gist.github.com/jpluimers/a21b51414e6ad7cb8298

zypper packages --installed-only https://gist.github.com/jpluimers/3e395b44322eb98c1b46

There is a qt and ncurses version from either of them (and in earlier times there was a gtk version too), that makes the dependency chain a bit more complicated, as you shouldn’t necessarily need to have libyui-qt* installed to use YaST.

And to make things worse, yast2-control-center-qt still only recommends “libyui-qt5”…

Since I have no qt things installed, I don’t have yast2-control-center-qtinstalled either: https://gist.github.com/jpluimers/ac7227d27227099ab3d1

Summarizing: why would yast need a libyui-qt when no qt is installed? And if it does require, why don’t the dependencies tell me?

Well, yes.
If you want to use the ncurses version, you do not need the libyui-qt* stuff.
But I was of the impression you are trying to start YaST in the GUI.
Sorry if I misunderstood, but you never mentioned anything else.

Which patterns are they part of? And more importantly: why doesn’t zypper update based on the patterns installed?

It’s part of the kde4_yast pattern in 13.2 at least, which you haven’t installed.

Summarizing: why would yast need a libyui-qt when no qt is installed? And if it does require, why don’t the dependencies tell me?

It doesn’t.
But yast2 is just a wrapper that tries to load the appropriate GUI.
It might try to load the Qt version in your case which isn’t installed.

So does running “yast” (not “yast2”) work?
[edit]
Sorry, that’s what you posted in the original post anyway, running “yast” gives that error.
[/edit]

You might also try “yast2 --ncurses”, does that give the same error?

I have to admit, I haven’t tried the ncurses version in current Tumbleweed yet (will do so in a minute), but that’s even more unrelated to the bug report you mentioned…

Just to confirm, the ncurses version works fine in my fresh Tumbleweed install too.
But that was a KDE installation in the first place.

Anyway, I don’t think you have incompatible packages installed, a “zypper dup” should have fixed that.
Maybe there is something missing? (although that’s not what the error message would suggest).
I’ll probably try a minimal installation in VirtualBox tomorrow, but I don’t really expect a different outcome either…

You are right: I didn’t and I’m sorry as I should have mentioned it right in the beginning. I’m so used to Unix like systems being back-end and text-only that for me it is a given (I’m a keyboard person since it helped me recover from RSI in the early 1990s http://wiert.me/category/power-user/keyboards-and-keyboard-shortcuts/)

It’s part of the kde4_yast pattern in 13.2 at least, which you haven’t installed.

[QUOTE]Summarizing: why would yast need a libyui-qt when no qt is installed? And if it does require, why don’t the dependencies tell me?

It doesn’t.
But yast2 is just a wrapper that tries to load the appropriate GUI.
It might try to load the Qt version in your case which isn’t installed.

…]

You might also try “yast2 --ncurses”, does that give the same error?
[/QUOTE]Yes it does: all permutations lead to the same error.

revue:~ # yast2 --ncurses
Error loading language plugin /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: undefined symbol: _ZNK11SymbolEntry8toStringB5cxx11Eb
/usr/lib/YaST2/bin/y2base: symbol lookup error: /usr/lib64/YaST2/plugin/libpy2UI.so.2: undefined symbol: _Z16should_be_loggediRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
revue:~ # yast2
Error loading language plugin /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: undefined symbol: _ZNK11SymbolEntry8toStringB5cxx11Eb
/usr/lib/YaST2/bin/y2base: symbol lookup error: /usr/lib64/YaST2/plugin/libpy2UI.so.2: undefined symbol: _Z16should_be_loggediRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
revue:~ # yast --ncurses
Error loading language plugin /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: undefined symbol: _ZNK11SymbolEntry8toStringB5cxx11Eb
/usr/lib/YaST2/bin/y2base: symbol lookup error: /usr/lib64/YaST2/plugin/libpy2UI.so.2: undefined symbol: _Z16should_be_loggediRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
revue:~ # yast
Error loading language plugin /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: /usr/lib64/YaST2/plugin/libpy2lang_ruby.so: undefined symbol: _ZNK11SymbolEntry8toStringB5cxx11Eb
/usr/lib/YaST2/bin/y2base: symbol lookup error: /usr/lib64/YaST2/plugin/libpy2UI.so.2: undefined symbol: _Z16should_be_loggediRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

I have to admit, I haven’t tried the ncurses version in current Tumbleweed yet (will do so in a minute), but that’s even more unrelated to the bug report you mentioned…

You are probably right. And by now I realise I’m probably amongst a minority of text-only openSuSE users.

Well, at least the output you posted in your original question does show that you use the text (ncurses) version.
It’s my fault for not noticing this in the first place…

You are probably right. And by now I realise I’m probably amongst a minority of text-only openSuSE users.

No, not really.
I’m using yast ncurses also every now and then, even on my graphical installation.

Anyway, as mentioned, also yast ncurses works fine here.
I’m not sure at the moment what else to check/try though, I will have to think about it.

The problem is, I’m not sure at all where the “undefined symbols” from your output should be defined in the first place. If we find that out, it will hopefully lead to the problem, as your installed yast2-bindings-ruby is the correct version.

Just one more thought at the moment:
yast itself is contained in the package “yast2”. Which version of that do you have installed?

rpm -qi yast2

And actually, this should be script that calls something else. So you shouldn’t even get that error message I think, even in case of incompatible packages.
So what does this give?

which yast
ls -l `which yast`
which yast2
ls -l `which yast2`

Thanks for all your patience so far.
I’m cutting away some quoting as I’m on the road on mobile.

I can install the qt package and check then uninstall and check again.

Just one more thought at the moment:
yast itself is contained in the package “yast2”. Which version of that do you have installed?
rpm -qi yast2

And actually, this should be script that calls something else. So you shouldn’t even get that error message I think, even in case of incompatible packages.
So what does this give?
which yast ls -lwhich yastwhich yast2 ls -lwhich yast2

This:


revue:~ # rpm -qi yast2
Name        : yast2
Version     : 3.1.149
Release     : 1.1
Architecture: x86_64
Install Date: Wed Sep  2 22:37:13 2015
Group       : System/YaST
Size        : 2048792
License     : GPL-2.0
Signature   : RSA/SHA256, Sat Aug 29 22:31:38 2015, Key ID b88b2fd43dbdc284
Source RPM  : yast2-3.1.149-1.1.src.rpm
Build Date  : Sat Aug 29 22:31:28 2015
Build Host  : build85
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : https://github.com/yast/yast-yast2
Summary     : YaST2 - Main Package
Description :
This package contains scripts and data needed for SUSE Linux
installation with YaST2
Distribution: openSUSE Factory
revue:~ # which yast
/sbin/yast
revue:~ # ls -l `which yast`
lrwxrwxrwx 1 root root 15 Aug 29 22:30 /sbin/yast -> /usr/sbin/yast2
revue:~ # which yast2
/sbin/yast2
revue:~ # ls -l `which yast2`
lrwxrwxrwx 1 root root 15 Aug 29 22:30 /sbin/yast2 -> /usr/sbin/yast2
revue:~ #

Well, that won’t tell where those symbols should come from…

Your output looks fine too.
Well, maybe ldd will show something interesting?

ldd /usr/lib64/YaST2/plugin/libpy2lang_ruby.so

I ran a grep over my /usr/lib64 now (on my 13.2 system) and those symbols should be in libscr.so.3 and libycp.so.5, which are part of the package yast2-core.
So please post the details for this package too (rpm -qi yast2-core), maybe try to reinstall it with:

sudo zypper in -f yast2-core

And just to be sure, reinstall yast2-ruby-bindings too.

I think we get closer:


revue:~ # ldd /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
        linux-vdso.so.1 (0x00007fff4111b000)
        liby2.so.4 => /usr/lib64/liby2.so.4 (0x00007fbb10ba1000)
        libycp.so.5 => /usr/lib64/libycp.so.5 (0x00007fbb10855000)
        libpy2wfm.so.2 => /usr/lib64/YaST2/plugin/libpy2wfm.so.2 (0x00007fbb10640000)
        libruby2.2.so.2.2 => /usr/lib64/libruby2.2.so.2.2 (0x00007fbb101c2000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fbb0fe3f000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbb0fc28000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fbb0f884000)
        liby2util.so.5 => /usr/lib64/liby2util.so.5 (0x00007fbb0f65e000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fbb0f45a000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbb0f23d000)
        libowcrypt.so.1 => /lib64/libowcrypt.so.1 (0x00007fbb0f039000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fbb0edfe000)
        libycpvalues.so.6 => /usr/lib64/libycpvalues.so.6 (0x00007fbb0eb92000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fbb0e893000)
        libscr.so.3 => /usr/lib64/libscr.so.3 (0x00007fbb0e683000)
        /lib64/ld-linux-x86-64.so.2 (0x000056160fd45000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fbb0e47f000)
revue:~ # zypper in -f yast2-core
Loading repository data...
Reading installed packages...
Forcing installation of 'yast2-core-3.1.17-3.4.x86_64' from repository 'Main Repository (OSS)'.
Resolving package dependencies...

Problem: yast2-core-3.1.17-3.4.x86_64 requires perl = 5.22.0, but this requirement cannot be provided
  uninstallable providers: perl-5.22.0-1.3.i586[download.opensuse.org-oss]
                   perl-5.22.0-1.3.x86_64[download.opensuse.org-oss]
 Solution 1: deinstallation of apache2-mod_perl-2.0.9-3.1.x86_64
 Solution 2: do not install yast2-core-3.1.17-3.4.x86_64
 Solution 3: do not install yast2-core-3.1.17-3.4.x86_64
 Solution 4: break yast2-core-3.1.17-3.4.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/4/c] (c): c
revue:~ #
 

Yes, indeed. The current apache2-mod_perl in Tumbleweed does indeed require perl-5.20.1, which doesn’t exist in the repo any more.
I’m not completely sure that this is the source of your problem, but it likely is because that’s what seems to have prevented yast2-core from being updated, which definitely could cause such an incompatibility…

The reason for this “problem” apparently is that apache2-mod_perl fails to build since some time, therefore didn’t get updated and still requires an older perl.
https://build.opensuse.org/package/show/openSUSE:Factory/apache2-mod_perl

Do you need apache2-mod_perl?
If not, try to choose Solution 1, deinstallation of apache2-mod_perl, and see whether it fixes your YaST problem.
If you do need it, it would probably be not a good idea to do that, as it won’t be possible to get the old perl back. We’d have to think of something else then (ideally the build failure should be fixed though of course).

Boy, why didn’t zypper tell me that in the first place? Why would I have to do something like this to see that something is out of date:

revue:~ # zypper info yast2-core
Loading repository data...
Reading installed packages...


Information for package yast2-core:
-----------------------------------
Repository: Main Repository (OSS)
Name: yast2-core
Version: 3.1.17-3.4
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: out-of-date (version 3.1.17-1.2 installed)
Installed Size: 3.2 MiB
Summary: YaST2 - Core Libraries
Description: 
  This package contains the scanner, parser, and interpreter runtime
  library for the YCP scripting language used in YaST2.

My earlier message about aborting zypper a while ago got me thinking, and searching the man zypper further to find verify which turned up the issue below.

Do you have any idea how to solve that first? I’d rather not break my kernel (:

Then later worry about the apache2-mod_perl issue.

revue:~ # zypper verify
Loading repository data...
Reading installed packages...

The following package is going to be reinstalled:
  kernel-default-4.1.6-3.2

1 package to reinstall.
Overall download size: 46.5 MiB. Already cached: 0 B. No additional space will be used or freed after the operation.
Some of the dependencies of installed packages are broken. In order to fix these dependencies, the following actions need to be taken:
Continue? [y/n/? shows all options] (y): d

The following package is going to be reinstalled:
  kernel-default  4.1.6-3.2  x86_64  Main Repository (OSS)  openSUSE


1 package to reinstall.
Overall download size: 46.5 MiB. Already cached: 0 B. No additional space will be used or freed after the operation.
Continue? [y/n/? shows all options] (y): y
Retrieving package kernel-default-4.1.6-3.2.x86_64                                                                         (1/1),  46.5 MiB (222.3 MiB unpacked)
Retrieving: kernel-default-4.1.6-3.2.x86_64.rpm ..............................................................................................[done (5.5 MiB/s)]
Checking for file conflicts: ............................................................................................................................[error]
Detected 3 file conflicts:

File /boot/.vmlinuz-4.1.6-3-default.hmac
  from install of
     kernel-default-4.1.6-3.2.x86_64(Main Repository (OSS))
  conflicts with file from package
     kernel-default-4.1.6-3.1.x86_64(@System)

File /boot/vmlinux-4.1.6-3-default.gz
  from install of
     kernel-default-4.1.6-3.2.x86_64(Main Repository (OSS))
  conflicts with file from package
     kernel-default-4.1.6-3.1.x86_64(@System)

File /boot/vmlinuz-4.1.6-3-default
  from install of
     kernel-default-4.1.6-3.2.x86_64(Main Repository (OSS))
  conflicts with file from package
     kernel-default-4.1.6-3.1.x86_64(@System)

File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
Continue? [yes/no] (no): 

Problem occured during or after installation or removal of packages:
Installation aborted by user

Please see the above error message for a hint.
revue:~ # ls -al /boot
total 27560
drwxr-xr-x 1 root root      546 Sep 27 09:11 .
drwxr-xr-x 1 root root      156 Jun  7 16:18 ..
-rw-r--r-- 1 root root       65 Sep  9 00:23 .vmlinuz-4.1.6-3-default.hmac
-rw-r--r-- 1 root root  3103643 Sep  8 22:40 System.map-4.1.6-3-default
-rw-r--r-- 1 root root      512 May 16 18:03 backup_mbr
-rw-r--r-- 1 root root     1484 May  2 17:53 boot.readme
-rw-r--r-- 1 root root   164308 Sep  8 21:53 config-4.1.6-3-default
drwxr-xr-x 1 root root        0 Sep  3 18:21 dracut
drwxr-xr-x 1 root root      168 Sep 27 09:11 grub2
lrwxrwxrwx 1 root root       22 Sep 12 11:19 initrd -> initrd-4.1.6-3-default
-rw-r--r-- 1 root root 11437520 Sep 27 09:11 initrd-4.1.6-3-default
-rw-r--r-- 1 root root   424448 Jul 11 07:54 message
-rwxr-xr-x 1 root root      166 May 16 18:00 perl-BL_delayed_exec
-rw-r--r-- 1 root root   328864 Sep  8 22:54 symvers-4.1.6-3-default.gz
-rw-r--r-- 1 root root      377 Sep  8 22:54 sysctl.conf-4.1.6-3-default
-rw-r--r-- 1 root root  6859403 Sep  8 23:01 vmlinux-4.1.6-3-default.gz
lrwxrwxrwx 1 root root       23 Sep 12 11:19 vmlinuz -> vmlinuz-4.1.6-3-default
-rw-r--r-- 1 root root  5844432 Sep  9 00:23 vmlinuz-4.1.6-3-default

Don’t worry about that.

This is not really a problem just a “glitch” in combination with multiversion, i.e. having more than one kernel installed.
Those two installed kernels are actually the exact same version 4.1.6-3 (4.1.6-3.2 is just a rebuild), so they contain files with the exact same name installed to exact same place (i.e. file conflicts).
The files from 4.1.6-3.2 overwrote the files from 4.1.6-3.1, so there’s nothing for you to do.

This has been “fixed” in the packaging recently and should not happen in the future.
The next kernel update will resolve that conflict anyway.

I bit the bullet, to see if anything would indeed require

So: neither of these revealed something interesting.


revue:~ # rpm -q --whatrequires apache2-mod_perl
no package requires apache2-mod_perl

revue:~ # find / -type d -name '.snapshots' -prune -o -name '*.pl' -print

I also tracked down in my notes where apache2-mod_perl originally came from:


revue:~ # zypper info --requires --provides --type pattern lamp_server
Loading repository data...
Reading installed packages...


Information for pattern lamp_server:
------------------------------------
Repository: Main Repository (OSS)
Name: lamp_server
Version: 20150828-2.1
Arch: x86_64
Vendor: openSUSE
Installed: No
Visible to User: Yes
Summary: Web and LAMP Server
Description: 
  Software to set up a Web server that is able to serve static, dynamic, and interactive content (like a Web shop). This includes Apache HTTP Server, the
  database management system MySQL, and scripting languages such as PHP, Python, Ruby on Rails, or Perl.
Provides:
  autopattern() == patterns-openSUSE-lamp_server
  pattern:lamp_server == 20150828-2.1
Requires:
  patterns-openSUSE-lamp_server == 20150828-2.1
Contents:

S | Name                          | Type    | Dependency
--+-------------------------------+---------+-----------
i | apache2                       | package |           
i | apache2-doc                   | package |           
i | apache2-example-pages         | package |           
i | apache2-mod_perl              | package |           
i | apache2-mod_php5              | package |           
i | apache2-prefork               | package |           
  | mariadb                       | package | Suggested 
i | patterns-openSUSE-base        | package |           
  | patterns-openSUSE-lamp_server | package |           
i | php5-ctype                    | package |           
i | php5-dom                      | package |           
i | php5-iconv                    | package |           
i | php5-mysql                    | package |           
i | yast2-http-server             | package |

I ditched that as mariadb suddenly started complaining about default installation being not secure for the first time (long after it had been installed for the first time). Software shouldn’t *****, but by default install a secure enough configuration. So I needed to uninstall mariadb which required me to remove the pattern; see https://forums.opensuse.org/showthread.php/508468-zypper-dup-installed-mariadb-on-a-server and https://github.com/jpluimers/OpenSuSE.Tumbleweed.Server-Install#start-with-minimal-server-selection-text-mode

Anyway, I think removing apache2-mod_perl solved my problem, but I’m amazed how many updates this apache2-mod_perl was preventing.
To me this is bug worthy.

revue:~ # zypper remove apache2-mod_perl
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be REMOVED:
  apache2-mod_perl

1 package to remove.
After the operation, 7.5 MiB will be freed.
Continue? [y/n/? shows all options] (y): y
(1/1) Removing apache2-mod_perl-2.0.9-3.1 ................................................................................................................[done]
revue:~ # zypper update yast2-core
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  net-tools-deprecated

The following 127 packages are going to be upgraded:
  apparmor-utils cyrus-imapd ddclient gfxboot git git-core git-cvs git-email git-gui git-svn git-web gitk inn libapparmor1 libsnmp30
  libsvn_auth_gnome_keyring-1-0 mirror perl perl-Archive-Zip perl-Authen-SASL perl-BerkeleyDB perl-Bootloader perl-Bootloader-YAML perl-CPAN-Changes
  perl-Class-Singleton perl-Config-Crontab perl-Convert-ASN1 perl-Convert-BinHex perl-Convert-TNEF perl-Convert-UUlib perl-Crypt-OpenSSL-RSA
  perl-Crypt-OpenSSL-Random perl-Crypt-SmbHash perl-Cyrus-IMAP perl-Cyrus-SIEVE-managesieve perl-DBD-SQLite perl-DBI perl-DateTime perl-DateTime-Locale
  perl-DateTime-TimeZone perl-Devel-Symdump perl-Digest-HMAC perl-Digest-MD4 perl-Digest-SHA1 perl-Dist-CheckConflicts perl-Encode-Detect perl-Encode-Locale
  perl-Error perl-Exporter-Tiny perl-File-Listing perl-HTML-Parser perl-HTML-SimpleParse perl-HTML-Tagset perl-HTTP-Cookies perl-HTTP-Daemon perl-HTTP-Date
  perl-HTTP-Message perl-HTTP-Negotiate perl-IO-HTML perl-IO-Socket-INET6 perl-IO-Socket-SSL perl-IO-stringy perl-LWP-MediaTypes perl-LWP-Protocol-https
  perl-Linux-Pid perl-List-AllUtils perl-List-MoreUtils perl-MIME-tools perl-Mail-DKIM perl-Mail-SPF perl-Mail-SpamAssassin perl-MailTools
  perl-Module-Implementation perl-Module-Runtime perl-Net-CIDR-Lite perl-Net-DBus perl-Net-DNS perl-Net-HTTP perl-Net-IP perl-Net-LibIDN perl-Net-Patricia
  perl-Net-SMTP-SSL perl-Net-SSLeay perl-Net-Server perl-NetAddr-IP perl-Params-Validate perl-Parse-RecDescent perl-Pod-Coverage perl-RPC-XML perl-Socket6
  perl-Sys-Hostname-Long perl-Term-ReadKey perl-TermReadLine-Gnu perl-Test-Pod perl-Test-Pod-Coverage perl-Tie-IxHash perl-TimeDate perl-Try-Tiny perl-URI
  perl-Unix-Syslog perl-WWW-RobotRules perl-X11-Protocol perl-X500-DN perl-XML-LibXML perl-XML-NamespaceSupport perl-XML-Parser perl-XML-SAX perl-XML-SAX-Base
  perl-XML-SAX-Expat perl-XML-Simple perl-XML-Twig perl-XML-XPath perl-YAML-LibYAML perl-apparmor perl-base perl-gettext perl-ldap perl-libwww-perl
  python3-apparmor spamassassin subversion subversion-bash-completion subversion-perl whois yast2-apparmor yast2-core yast2-perl-bindings

127 packages to upgrade, 1 new.
Overall download size: 35.3 MiB. Already cached: 0 B. After the operation, additional 4.4 MiB will be used.
Continue? [y/n/? shows all options] (y): y

As I’ve already put way too much CODE tags in the message, you will find the rest of the download and install log in this gist: https://gist.github.com/jpluimers/e9cf23945d7feddb79e4

Given this zypper ps, I did a reboot, then checked yast:


revue:~ # zypper ps
The following running processes use deleted files:

PID  | PPID | UID  | User    | Command | Service | Files                      
-----+------+------+---------+---------+---------+----------------------------
1    | 0    | 0    | root    | systemd |         | /lib64/libapparmor.so.1.2.1
4915 | 1    | 1000 | jeroenp | systemd |         | /lib64/libapparmor.so.1.2.1
4916 | 0    | 1000 | jeroenp | (sd-pam |         | /lib64/libapparmor.so.1.2.1

You may wish to restart these processes.
See 'man zypper' for information about the meaning of values in the above table.
revue:~ # 

Gues what: yast just works. Problem solved. At the cost of many hours of you and me figuring out what was wrong.

So thanks for all the help.

Thanks also for the kernel info: I’m much more relieved now.