3rd attempt to upgrade to Leap 16.0 from 15.6 ... failed

English Install/Boot/Login
1

I tried the 3rd time to upgrade from Leap 15.6 to Leap 16.0 but the attempt failed again. I did keep an extensive list of log files so hopefully we can find out what might be wrong.

Command %inxi -GSaz

System:
  Kernel: 6.4.0-150600.23.103-default arch: x86_64 bits: 64 compiler: gcc
    v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz-6.4.0-150600.23.103-default
    root=UUID=c39847c8-a96b-4977-a909-47b19192521c
    rootflags=subvol=/@/.snapshots/701/snapshot
    resume=/dev/disk/by-uuid/852ce9d3-6aed-4215-9396-3ce492397c04
    preempt=full security=apparmor mitigations=auto quiet loglevel=3
  Desktop: KDE Plasma v: 5.27.11 tk: Qt v: 5.15.12 wm: kwin_x11 vt: 2
    dm: SDDM Distro: openSUSE Leap 15.6
Graphics:
  Device-1: AMD Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
    vendor: Hewlett-Packard driver: amdgpu v: kernel arch: GCN-4
    code: Arctic Islands process: GF 14nm built: 2016-20 pcie: gen: 3
    speed: 8 GT/s lanes: 8 ports: active: HDMI-A-1 empty: DP-1,DP-2
    bus-ID: 05:00.0 chip-ID: 1002:699f class-ID: 0300 temp: 37.0 C
  Device-2: Logitech CrystalCam driver: snd-usb-audio,uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-1.1:3
    chip-ID: 046d:0894 class-ID: 0102 serial: <filter>
  Display: x11 server: X.Org v: 1.21.1.11 compositor: kwin_x11 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: radeonsi gpu: amdgpu
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: HDMI-A-1 mapped: HDMI-1 model: HP 25es serial: <filter>
    built: 2016 res: 1920x1080 hz: 60 dpi: 88 gamma: 1.2
    size: 553x309mm (21.77x12.17") diag: 633mm (24.9") ratio: 16:9 modes:
    max: 1920x1080 min: 720x400
  API: OpenGL v: 4.6 Mesa 23.3.4 renderer: AMD Radeon RX 550 / 550 Series
    (radeonsi polaris12 LLVM 17.0.6 DRM 3.57 6.4.0-150600.23.103-default)
    direct-render: Yes

All the log files are:

zypp.history https://paste.opensuse.org/pastes/f0c7ebca0955

migration_attempt.log https://paste.opensuse.org/pastes/59f0f13b6685

migration_journal.log https://paste.opensuse.org/pastes/53db1d7adb86

zyyper.part1.log https://paste.opensuse.org/pastes/476bc71b7cce
zypper.part2.log https://paste.opensuse.org/pastes/d87a6344c671
zypper.part3.log https://paste.opensuse.org/pastes/2d1ef599a81e
zypper.part4.log https://paste.opensuse.org/pastes/ded3f1d45e23
zypper.part5.log https://paste.opensuse.org/pastes/576b01708da9
zypper.part6.log https://paste.opensuse.org/pastes/85e65b3f8419
zypper.part7.log https://paste.opensuse.org/pastes/8895e8b1fdd5
zypper.part8.log https://paste.opensuse.org/pastes/c354b3b1d234
zypper.part9.log https://paste.opensuse.org/pastes/3087ead2d77f
zypper.part10.log https://paste.opensuse.org/pastes/bc2d8ff8988b
zypper.part11.log https://paste.opensuse.org/pastes/25df894a9378
zypper.part12.log https://paste.opensuse.org/pastes/205d0840ca04
zypper.part13.log https://paste.opensuse.org/pastes/b20dd82c85b4
zypper.part14.log https://paste.opensuse.org/pastes/4ccb116c157c
zypper.part15.log https://paste.opensuse.org/pastes/a2f30ae91f12
zypper.part16.log https://paste.opensuse.org/pastes/29b9291dfd80
zypper.part17.log https://paste.opensuse.org/pastes/5a8c5c87e47c
zypper.part18.log https://paste.opensuse.org/pastes/2e24f9a71010
zypper.part19.log https://paste.opensuse.org/pastes/e782684d63fa
zypper.part20.log https://paste.opensuse.org/pastes/ee482eb5e7d1
zypper.part21.log https://paste.opensuse.org/pastes/a3214c4b287e
zypper.part22.log https://paste.opensuse.org/pastes/1915d9c1abf1
zypper.part23.log https://paste.opensuse.org/pastes/9afc7ae74f45

I am guessing but I noticed again a key file removal which caused problems in the past.

migration_attempt.log:(5240/5579) Removing: libffi7-32bit-3.2.1.git259-10.8.x86_64 [...done]
migration_attempt.log:(5370/5579) Removing: libffi7-3.2.1.git259-10.8.x86_64 [...done]

This upgrade attempt was over 5.5 hours in time.

What can I do to get a successful upgrade?

Here’s the boot log: boot log

- Randall

2

I overlooked the last zypper log file, sorry about this zypper log part23

3 
SATResolver.cc(solverInitSetSystemRequirements):561 SYSTEM Requires glibc
SATResolver.cc(solverInitSetLocks):606 Locked 0 installed items and 0 NOT installed items.

606 packages locked, maybe because of glibc. That’s all I have for now, I’m not very advanced in my knowledge about the internals of a Linux system.

4

Early this morning I took a careful look at the migration_attempt.log. After removing the good installs or removes, I was left with a curious set of 19 glib-compile-schema errors, see glib-compile-schema errors .

I had Gemini AI scan the log and it made a recommendation to fix the system

I had a discussion with Gemini AI about the fact that these glib-compile-schema errors look connected to the Gnome desktop.

It sketched out a discussion on its findings and I would like comment on the accuracy of these comments. Certainly the 19 glib-compile-schema errors did occur and they point at something broken, during the upgrade attempt.

Here’s the discussion points (and remember AI can make mistakes)

Topic: Leap 16.0 Upgrade Brick / Critical GLib2 RPM File Trigger Dependency Loop

Summary

During a zypper dup upgrade to Leap 16.0 on a system with the GNOME Desktop Pattern installed, a critical package ordering mismatch occurs. Zypper updates glib2-tools early in the transaction, but delays upgrading or activating the core runtime library (libglib-2_0-0 / glib2). 

As a result, subsequent installations of thousands of GNOME-related packages trip an RPM File Trigger that executes a broken, mismatched /usr/bin/glib-compile-schemas binary, throwing symbol lookup errors and exiting with status 127. This leaves the system in an unbootable state (unable to reach Runlevel 5 / graphical target). 

Evidence from errors.log :

The break begins early in the transaction sequence and cascades across over 4,000 package installations: 

    • Step 1093/5579 (The Breakpoint): glib2-tools is upgraded, but the execution environment is broken: 
      Plaintext

    • Step (1093/5579) Installing: glib2-tools-2.84.4-160000.2.1.x86_64 [... 
      /usr/bin/glib-compile-schemas: symbol lookup error: /usr/bin/glib-compile-schemas: undefined symbol: g_variant_builder_init_static 
      warning: %triggerin(glib2-tools-2.84.4-160000.2.1.x86_64) scriptlet failed, exit status 127 ..done]

* **Steps 2626 through 5242+ (The Cascade):** Every subsequent GNOME desktop schema or application package (e.g., `gsettings-desktop-schemas`, `simple-scan`, `evince`, `gnome-disk-utility`) fires `%filetriggerin`, executing the broken binary and failing silently via scriptlet exits.

* **Step 5271/5579 (The Proof of Wrong Order):** Even near the very end of the upgrade, `glib2-devel` is pulled in, but the runtime shared library environment still has not been resolved or refreshed via `ldconfig`

---

### Why This is a Leap 16.0 Upgrade System-Killer

Because openSUSE’s GNOME pattern relies heavily on GSettings schemas, the system forces a broken tool to execute thousands of times sequentially.

Because core system services depend on a properly linked and configured GLib2 library ecosystem, the system stalls out completely on reboot and cannot initialize the display manager or network targets.

### Current Post-Upgrade Workaround

If the system bricks, it must be rescued via a Live USB or `init=/bin/bash` chroot by manually executing:
```bash
sudo ldconfig
sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
sudo zypper dup

Questions for the Gurus :

    1. Is there an open bug tracking the dependency/order calculation for glib2-tools vs its runtime shared libraries during a major distribution upgrade?
    2. Should glib2-tools or glib2 include a post-install hint that forces an immediate ldconfig execution before processing subsequent file triggers in the RPM transaction queue?

Personally I am very leary of attempting to do this fix on a system in a rather raw state when it cannot come up to the graphical mode level.

sudo ldconfig
sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
sudo zypper dup

Should I remove ALL the gnome code entirely from my system and attempt the upgrade again?

- Randall

5

Probably save more time on a backup and fresh install… I have no insight to why, originally there was no migration path for Leap 16.0 since it was a very intrusive change…

6

You might be right. Comments by Deep Seek on upgrade failure. Earlier in this series of attempted upgrades, I did see problems with the libffi.so.7 file and it is a key file.

7

Suggest if you go ahead with a fresh install, setup /boot/efi “type ef00” and size 2-4GB to future-proof…

8

An unbootable state does not directly equate to graphical.target unreachable! If one is able to boot to multi-user.target, login as root on any of ttys 3-6, and find working network and zypper, one ought to be able to use zypper (e.g. dup, mr, dr, ar, etc.) to finish upgrading GDM & Gnome I would think, as long as no non-default repos are allowed to interfere.

9

This is what Claude Opus v4.8 found:

There it is — the smoking gun for the entire problem. Both /usr/local/lib64 and /usr/local/lib are explicitly listed in /etc/ld.so.conf itself, which means they’ve been taking priority over /usr/lib64 system libraries for every single process on this machine. This is why every KDE, Firefox, and system process was loading the /usr/local glib instead of the system one.

This single file is the root cause of the entire upgrade failure. When the migration installed Leap 16.0 binaries that needed glib 2.84, ldconfig pointed them at your manually-built glib 2.80 in /usr/local instead.

So it looks like all this is my fault.

I consider this problem resolved and yes, this is a bit embarrassing.

- Randall

1 Like
10

One more thing. I carefully followed advice from the internet about the ld.so.conf file and local executables, but this (now, as is obvious) has led to this breakdown on upgrading. I have lots of mathematics and scientific programs which run in the /usr/local folders, but I am trying to establish the correct structures so that future upgrades are possible and I won’t have to endure this trial again.

11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.