For my usages should I upgrade Leap from version 15.6 to version 16.0 or not?

English Open Chat
1

Hello. With updates for Leap-15.6 computer software scheduled to cease being produced on April 30, 2026, here I ask for your advice on what I should do, given what I have been producing in Leap 15.6 and even earlier versions of openSUSE in each case as a so-called “guest” or Virtual Machine (VM) in Oracle VM VirtualBox. My so-called “host” operating system, in which Oracle VM VirtualBox was installed, was 64-bit Windows 10 Home Edition. Since August of the year 2025 my relatively new, Solid-State-Drive- (SSD-) loaded computer’s “host” operating system has been the 64-bit Windows 11 Professional Edition. According to what I have read on the Internet some users of Leap 16.0 have not been pleased with it, finding it cumbersome or else perhaps having lost some functionalities and/or familiar utilities they desired in Leap 16.0 that they had in Leap 15.6 (However, such impressions might have changed over time, if those desired functionalities and conveniences began to work well and became available in Leap 16.0.). Therefore with gratefully having gotten my Leap-15.6 installation to work satisfactorily for me, rather than upgrade my Leap-15.6 to a Leap-16.0 installation, I have so far not upgraded my Leap-15.6 installation to a Leap 16.0 one. And, thinking even further ahead in time, there is the additional concern of whether the installation of openSUSE following Leap 16.0 will work well for my production needs or not.

Okay, now here are the main production capabilities I would like to continue to have in my openSUSE “guest” installation, along with the continued conveniences of computer software with which I have become familiar.

  1. To in the computer program KWrite write technical write-ups using LaTeχ code in .tex files. A needed software package of, for example, the fictitious texlive-PackageName, may be included in such a file, after it has been installed in my openSUSE “guest” operating system, via a LaTeχ-code statement of the form \usepackage{PackageName}. Then afterward I have been, in multiple iterations, using the software packages pdflatex and bibtex to compile that LaTeχ code to produce Portable Document Format (.pdf) output files that I can visibly check for errors using the computer program Okular. Such technical write-ups may contain

a) equations with mathematical symbols and sometimes Greek letters for the names of mathematical variables;

b) hand-drawn figures produced by scanning them in my Windows, “host” operating system or, in the case of some graphs, by the use of Ivan Johansen’s free computer program Graph 4.4.2 (For at least a Windows operating system an installation file for it has been available on http://www.padowan.dk on the Internet.) with figure captions; then afterward I may adjust the sizes of those figures using, in my openSUSE, “guest” operating system, the GNU’s Not Unix (GNU) Image Manipulation Program (GIMP);

c) internally hyperlinked references (for example, after “clicking” on colored reference number in the text of such a write-up being “sent” to that reference in a bibliography of that write-up), and/or

d) externally hyperlinked references to pages on the World-Wide Web.

The VirtualBox Guest Addition features of being able to copy and “paste” text and share files between my Windows “host” and openSUSE “guest” operating systems has been important to me both in producing my so-produced .pdf output files and to eventually have my so-produced .pdf output files available in my Windows “host” operating system where I can attach them to electronic- (e-) mail letters I e-mail to friends and/or acquaintances of mine (A folder containing such files is shared by the Windows “host” and openSUSE “guest” operating system. The files to be so shared must be in that shared folder. And settings within Oracle VM VirtualBox have to be set to allow for such file sharing and copying via the so-called “clipboard” of computer memory. In the source the copying of some text is accomplished by highlighting the text and simultaneously pressing down on a computer keyboard’s “Ctrl” and “C” keys; afterward in the destination and where the flashing-on-and-off cursor is located the “pasting” of such text is accomplished by simultaneously pressing down on a computer keyboard’s “Ctrl” and “V” keys.).

  1. To occasionally compile, link, and execute Fortran computer codes I wrote using the Fortran compiler gfortran (GNU’s Not Unix [GNU] Fortran).

Important and useful for me has been the use of the computer program Konqueror as a file manager in my openSUSE, “guest” operating system. I like the Red-Hat Package Manager (.rpm) system for installation files in openSUSE installations that I have using since the year 2009. I would like to continue to be able to use the “zypper refresh” and “zypper install” commands to update software packages available from online, openSUSE, software repositories. And the use of Yet another Software Tool 2 (YaST2) has been useful for me to see whether a software package has been currently installed or not, or available or not for installation, in my openSUSE “guest” operating system.

I have usually been using the Lightweight X Windows System, Version 11 (X11) Desktop Environment (LXDE) in my openSUSE “guest” installations. And within it the computer program LXTerminal has been quite essential for my use.

Aside from time spent upgrading an openSUSE “guest” installation, a great deal of my time in my openSUSE “guest” operating systems has been spent in keeping it up to date via a connection to the Internet that gratefully has been kindly provided free of charge for me in a number of publicly available locations. Aside from upgrades of openSUSE operating systems, for that purpose I have usually been using the commands “zypper refresh” and “zypper update”, along with afterward often “rebooting” my openSUSE “guest” operating system to complete the installation of one or more upgraded software packages.

I prefer upgrading VirtualBox Guest Additions after each upgrading of VirtualBox or the installation of a new Linux kernel obtained via the Internet. Lately I have been able to perform such upgrading of VirtualBox Guest Additions in my Leap-15.6 installation by, in the window provided by Oracle VM VirtualBox for Leap 15.6, clicking on “Devices”, then on “Upgrade Guest Additions…”. But for the proper function of VirtualBox Guest Additions there needs to first be support provided by Oracle VM Virtual Box for the Linux kernels used in whatever openSUSE “guest” operating system I have installed. And until that support is provided by Oracle VM VirtualBox for a Linux kernel released via an openSUSE software repository, I may have to use an older version of the Linux kernel that is supported by Oracle VM VirtualBox. The location on the Internet for me to determine whether such Linux-kernel support has been provided by Oracle VM VirtualBox or not is in the release notes for the relevant version of Oracle VM VirtualBox somewhere within https://www.virtualbox.org/ on the Internet. However, fortunately and I remember this matter correctly, I think that by June of the year 2024, when I first upgraded Leap 15.5 to Leap 15.6, Oracle VM VirtualBox may have gratefully already provided support for the first version of the Linux kernel released via a Leap-15.6, online repository for Leap 15.6.

Upgrading Leap rather than making a so-called “clean” installation of a new version of Leap onto virtually blank data-storage drive has seemed easier for me, for one reason because I have numerous texlive-…. software packages installed in my Leap operating systems (Though I admit that I probably have a number of texlive-…. software packages installed that I probably have not been using.)

I suppose that, unlike Windows operating systems, openSUSE, Linux operating systems, and Linux operating systems in general, would not have computer-security risks if they would not be kept up to date.

Basic question A: Is this notion of mine correct?

If so, I suppose I could just keep on using my Leap-15.6 installation without a computer-security risk beyond April 30, 2026, without updating it, since gratefully it has been working satisfactorily for me.

Basic question B, part i: Given my above description of what I have been doing in my Leap-15.6 “guest” installation within Oracle VM VirtualBox plus my above-desired functionalities within it, among them is there anything I could not similarly have implemented in a Leap-16.0 “guest” installation? For example, suppose that for some reason I could not install Konqueror as a file manager in Leap 16.0. I suppose that then I might instead use, for example, the Dolphin file manager, a file manager I have sometimes used.

Basic question B, part ii : In the more distant future would there be any feature I desire dropped in Leap 16.0, which would be expected to continue to be absent in later openSUSE installations?

Basic question C: Would there be anything in a Leap-16.0 “guest” installation that would be difficult or time consuming for me to learn how to use which could impede my production in that installation?

Basic question D : On the positive side of things, can you think of any new feature in Leap 16.0 that I might find to be helpful and not time consuming to learn how to implement in my use of an openSUSE “guest” operating system for especially my above purposes 1a-d and 2?

Basic question E : After a new version of openSUSE has been released, where on the Internet could one read what users of it consider to be the positive and negative features of that version, as well as what features of the most-recent previous version of openSUSE have been discontinued? Ideally such a discussion should include use of openSUSE as “guest” operating system in Oracle VM VirtualBox. Perhaps most useful for a wide scope of users could be a list of all of the major features and capabilities of a previous operating system with check boxes beside each of them to indicate which features and capabilities have been continued and which ones among them have been discontinued in the next version.–Then a check mark in such a check box could indicate a continuation; and the absence of such a check mark such a check box could indicate a discontinuation. Or simply, by the use of such a check-box system it could be useful for a potential user of a new version of an openSUSE operating system to not have to try using it in order for him to determine if it would be suitable for his desired uses or not.

In a local electronics repair shop in my part of the world in probably August or July of the year 2025 I heard that there may something in a Windows, perhaps Windows-11, installation which could make a “container” or hypervisor like Oracle VM VirtualBox or VMware for another, or “guest,” operating system unnecessary.–I guess that it could mean that a second operating system might be operable within a Windows-11 operating system. I read on the Internet that a 64-bit Windows Professional Edition operating system like mine could have Microsoft (Corporation) Hyper-V in it. My computer includes a central processing unit (cpu) with the necessary Second Level Address Translation (SLAT) technology for Microsoft (Corporation) Hyper-V. However, I have not made any practical use of such a Hyper-V, presumably hypervisor. I have so far been continuing to use Oracle VM VirtualBox as a hypervisor on my computer.

2

Welcome back to the Forums! Sorry, but you are asking too much of us, especially since some of the questions are about the Win* world.
But to upgrade Leap to 16.0 in a Virtualbox machine at least wait that bug No precompiled guest kernel modules for Virtualbox in Leap 16 is fixed, otherwise you will not be able to easily exchange files with the host system.

3

Hy!

make copy of your VM and start playing around, but be aware of the limitations with guest kernel modules. I lost a VB VM with 15.6 when trying to upgrade from 15.6 to 16.0 some time ago. Never tried to install fresh 16.0 to VB, switched to Debian.

If you are virtual in linux land, why not trying something else? How about Debian trixie with KDE or much lighter LXDE?

Simply install a VM, play around, if it fits your needs: keep it! Otherwise delete the VM and look for something else.

4

Have you tried Emacs with the AUCTeX package? It defines lots of practical keyboard shortcuts for frequently-used symbols and can even render text with interspersed formulae as graphics in the .tex code editor.

5

I thank those ones of you who have kindly taken some time to post replies here. However, I prefer to, if possible, avoid using time to learn a totally new way to produce technical write-ups. It has taken me a lengthy period of time to learn how to gratefully be able to produce some technical write-ups using openSUSE computer software. Reasons: 1) It could take time to learn one or more new ways to produce technical write-ups. And I have some other things to do in life. 2) But suppose that I would take that time to learn and try such a new method. In that case there might still be a question of whether the new way of producing technical write-ups would be as complete and/or as good as the old way of producing such write-ups.

Will the 64-bit, openSUSE, Leap-15.6 online repositories and Yet another Software Tool 2 (YaST2) for now-existing, online Leap-15.6 computer software packages usable in Leap 15.6 still be accessible online after April 30, 2026?

Thinking somewhat deeper concerning Leap 15.6 being a so-called “guest” operating system in Oracle Virtual Machine (VM) VirtualBox, suppose that the Windows “host” for Oracle VM VirtualBox or a new version of VirtualBox itself would contain NEW computer software that Leap-15.6 computer code might not be programmed to accommodate. That is one way I could imagine Leap 15.6 failing to work after its end-of-life support with such NEW computer software. A way I could imagine at least delaying some of that kind of trouble could be to keep the version of VirtualBox the same which has worked well with Leap 15.6 as its “guest” operating system; or else if there is trouble in a Leap-15.6 operating system after upgrading VirtualBox, revert back to the previous version of VirtualBox which worked well with Leap 15.6.

With primarily production capabilities in mind, I think that full online support for Leap 15.6 should be continued at least until Leap 16.0 can be shown to be a full functional substitute for Leap 15.6, including when Leap 15.6 is a “guest” operating system in a hypervisor of, for example, Oracle VM VirtualBox. This thinking is somewhat like the American saying of “Don’t throw away your old shoes until you obtain your new shoes.” Furthermore I suppose that predicting the time it takes to solve one or more problems, especially technical problems, may often not be humanly predictable. It was good to have extended full support for Leap 15.6 by an additional few months of time beyond, I think, the usual time for full support for an openSUSE Leap operating system. However, based on the second poster’s posting in this thread, it appears that that extension of time was unfortunately insufficient to have allowed for the solution of at least one technical problem in Leap 16.0 that has not been a recent problem for me in Leap 15.6. Please pass this message along to whomever among Leap 15.6’s administrators has the authority to arrange for such a delay of the date beyond April 30, 2026 for the so-called date of end-of-life support for Leap 15.6. Or else give me here his or her name and a way for me to contact him or her to request such a delay, such as via his or her electronic- (e-) mail address. Thank you.

6

@2009Newbie Then perhaps look at a fresh install after backing up, assuming your hardware meets the requirements?

Many Leap 15.6 repositories have gone, I have no intention of supporting Leap 15.6 for the packages I maintain. There has already been one extension, not sure if another is planned, perhaps @lkocman may have some thoughts…

I’ve been using Leap 16.0 (incl beta releases) here since probably this time last year without any major issues, but I chose fresh installs since the changes were extensive, likewise future proofing for a changing bootloader (/boot/efi 4GB in size).

1 Like
7

The time you spend for writing pages and pages of elaborate forum threads you could have spent to install a fresh VM and read up how to use apt instead of zypper. :slight_smile:

just saying.

4 Likes
8

Skipping some difficulties and details, with a written backup of my Oracle Virtual Machine (VM) VirtualBox- (hereafter called simply “VirtualBox”) 7.2.6, “guest,” Leap 15.6 operating system, on April 21, 2026 I upgraded my installed version of Leap from 15.6 to 16.0 via the command, as a so-called “root” user,

opensuse-migration-tool

. Very helpful to me in understanding what occurred during April 20-21, 2026 and knowing what to do in this regard were the postings by the poster crmrhm on Query about upgrading to Leap 16 - #16 by determined_suse_noob on the Internet, especially his comment that after checking for file conflicts and answering “y” or “yes” to “Continue?” led to all of the software packages to be installed being downloaded a second time from the Internet. Today, April 22, 2026, I installed an update for opensuse-migration-tool in my Leap-16.0 installation. So the function of that opensuse-migration-tool in Leap 16.0 on April 22, 2026 might be more efficient or different than the function of opensuse-migration-tool in my previous, Leap-15.6 installation during April 20-21, 2026.

A brief review: My computer’s “host” operating system has recently been 64-bit Windows 11 Professional Edition. VirtualBox is a hypervisor, or “container” for a second operating system, that I have installed in that Windows-11, “host” operating system. My “guest” operating system in VirtualBox was upgraded from Leap 15.6 to Leap 16.0.

The first “booting” of my Leap-16.0 was taking considerable time; and initially it appeared to have had numerous problems. In fact, I gave up on it, terminated it, and tried to “boot” Leap 16.0 again. Afterward gratefully I could eventually reach a so-called “desktop” screen in my Leap-16.0 installation! From my reading on the Internet I learned that the Lightweight X Windows system, version 11 (X11) Desktop Environment (LXDE) was not available via Leap-16.0 online software repositories because the necessary software package of lxde-common was not available for the LXDE via Leap-16.0, online, software repositories. So far my preferred substitute for the LXDE in my Leap-16.0 installation has been the “Plasma (X11)” “desktop”, which I could choose via the lower-left corner of the login screen for Leap 16.0. In fact, it appeared that the desktop shortcuts I had in the LXDE of my previous Leap-15.6 installation had been transferred to the “Plasma (X11)” desktop. And the double-clicking of the to-me important ones among those desktop shortcuts gratefully continued to work for me!

Afterward in that Leap-16.0 installation in VirtualBox 7.2.6, and with the Linux kernel 6.12.0-160000.28.1.x86_64 “running,” I made the following tests.

  1. the production of a Portable Document Format (.pdf) output file by executing the commands of pdflatex on a LaTeχ-coded .tex file and bibtex on a bibliographic file containing references to publications and/or writings. The so-produced .pdf output file gratefully looked good in the computer program Okular in my Leap-16.0 installation!

  2. The compilation, linking, and execution of the result of an initially Fortran-language-coded, .f file gratefully also worked well!

  3. The functions of file sharing via a folder shared by my Windows-11, “host” operating system and my Leap-16.0, “guest” operating system and the copying and “pasting” of text via the so-called “clipboard” of computer memory in each direction between my Windows-11 “host” and Leap-16.0 “guest” operating systems also gratefully worked well!

Then on April 21, 2026 the new version 7.2.8r173730 of VirtualBox was released. So on that same day I updated or upgraded VirtualBox 7.2.6 and its Extension Pack to and for that new version of VirtualBox. And I tried to update the VirtualBox Guest Additions for that new version 7.2.8r173730 of VirtualBox via, in the window provided by VirtualBox for my “guest” operating system, “Devices, Upgrade Guest Additions…” But that attempt and some later attempts to have VirtualBox Guest Additions produced for Leap-16.0 in VirtualBox 7.2.8r173730 were reported to have failed. Afterward the operation of copying and “pasting” text between my Windows-11, “host” and Leap-16.0, “guest” operating systems was still successful. But the sharing of folders within the folder designed to be shared by my “host”, Windows-11 and “guest”, Leap-16.0 operating systems unfortunately no longer occurred.

Here is an example of the notification of such a failure.

“Guest Additions Update failed: Files were installed, but kernel modules were not reloaded automatically. Please consider reloading the guest.” error code 0x80bb000f. But “rebooting” Leap 16.0 unfortunately did not result in any improvement in this regard.

I also tried to have the new VirtualBox Guest Additions “built” via, in the window provided by VirtualBox for my Leap-16.0 “guest” operating system, “Devices, Insert Guest Additions CD” (Compact Disc) “image…” And I had the directory C:\Program Files\Oracle\VirtualBox’s file VBoxGuestAdditions.iso listed and chosen among other files under VirtualBox 7.2.8’s “Settings, Storage, Controller: IDE” [Via “Devices, Optical Drives, IDE (IDE Primary Device 0)>” a check mark was visible on the left-hand side of VBoxGuestAdditions.iso.].–But nothing visible occurred after clicking on that “Insert Guest Additions CD image…”

Concerning kernel modules I also entered, as a so-called “root” user, the command

/sbin/rcvboxadd quicksetup all

with an apparent purpose of “Building the VirtualBox Guest Additions kernel modules”. But the result included some reports of “No such file or directory” for the files vboxguest.ko, vboxdrv.ko, vboxvideo.ko, vboxnetfit.ko, vboxnetflt.ko, and vboxnetadp.ko. My Mozilla Firefox Web browser’s DuckDuckGo’s search “engine’s” “Search Assist” gave me this explanation from the Internet for .ko files. “Yes, .ko files are loadable kernel modules in Linux, which are used to extend the functionality of the kernel, such as adding support for new hardware or filesystems. These modules can be loaded and unloaded dynamically without needing to reboot the system.” With this understanding the kernel modules needed for “building” VirtualBox Guest Additions for VirtualBox 7.2.8r173730 could not be found by a portion of computer code which was designed to “build” such Guest Additions!

In the file /var/log/vboxadd-setup.log some relevant information concerning one or more errors was

MODPOST /tmp/vbox.0/Module.symvers

scripts/mod/modpost -M -m -a -l /tmp/vbox.0/modules.livepatch -o /tmp/vbox.0/Module.symvers -n -S Module.supported -T /tmp/vbox.0/
modules.order -i Module.symvers -e
ERROR: modpost: “is_endbr” [/tmp/vbox.0/vboxguest.ko] undefined!
make[2]: *** [/usr/src/linux-6.12.0-160000.28/scripts/Makefile.modpost:152: /tmp/vbox.0/Module.symvers] Error 1
make[1]: *** […/…/…/linux-6.12.0-160000.28/Makefile:1923: modpost] Error 2
make: *** [/tmp/vbox.0/Makefile-footer.gmk:146: vboxguest] Error 2

Consider that whatever tasks were performed concerning VirtualBox Guest Additions during the installation of Leap 16.0 worked concerning the copying-and-“pasting” and file sharing between my “host” and “guest” operating systems via their shared folder. Therefore if those general operations could be reproduced now for the new version of VirtualBox and the current Linux kernel in Leap 16.0, it seems to an “outsider” like myself, who did not write any part of the computer codes for the VirtualBox Guest Additions, that the functions of the so-produced VirtualBox Guest Additions ought to be successful. And whatever was so-done might have somehow circumvented the need for one or more precompiled kernel modules. Could there be a need here of compiling the source codes for both the relevant kernel modules and the Linux kernel together, especially when, as poster OrsoBruno here referenced, that at least as of April 16, 2026, there were no precompiled “guest” kernel modules for VirtualBox in Leap 16.0, in order to make well-working VirtualBox Guest Additions?
In the meantime I do have one so-called “workaround” solution for transferring files between my Leap-16.0, “guest” and Windows-11, “host” operating systems.–For example, in an electronic- (e-) mail account of mine I could attach a .pdf file I produced in my Leap-16.0 operating system and send that e-mail letter via the Internet to that same e-mail account. Then in my Windows-11 I could open that e-mail letter and download its attachment to my computer’s Windows-11 downloads folder.

9

In the line in my previous posting here reading MODPOST /tmp/vbox.0/Module.symvers there should be a number sign (#) on the left-hand side of that line. I found that there was a tooltip or context menu with a symbol of a couple of links of a chain appearing there when my computer’s touchpad “arrow” symbol was there. I do not know what the purpose is for that symbol of two links of a chain there.

10

In the following few ways I tried, but failed to upgrade or update the VirtualBox Guest Additions for VirtualBox 7.2.8r173730 in my Leap-16.0, “guest” operating system in VirtualBox:

In the window provided by VirtualBox 7.2.8 for Leap 16.0 I clicked on

  1. “Devices, Upgrade Guest Additions…” and

  2. “Devices, Insert Guest Additions CD image…”.

  3. In the Leap-16.0 computer program LXTerminal, after entering my “root”-user password and as a so-called “root” user, I entered “/sbin/rcvboxadd quicksetup all”.

  4. I tried to mount [C:\Program](file:///C:/Program) Files\Oracle\VirtualBox’s file VBoxGuestAdditions.iso as a “root” user in LXTerminal via the commands

mkdir /mnt/cdrom

mount /dev/cdrom /mnt/cdrom

. Afterward, however, the command “dir” for I think “directory” resulted in “total 0”. (What command did I not issue that resulted in this “response”? You can try to teach me something here.) Then I tried to unmount /dev/cdrom via the command

umount /dev/cdrom

. But VBoxGuestAdditions.iso was apparently still mounted because via “Devices, Optical Drives, IDE (IDE Primary Device 0)” I saw “Remove Disk From Virtual Drive”; and after I clicked on it I saw the message “Unable to eject the virtual optical disk [C:\Program](file:///C:/Program) Files\Oracle\VirtualBox\VBoxGuestAdditions.iso from the machine openSUSE Linux.” So I clicked on “Force Unmount”. And afterward, via “Devices, Optical Drives” and one of the “IDE…” items listed, I clicked on “Host Drive ‘E’” to enable a check mark to be placed on the left-hand side of that text. Then afterward I noticed that a dialog box appeared that was labeled at its top with “<Disks & Devices”. It had three other lines of text on it. I clicked on the right-hand side of a line among those three lines looking like

“VBox_Gas_7.2.8 downward-pointing arrowhead Mount and Open, a check mark or a downward-pointing arrowhead. Next I clicked on a symbol, looking like part of the symbol of a diode on an electrical circuit diagram, with I think a label of “Mount” near it, and then clicked on text overlapping Open with File Manager and afterward saw that the PCMan File Manager had opened with the directory /run/media/newbie/VBox_Gas_7.2.8’s files shown on it (My Leap-16.0 user name is “newbie”.). Among those files was the file VBoxLinuxAdditions.run. So then as a “root” user in LXTerminal I entered

cd /run/media/newbie/VBox_Gas_7.2.8

./VBoxLinuxAdditions.run

. But afterward I saw what appeared to be the same collection of error messages beginning with

ERROR: modpost: ‘is_endbr’ [/tmp/vbox.0/vboxguest.ko] undefined!

that I posted earlier in this so-called “thread” of postings.

Nevertheless and gratefully I found a way that I could have the full function of VirtualBox Guest Additions in my Leap-16.0 “guest” installation in VirtualBox 7.2.8! That process began with my “booting” Leap 16.0 in VirtualBox 7.2.6 with the last version 6.4.0-150600.23.92.1 of the Linux kernel-default that I used in my Leap-15.6, “guest” operating system before I upgraded Leap 15.6 to Leap 16.0. That was possible probably because A) in /etc/zypp/zypp.config I had a statement in it reading it as

multiversion.kernels = 5.14.21-150500.55.65.1ꓕlatestꓕlatest-1ꓕrunning

, B) because up to that time since my upgrading from Leap 15.6 to Leap 16.0 I had only “booted” Leap 16.0 using the Linux kernel-default 6.12.0-160000.28.1, and C) because the “booting” of Leap 16.0, perhaps in grub2 (the GRand Unified Bootloader 2), allowed a choice to be made of which one of a very small set of Linux kernels into which Leap 16.0 could be “booted” or run. To further explain “A”, the line of code beginning with “multiversion” listed all of the versions of the Linux kernel into which Leap 16.0 would be permitted to be “booted” or run.—The first such allowed version 5.14.21-150500.55.65.1

was the last version of kernel-default that I used in an earlier, Leap-15.5, “guest” operating system in a VirtualBox installation. I think I wanted to keep that version of the Linux kernel for potential use in my previous, Leap-15.6 “guest” operating system. The word “latest” represents the latest version of the Linux kernel in which Leap 16.0 had been “booted.” Similarly “latest-1” represents the next-to-latest version of the Linux kernel into which Leap 16.0 had been “booted.” And “running” I suppose allows the version of the Linux kernel which is currently running to continue to run in my Leap-16.0 “guest” operating system. To explain “B” through some time during the evening of April 25, 2026 the only version of the kernel-default into which I had “booted” Leap 16.0 was version 6.12.0-160000.28.1. That version as the “latest” version, the version 6.4.0-150600.23.92.1 as the “latest-1”version of kernel-default from my Leap-15.6 installation, the kept version 5.14.21-150500.55.65.1 of kernel-default from my much-earlier Leap-15.5 installation, and kernel-default 6.4.0-150600.23.92.1 as a potential version of the Linux kernel in which Leap 16.0 could be running altogether meant that version 6.4.0-150600.23.92.1 of kernel-default was then allowed, according to the above “multiversion” line, for “booting” and running my Leap-16.0 installation. In my Leap-16.0 “guest” operating system I wanted to keep version 6.4.0-150600.23.92.1 of kernel-default from my previous, Leap-15.6 “guest” operating system, instead of the last version of kernel-default I used in my Leap-15.5 “guest” operating system, as a continuing version of kernel-default into which I could “boot” and run Leap 16.0. So, as a “root” user I edited the above “multiversion”-containing line in /etc/zypp/zypp.config to read as

multiversion.kernels = 6.4.0-150600.23.92.1ꓕlatestꓕlatest-1ꓕrunning

. If the software package purge-kernels would be installed and working correctly after the next update of the Linux kernel, all versions of the installed kernel-default in my Leap-16.0 installation which would not match any of the criteria in the list of allowed Linux kernels specified by the above “multiversion” line of computer code should automatically be purged or deleted from my Leap-16.0 installation.

Via “Devices, Upgrade Guest Additions…” in the window provided by VirtualBox 7.2.6 for my Leap-16.0 “guest” installation I was gratefully able to have VirtualBox Guest Additions produced without an error message for the Linux kernel-default 6.4.0-150600.23.92.1 in my Leap-16.0 “guest” installation in VirtualBox 7.2.6. The VirtualBox Guest Additions’ functions of the copying and “pasting” of text in both directions between my “host,” Windows-11 and Leap-16.0, “guest” operating systems, as well as the sharing of folders in my folder shared by Windows 11 and Leap 16.0 gratefully worked correctly.

Next in my Windows-11 “host” operating system I uninstalled VirtualBox 7.2.6 and installed VirtualBox 7.2.8, as well as upgraded the VirtualBox Extension Pack from version 7.2.6 to 7.2.8. Next I “booted” Leap 16.0 using the Linux kernel-default 6.4.0-150600.23.92.1, which was effectively “inherited” by my Leap-16.0 installation in the process of upgrading my previous Leap-15.6 installation. After that in the window provided by VirtualBox 7.2.8 for Leap 16.0 I clicked on “Devices, Upgrade Guest Additions…” to have VirtualBox Guest Additions produced, gratefully without an error message, for Leap 16.0, the Linux kernel-default 6.4.0-150600.23.92.1, and VirtualBox 7.2.8. Gratefully once again the VirtualBox Guest Additions’ functions of the copying and “pasting” of text in both directions between my “host,” Windows-11 and “guest” Leap-16.0 operating systems, as well as the sharing of folders in my folder shared by Windows 11 and Leap 16.0 gratefully worked correctly.

So now in the following table I tabulate some results of my experiments regarding the successful or failed functions of VirtualBox Guest Additions with the two Linux kernels and the two versions of VirtualBox.

Table 1. Success or failure in the production of well-working VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…” while the below-tabulated versions of kernel-default and VirtualBox were in operation.

Column 1 Column 2 Column 3
Linux kernel-default Linux kernel-default
Version of VirtualBox 6.4.0-150600.23.92.1 6.12.0-160000.28.1
VirtualBox 7.2.6 Success Success
VirtualBox 7.2.8 Success Failure

After producing VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…” and then regarding the VirtualBox Guest Additions’ functions between the “host” and “guest” operating systems, the Linux kernel-default 6.12.0-160000.28.1 was somehow incompatible with VirtualBox 7.2.8. Regarding the successful production without errors via “Devices, Upgrade Guest Additions…” of VirtualBox Guest Additions in the future, until this problem of incompatibility is solved, two “paths” seem likely to be successful: 1) upgrading VirtualBox, but not updating the Linux kernel-default away from version 6.4.0-150600.23.92.1 or 2) keeping VirtualBox 7.2.6 while allowing updates to the Linux kernel-default away from version 6.12.0-160000.28.1 of it.

On https://www.virtualbox.org/wiki/Changelog-7.2 I found a so-called “Changelog” which lists the historical changes made in VirtualBox for several recent versions of VirtualBox, historical version by historical version of it. An apparently well-established tradition appears to have been that the version numbers of the released versions of the Linux kernel have steadily increased with time such that a version of the Linux kernel with a higher primary number in kernel-version number was issued later in time than a version of the Linux kernel with a lower primary number in its kernel-version number. With that tradition in mind I saw in the “Changelog for VirtualBox 7.2” that support in VirtualBox 7.2.8 for the Linux kernel 10.2 was added and that in the “Changelog” for VirtualBox 7.2.0 that support in VirtualBox 7.2.0 for the Linux kernels 6.16 and 6.17 was added. Therefore from the VirtualBox side of the matter all released versions of VirtualBox from version 7.2.0 to 7.2.8 of it should support the Linux kernel-default version 6.12.0-160000.28.1. Here I may have reached one of the “frontiers” of my knowledge and/or understandings of VirtualBox, the production of VirtualBox Guest Additions, and what exactly may be performed on the openSUSE, Leap-16.0 side of these matters. But I suppose that the problem of the incompatibility between VirtualBox 7.2.8 and my Leap-16.0 installation with version 6.12.0-160000.28.1 running in it may be somewhere in the Linux kernel version 6.12.0-160000.28.1 or in the kernel modules for it released through one or more online Leap-16.0 repositories, rather than on the VirtualBox side of these matters. Furthermore it is inconceivable to me that a problem could exist in a compiled version 6.12.0-160000.28.1 of the Linux kernel-default or one of the kernel modules when there is no related problem in the source code for version 6.12.0-160000.28.1 of the Linux kernel-default or one of the Linux kernel modules for it. So I suspect that a problem may exist in the source computer code for the Linux kernel-default version 6.12.0-160000.28.1 and/or one of the Linux kernel modules. And until that problem or those problems would be precisely located and fixed within the relevant source computer code or codes for the Linux kernel-default version 6.12.0-160000.28.1 and/or one or more of the Linux kernel modules for that Linux kernel, it seems likely that that problem or those problems would be propagated into future versions of the Linux kernel and/or kernel modules for Leap 16.0. From my own experience of writing and “debugging” computer programs I wrote in the Fortran computer-programming language, it could take time for me to locate a problem in my computer code and, after having located it, to remedy or fix it.

While Linux kernel-default 6.4.0-150600.23.92.1 was running in Leap 16.0 I noticed that I had lost the VirtualBox Guest Additions’ function of the copying and “pasting” of text from my Leap-16.0, “guest” installation into my Windows-11, “host” operating system. But gratefully that problem was easily remedied by clicking on “Devices, Upgrade Guest Additions…” while that version 6.4.0-150600.23.92.1 of kernel-default was running.

I now make a distinction between the combinations of versions of VirtualBox and kernel-default in which via “Devices, Upgrade Guest Additions…” well-working VirtualBox Guest Additions could be produced without errors (marked with “Success” in Table 1) and the versions of VirtualBox and kernel-default in which VirtualBox Guest Additions could be successfully used, the matter I next discuss. There were two important practical matters concerning my Leap-16.0 “guest” operating system in VirtualBox 7.2.8.–1) I found that the VirtualBox Guest Additions could not be produced via “Devices, Upgrade Guest Additions…” in VirtualBox 7.2.8 and Leap 16.0 while kernel-default 6.12.0-160000.28.1 was running. In this point my focus is on the VirtualBox Guest Additions’ functions between my Windows-11 “host” and Leap-16.0 “guest” operating systems of the copying and “pasting” of text and the sharing of folders in a folder shared by those two operating systems. In this regard I found that those functions of the VirtualBox Guest Additions produced in Leap 16.0 while kernel-default 6.4.0-150600.23.92.1 was running could be successfully used when either version 6.4.0-150600.23.92.1 or 6.12.0-160000.28.1 of kernel-default was running in my Leap-16.0 installation. And I hope that those same functions of VirtualBox Guest Additions produced while kernel-default 6.4.0-150600.23.92.1 was running would also be successfully usable, before the mentioned compatibility problem would be solved, after kernel-default will be updated beyond version 6.12.0-160000.28.1 of it. 2) I had a timeout issue that if I did not move the pointer arrow over the Plasma (x11) “desktop” screen in my Leap-16.0 installation within some period of time that that screen became totally black in color. Normally afterward that “desktop” screen would be recoverable by clicking once on that black-colored screen; seeing a login dialog box; entering my openSUSE, regular-user password in that dialog box; and then either pressing down on my computer keyboard’s “Enter” key or else clicking on perhaps an “OK” software “button” of that dialog box. However, when that “desktop” screen became black colored after the end of such a timeout period and the Linux kernel-default 6.12.0-160000.28.1 was running, the pointer-arrow symbol could no longer be seen when it was supposed to be visible over that “desktop” screen. And my only immediate option to recover from that situation was to click on the “X” on the upper-right-hand corner of that screen, then, in the ensuing dialog box which appeared, to see that the “radio button” on the left-hand side of “Power off the machine” would be selected, afterward to click on the “OK” software “button” on that dialog box, and then after the Leap-16.0 “machine” shut down to “boot” Leap 16.0 again with the default Leap kernel-default 6.12.0-160000.28.1.

Alternatively, while my computer was connected to the Internet, from the Mozilla Firefox Web browser’s search “engine’s” “Search Assist” I learned how to at least begin to make that timeout time very large in the hope of avoiding loosing the visibility of the touchpad arrow over the Plasma (x11) “desktop” and having to shut down Leap 16.0. What I actually did was to in Leap 16.0 click on the image of an iguana on the lower-left-hand portion of the panel or taskbar at the bottom of the screen and then to click on “System, System Settings, System, Power Management” and under “Display and Brightness” and to the right side of “Turn off screen:” in a drop-down list box to increase the time there from 10 minutes to 1,440 minutes (equivalent to 24 hours of time). Then I clicked on “OK”, “Apply”, and then on the “X” at the upper-right-hand corner of the window open at that time.

11

For the German “SUSE” in presumably openSUSE, from the Mozilla Firefox Web browser’s search “engine’s” “Search Assist”, “SUSE originally stood for “Software- und System-Entwicklung,” which translates to ‘Software and Systems Development’ in English.”

13

Sorry but your post is impossible to follow. Apparently you missed the easy way provided by openSUSE.

On the host system:
Download the Extension Pack available from Oracle here
Install it in the VirtualBox Manager app via “Extension” then “Install” (or CTRL+Shift+I) and select the Extension_Pack file just downloaded.

On the Guest:
Install the virtualbox-guest-tools package using Myrlyn or zypper in virtualbox-guest-tools; that should automatically select for installation also virtualbox-kmp-default.

In the VirtualBox Manager,
Machine > Settings > General > Features tab : Shared Clipboard and/or Drag-and-Drop shall be enabled according to your needs.

17

After I returned home during a locally rainy period of natural darkness, I began to think that while kernel-default 6.12.0-160000.28.1 was running that the running or active VirtualBox Guest Additions could be from that kernel’s computer software instead of the VirtualBox Guest Additions I enabled to be “built” via “Devices, Upgrade Guest Additions…” while kernel-default 6.4.0-150600.23.92.1 was running. After checking my hand-produced notes of my actions with my computer, I realized that kernel-default 6.12.0-160000.28.1 was installed during my upgrading of Leap 15.6 to Leap 16.0 on April 21, 2026, with VirtualBox 7.2.6r172322 installed during that entire upgrading period of time. Then on that same day, but after that process of upgrading Leap was complete, I, in effect, upgraded or updated VirtualBox from version 7.2.6r172322 to version 7.2.8r173730 of it. While kernel-default 6.12.0-160000.28.1 was running in my Leap-16.0 installation in VirtualBox 7.2.8, as a “root” user in the computer program LXTerminal on April 28, 2026 I input the command

/usr/sbin/modinfo vboxguest

to show which version of the VirtualBox Guest Additions was installed at that time in my Leap-16.0 installation. The “response” from that command included

filename: /usr/lib/modules/6.12.0-160000.28-default/updates/vboxguest.ko

version: 7.2.6 r172322

. That version “7.2.6 r172322” for the kernel module vboxguest.ko and the VirtualBox Guest Additions running with kernel-default 6.12.0-160000.28.1 was also the version of VirtualBox installed during the time that the kernel-default 6.12.0-160000.28.1 was being installed in Leap 16.0 during the overall process of upgrading Leap 15.6 to Leap 16.0 on April 21, 2021. And at that time I had not yet tried to “build” any VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…” with the combination of kernel-default 6.12.0-160000.28.1 or 6.4.0-150600.23.92.1 and VirtualBox 7.2.8r173720. So that version of VirtualBox Guest Additions must have come with the version kernel-default 6.12.0-160000.28.1 that I had had installed during my Leap upgrading process. The “response” to the command

systemctl status vboxadd-service

of

Output: vboxadd-service.service

Loaded: loaded (/opt/VBoxGuestAdditions-7.2.8/init/vboxadd-service; enable; preset; disabled)

Active: active (exited) since Tue 2026-04-28 12:24:01 EDT; 29 min ago

to show which version of VirtualBox Guest Additions was running on April 28, 2026 was in my opinion not as revealing concerning which version of VirtualBox Guest Additions could have been running as the “response” to the command “/usr/sbin/modinfo vboxguest”.

My earlier statement in this so-called “thread” of postings of

“In this regard I found that those functions of the VirtualBox Guest Additions produced in Leap 16.0 while kernel-default 6.4.0-150600.23.92.1 was running could be successfully used when either version 6.4.0-150600.23.92.1 or 6.12.0-160000.28.1 of kernel-default was running in my Leap-16.0 installation.”

now seems likely to have been incorrect.–Rather it may have been that the VirtualBox Guest Additions which I now suppose came with kernel-default 6.12.0-160000.28.1 and had been “built” for VirtualBox 7.2.6, yet also later worked in VirtualBox 7.2.8, may now be the VirtualBox Guest Additions that are active while kernel-default 6.12.0-160000.28.1 is running in my Leap-16.0 “guest” operating system in VirtualBox 7.2.8.

Next I decided to see what “responses” I would obtain from the “root”-user commands /usr/sbin/modinfo vboxguest” and “systemctl status vboxadd-service” after “booting” my Leap-16.0 “guest” installation in VirtualBox 7.2.8 with kernel-default 6.4.0-150600.23.92.1. Those responses included,

from “/usr/sbin/modinfo vboxguest” ,

filename: /usr/lib/modules/6.4.0-150600.23.92-default/misc/vboxguest.ko

version: 7.2.8 r173730

, and from “systemctl status vboxadd-service” ,

vboxadd-service.service

Loaded: loaded (/opt/VBoxGuestAdditions-7.2.8/init/vboxadd-service; enable>

Active: active (running) since Tue 2026-04-28 14:45:50 EDT; 6min ago

. In comparing the “responses” to the command “/usr/sbin/modinfo vboxguest” when “booting” Leap 16.0 with the two different Linux kernels, note the change in the version from 7.2.6 r172322 to 7.2.8 r173730 of the kernel module vboxguest.ko! This time, while kernel-default 6.4.0-150600.23.92.1 was running in Leap 16.0 in VirtualBox 7.2.8, the VirtualBox Guest Additions which were running or active appear to have been the VirtualBox Guest Additions which I knew to have been previously “built” via “Devices, Upgrade Guest Additions…” while while kernel-default 6.4.0-150600.23.92.1 was running in Leap 16.0 in VirtualBox 7.2.8. Therefore, with definitely different histories involved in the two different sets of VirtualBox Guest Additions, the VirtualBox Guest Additions which were running or active depended on the version of the Linux kernel running in my Leap-16.0 “guest” installation in VirtualBox 7.2.8! Then my earlier statement regarding “successfully used” VirtualBox Guest Additions needed to be modified via a pair of statements in the following way.–The VirtualBox Guest Additions produced via “Devices, Upgrade Guest Additions…” while kernel-default 6.4.0-150600.23.92.1 was running in Leap 16.0 in VirtualBox 7.2.8 could later be successfully used while that version of kernel-default was running in that same combination of Leap 16.0 and VirtualBox 7.2.8. And the apparently different version of VirtualBox Guest Additions, which appears to have come with kernel-default 6.12.0-160000.28.1 in Leap 16.0 within VirtualBox 7.2.6, could later be successfully used while that version of kernel-default was running in the combination of Leap 16.0 and VirtualBox 7.2.8.

Another change is that on April 28, 2026, in following the advice on https://www.virtualbox.org/wiki/LinuxAdditionsDebug on the Internet I, as a “root” user, uninstalled the software package virtualbox via the command

zypper remove virtualbox

, agreeing in that process to also remove the software package virtualbox-qt.

I found out the hard way that having the software package virtualbox-kmp-default installed in my Leap-16.0 installation was essential under the present circumstances, by at first uninstalling it and losing the sharing of folders in the folder shared by my Windows-11, “host” and Leap-16.0, “guest” operating systems and then afterwards reinstalling virtualbox-kmp-default and then finding the copying and “pasting” of text between, and the sharing of folders in the folder shared by, my “host” and “guest” operating systems in VirtualBox 7.2.8r173730 gratefully good once again.

18

Please do not write a book, ask what your problem is in simple few phrases.

Virtualbox on Leap 16.0 host is running fine,if using secure boot you have to download and install the necessary signkey from Tumbleweed:
zypper in https://download.opensuse.org/tumbleweed/repo/oss/x86_64/openSUSE-signkey-cert-20230303-3.1.x86_64.rpm
This should be only a workaround, I think the packages is on it’s way.

zypper se -si signkey virtualbox
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                   | Type  | Version                           | Arch   | Repository
---+------------------------+-------+-----------------------------------+--------+--------------
i+ | openSUSE-signkey-cert  | Paket | 20230303-3.1                      | x86_64 | Programme-rpm
i+ | virtualbox             | Paket | 7.2.6-lp160.1.1                   | x86_64 | OSS
i+ | virtualbox-kmp-default | Paket | 7.2.6_k6.12.0_160000.28-lp160.1.1 | x86_64 | OSS
i+ | virtualbox-qt          | Paket | 7.2.6-lp160.1.1                   | x86_64 | OSS
2 Likes
19

The OP is using W11 as the host:

+1 :+1:

26

My correction to the first and my posting in this “thread” of postings:

In ‘I would like to continue to be able to use the “zypper refresh” and “zypper install” commands to update software packages”’
Change “zypper install” to “zypper update”.
Sorry, I made that mistake.

Reference: last paragraph of posting number 10 in this “thread” of postings
My attempt failed to enable my Plasma (x11) “desktop” in Leap 16.0 to again become visible after a lengthy period of my inactivity on it. But from the Mozilla Firefox Web browser’s search “engine’s” “Search Assist” here is what gratefully did work for me to have no timeout of my Plasma (x11) “desktop” screen.
In the file Logout.qml in the directory
/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/logout
in the line reading as
“property real timeout: 30”
as a “root” user I changed it to read as
“property real timeout: 0”.

Now I present a summary of the situation I have otherwise discussed here. Usually I upgraded my openSUSE or OpenSUSE “guest” operating system in Oracle VM (Virtual “Machine”) VirtualBox, or hereafter just “VirtualBox,” soon after a new version of openSUSE or OpenSUSE was released. But after I learned that Leap 16.0 had been released in early October of the year 2025, I did not immediately upgrade my Leap-15.6 installation due to the following two, linked reasons:

  1. My Leap-15.6 installation eventually was working satisfactorily for me to produce mainly technical write-ups and occasionally to compile, link, and execute Fortran computer programs. And I would like to continue to have those computer-software capabilities in the future.
  2. Reports from my Mozilla Firefox Web browser’s DuckDuckGo’s search “engine’s” “Search Assist” indicated that were that there were problems with Leap 16.0 and/or that some users of it were not pleased with it because they had apparently lost some features or conveniences of an earlier version of openSUSE Leap.
    However, a later report on Leap 16.0 seemed to be more favorable than earlier concerning Leap 16.0.

I think that my title for this “thread” of postings of
“For my usages should I upgrade Leap from version 15.6 to version 16.0 or not?“
accurately reflected the question of whether I should upgrade Leap 15.6 to Leap 16.0 or not. Perhaps someone in such a posting could provide information which could help me make that decision. In fact, besides myself, the first other poster OrsoBruno’s posting in this “thread” of postings could encourage a fellow to at least delay making that upgrade until a problem he reported in Leap 16.0 would be fixed.

Nevertheless with the April 30, 2026 date of the ending of new updates for Leap 16.0 approaching, in the latter part of April of the year 2026 I went ahead to try to make that upgrade! And the backup I made of my satisfactorily working Leap-15.6 installation gave me a so-called “fall-back” option in the case of problems with Leap 16.0 which could allow me to take such a chance with Leap 16.0.

Now, skipping the discussion of some problems I had in making that upgrade, the results of some tests showed that I could continue to produce technical write-ups and compile, link, and execute Fortran computer programs in my Leap-16.0 installation, as in some earlier installations of openSUSE Leap or OpenSUSE. The main operational problem I “faced” in my Leap-16.0 installation was that I could no longer produce VirtualBox Guest Additions after updates of either VirtualBox or the Linux kernel via either one of my preferred methods of “Devices, Upgrade Guest Additions…” or “Devices, Insert Guest Additions CD” (Compact Disc) “image…” In fact, that shortcoming in my Leap-16.0 I assume still exists today, April 29, 2026. The VirtualBox Guest Additions have been needed for the convenience of a) being able to copy and “paste” text between my Windows-11, “host” and Leap-16.0, “guest” operating systems and b) to be able to transfer files between those two operating systems via a folder shared by those two operating systems. To continue with Leap 16.0 in the short run of time I needed to find other means of having well-working VirtualBox Guest Additions. And gratefully I found two of those means:

A) to “boot” Leap 16.0 with the Linux kernel-default

6.4.0-150600.23.92.1

from my previous, Leap-15.6 installation; while running Leap 16.0 in that Linux kernel-default, to produce VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…”; and to continue to “boot” Leap 16.0 with that Linux kernel;

B) to “boot” Leap 16.0 with the latest Linux kernel-default available via an openSUSE, Leap-16.0, online repository, which now on April 29, 2026 happens to be version

6.12.0-160000.28.1

of the Linux kernel-default, and to rely on the VirtualBox Guest Additions which came with that Linux kernel-default based presently on VirtualBox 7.2.6 and/or the software package virtualbox-kmp-default, which contains .ko kernel modules.

So far there has been some kind of a problem of incompatibility between Leap 16.0 and VirtualBox 7.2.8 concerning the production of VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…” I think that problem is more likely on the Leap-16.0 side than on the VirtualBox 7.2.8 side of that matter. But after that problem is fixed, I hope that new VirtualBox Guest Additions could again be produced by the method of “Devices, Upgrade Guest Additions…” when a version of kernel-default from an openSUSE, Leap-16.0 repository is available and running in my Leap-16.0 installation. And furthermore there is the hope that the method of “Devices, Upgrade Guest Additions…” or “Devices, Insert Guest Additions CD image…” could be used to produce new VirtualBox Guest Additions after an update of either the Linux kernel-default or VirtualBox, or both of them.

I have experienced problems with properly operating VirtualBox Guest Additions in at least one other version of openSUSE. And such a problem occurred after upgrading or installing a new version of openSUSE. Some years ago the late Larry Finger informed me that there was a problem requiring the backporting of computer code to enable compatibility between versions of VirtualBox and openSUSE. Such a problem could in principle be solved by, on the openSUSE side, the backporting of computer code or, on the Oracle Corporation side and some time after a new version of openSUSE was released, the production of new versions of VirtualBox which were supportive of openSUSE Linux kernels. But my impression is that that matter may been improved on the VirtualBox side of the matter because more recently some new versions of VirtualBox were kindly made by Oracle Corporation which were immediately supportive for the Linux kernels issued by openSUSE online repositories.

27

@2009Newbie not sure why your not just creating a new Leap 16.0 guest to test? Anyway the point is somewhat moot, you have one more day before Leap 15.6 goes End of Life, would have thought a process would have been started in June last year to work out the kinks?