Upgrade Leap 15.6 to 16.0

Hello,

I’ve done 3 upgrades from 15.6 to 16.0 on 2 laptops and 1 desktop system using my old method of “zypper --releasever=16.0 ref” and then “zypper --releasever=16.0 dup” after doing all the other preparation work. Today I have tried another desktop system as a test but this one is failing. It shows me the amount of packages to install and then starts to install packages after around 500 it reaches rpm and then the next package after that fails. See below

( 503/3853) Installing: rpm-config-SUSE-20250328-160000.2.2.noarch […done]
( 504/3853) Installing: rpm-4.20.1-160000.2.2.x86_64 […

Updating /etc/sysconfig/services …
.done]

( 505/3853) Installing: p11-kit-tools-0.25.5-160000.2.2.x86_64 [.
warning: Found bdb_ro Packages database while attempting ndb backend: using bdb_ro backend.( 505/3853) Installing: p11-kit-tools-0.25.5-160000.2.2.x86_64 [.

warning: Found bdb_ro Packages database while attempting ndb backend: using bdb_ro backend.

warning: Found bdb_ro Packages database while attempting ndb backend: using bdb_ro backend.

warning: Converting database from bdb_ro to ndb backend

error: cannot add record originally at 6

warning: failed to rebuild database: original database remains in place

warning: Found bdb_ro Packages database while attempting ndb backend: using bdb_ro backend.

error: cannot open Packages database in /usr/lib/sysimage/rpm

error]

Installation of p11-kit-tools-0.25.5-160000.2.2.x86_64 failed:

Error: Subprocess failed. Error: RPM failed: Command exited with status 1.

I’ve tried retry, ignore without result. When I do abort I get the following

Problem occurred during or after installation or removal of packages:
Failed to cache rpm database (127).
History:

  • ‘rpmdb2solv’ ‘-r’ ‘/’ ‘-D’ ‘/usr/lib/sysimage/rpm’ ‘-X’ ‘-p’ ‘/etc/products.d’ ‘/var/cache/zypp/solv/@System/solv’ ‘-o’ ‘/var/cache/zypp/solv/@System/solvkRVYWh’
    rpmdb2solv: error while loading shared libraries: librpmio.so.8: cannot open shared object file: No such file or directory
    Please see the above error message for a hint.

This to me is indicating that it is still looking for an old library of leap 15.6 which is no longer there I do find librpmio.so.10 which is for leap 16.0. The same for librpm.so

Is there anything I can do here at this point or should I have done something in the first place.

I have found 2 references of people having the same issues but not really had resolutions either.

The migration tool has also been mentioned quite a few times but just as often people complain that it fails as well hence I haven’t tried that method myself yet.

https://bugzilla.opensuse.org/show_bug.cgi?id=1242188#c10

1 Like

Thank you. Much appreciated.

Issuing the 2 commands in a 2nd terminal did the trick

#rpm -q rpm
warning: Found bdb_ro Packages database while attempting ndb backend: using bdb_ro backend.
rpm-4.20.1-160000.2.2.x86_64

rpmdb --rebuilddb

warning: Converting database from bdb_ro to ndb backend

Thanx for helping out us with older systems out. As my original install is from 2007, I also had to apply

I have still to sort out a successfull boot with the 16.0 kernel, but think that is caused by outdated INITRD modules in /etc/sysconfig/kernel.

Correct I did the boot this morning as last night it failed with the default target issue. I found the resolution this morning and it continued after that fix. It’s going into graphical mode but only 1280x1024 resolution and nvidia kernel modules are not loaded.

Now I’m looking at outdated hardware as I used nvidia G04 with GT710 and it seems that I have to upgrade my graphics card to overcome that issue.

This system does go back to openSUSE 11 or 12 maybe even 10 and has been upgraded ever since.

A PC that old may have an unsupported CPU. Using the migration tool should report whether supported or not. This explains how to test without using the migration tool.

Thank you for that information

I had checked that, the fact that the OS was originally installed like 15 years ago doesn’t mean it is still running on the same hardware, every item of it from back then has likely been changed in my system. I have an AMD R5 inside that does support sse4_2. It was one of the items that did show up in articles around the upgrade as being required. Once I have my new graphics card I’m good to go I think.

Then there might be some software issues coming my way as VirtualBox after 7.0.18 is having issues with PXE and UEFI but I believe they should have been resolved fully in the 7.2 version that is part of Leap 16.0. Also I did try wayland in the Leap 15.6 and on this machine it was unbelievably unresponsive on the mouse, it was very much lagging and unusable. Don’t have that issue on newer builds and VM’s so not sure what is causing that but I can avoid the issue with X11 which I need anyway for another program I’m using and so far not found a proper replacement for.

Why not move away from the Oracle troublemaker? KVM/Qemu is in-kernel. Never issues with kmps,

1 Like

The graphics card is installed and created no issues.

But as I had expected some software issues would rear their head.

Some minor ones I resolved.

But I noticed that immediately after login there is the service plasma-kglobalaccel.service which is a KDE Plasma user-level systemd service that manages global keyboard shortcuts and hotkeys.

It generates quite some disk access on the file .cache/ksycoca6_en-GB_6TSVDJht1NDx4jm4PhNtqsxuNFg= via inotify I see that it accesses .desktop files in .local/share/applications. When I leave it working with the desktop is very hard and slow so the first thing I do is stop that service and it is fine.

Then something similar happens when I open dolphin the file manager. It also goes through .local/share/applications and updating .cache/ksycoca6_en-GB_6TSVDJht1NDx4jm4PhNtqsxuNFg= multiple times per second. This will stop when I close dolphin.

It seems both “processes” do a similar job and access the same file and are both in some sort of endless loop. I’ve had it where I had left dolphin open and after a couple of hours my system started to become low on memory.

As part of trying to fix the issue I have deleted and rebuild the cache.

I do not have baloo file index active at all, this is often mentioned via AI answers

I’ve tried it with a new user with no difference.

I deleted the user .cache directory without a difference.

One thing I did notice was when I remove the NFS links from /etc/fstab the new user has no high disk access when using dolphin, but the service is still generating the same amount of activity.

What is the filesystem on the NFS share?
Are there many small files on it?
Can you show the export from the server and the fstab line from the mount on the clien?

the file-system is ext4 and both servers are running on debian, the client is opensuse leap 16.0

altogether they contain 24k files, mainly music, pictures, movies, iso’s. I wouldn’t say they contain lots of small files. This setup has been in place for a while and not caused issues until the upgrade and they only show a difference when using dolphin as a new user, for all other situations it stays the same high disk access. From inotifywait I see not difference in monitoring /data where the monitoring of /home is quite clear.

server side

/data/LinuxInstall x.21.x.0/22(rw,no_root_squash,sync,insecure,no_subtree_check) 10.8.0.0/24(rw,no_root_squash,sync,insecure,no_subtree_check)
/data/windowsShare x.21.x.0/22(rw,no_root_squash,sync,insecure,no_subtree_check) 10.8.0.0/24(rw,no_root_squash,sync,insecure,no_subtree_check)

/data/MultiMedia/Mp3_Downloaded x.21.x.0/23(rw,no_root_squash,sync,insecure,no_subtree_check) 10.8.0.0/24(rw,no_root_squash,sync,insecure,no_subtree_check)
/data/MultiMedia/_Mp3_Downloaded x.21.x.0/23(rw,no_root_squash,sync,insecure,no_subtree_check) 10.8.0.0/24(rw,no_root_squash,sync,insecure,no_subtree_check)
/data/MultiMedia/Mp3_Private x.21.x.0/23(rw,no_root_squash,sync,insecure,no_subtree_check) 10.8.0.0/24(rw,no_root_squash,sync,insecure,no_subtree_check)
/data/Office/Recipes x.21.x.0/23(rw,no_root_squash,sync,insecure,no_subtree_check) 10.8.0.0/24(rw,no_root_squash,sync,insecure,no_subtree_check)

client side
nfs-01:/data/LinuxInstall/ /data/LinuxInstall nfs noatime,nosuid,x-systemd.automount,x-systemd.device-timeout=10,x-systemd.idle-timeout=0 0 0
nfs-01:/data/windowsShare/ /data/windowsShare nfs noauto,defaults,noatime,vers=4.2,rsize=65536,wsize=65536,_netdev 0 0

nfs-02:/data/MultiMedia/_Mp3_Downloaded /data/MultiMedia/_Mp3_Downloaded nfs noauto,defaults,noatime,vers=4.2,rsize=65536,wsize=65536,_netdev 0 0
nfs-02:/data/MultiMedia/Mp3_Downloaded /data/MultiMedia/Mp3_Downloaded nfs noauto,defaults,noatime,vers=4.2,rsize=65536,wsize=65536,_netdev 0 0
nfs-02:/data/MultiMedia/Mp3_Private /data/MultiMedia/Mp3_Private nfs noauto,defaults,noatime,vers=4.2,rsize=65536,wsize=65536,_netdev 0 0
nfs-02:/data/Office/Recipes /data/Office/Recipes nfs noauto,defaults,noatime,vers=4.2,rsize=65536,wsize=65536,_netdev 0 0

The NFS options for all shares originally were like the one for LinuxInstall, when I did some testing and research changed the other to how they show now but there was no clear difference in behaviour