~> ll /lib/modules/
insgesamt 12
drwxr-xr-x 3 root root 4096 7. Nov 22:28 5.14.21-150500.53-default
drwxr-xr-x 3 root root 4096 7. Nov 19:35 5.14.21-150500.55.31-default
drwxr-xr-x 4 root root 4096 20. Jan 10:43 5.14.21-150500.55.44-default
~> ll /lib/modules/5.14.21-150500.55.44-default/weak-updates/extra/
insgesamt 16
lrwxrwxrwx 1 root root 58 20. Jan 10:42 vboxdrv.ko -> /lib/modules/5.14.21-150500.55.31-default/extra/vboxdrv.ko
lrwxrwxrwx 1 root root 60 20. Jan 10:42 vboxguest.ko -> /lib/modules/5.14.21-150500.55.31-default/extra/vboxguest.ko
lrwxrwxrwx 1 root root 61 20. Jan 10:42 vboxnetadp.ko -> /lib/modules/5.14.21-150500.55.31-default/extra/vboxnetadp.ko
lrwxrwxrwx 1 root root 61 20. Jan 10:42 vboxnetflt.ko -> /lib/modules/5.14.21-150500.55.31-default/extra/vboxnetflt.ko
lrwxrwxrwx 1 root root 57 20. Jan 10:42 vboxsf.ko -> /lib/modules/5.14.21-150500.55.31-default/extra/vboxsf.ko
lrwxrwxrwx 1 root root 60 20. Jan 10:42 vboxvideo.ko -> /lib/modules/5.14.21-150500.55.31-default/extra/vboxvideo.ko
~> ll /lib/modules/5.14.21-150500.55.44-default/weak-updates/updates/
insgesamt 12
lrwxrwxrwx 1 root root 60 20. Jan 10:42 nvidia-drm.ko -> /lib/modules/5.14.21-150500.53-default/updates/nvidia-drm.ko
lrwxrwxrwx 1 root root 56 20. Jan 10:42 nvidia.ko -> /lib/modules/5.14.21-150500.53-default/updates/nvidia.ko
lrwxrwxrwx 1 root root 64 20. Jan 10:42 nvidia-modeset.ko -> /lib/modules/5.14.21-150500.53-default/updates/nvidia-modeset.ko
lrwxrwxrwx 1 root root 60 20. Jan 10:42 nvidia-uvm.ko -> /lib/modules/5.14.21-150500.53-default/updates/nvidia-uvm.ko
I’m wondering why it’s not possible to keep NVidia drivers and VirtualBox kernel modules in sync with the OpenSUSE Leap kernel version. This seems to be perfectly possible in all Debian- or Ubuntu-based distributions.
In OpenSUSE, the current kernel’s weak updates (/lib/modules/…LEAP kernel version…/weak-updates/extra/ and /lib/modules/…LEAP kernel version…/weak-updates/updates/) continue to point to older kernels which also must remain in the system. For administrators it is impossible to keep the system clean by maintaining one singe kernel version.
Multiple kernels are preserved for recoverability; should something happen with a kernel update, you can always get back using an earlier kernel.
You can configure the number of kernels maintained by modifying /etc/zypp/zypp.conf - it’s not recommended (the default is to keep the latest, latest-1, and running kernels).
This really doesn’t have anything to do with VirtualBox or nVidia.
If there are others present, you can manually run the purge-kernels service, but that should be running automatically at system startup anyways.
My only “real” (bootable) kernel is the 5.14.21-150500.55.44. All others are partial fragments needed to build the VirtualBox and NVidia modules, and are not bootable.
The 5.14.21-150500.55.31 directory is even fully empty except the “extra” subfolder containing the VBox ko-modules.
Thanks for clarifying what you are seeing. We only know about your system what you tell us - and the inclusion of multiple bootable kernels in openSUSE is something that’s generally understood.
So the additional information about what’s actually in the directories is a data point we didn’t really have until you told us - so now we know.
As you can see in my first post, the NVidia entries in the current bootable 55.44 kernel, more precisely in directory /lib/modules/5.14.21-150500.55.44-default/weak-updates/updates/, are (only) pointers to the older partial 53 kernel /lib/modules/5.14.21-150500.53-default/updates/
As soon as I delete the 53 kernel, those modules are gone and the system won’t boot anymore.
Well, then, as you observed, those modules are the only ones there, so it’s not really “dragging along old kernels”.
If you want to get more detailed info from the developers, you might check out the development mailing lists. These forums are generally users helping users.
https://lists.opensuse.org - you probably want to ask in either the factory list (which tends to be more Tumbleweed-related topics, but likely would still be relevant) or the support list. Those tend to be frequented by developers who I’m sure will be able to get down to the nitty-gritty level you’re looking for.
Thank you for the advice. I understand what you say.
I’m just wondering why OpenSUSE LEAP has this kind of need and seems to be unable to run on one single kernel (at least, as soon as you deploy NVidia drivers and/or VirtualBox), which is what any other distribution in my system can do. And why I’m the only one who bothers.
I am not sure what you try to communicate with this zypper se -si kernel list. I see only one kernel (the first package in the list). I fail to see how you connect this to the topic title “… so many kernels”.
BTW, when you want to post computer output in this English language section from a non English system, please precede your command with LANG=C like
As said in my first post, I have remaining “parts” from older and seemingly superseeded kernels (53 and 55.31) in my system, that I cannot get rid of, since they contain the ko-modules of symbolic links from the “real” and currently actively running kernel (55.44).
~> ll /lib/modules
insgesamt 12
drwxr-xr-x 3 root root 4096 7. Nov 22:28 5.14.21-150500.53-default
drwxr-xr-x 3 root root 4096 7. Nov 19:35 5.14.21-150500.55.31-default
drwxr-xr-x 4 root root 4096 20. Jan 10:43 5.14.21-150500.55.44-default
I hope you do not mind, but the LANG=C works on all commands (that have locale dependent output). It is you that decided not to ask in the German section, please adapt to the people here.
I maybe don‘t understand the actual issue. The system takes care of automatically removing older kernel module directories. Whith the next kernel update, the oldest directory will automatically get emptied and removed. No manual intervention is needed.
The number of directories is directly depended on the number of kernels to keep.
Additionally why do you even care about some MB or kB? The system is taking care of it. Manually deleting module directories without knowing the basics and connections will earlier or later brake your system.
You already manipulated your system in an unhealthy way. It is the philosophy of a good OS to keep at least two kernels to have a fallback (as already described in this thread above).
That’s exactly my point! And it seems to apply for the VirtualBox’s kernel modules, too.
I never need (and want) more than one kernel in my system. In case I need to fall back, I do so with timeshift. That protects me not only against bugs in the kernel, but also against hardware failures or any user errors (yes, that’s me). But we are drifting away from the topic.
And I never claimed this was a bug. It’s rather a systematic feature that I don’t understand.
If NVidia and VirtualBox are able to compile with the most recent and active single kernel in Debian and Ubuntu, we can’t they do so in OpenSUSE LEAP?
openSUSE aims to be a stable and user friendly distribution. As Nvidia and Virtualbox modules often don‘t compile with newest kernels after release, openSUSE has a fallback mechanism ( *buntu and Debian use really old kernels…)
With two kernels you can fall back and still use Nvidia and Virtualbox. With only one kernel you may have a non working system due to graphic issues or a broken Virtualbox setup.
With two kernels you will always have the latest system security updates whilst working with the older kernel.
Your solution with timeshift leaves you with a vulnerable system when you roll back…
openSUSE and most other rpm distributions keep an configurable amount of kernels. This is standard since ages. It is a part of a well thought stability, security and easy to use concept.
And you need to understand that deb and rpm are two different universes with different strategies…
And to be honest i trust the strategies of rpm distributions more. Rpm distributions at least update their stuff and don‘t deny it because „of *buntu/Debian is a rock solid distribution“……
