Category Archives: Opensuse

Upgrade from Leap 15.3 over 15.4, 15.5 up to Leap 15.6 – problems with the named service

Posted on by

Sometimes one takes a challenge with Linux. During my stay in Norway I wanted to find out whether one could bring a really old server system (regarding HW) to the latest Leap version of Opensuse. Such an old system can still serve valuable purposes – as testing complex configurations of server components, using it as an extended IDS/Firewall-system, etc. In my case I was fortunate as the real problem occurred with SW and not HW.

Regarding HW my concerns related to an old Nvidia GT 710. The advantage of this card was/is that it is passively cooled and provides enough power for using both a present KDE or Gnome desktop – if necessary or useful. I was lucky to find that the present G05 Nvidia drivers support this card.

Somewhat unexpectedly, real problems occurred with an installed named-service at the upgrade from 15.3 to Leap 15.4 – and again when upgrading from 15.5 to 15.6. While you can find many complaints on the Internet, I did not find a solution that covered all my problem. Therefore, I want to give Linux users or administrators who experience similar problems some hints.

Continue reading →

Leap 15.6, Nvidia driver 570 – resume from suspend to RAM not working / workaround

Posted on by

Hint: After some experiments and further Internet digging, this post was rewritten and supplemented on the 5th of March, 2025. Sorry for any inconvenience.
—–

Recently, I have upgraded Opensuse Leap to version 15.6 on 5 PC-systems – all with (different) Nvidia graphic cards. I use KDE/Plasma on all these systems.

My daily working system is equipped with a 4060 TI Nvidia card. Nvidia drivers of version 570.124.06-1 on this particular system came from the Nvidia CUDA repository for Opensuse system at

https://developer.download.nvidia.com/ compute/ cuda/ repos/ opensuse15/ x86_64.

I sadly must say that the named particular driver, but also the present Nvidia drivers of version 570.86.16 on other systems, are at least in their corporation with the Linux kernel (6.4.0) and other components of the present Leap 15.6, unreliable or even buggy (for KDE/Plasma):

The resume process from “Suspend to RAM” does not work reliably on any of the systems.

Continue reading →

Leap 15.6 – upgrade from Leap 15.5 on laptop with Optimus architecture

Posted on by

The last 4 months I was primarily occupied with physics. I got a bit sloppy regarding upgrades of my Linux systems. An upgrade of an rather old laptop to Leap 15.6 was overdue. This laptop had an Optimus configuration: To display graphics one can use either the dedicated Nvidia card or a CPU-integrated Intel graphics or both via an “offload” option for certain applications.

General steps to perform the upgrade

I just list up some elementary steps for the upgrade of an Opensuse Leap system – without going into details or potential error handling:

Step 1: Make a backup of the present installation
You can, for example, create images of the partitions or LVM volumes that contain your Leap-installation and transfer them to an external disk. Details depend of course on whether and how you have distributed system files over partitions or (LVM) volumes. In the simple case of just one partition, you may simply boot a rescue system, mount an external disk to /mnt and then use the “dd”-command;

# dd status=progress if=/dev/YOUR_PARTITION of=/mnt/bup_leap155.img  bs=4M

Step 2: Update the installed packages of the present Leap installation
Perform an update of (all) installed packages – if newer versions are available. Check that your system runs flawlessly afterwards.

Step 3: Change the addresses of repositories to use the ${releasever} variable
You can e.g. use YaST to change the release number in the definition of your repositories’ addresses to the variable ${releasever}. The name of the SLES repository may then look like “https://download.opensuse.org/update/leap/${releasever}/sle/”.

Continue reading →

Opensuse Leap 15.5 – KDE Plasma on Wayland – Nvidia driver, Opera, Chromium, Libreoffice, StandBy

Posted on by

Some days ago I wrote a post on Eclipse and discussed fractional scaling of a selected monitor-screen in a Wayland-session. A reader has written to me and asked whether Wayland works on my system (Opensuse Leap 15.5) reasonably well otherwise.

Frankly, it is a bit like in the early days of KDE4. Wayland works, basically – and compared to Leap 15.4 the situation has improved significantly. But I wouldn’t use Wayland on Leap 15.5, yet, for any professional work under time pressure. During periods of hard work you need to trust your work environment to do what it is supposed to do. You should be able focus a 100% on your tasks – and not loose time with some unexpected glitches in your desktop environment.

However, I use Wayland these days when the risks are low. E.g. when writing blog posts or doing some information gathering on the Internet. Just to become prepared for the day when KDE Plasma switches to Wayland as the standard server for graphical applications. With this post I want to share some experiences with Wayland on a Leap 15.5 system – and give some hints regarding potential problems and workarounds.

Continue reading →

Leap/SLES 15.5 – strange compatibility problem between tcpdump, libpcap and arping from iputils

Posted on by

My readers know that I presently work again with virtual networks. A part of my studies is related to ARP and routes on veth devices with VLAN-interfaces. I follow the packet transfer across VLANs with tcpdump, which itself depends on libpcap. On Leap 15 the relevant package is: libpcap1. ARP commands were generated by the arping command, which gets available after an installation of the package “iputils“.

This worked perfectly on a laptop. I know for a presentation had to use another system with the same kernelversion and virtual networking support. There I got strange messages for ARP packets passing a veth endpoint’s main device (in my example: veth2V) on their way to a VLAN interface (“veth2V.30) on the same veth endpoint: 

netns2:~ # tcpdump -n -e -i any -v
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

15:15:36.334692 veth2V B   ifindex 2 46:b9:81:00:00:1e ethertype ARP (0x0806), length 52: Unknown Hardware (36461) (len 0), Unknown Protocol (0x0000) (len 1), Unknown (2048) 
        0x0000:  8e6d 0000 0001 0800 0604 0001 46b9 8b4b  .m..........F..K
        0x0010:  8e6d c0a8 0501 ffff ffff ffff c0a8 0502  .m..............
15:15:36.334692 veth2V.30 B   ifindex 4 46:b9:8b:4b:8e:6d ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.1, length 28
15:15:36.334720 veth2V.30 Out ifindex 4 d2:85:39:c8:43:fc ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Reply 192.168.5.2 is-at d2:85:39:c8:43:fc, length 28
15:15:36.334721 veth2V Out ifindex 2 d2:85:81:00:00:1e ethertype ARP (0x0806), length 52: Unknown Hardware (17404) (len 0), Unknown Protocol (0x0000) (len 1), Unknown (2048) 
        0x0000:  43fc 0000 0001 0800 0604 0002 d285 39c8  C.............9.
        0x0010:  43fc c0a8 0502 46b9 8b4b 8e6d c0a8 0501  C.....F..K.m....

I had never seen similar messages in comparable experiments with veths before. And these messages about “Unknown Hardware”. In addition the length of the Ethernet packets were wrong. I did not get such errors on my laptop where I had prepared the setups of the virtual VLANs.

It took me some time to find the difference between the systems: iputils as well as tcpdump on both systems came from the Network:Utilites-repository
“https://download.opensuse.org/ repositories/ network: /utilities/ 15.5/“.

However, libpcap1 on the presentation system came from the main SLES 15.5 OSS repository in version 1.10.1-150400.1.7. On my laptop I had instead fetched the library from the Network:Utilites-repository, too.

Changing libpcap1 to the present version 1.10.4-lp155.92.1 from the Network:Utilites-repository led to correct tcpdump information: 

netns2:~ # tcpdump -n -e -i any -v
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

15:38:44.899645 veth2V B   ifindex 2 f2:5b:23:ba:16:8a ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.1, length 28
15:38:44.899645 veth2V.30 B   ifindex 4 f2:5b:23:ba:16:8a ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.1, length 28
15:38:44.899667 veth2V.30 Out ifindex 4 9a:88:24:0c:f9:99 ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Reply 192.168.5.2 is-at 9a:88:24:0c:f9:99, length 28
15:38:44.899669 veth2V Out ifindex 2 9a:88:24:0c:f9:99 ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Reply 192.168.5.2 is-at 9a:88:24:0c:f9:99, length 28

Interestingly, even if one changed both tcpdump, iputils and libpcap1 to the main Leap /SLES 15.5 repository the problem would come up, too.

So, there seems to be something severely wrong with libpcap1 of the main Leap /SLES 15.5 repositories.