Post Install very little in the GUI works

SUSE Product Topics SLES Install-Boot
1

I have two servers I have upgraded from 11.SP4 to 15 running in Hyper-V. Both of them are exhibiting this problem.

The issue I am running into is essentially all Gnome applications are broken. Terminal and Files work, but no Yast module works, Firefox, Wireshark, Yast2 crash, etc.

Here are some of the errors I see:

Wireshark and Yast2 run from a command line fail with:

wireshark.desktop[5160]: /usr/bin/wireshark: symbol lookup error : /usr/lib64/libQt5XcbQpa.so.5: undefined symbol: FT-Get_Font_Format

Firefox fails with the following:

firefox.desktop[5232]: XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
firefox.desktop[5232]:/usr/local/lib/libz.so.1: version ‘ZLIB_1.2.9’ not found (required by /usr/lib64/firefox/libxul.so)
firefox.desktop[5232]: Couldn’t load XPCOM

rpm -qa | grep zlib shows:

zlib-devel-1.2.11-1.422.x86_64 is installed

Running yast modules from the Gnome interface creates these errors

gnomesu-pam-packend[5293]: pam_systemd(gnomesu-pam:session): Cannot create session: Already running in a sesson
YaST2-timezone.desktop[5285]: terminate called after throwing an instance of ‘YUIPluginException’
YaST2-timezone.desktop[5285]: what(): Couldn’t load plug-in qt

libyui-qt8-2.49.2-1.30.x86_64 is installed on these systems.

I’m currently at a loss. I’ve check the repositories and I believe they are correct. These are the 2 I believe should be Enabled and they are:

SLE-Module-Basesystem15-Pool
SLE-Module-Basesystem15-Updates

I ran an forced zypper update and dup and nothing will currently download on these servers indicating they are up-to-date.

Did the installer bork these systems somehow and what ideas does anyone have to correct it?

2

Hi and welcome to the Forum :slight_smile:
So, how did you go through the upgrade process?

Your missing a few repositories by the looks;

SLE-Product-SLES15-Pool
SLE-Product-SLES15-Updates

Perhaps consider running SUSEConnect to de-register and cleanup, then re-register the system and it should pick up the ones required. Then try a zypper dup again.

3

DVD iso Update.

I didn’t list all the repositories…the system is currently in a configuration where cut/paste doesn’t work and its internet connection was cutoff the moment the upgrade process finished. (i.e. I’m manually typing everything from this server to the browser window)

There are 51 repos in the full list spanning all the modules that have been created in the new version. I just listed the two that I expect to be the relevant repos.

4

I was able to convince TPTB to re-attach this to the internet temporarily. I de-registered and re-registered the servers. The repository list changed dramatically…down to 16. It looks like it removed Module repos.

zypper dup and zypper update only brought down an sssd update. No other changes. Everything is still in the same broken state on both servers.

5

Hi
What is the output from;

zypper lr -E

Where there third party, OBS repos present?

That maybe old info in the ~/ directory. If you create a test user and
login, do the discrepancies duplicate?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.3-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

6

No third party repos.

zypper lr -E shows the following repos:

SLE-Module-Basesystem15-Pool
SLE-Module-Basesystem15-Updates
SLE-Module-SLES15-Pool
SLE-Module-SLES15-Updates
SLE-Module-Server-Applications15-Pool
SLE-Module-Server-Applications15-Updates

I don’t understand your comment about discrepancies.

7

[QUOTE=jaredh;53707]No third party repos.

zypper lr -E shows the following repos:

SLE-Module-Basesystem15-Pool
SLE-Module-Basesystem15-Updates
SLE-Module-SLES15-Pool
SLE-Module-SLES15-Updates
SLE-Module-Server-Applications15-Pool
SLE-Module-Server-Applications15-Updates

I don’t understand your comment about discrepancies.[/QUOTE]
Hi
Since you upgraded there maybe stuff left over in your user directory (/home/username), so if you create a new user and login, do all the things (discrepancies) that are not working now work for the test user.

8

[QUOTE=malcolmlewis;53708]Hi
Since you upgraded there maybe stuff left over in your user directory (/home/username), so if you create a new user and login, do all the things (discrepancies) that are not working now work for the test user.[/QUOTE]

New users are worse. A new user cannot login. It has the following pertinent errors in the log:

WARNING: Application ‘org.gnome.SettingsDaemon.Wacom.desktop’ killed by signal 15 (There are about 20 of these)
Failed to remove greeter program access to the display. Trying to proceed.
Unregistered Authentication Agent for unix-session:c6 (system bus name :1.445, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
WARNING: IceLockAuthFile failed: No such file or directory
gdm_display_finish: assertion ‘GDM_IS_DISPLAY (self)’ failed

Non-root users that were pre-existing CAN login to the graphical interface. They are prompted for elevation but the apps fail.

Root continues to behave as prior.

9

Scratch the new user comment…I didn’t realize initially useradd didn’t create a home directory. Once that was created, the test user could login.

It continues to have the same essential issues though, with the following errors noticeably added:

The gnome keyring socket is not owned with the same credentials as the user login: /run/user/2001/keyring/control
gkr-pam: couldn’t unlock the login keyring

10

[QUOTE=jaredh;53727]Scratch the new user comment…I didn’t realize initially useradd didn’t create a home directory. Once that was created, the test user could login.

It continues to have the same essential issues though, with the following errors noticeably added:

The gnome keyring socket is not owned with the same credentials as the user login: /run/user/2001/keyring/control
gkr-pam: couldn’t unlock the login keyring[/QUOTE]
Hi
That error is normally a password user change has not synced with the seahorse/keyring…

As root user cd to the user directory and remove ~/.local/share/keyrings/* reset the user password and try logging in.

Can you detail your upgrade process to get from SLE 11 to SLE 15?

11

Hi
Re upgrade path, was it offline as per;
https://www.suse.com/documentation/sles-15/book_sle_upgrade/data/cha_upgrade-offline.html

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.3-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

12

[QUOTE=malcolmlewis;53728]
That error is normally a password user change has not synced with the seahorse/keyring…

As root user cd to the user directory and remove ~/.local/share/keyrings/* reset the user password and try logging in.[/QUOTE]

No change. Same error still occurs.

Just a DVD iso Upgrade from fully patched 11 SP4 systems. Nothing unusual beyond fighting tooth and nail to get the internet connection to work since the installer doesn’t (easily) allow network configuration (SUSE should reconsider taking network configuration out of the installer and making it all boot parameters :rolleyes:)

We cut our teeth on the first one. The second one we had no trouble getting through to SCC. I’ve been doing most of my testing on the second one to take the first one out of the equation, although it behaves the same.

13

[QUOTE=malcolmlewis;53729]Hi
Re upgrade path, was it offline as per;
https://www.suse.com/documentation/sles-15/book_sle_upgrade/data/cha_upgrade-offline.html
[/QUOTE]

Unless the DVD installer brings it online behind the scenes, it would have been offline. These were booted from the DVD through the Update choice from the DVD menu.

14

I should add both of these systems were cloned before the 11 SP4 → 15 upgrade and simultaneously upgraded to 12 SP3 (we are testing both).

12 SP3 doesn’t have the same issue…it runs clean.

I am in the process of cloning one of the 12 SP3 systems and upgrading it to SLES 15 to see if putting an intermediate step between 11 and 15 fixes the problem. I’m hoping this is something the kernel upgrade process breaks and just goes away with 12 → 15.

15

jaredh Wrote in message:
[color=blue]

I should add both of these systems were cloned before the 11 SP4 → 15
upgrade and simultaneously upgraded to 12 SP3 (we are testing both).

12 SP3 doesn’t have the same issue…it runs clean.

I am in the process of cloning one of the 12 SP3 systems and upgrading
it to SLES 15 to see if putting an intermediate step between 11 and 15
fixes the problem. I’m hoping this is something the kernel upgrade
process breaks and just goes away with 12 → 15.[/color]

Your reference to cloning leads me to ask whether the original was
registered before being cloned or was each clone registered after
being restored?

HTH.

Simon Flood
SUSE Knowledge Partner

----Android NewsGroup Reader----
http://usenet.sinaapp.com/

16

[QUOTE=smflood;53736]j

Your reference to cloning leads me to ask whether the original was
registered before being cloned or was each clone registered after
being restored?
[/QUOTE]

Sorry wasn’t clear there. I started with 2 production servers that I copied to make 4 new ones. I completely renamed/sanitized them and registered all of them to SCC on 11SP4 first…12 and 15 would not upgrade these servers due to the old NCC registrations they had (both versions insist on SCC registrations be in place before upgrading).

17

OK here’s the update for 11SP4 → 12SP3 → 15

This ends up with a different GUI than the 11SPR → 15 update does. Where the direct update goes to a GUI with the pulldown for apps in the top left, going through 12 retains the 12 GUI (bottom right for apps)

It also breaks exactly the same as the direct update…same errors on the same apps.

At this point, I am starting to suspect Updates to 15 are broken from the current ISO.

18

I have figured out the issue.

We had zlib version 1.2.8 installed (when it was bleeding edge) for an app and had /usr/local/lib higher in LD_LIBRARY_PATH than the system path.

Removing the old local libraries and rebooting entirely fixed this problem.

19

[QUOTE=jaredh;53759]I have figured out the issue.

We had zlib version 1.2.8 installed (when it was bleeding edge) for an app and had /usr/local/lib higher in LD_LIBRARY_PATH than the system path.

Removing the old local libraries and rebooting entirely fixed this problem.[/QUOTE]
Hi
Thanks for reporting back that you solved the issue :slight_smile:

20

jaredh Wrote in message:
[color=blue]

Sorry wasn’t clear there. I started with 2 production servers that I
copied to make 4 new ones. I completely renamed/sanitized them and
registered all of them to SCC on 11SP4 first…12 and 15 would not
upgrade these servers due to the old NCC registrations they had (both
versions insist on SCC registrations be in place before upgrading).[/color]

Okay so my interpretation of the above is that you registered,
cloned, then copied. Based on that I’ll note that your copied
machines will share the same registration details thus SCC will
have an incorrect view of them i.e. If you created two copies
from one cloned machine SCC will think they are one machine. You
should therefore unregister then re-register each
copy.

HTH.

Simon Flood
SUSE Knowledge Partner

----Android NewsGroup Reader----
http://usenet.sinaapp.com/