Serious errors after update

English Applications
1

After running a set of updates, KDE becomes unresponsive. On the following boot I get the following serious error:

[   4.241328][   T669] (sd-executor)[669]: /usr/lib/systemd/system-environment-generators/60-flatpak-system-only failed with exit status 127.
[   4.253482][   T671]: /usr/lib/systemd/system-generators/ostree-system-generator failed with exit status 127.
[FAILED] Failed to start X Display Manager.
[FAILED] to start OpenSSH Daemon.
[FAILED] to start OpenSSH Daemon.
[FAILED] to start OpenSSH Daemon.

Please could someone try to explain what is going on here and how I can identify the update causing the problem?

I don’t understand why it is affecting X-Display manager and SSH assurely these are not related?

Strangely, I have three machines here, all running leap 15.5, all having updates applied as prompted but only the one machine is affected. It is not running any software different from the others - although it does have a different graphics card.

Many thanks for any help.

2

How long before unresponsiveness began after logging in? Does another reboot or two change anything? Did you try an extra zypper ref and zypper up to be sure all went well with updates?

I just finished a 15.5 zypper up on an old Core2Duo with Plasma on LightDM. My dmesg failures differ, and I don’t detect any kind of sloth.

# inxi -CG --vs
inxi 3.3.30-00 (2023-09-25)
CPU:
  Info: dual core model: Intel Core2 Duo E8400 bits: 64 type: MCP cache:
    L2: 6 MiB
  Speed (MHz): avg: 2493 min/max: N/A cores: 1: 1995 2: 2992
Graphics:
  Device-1: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] driver: radeon
    v: kernel
  Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: modesetting
    dri: r600 gpu: radeon resolution: 1: 1920x1200~60Hz 2: 1680x1050~60Hz
  API: EGL v: 1.5 drivers: r600,swrast platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.5 vendor: x.org mesa v: 22.3.5 renderer: AMD CAICOS (DRM
    2.50.0 / 5.14.21-150500.55.31-default LLVM 15.0.7)
  API: Vulkan Message: No Vulkan data available.
# inxi -Saz
System:
  Kernel: 5.14.21-150500.55.31-default arch: x86_64 bits: 64 compiler: gcc
    v: 7.5.0 clocksource: tsc available: hpet,acpi_pm parameters: root=/dev/sda7
    noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full
    mitigations=off
  Desktop: KDE Plasma v: 5.27.4 tk: Qt v: 5.15.8 wm: kwin_x11 vt: 7
    dm: LightDM v: 1.32.0 Distro: openSUSE Leap 15.5
# dmesg | grep -i ailed
[  880.926638] [drm:btc_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed
# journalctl -b | grep -i ailed | egrep -v 'not support|udisks'
Oct 17 19:44:31 gx78b apparmor.systemd[430]: Warning from stdin (line 1): Cache: failed to add read only location '/usr/share/apparmor/cache', does not contain valid cache directory for the specified feature set
Oct 17 19:44:33 gx78b accounts-daemon[668]: g_dbus_interface_skeleton_get_object_path: assertion 'G_IS_DBUS_INTERFACE_SKELETON (interface_)' failed
Oct 17 19:44:33 gx78b kernel: [drm:btc_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed
Oct 17 19:44:48 gx78b org_kde_powerdevil[934]: org.kde.powerdevil: org.kde.powerdevil.backlighthelper.brightness failed
Oct 17 19:44:49 gx78b kwin_x11[903]: kf.config.core: "\"fsrestore1\" - conversion of \"0,0,0,0\" to QRect failed"
Oct 17 19:44:49 gx78b kwin_x11[903]: kf.config.core: "\"fsrestore2\" - conversion of \"0,0,0,0\" to QRect failed"
Oct 17 19:44:49 gx78b kwin_x11[903]: kf.config.core: "\"fsrestore3\" - conversion of \"0,0,0,0\" to QRect failed"
Oct 17 19:44:49 gx78b kwin_x11[903]: kf.config.core: "\"fsrestore4\" - conversion of \"0,0,0,0\" to QRect failed"
Oct 17 19:44:49 gx78b kwin_x11[903]: kf.config.core: "\"fsrestore5\" - conversion of \"0,0,0,0\" to QRect failed"
Oct 17 19:45:07 gx78b kwin_x11[903]: kwin_core: Failed to focus 0x1000023 (error 3)
Oct 17 19:45:07 gx78b kwin_x11[903]: kwin_core: Failed to focus 0x1000023 (error 3)
#

Lots of udisks noise in the journal omitted. Udisks isn’t installed. :stuck_out_tongue:

3

@KermitXYZ:

Please check, from an administrator login on a VT (tty1 … tty6) the status of the following systemd Services:

  • “display-manager.service”

  • “sshd.service”

As a reference, they should look like this:

 # systemctl status display-manager.service 
● display-manager.service - X Display Manager
     Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-10-18 10:19:50 CEST; 2h 57min ago
    Process: 1870 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS)
   Main PID: 1930 (sddm)
      Tasks: 10 (limit: 4915)
     CGroup: /system.slice/display-manager.service
             ├─ 1930 /usr/bin/sddm
             └─ 8716 /usr/bin/X -nolisten tcp -auth /run/sddm/{6cf6ae12-2662-4951-8875-70e42b8c3846} -background none ->

Okt 18 11:36:04 xxx sddm-helper[8793]: [PAM] Conversation with 1 messages
Okt 18 11:36:04 xxx sddm-helper[8793]: [PAM] returning.
Okt 18 11:36:04 xxx sddm[1930]: Authenticated successfully
Okt 18 11:36:04 xxx sddm-helper[8793]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Okt 18 11:36:04 xxx sddm[1930]: Auth: sddm-helper exited successfully
Okt 18 11:36:04 xxx sddm[1930]: Greeter stopped.
Okt 18 11:36:04 xxx sddm-helper[8793]: pam_unix(sddm:session): session opened for user dcu by (uid=0)
Okt 18 11:36:04 xxx sddm-helper[8793]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
Okt 18 11:36:04 xxx sddm-helper[8793]: Starting: "/etc/X11/xdm/Xsession \"/usr/bin/startplasma-x11\""
Okt 18 11:36:04 xxx sddm[1930]: Session started
 # 
 # systemctl status sshd.service 
● sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2023-10-18 10:19:29 CEST; 2h 58min ago
    Process: 1769 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
    Process: 1782 ExecStartPre=/usr/sbin/sshd -t $SSHD_OPTS (code=exited, status=0/SUCCESS)
   Main PID: 1793 (sshd)
      Tasks: 1
     CGroup: /system.slice/sshd.service
             └─ 1793 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Okt 18 10:19:29 xxx systemd[1]: Starting OpenSSH Daemon...
Okt 18 10:19:29 xxx sshd-gen-keys-start[1769]: Checking for missing server keys in /etc/ssh
Okt 18 10:19:29 xxx sshd[1793]: Server listening on 0.0.0.0 port 22.
Okt 18 10:19:29 xxx sshd[1793]: Server listening on :: port 22.
Okt 18 10:19:29 xxx systemd[1]: Started OpenSSH Daemon.
 #
4

@KermitXYZ:

After updating, did you execute “rpmconfigcheck” ?

 # rpmconfigcheck 
Searching for unresolved configuration files
 #
5

I think the problem is caused by an update to Zypper: openSUSE_SLE_15.5-2023-3973(1)

Here are my replies and reasonings:

I have re-imaged the machine again, and re-tried the updates.

How long before unresponsiveness began after logging in?

It starts as soon as the updates have finished. For instance, clicking shutdown does nothing and clicking any program does nothing either. So this time I left a terminal open, and could shutdown with “shutdown now”.

Does another reboot or two change anything?

No.

Did you try an extra zypper ref and zypper up to be sure all went well with updates?

These both give the following response:

> zypper: symbol lookup error: /usr/lib64/libssh.so.4: undefinied symbol: EVP_KDF_CTX_new_id, versionOPENSSL_1_1_1d

Please check, from an administrator login on a VT (tty1 … tty6) the status of the following systemd Services:

  • “display-manager.service”
  • “sshd.service”

Both are running fine, even after the system won’t shutdown by clicking shutdown. Obviously on the next boot they are both failing.

After updating, did you execute “rpmconfigcheck” ?

This gives the following output (after the Zypper update)

Searching for unresolved configuration files
Please check the following files (see /var/adm/rpmconfigcheck):
    /etc/zypp/repos.d/repo-backports-debug-update.repo.rpmsave
    /etc/zypp/repos.d/repo-backports-update.repo.rpmsave
    /etc/zypp/repos.d/repo-sle-debug-update.repo.rpmsave
    /etc/zypp/repos.d/repo-sle-update.repo.rpmsave

This is why I think the Zypper update is the culprit:

When I start the updates, at first I just given ONE, an update for Zypper. I install that, reboot and all is fine. The next time, I have discovered that installing ANY SINGLE ONE of the next block of updates causes the problem.

(nb - I am updating from the GUI not command line if that makes any difference)

So it’s as if the updated Zypper is causing the problem - does the above output from “zypper up” confirm that? If so, what can I do to solve this? Google has drawn a blank.

Thanks for the help so far :slight_smile:

6 
# cat /usr/local/bin/zypsei
#!/bin/sh
zypper --no-refresh se -s -i $*  | grep -Ev 'debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort
# zypsei zypp rpm libssh
i  | libssh-config           | package | 0.9.6-150400.1.5       | x86_64 | OSS
i  | libssh2-1               | package | 1.9.0-150000.4.16.1    | x86_64 | UpdateSLE
i  | libssh4                 | package | 0.9.6-150400.1.5       | x86_64 | OSS
i  | python3-rpm             | package | 4.14.3-150400.59.3.1   | x86_64 | UpdateSLE
i  | rpm                     | package | 4.14.3-150400.59.3.1   | x86_64 | UpdateSLE
i  | rpm-config-SUSE         | package | 1-150400.14.3.1        | noarch | OSS
i  | ruby2.5-rubygem-gem2rpm | package | 0.10.1-3.45            | x86_64 | OSS
i  | systemd-rpm-macros      | package | 13-150000.7.33.1       | noarch | UpdateSLE
i+ | libzypp                 | package | 17.31.20-150400.3.40.1 | x86_64 | UpdateSLE
i+ | zypper                  | package | 1.14.64-150400.3.32.1  | x86_64 | UpdateSLE
#

Do you have the same packages installed as I do? If you have most, but one or two not, I’d think about trying force installating the mismatched one(s) using rpm --nodeps.

7

Such patch does not exist.

Neither libssh.so.4 nor OpenSSL are related to zypper.

bor@leap15:~> readelf -W --dyn-syms /usr/lib64/libcrypto.so.1.1 | grep KDF_CTX_new_id
  2918: 00000000001a990e   275 FUNC    GLOBAL DEFAULT   14 EVP_KDF_CTX_new_id@@OPENSSL_1_1_1d
bor@leap15:~> rpm -qf /usr/lib64/libcrypto.so.1.1
libopenssl1_1-1.1.1l-150500.17.19.1.x86_64

Is libopenssl1_1 installed?

8

The file names of the Zypp configuration files mentioned by “rpmconfigcheck” all have the suffix “.rpmsave”.

  • This means what it says – the update has updated the Zypp configuration settings and, saved the previous configuration settings in the “.rpmsave” files.

Simply, perform a “diff -cw” on a current configuration file and the partnered “.rpmsave” configuration file …

9

Agreed but, this Patch does exist – just a little ‘_’ versus ‘-’ confusion –

 > LANG=C zypper patch-info openSUSE-SLE-15.5-2023-3973
Loading repository data...
Reading installed packages...


Information for patch openSUSE-SLE-15.5-2023-3973:
--------------------------------------------------
Repository  : Update repository with updates from SUSE Linux Enterprise 15
Name        : openSUSE-SLE-15.5-2023-3973
Version     : 1
Arch        : noarch
Vendor      : maint-coord@suse.de
Status      : applied
Category    : recommended
Severity    : moderate
Created On  : Do 05 Okt 2023 10:15:23 CEST
Interactive : restart
Summary     : Recommended update for zypper
Description : 
    This update for zypper fixes the following issues:

    - Fix name of the bash completion script (bsc#1215007)
    - Update notes about failing signature checks (bsc#1214395)
    - Improve the SIGINT handler to be signal safe (bsc#1214292)
    - Update to version 1.14.64
    - Changed location of bash completion script (bsc#1213854).
Provides    : patch:openSUSE-SLE-15.5-2023-3973 = 1
Conflicts   : [9]
    srcpackage:zypper < 1.14.64-150400.3.32.1
    zypper.noarch < 1.14.64-150400.3.32.1
    zypper.x86_64 < 1.14.64-150400.3.32.1
    zypper-aptitude < 1.14.64-150400.3.32.1
    zypper-log < 1.14.64-150400.3.32.1
    zypper-needs-restarting < 1.14.64-150400.3.32.1
    zypper.s390x < 1.14.64-150400.3.32.1
    zypper.ppc64le < 1.14.64-150400.3.32.1
    zypper.aarch64 < 1.14.64-150400.3.32.1

 >

And, one of the things that patch fixes is, this one – <https://bugzilla.suse.com/show_bug.cgi?id=1215007> :sunglasses:

10

@KermitXYZ:

It’s rather strange but, none of the the recent Zypp patches on this Leap 15.5 system caused any changes to the Zypp repository definitions located in ‘/etc/zypp/repos.d/’ …

  • But then, I patch first and then, update afterwards …

  • And, I usually call “zypper refresh --force” to catch any nasty changes in the local copies of each repository’s meta-data …
    Which is also what the PackageKit updater does and, often, the YaST updater …

Bottom line: somewhere, there’s an inconsistency in your system.

  • Please, execute “rpm --rebuilddb”
  • Please, execute “zypper verify”.
  • Please, execute “rpm --verify --all”.
  • Please, correct any errors those commands raise.
1 Like
11

These commands DID allow Zypper to update and the machine rebooted OK. Unfortunately, installing subsequent updates caused exactly the same problem as before.

Therefore, it was quicker to re-install the machine rather than spend further time troubleshooting.

Thank you for all the help everyone :slight_smile: