Login no longer possible after update to Thumbleweed 20190512

English Install/Boot/Login
1

After yesterday evening’s automatic update I’m no longer able to login to my Tumbleweed installation on my Thinkpad laptop.
The machine still boots, but the graphical login screen does not appear. In a console I cannot input my password because after entering the user name the system directly switches back to requesting the user name instead of asking for the password.

I extracted the drive and attached it to another machine. Looking in the logs gave me a hint that pam_unix.so no longer loads. The reason is an unfulfilled dependency on a special libcrypt version.

I tried to update to newer versions of pam_unix.so and/or libcrypt, but it seems I already have the latest. Any ideas how to solve this?

Excerpt from /var/log/messages:


2019-05-14T11:24:49.921389+02:00 t440p systemd: PAM unable to dlopen(/lib64/security/pam_unix.so): /lib64/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /lib64/security/pam_unix.so)
2019-05-14T11:24:49.921469+02:00 t440p systemd: PAM adding faulty module: /lib64/security/pam_unix.so
2019-05-14T11:24:49.922724+02:00 t440p systemd[2183]: PAM failed: Module is unknown
2019-05-14T11:24:49.922850+02:00 t440p systemd[2183]: user@481.service: Failed to set up PAM session: Operation not permitted
2019-05-14T11:24:49.922931+02:00 t440p systemd[2183]: user@481.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
2019-05-14T11:24:49.923356+02:00 t440p systemd[1]: user@481.service: Failed with result 'protocol'.
2019-05-14T11:24:49.923656+02:00 t440p systemd[1]: Failed to start User Manager for UID 481.
2019-05-14T11:24:49.923723+02:00 t440p systemd[1]: user-runtime-dir@481.service: Unit not needed anymore. Stopping.
2019-05-14T11:24:49.923940+02:00 t440p sddm-helper: pam_systemd(sddm-greeter:session): Failed to create session: Start job for unit user@481.service failed with 'failed'
2019-05-14T11:24:49.924749+02:00 t440p systemd[1]: Stopping /run/user/481 mount wrapper...
2019-05-14T11:24:49.925884+02:00 t440p sddm-helper[2180]: [PAM] openSession: Module is unknown
2019-05-14T11:24:49.925977+02:00 t440p sddm[2159]: Error from greeter session: "Module is unknown"
2019-05-14T11:24:49.940857+02:00 t440p systemd[1]: Stopped /run/user/481 mount wrapper.

Dependencies of pam_unix.so (inside a chroot env):


donald:/lib64/security # ldd pam_unix.so
./pam_unix.so: /lib64/libcrypt.so.1: version `XCRYPT_2.0' not found (required by ./pam_unix.so)
        linux-vdso.so.1 (0x00007ffcfd19a000)
        libpam.so.0 => /lib64/libpam.so.0 (0x00007fbebabd9000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fbebab9c000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fbebab70000)
        libnsl.so.2 => /usr/lib64/libnsl.so.2 (0x00007fbebab55000)
        libtirpc.so.3 => /lib64/libtirpc.so.3 (0x00007fbebab20000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fbeba95e000)
        libaudit.so.1 => /usr/lib64/libaudit.so.1 (0x00007fbeba935000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fbeba930000)
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fbeba8a0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fbebac50000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007fbeba852000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbeba831000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007fbeba74f000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007fbeba72f000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fbeba729000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007fbeba719000)
        libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007fbeba713000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fbeba6f9000)
        libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fbeba26f000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fbeba253000)
2

Hi and welcome to the Forum :slight_smile:
How are you updating your system, should only be via zypper dup?

Sounds like this fixed bug with sshd (zypper dup not being used);
https://bugzilla.opensuse.org/show_bug.cgi?id=1128555

3

Thanks for the fast reply!

I must confess that I don’t know what happens behind the scenes. I just update when the KDE Software Update Widget indicates that there are updates available.

As I didn’t do any special configuration that should use the standard behavior for a KDE Tumbleweed.

But I’ll try to run a zypper dup and see what happens.

4

Tou should NOT use that KDE Update thing. Tumbleweed is only to be updated with

zypper dup
5

That updater applet should be unusable. In my case it reports ‘Use zypper dup’. And has done so for quite a while. AFAIK a fix for the Plasma5 applet is on the way, to allow it to perform ‘zypper dup’ … But, Henk is right, for the moment one can only use ‘zypper dup’ due to TW’s nature of being released as a distro version over and over again.

6

I really hope that I’m not out of line here with this post. I apologise if I am.
Although I don’t use Tumbleweed, but Leap 15.0, I’ve seen it many times where someone unwittingly used that “widget” updater.
I would think that somewhere up the line, a decision must be made about ridding Tumbleweed of that aformentioned “widget”.
Or simply defaulting it to disabled and locked.
It’s just my opinion, of course. It’s just that it seems that we hear of this waaayyy too often.
And if it’s a question of having chosen an inappropriate openSUSE version, then they will learn fairly quickly, I would think, that they will have to inform themselves (probably here on this forum) on how to update their Tumbleweed system.
And of course we will help them graciously if they ask for it, because that is one of things we who frequent here like to do.

7

TW is a test bed for leap and SUSE so all things need to be tested. Agreed that many who don’t understand the nature of TW and think it is normal distro should be warned some way. Adjusting the desktop updater to do dup would help a lot.

Be sure to have plenty of band-aids when riding the cutting edge :stuck_out_tongue:

8

chroot to that busted drive again, “zypper ref” and “zypper dup”, get out and try booting it again. (For future reference, you can boot a live iso from a thumb drive instead of yanking the drive out to another machine for diagnostics.)