Concerning "1.  I suppose that openSUSE code developers receive the source code for a new kernel version from an organization outside of openSUSE and then modify that code to make it suitable for an openSUSE environment.", the original source for a new kernel for a Linux operating system be might be within https://www.kernel.com/ on the Internet.

The problems or potential problems I reported on https://bugzilla.opensuse.org/show_bug.cgi?id=1227357 and https://bugzilla.opensuse.org/show_bug.cgi?id=1227354 on the Internet might have a partially overlapping cause with the problems I reported in this so-called "bug" report.

I cannot duplicate this on my laptop.

If you try to install Oracle's 7.0.18 on 15.6 - it will not compile.
/sbin/vboxconfig would not compile - so no VirtualBox from Oracle.

Larry Finger got it to work and it work correctly for my laptop.

virtualbox-kmp-default has 6.9.x code fixes from Oracle - that is Tumbleweed and Slowroll.

6.4.x (Leap 15.6) is OpenSUSE patched to CVE's that are in 6.9.x and those fixes are not know to Oracle's virtualbox-kmp-default source.

Now, with Oracle's help, I get fixes for 15.6. These will be in 7.0.20.
I have been testing this on my systems but have not sent to OpenSUSE yet.

You can try the Oracle code with this Oracle rpm.
Download link: https://www.transferxl.com/download/00vQ0dZrFxrKK8

Sorry, in rereading some of my own writing in my first posting in this “thread” of postings I discovered that I mistakenly omitted the word “of” in ‘That is in either case such movement should be accompanied by the movement of a symbol looking like a pointer “arrow” or “I beam” over the computer screen.’

Larry Rainey, our communications to each other here unfortunately may not have been very effective or else resulted in my guessing and/or supposing what you meant by some of your writing.   I can imagine two possible interpretations for your text reading

“If you try to install Oracle's 7.0.18 on 15.6 - it will not compile.” 
:
C1) From “try to install Oracle’s 7.0.18 on 15.6”, especially from your word “on” you might have meant that you tried to install Oracle Corporation’s VM (Virtual “Machine”) VirtualBox 7.0.18 as an application in a Leap-15.6 installation.   Or

C2) you might have meant that you tried to have VirtualBox Guest Additions “built” or compiled from Oracle Corporation’s VirtualBox 7.0.18 computer software on or in a Leap-15.6 installation.

On probably June 12 or 13, 2012 I did try C2 via the Oracle Corporation command 

./VBoxLinuxAdditions.run

with probably the first-supplied Leap-15.6 kernel-default-6.4.0-150600.21.2.x86_64 in my Leap-15.6, “guest” installation in VirtualBox 7.0.18, but failed in successfully performing C2.  And that was probably because of a mismatch due to a lack of backporting to make kernel-related computer software match between Oracle Corporation’s VirtualBox 7.0.18 and Leap-15.6’s kernel-default-6.4.0-15600.21.2.x86_64, a phenomenon kindly explained to me for a similar situation in the year 2021 by Larry Finger.  Since that failure on June 12 or 13, 2024 I have not tried to perform either C1 or C2.  And the problems I reported in the https://bugzilla.opensuse.org/ postings numbered 1226910, 1227354, and 1227357 and for which I seek resolutions or explanations do not have to do with either one of the procedures C1 or C2.  Instead I reached a state in my Leap-15.6, “guest” installation in VirtualBox 7.0.18 in which I am depending on

D1) the version of the VirtualBox Guest Additions which are probably contained within kernel-default-6.4.0-150600.23.7.3.x86_64 and

D2) the software packages virtualbox-kmp-default and virtualbox-guest-tools installed from Leap-15.6, online repositories. 

Larry Finger kindly explained to me in another, https://bugzilla.opensuse.org/ so-called “bug” report of mine some years ago that in recent years the VirtualBox Guest Additions have been included in openSUSE Linux kernels; and I assume that policy has continued through at least July 9, 2024.

Notice that I have comments here to two different Larrys—Larry Rainey and Larry Finger.  But all of my comments except the ones in which I explicitly mention “Larry Finger” in this July 9, 2024 set of comments of mine are directed only to Larry Rainey.

I suggest that Larry Rainey and Larry Finger read at least all of my first posting in this “thread” of postings and, in addition my postings on https://bugzilla.opensuse.org numbered 1227354 and 1227357 because

B1) all three of these postings concern problems or unusual phenomena in my Leap-15.6 installation and

B2) there might a common cause for more than one of those problems or unusual phenomena I have reported in my https://bugzilla.opensuse.org postings numbered 1226910, 1227354, and 1227357.

And Larry Rainey, if you have trouble understanding my writing especially in this posting on https://bugzilla.opensuse.org numbered 1226910 and you have a personal connection with Larry Finger, kindly ask Larry Finger to please explain to you my writings in these “bugzilla” postings numbered 1226910, 1227354, and 1227357.  Based on Larry Finger’s and my past communications within another posting on https://bugzilla.opensuse.org I think that Larry Finger may understand much of my writing concerning at least the matter of probably minor importance of VirtualBox Guest Additions among these three “bugzilla” postings, since by now I have the aspects A, B, and C, which I later explain here, of VirtualBox Guest Additions gratefully working in my Leap-15.6 installation.

In contrast, of particular and perhaps major importance is the error message

“vmwgfx seems to be running on an unsupported hypervisor” (with VirtualBox 7.0.18 being the hypervisor in my case) 

,  which appeared during “booting” with a kernel-default-6.4.0-150600….x86_64 running toward Leap 15.6’s login screen, that I discussed in my “bugzilla” posting numbered 1227357 which,

aaa) given how well VirtualBox 7.0.18 worked with its “Settings, Display, Graphics Controller” set to VMSVGA (Virtual “Machine” Super Video Graphics Array) for me with Leap 15.5 installed as the “guest” operating system within VirtualBox 7.0.18 and

bbb) the fact that I did not receive the above “vmwgfx..” message during the early stage of “booting” into Leap 15.6 while the kernel-default-5.14.21-150500.55.65.x86_64 from Leap 15.5 was the running Linux kernel

make me very suspicious that a combination of virtualbox-kmp-default, virtualbox-guest-tools, and probably any one of the first three versions 6.4.0-150600….x86_64 of the Linux kernel-default, all of which were supplied through Leap-15.6, online repositories, may not have been well designed to work well within VirtualBox 7.0.18, still with VirtualBox-7.0.18’s, “Settings, Display, Graphics Controller” of VMSVGA.  Please notice that the word “within” in my previous sentence implies that I am here discussing Leap 15.6 as a “guest” operating system within VirtualBox and not “the other way around” of trying to install VirtualBox within an openSUSE, Leap-15.6, “host” operating system.

(A parenthetical question for which the answer could be important for users of openSUSE operating systems as “guest” operating systems within VirtualBox: My following question deals exclusively with openSUSE “guest” operating systems within VirtualBox.  How may I, from outside of a version of an openSUSE-supplied kernel-default, which in practice could mean without inspecting kernel-default’s source code, determine which version or versions of VirtualBox that a version of an openSUSE-supplied kernel-default is supposed to support?  Note that this is the opposite question of which versions of openSUSE and its Linux kernel-default that VirtualBox will support; and it is conceivable that these two questions could have different answers.  [It is somewhat like a man and a woman getting married.  If the man likes the woman, that is only half of what is needed for a marriage between them to occur.  If a woman likes a man, that is another half of what is needed for a marriage between that man and woman to occur.  Similarly the computer software in an openSUSE, “guest” operating system needs to work well with the computer software in VirtualBox; and vice versa the computer software in VirtualBox needs to work well with the computer software in an openSUSE, “guest” operating system.  If the computer software in either the VirtualBox or openSUSE installation cannot work well with the computer software in the other installation, then that openSUSE, “guest” operating system may not work well in that VirtualBox installation.]  In this regard I think that it would be good for the developers of openSUSE’s software package kernel-default to publish online a table of the versions of VirtualBox that openSUSE-supplied versions of kernel-default are supposed to support and to regularly update that table with new data.  Without users of openSUSE knowing the answer to my question here, it is conceivable that some users of openSUSE operating systems may try to get a version of the Linux kernel-default in an openSUSE “guest” operating system to work inside a version of VirtualBox for which that version of openSUSE was not designed to support.)

Then afterward, Larry Rainey, please start over in your writing here and write to me what remains, if anything of it, to be relevant to my situation.  And please make your sentences long enough so that I can know precisely about what you are writing.---For example, every time you write a version number please inform me of which computer program or software package you are quoting that version number.  But I think I can guess that frequently your version numbers were likely for versions of a Linux kernel.  And instead of writing, “I cannot duplicate this on my laptop,” please in this kind of situation write a sentence with enough very specific detail in it so that I can see whether your test situation was equivalent to any of my sets of software installations or not.

Important points for you to realize:

1.  I have Oracle Corporation’s VirtualBox 7.0.18 r162988 (Qt5.15.2) installed as an application or computer program in a 64-bit, Windows 10 Home Edition, “host” operating system on my notebook computer’s internal hard-disk drive.  (You can see that “in passing” I mentioned that fact in

‘my VirtualBox-“host”, 64-bit, Windows 10 Home Edition, operating system’s screen’

in the next-to-last sentence of my first paragraph in this so-called “thread” of postings.)  Leap 15.6 is a so-called “guest” operating system that I have installed in my Oracle Corporation’s VirtualBox 7.0.18, Windows-10 application.  The word “guest” here makes sense if you think of a guest visiting someone’s home.  That is, when writing figuratively and by analogy, in my situation Leap 15.6 is like a “guest” in the “home” of VirtualBox; and VirtualBox is like the “home” for its “guest”, Leap-15.6 operating system.

Or, in an even better and more complete analogy, you can think of some computer-related software in the following way.  Suppose that you travel to the house of a distant friend of yours and stay overnight in his house, sleeping overnight in a bedroom of his house that is available only for guests in that house.  That friend of yours is your “host;” his bedroom for your sleeping is your temporary “home” in his house; and you are your friend’s “guest” in that bedroom.  Similarly I have a Windows 10 Home Edition, “host” operating system on my computer.  In that “host” operating system I have a “home” of VirtualBox 7.0.18 for its “guest” operating system of Leap 15.6.  

I have not been trying to install Oracle Corporation’s VirtualBox 7.0.18 in my Leap-15.6 operating system.  So I have not been trying to make Oracle Corporation’s VirtualBox 7.0.18 be a “guest” in the “home” of Leap 15.6.

2.  In my Leap-15.6 “guest” operating system I could not have VirtualBox Guest Additions (VBGA) “built” from Oracle Corporation computer software.  Some repetition here: Larry Finger kindly explained at least some of that matter for me in another https://bugzilla.opensuse.org/ posting on the Internet.  This result was probably due to the necessary backporting of Leap-15.6-related computer software not yet having been made to enable me to have Oracle Corporation VBGA successfully “built” for my Leap-15.6, “guest” operating system in VirtualBox.  In this regard and at least for the present period of time I am content to use the VBGA, which I understood from Larry Finger, have been supplied for already a few years of time within the openSUSE Linux kernels and I assume are continued to be supplied with openSUSE Linux kernels.  I have found that in Leap 15.6 I can gratefully have the well-working VBGA functions of

A. the sharing of a folder by my “host”, Windows-10 and “guest”, Leap 15.6 operating systems;

B.  the copying and “pasting” of text via the so-called computer “clipboard” of I suppose Random Access Memory (RAM); and

C.  VirtualBox 7.0.18 providing a wide window for my “guest” operating system, which probably includes the window-resizing function the VBGA,

by having the following, openSUSE, software packages installed:

kernel-default,
virtualbox-guest-tools, and
virtualbox-kmp-default.

And in the meantime I am content to wait for Oracle Corporation to kindly make a new version of VirtualBox with the provision of “initial support for Leap-15.6 kernels,” the sort of “signal” I would expect to find in a so-called “Changelog” within the World-Wide Web site with the https://www.virtualbox.org/ for such a new version of VirtualBox.  After seeing such a “signal” in such a “Changelog” for a new version of VirtualBox I could expect the “building” of VBGA using Oracle Corporation computer software via the command ./VBoxLinuxAdditions.run to be successful for the versions of kernel-default to be used in a Leap-15.6 installation and thereafter for me to not have to rely on Leap-15.6 Linux kernels to supply VBGA for me or to need to have virtualbox-guest-tools installed in my Leap-15.6 installation.

Doing a little guessing on my part, it might be that openSUSE software developers might be diligently working close to the date of the public release of a new version of openSUSE to develop a version of the Linux kernel which will work well with both the computer programs to be used in a new version of openSUSE and the numerous types of computer hardware in which that new version of openSUSE would be expected to be used.  So then after that release of the new version of openSUSE it might take Oracle Corporation some time to kindly enable support for the series of versions of the Linux kernel to be used in that new version of openSUSE.

3.  I suppose that the words “build” and “compile” may be used interchangeably among some developers of computer code.  If so, there is one “build” or “compilation” which it appears is designed to occur automatically every time I update the Linux kernel in an openSUSE installation.--And that is to automatically have a new version of the initial Random Access Memory (RAM) disk (initrd) “built” every time a new version of the software package kernel-default is installed in an openSUSE installation.  Aside from that automatic process I occasionally had some Fortran computer programs compiled and linked.  And, more frequently than compiling Fortran code, I processed some .tex files containing LaTeχ code and .bib, reference-containing files that I wrote using, respectively, the computer programs pdflatex and bibtex.  Perhaps those executions might be called compilations or “builds”.  Besides these kinds of situations I am not aware of any need for me to compile or “build” anything else in my openSUSE, “guest” installation in my application of VirtualBox installed within my Windows-10 “host” operating system.  But I expect that to change after Oracle Corporation will release a new version of VirtualBox which will provide “initial support for Leap-15.6 kernels.”  After that I expect to resume having VirtualBox Guest Additions “built” from Oracle Corporation computer software via the command ./VBoxLinuxAdditions.run, instead of me relying on the VirtualBox Guest Additions which I assume will continue to be included in new versions of the Linux kernel released via openSUSE, online repositories.

4.  I looked up your abbreviation “CVE” on the Internet to see for what words those capital letters might stand.  Based on https://www.suse.com/security/cve/CVE-2024-3094.html on the Internet in the SUSE context it appears that that abbreviation may stand for Common Vulnerabilities and Exposures.

5.  Via a data backup of my notebook computer’s internal hard-disk drive, which included my Leap-15.5 installation, onto an external hard-disk drive, I was gratefully able to upgrade my Leap-15.5 installation twice to Leap 15.6.  After I knew for certain that via Oracle Corporation’s command

./VBoxLinuxAdditions.run

in Leap 15.6 I could not successfully have VirtualBox Guest Additions “built” from Oracle Corporation VirtualBox 7.0.18 computer software for one or two of the initially released versions of kernel-default supplied through Leap-15.6 software repositories, prior to my second such upgrade I set up Leap 15.5 to be depending on the VirtualBox Guest Additions that I assumed, based on Larry Finger’s, years-earlier, kindly supplied information, would continue to be included in the Linux kernel (version 5.14.21-150500.55.65.1.x86_64.x86-64 of kernel-default in this case) of Leap 15.5.  In addition, I had the software packages virtualbox-guest-tools and virtualbox-kmp-default installed from Leap-15.5, online repositories.

And here is how I did that with an inclusion of some of my thinking for why implementing the following procedure could make sense.  For later reference let me define the following procedure below through item “cc” as “Leap-15.5 Preparation”.  After my upgrade from version 15.5 to 15.6 of Leap I speculated that some of my problems in Leap 15.6 might have been due to Oracle Corporation-”built” VirtualBox Guest Additions for the Linux kernel 5.14.21-150500.5.65.1.x86_64 “passed along” to Leap 15.6 and attempted to be used with the Leap-15.6 Linux kernel 6.4.0-160600.21.2.x86_64.

(Important parenthetical comments: In my mind an ideal situation is to have VirtualBox Guest Additions “built” from Oracle Corporation computer software via Oracle Corporation’s command “./VBoxLinuxAdditions.run” [You might be still able to find advice preferring the “building” of VirtualBox Guest Additions from Oracle Corporation computer software on https://en.opensuse.org/VirtualBox on the Internet.].  I could issue that command as a “root” user in the computer program LXTerminal after clicking in the top “menu” of the “window” supplied by VirtualBox for an openSUSE, “guest” operating system on “Device, Insert Guest Additions CD” [Compact Disc] image...” for each version of VirtualBox and after each update of the software package kernel-default supplied through an openSUSE, online repository.  But sometimes, especially soon after the public release of a new version of openSUSE, due to mismatches between the kernels supported by Oracle Corporation’s VirtualBox and the kernels supplied through openSUSE repositories, this procedure cannot always be successfully executed.  And after such a failure that is a time I can resort to depending on the VirtualBox Guest Additions, which according to Larry Finger, have been included for some years of time in the Linux kernels supplied through openSUSE, online repositories.  Let me define as the “fallback option” the option of relying on the VirtualBox Guest Additions within the Linux kernels supplied through openSUSE, online repositories together with the installations of the software packages virtualbox-kmp-default and virtualbox-guest-tools from openSUSE, online repositories.  The good news for me is that this “fallback option” for VirtualBox Guest Additions may work well for me.)

Somewhat in ignorance, I just guess that there might have been significant differences between those two Linux kernels.  So with some ignorance on my part regarding the relevant computer codes and to use an American expression, I might have been, in effect, “mixing apples and oranges” or making an incompatible mixing of different things in trying to make VirtualBox Guest Additions, “built” from Oracle Corporation VirtualBox-7.0.18 computer software with Leap-15.5’s kernel-default-5.14.21-150500.55.64.1.x86_64 running, work, still as a “guest” in VirtualBox-7.0.18, in Leap 15.6 with its kernel-default-6.4.0-150600.21….x86_64.  So via a backup on an external hard-disk drive of the data previously written on my computer’s internal hard-disk drive, I could gratefully return to my well-working, Leap 15.5, “guest” installation in Oracle Corporation’s VirtualBox.  My goal was to try to rely on the VirtualBox Guest Additions (VBGA) supplied by an openSUSE software repository in a Leap-15.5 kernel-default, rather than VBGA “built” from Oracle Corporation computer software, and afterward to attempt another upgrade from Leap 15.5 to Leap 15.6; then after that upgrade, in Leap 15.6 I would attempt to rely on the VBGA in the Leap-15.6 Linux kernel-default again from an openSUSE repository.  Toward that goal I uninstalled the Oracle Corporation-”built” VBGA by in the VirtualBox window supplied for Leap 15.5 clicking on “Devices, Insert Guest Additions CD image…” and in the terminal computer program LXTerminal as a so-called “root” user switching to a directory via the command

cd /run/media/newbie/VBox_GAs_7.0.18

(“Change directory” is for what the abbreviation “cd” stands.) for my Leap-15.5, regular-user “name” “newbie” and my Oracle Corporation VirtualBox version 7.018r162988 (Qt5.15.2) installed in my Windows-10, “host” operating system, and then, continuing in the directory /run/media/newbie/VBox_GAs_7.0.18, by 

aa) entering the command

./VBoxLinuxAdditions.run uninstall

(I think that thought stimulating for me in this uninstallation procedure was “Uninstalling Oracle VM VirtualBox Guest Addition CD image in Ubuntu – YouTube” on https://www.youtube.com/watch?v=XmTFPj5sfNA on the Internet.) and

bb) in “YaST” (Yet another Software Tool) “Software” changing the setting for the software package virtualbox-guest-tools from “Taboo”, which I think was equivalent to “never install”, to probably “Update unconditionally.”  (From the looks of the upward-pointing green arrow in a check box beside virtualbox-guest-tools after selecting either “Update” or “Update unconditionally” for virtualbox-guest-tools, I think that selecting either “Update” or “Update unconditionally” while my Leap-15.5 installation was connected to the Internet would likely have resulted in the latest version of the Leap-15.5 version of the software package virtualbox-guest-tools being installed.)

However, in that first attempt to prepare my Leap-15.5 installation for upgrading it to Leap 15.6 I also

cc) unfortunately in “YaST Software” had all installed versions of virtualbox-kmp-default uninstalled and afterward had virtualbox-kmp-default reinstalled from a Leap-15.5 online repository.

But the result of executing the above, “Leap-15.5 Preparation” procedure was that after probably upgrading my Leap-15.5 installation to Leap 15.6 I did not have the good functions of VirtualBox Guest Additions in my resulting Leap-15.6 installation.  I reasoned that the cause of this malfunction may have been my mistaken inclusion of all of the above item “cc” in the above “Leap-15.5 Preparation” procedure.  So via the backup of my Leap-15.5 installation onto an external hard-disk drive I returned on my computer’s internal hard-disk drive to my previously written Leap-15.5 “guest” installation in VirtualBox 7.0.18.  And then afterward I repeated the above, “Leap-15.5 Preparation” procedure without performing the above item “cc”.   And then I upgraded that Leap-15.5 “guest” installation in VirtualBox 7.0.18 a second time to Leap 15.6.   And gratefully afterward I had the good function of the VirtualBox Guest Additions in my Leap-15.6 “guest” installation in VirtualBox 7.0.18, which was still an application in my “host”, Windows-10 operating system.  The version of kernel-default used in that Leap-15.6 installation at that time was one of the 6.4.0-150600.21…..x86_64 versions supplied through a Leap-15.6 online repository.  The problems I have been reporting in my https://bugzilla.opensuse.org/ postings numbered 1226910, 1227354, and 1227357 have apparently not been due to the VirtualBox Guest Additions included in any of the first three versions of kernel-default supplied through an Leap-15.6 online repository.  But the problems and/or unusual phenomena I reported in my https://bugzilla.opensuse.org/ postings numbered 1226910, 1227354, and 1227357 have likely appeared due to a combination of probably any one of the first three versions of the software package kernel-default and the software packages virtualbox-guest-tools and virtualbox-kmp-default, all of which were supplied through Leap-15.6 online repositories. 

Returning to discussing my previous, Leap-15.5 installation, I gratefully had the good function of Leap 15.5 as a “guest” operating system in VirtualBox 7.0.18, which in turn has been an application in my “host,” Windows 10 Home Edition operating system; and not only that, I think my entire Leap-15.5 installation worked well in the Lightweight X Windows System, Version 11 (X11), Desktop Environment (LXDE) I have generally preferred to use in openSUSE operating systems!  And even after the upgrade from Leap 15.5 to my new, “guest,” Leap-15.6 operating system, still in VirtualBox 7.0.18!, I gratefully continued to have the good above functions A, B, and C of VirtualBox Guest Additions in Leap 15.6 kernel-default in my Leap-15.6 installation with kernel-default virtualbox-guest-tools and virtualbox-kmp-default from Leap-15.6 online repositories.  So even though I did not write any of the core, Leap-15.6 computer code, including its versions of kernel-default, my confidence level is fairly high that any of the matters I report in the bugzilla postings numbered 1226910, 1227354, and 1227357 which turn out to be actual problems instead of intentional designs, would not be due to problems in Oracle Corporation VirtualBox 7.0.18, but rather be due to software problems within Leap 15.6.  Therefore rather than wait for a new version 7.0.20 of VirtualBox to be publicly released, unless it will include “initial support for Leap-15.6 kernels,” I request that any of the matters I reported in the “bugzilla” postings numbered 1226910, 1227354, and 1227357 be fixed in openSUSE Leap 15.6 before I update VirtualBox in my Windows-10, “host” installation from version 7.0.18 to 7.0.20.  Otherwise it might well be that I might have some, if not all of the same problems in my Leap-15.6 installation as a “guest” of VirtualBox 7.0.20 that I have been having in Leap 15.6 as a “guest” of VirtualBox 7.0.18!  [Note that some of those problems have been exclusively in the Lightweight X Windows System, Version 11 (X11) Desktop Environment (LXDE) of Leap 15.6.]  I think rather that the major improvements need to be made in some combination of the software packages kernel-default, virtualbox-guest-tools, and virtualbox-kmp-default of Leap 15.6 to eliminate the matters which turn out to be real software problems instead of possibly intentional design changes from Leap 15.5 to Leap 15.6.

From your writing, Larry Rainey, I can realize that you are an “insider” in the code maintenance and/or development for openSUSE concerning VirtualBox.  I do not know if you are paid for such work or not.  But you might have a supervisor in your work.  And it seems as though your focus may be on trying to accommodate the upcoming VirtualBox 7.0.20 in openSUSE computer software.  Concerning the Leap-15.6 problems and/or Leap design changes I have reported among my https://bugzilla.opensuse.org/ postings numbered 1226910, 1227354, and 1227357 I think that both you and your supervisor need to realize that focusing on preparing openSUSE Leap 15.6 for VirtualBox 7.0.20 is, at least logically, the wrong focus to have, unless you have no choice but to be ready in Leap 15.6 for the release of VirtualBox 7.0.20.  Ideally your focus should instead be changed to fixing the problems in Leap 15.6.  With some repetition here is the logic for now focusing on solving Leap 15.6’s problems.

AA.  In VirtualBox 7.0.18 I did not have the problems in my Leap-15.5 “guest” that I have been having in Leap-15.6 “guest” operating system.  (Again I reported those problems in the postings numbered 1226910, 1227354, and 1227357 on https://bugzilla.opensuse.org/.)

BB.  Therefore those problems are not in VirtualBox 7.0.18 and were not in Leap 15.5, but are in Leap 15.6!

CC.  And therefore I think that trying to make Leap 15.6 work with VirtualBox 7.0.20 is the wrong focus in your work at this time, unless you have no choice in this matter!  Instead consider you and Leap-15.6 software developers temporarily placing a higher priority on fixing the problems in Leap 15.6 as a “guest” in VirtualBox 7.0.18.  Then, after you and/or those developers solve those problems, do what remains to be done to make Leap 15.6 work well as a “guest” operating system within the future VirtualBox 7.0.20.

Important: Unless you have no choice in the matter, both you and your supervisor need to “get on board” (an American expression) or agree with this logic.  Do you both agree with my logic here?

A detail is that https://bugzilla.opensuse.org/ posting number 1226910 concerning the initially invisible pointer arrow concerns primarily the LXDE and the first three versions of kernel-default and/or virtualbox-kmp-default and/or virtualbox-guest-tools, which are all supplied through Leap-15.6 online repositories.  And for https://bugzilla.opensuse.org/ postings numbered 1227354 and 1227357 they may contain problems before leaving the login screen to proceed toward some choice of the “Desktop Session” in Leap 15.6.  I only write “may contain” because some of those “problems” might not be software problems, but instead be intentional changes in designs from Leap 15.5 to Leap 15.6.  In fact in posting numbered 1227354 I ask which ones of the four unusual phenomena reported there are due to intentional design changes from Leap 15.5 to Leap 15.6.

Potential difficulties:

AAA) If VirtualBox 7.0.20 will be publicly released before you and openSUSE software developers can solve the problems in Leap 15.6 as a “guest” in VirtualBox 7.0.18 (which I have reported in the https://bugzilla.opensuse.org/ postings numbered 1226910, 1227354, and 1227357) and VirtualBox 7.0.20, I do not know what you can do to prevent or delay people from upgrading or updating VirtualBox (with a Leap-15.6 “guest” in it) from its current version of 7.0.18 to its future version of 7.0.20.  You might not be able to effect such a temporary prevention or delay.  Ah!  Maybe that is why you would have no choice but to now or soon be concerned with preparing a Leap-15.6 “guest” operating system to work in VirtualBox 7.0.20!  But I think I can avoid almost all of the problems I reported in Leap 15.6 in the above three “bugzilla” postings by in Leap 15.6 using the Leap-15.5 combination of kernel-default-5.14.21-150500.55.65.1.x86_64 and the virtualbox-guest-tools and virtualbox-kmp-default which have probably all been “passed along” from my Leap-15.5 to my Leap-15.6 installation in my upgrade of Leap 15.5 to Leap 15.6.

BBB) If the problems I reported in the https://bugzilla.opensuse.org/ postings numbered 1226910, 1227354, and 1227357 in Leap 15.6 are not solved before Oracle Corporation kindly begins to “provide initial support for Leap-15.6 kernels” in openSUSE “guest” operating systems, it could put the developers of Oracle Corporation’s VirtualBox in an awkward position of trying to develop such kernel support in its new version of VirtualBox for an openSUSE kernel-default which does not work completely well in an openSUSE, “guest” operating system in VirtualBox 7.0.18 or maybe version 7.0.20 of it.  An obvious logical solution is for openSUSE developers to at some level eliminate the problems in its kernel-default when the openSUSE operating system is a “guest” operating system in VirtualBox 7.0.18 and to inform VirtualBox developers that its kernel-default at least generally works well before those VirtualBox developers begin to “provide initial support for Leap-15.6 kernels” in a new version of VirtualBox.  But I may have “gotten myself somewhat lost” in a “circular argument” here regarding who must work first and who must work second concerning the developers of openSUSE’s kernel-default and Oracle Corporation’s developers of VirtualBox.  So regarding the situation in which openSUSE would be a “guest” operating system in VirtualBox maybe the developers of openSUSE’s kernel-default and Oracle Corporation’s VirtualBox will have to coordinate their corresponding computer-software developing activities to enable a well-working, coordinated match between openSUSE’s kernel-default and the openSUSE kernel support in a new version of VirtualBox designed to support Leap-15.6 kernels.

Some closing thoughts in this collection of data and thoughts: My usual habit has often been to put all of my writing with all of its aspects in one online, “forum” posting.   As usual in life before problems are solved the thinking and writing can be lengthy, especially when considering multiple possible solutions to a problem.  However, this time I separated my thoughts into multiple Web pages with the “bugzilla” postings numbered 1227354 and 1227357 so far being relatively short in length and this posting numbered 1226910 now becoming lengthy.  This strategy had the apparent advantages that

A1) a group of problems and/or unusual phenomena appearing together during “booting” or together on the same login screen when briefly discussed could be “digested” and considered together and,

A2) for people lacking the time and/or patience to read all of my lengthy postings, making short postings might increase the number of people reading my postings in their entireties.

However, a major disadvantage of this separating strategy is that people who do not turn to and read all of my “bugzilla” postings numbered 1226910, 1227354, and 1227357 and who are thinking people might not realize a possible “key” error which might have caused more than one of the problems I reported in these postings.  That is the more clues that a thinking person obtains, the probability that he may solve a mystery may increase.  In this posting I have incorporated at least two data and just some of my thinking in the https://bugzilla.opensuse.org/ posting numbered 1227354 in the hope that you, this posting’s readers, might realize that a combination of virtualbox-kmp-default, virtualbox-guest-tools, and probably any one of the first three versions 6.4.0-150600….x86_64 of the Linux kernel-default, all supplied through Leap-15.6, online repositories may not have been well designed to work well within VirtualBox 7.0.18.

Sorry, in case I caused either of you, Larry Finger or Larry Rainey, any trouble for any of my postings within https://bugzilla.opensuse.org/ on the Internet.  But thank you in advance for any and all efforts you will make toward solving the problems I reported with my “bugzilla” postings numbered 1226910, 1227354, and 1227357.

Larry Finger died 3 weeks ago.

I do not fix Virtualbox code - I just take what Oracle has and make it compile in OBS to add to the repos. 

I cannot make your problem happen.

Here is a link to the pure Oracle for Leap 15.6 for you to install to see if it still happens. If so - report the bug to Oracle. The link is good for 7 days. It is in a zip file at tansferxl.

https://www.transferxl.com/download/00v7sRbk8pk6vZ

Also you can go here and try the corrected patched OpenSUSE 15.6 Virtualbox

https://build.opensuse.org/project/subprojects/home:larryr

I have submitted to Factory - I have no control over if they will release it.

the correct way to install the pure Oracle rpm is to 

zypper rm virtualbox virtualbox-kmp-default virtualbox-qt

then reboot

zypper in VirtualBox-7.0-7.0.18_20240703_openSUSE156-1.x86_64.rpm

It is not signed so you will have to "i" ignore to install it

You may have to reboot.

I am not a developer - I volunteered to help Larry Finger test VirtualBox in OpenSUSE. I saved everything that Larry Finger did to go from 7.0.16 to 7.0.18. Larry Finger actually looked at the Kernel Source code and came up with 4 patches to get a clean compile and a week to get the bugs out. I took two weeks to get it to work with Oracle's 15.6 patches and still do 15.5 and Tumbleweed. Getting the Oracle rpm created took in 1 try. I spent at least 60 tries in OBS before I got a clean compile.

Larry Finger developed his own patches to the kernel to get 7.0.18 into Leap 15.6. I cannot do that nor will I even try. I barely got the Oracle 15.6 patches into the OBS system, I removed every Larry Finger patch as Oracle has code that works in Leap 15.6 , 15.5 and Tumbleweed. That puts all the problems in Oracles court. I cannot fix any problems, I can confirm them with Oracle.

I cannot and will not test every desktop. OpenSUSE come in Gnome and KDE and I test those hard along with the MATE desktop that I use.

You are welcome to download the project yourself and go thru the 101000 files that make up VirtualBox 7.0.18. It takes 14 minutes to compile on an i7-12000T with 20 cores for each of the 3 supported version of OpenSUSE.

There are plenty of problems reported with Oracles VirtualBox 7.0.18 on their bugzilla.

Hello, Larry Rainey.  That was too bad that Larry Finger unfortunately died on June 21, 2024!  Larry Finger was kindly helpful to me in another “bugzilla” report of mine some years ago.

But, regarding the opening problem in this “thread” of postings, gratefully I found a way to make the pointer arrow stay visible over the Lightweight X Windows System, Version 11 (X11) Desktop Environment (LXDE) window after entering that “Desktop Setting” in my Leap-15.6, so-called “guest” installation within Oracle (Corporation’s) VM (Virtual “Machine”) VirtualBox 7.0.18 r162988 (Qt5.15.2).  (Again my so-called “host” operating system is a 64-bit, Windows 10 Home Edition, operating system; and VirtualBox 7.0.18 is an application or computer program installed in that Windows-10 operating system.  And all of this computer software is installed on an internal hard-disk drive of my 64-bit notebook computer.)  And gratefully I did not have to do anything to or within the installed software packages

kernel-default 6.4.0-150600.23.7.3.x86_64,
virtualbox-kmp-default 7.0.18_k6.4.0_150600.21-lp156.1.4, or
virtualbox-guest-tools 7.0.18-lp156.1.6

or to Oracle VM VirtualBox 7.0.18 r162988 (Qt5.15.2)

or to any of their source codes to make that pointer arrow so-remain visible.

Really I worked toward making the pointer arrow become and remain visible over the LXDE window and, at least from my perspective, to improve on some matters in the Leap-15.6 login screen which I reported in my https://bugzilla.opensuse.org/, so-called “bug” report numbered 1227354.  There is some question of which one of the following operations which I performed on July 11, 2024 made the pointer arrow remain visible over the LXDE window.   So I discuss all of them here.   And I have all but the last one of the following paragraphs in this “bugzilla” posting numbered 1226910 in my “bugzilla” posting numbered 1227354.

There was a problem of an occasionally invisible pointer arrow reported in posting number 1 in the “thread” of postings on https://forums.opensuse.org/t/opensuse-12-1-1-gaps-between-panel-icons-in-lxde-2-invisible-pointer-arrow-when-choosing-desktop/74522/6 on the Internet.  Based on that report I decided to consider some settings within the LXDE of my Leap-15.6 installation.

My action 1: Among them via a software “button” on the left side of my widget panel or taskbar, similar to the “Start button” in a Windows operating system, then “System, Desktop Session Settings” on the “Automatically Started Applications” tab I clicked on the empty check box on the left side of “GNOME XSettings” to have a check mark placed in that previously empty check box and then clicked on an “OK” software “button”.  (GNOME stands for GNU’s Not Unix [GNU] Object Model Environment.)  Then, following the instructions on https://www.reddit.com/r/xfce/comments/6p8edb/mouse_cursorpointer_becomes_invisible_after_login/?rdt=62326 to attempt to make the pointer become visible,

My action 2: as a so-called “root” user I entered the command

gsettings set org.gnome.settings-daemon.plugins.cursor active false

and afterward received a “response” including

“No such schema ‘org.gnome.settings-daemon.plugins.cursor’”.

So “My action 2”, aside from possibly automatic writing in a log file, probably did not change anything else in my Leap-15.6 computer software.

From the Internet I learned that a so-called “display manager” is or makes the login screen in at least some Linux operating systems.  From the following command I could learn that the display manager running in my Leap-15.6 installation was the “X Display Manager”:

systemctl status display-manager
.
Given the unusual visual phenomena in my Leap-15.6 login screen which I reported in my “bugzilla” report numbered 1227354 and perhaps my switch to “GNOME XSettings”, it made sense for me to try a GNOME-desktop-environment-related display manager as a Leap-15.6-replacing login screen.

My action 3: So I chose the GNOME Display Manager, or gdm, and installed it in my Leap-15.6 installation via, as a “root” user, the following two commands

zypper refresh
zypper in gdm (or else “zypper install gdm”)
,
in which “in” in the above command is I think short for the word “install”.

My agreement to that installation resulted in 69 software packages being installed in my Leap-15.6 installation.

My action 4: Next, according to the instructions on https://en.opensuse.org/SDB:Change_Display_Manager, I made gdm my Leap-15.6 display manager via the commands

update-alternatives –set default-displaymanager /usr/lib/X11/displaymanagers/gdm

and afterward “rebooted” toward the LXDE of Leap 15.6.

Along the way toward the LXDE I needed to become acquainted with what to do on my new, Leap-15.6 login screen.  It gratefully looked good and more like I have been accustomed to login screens appearing concerning texts and a light-colored, almost rectangularly shaped edit control into which black or dark-colored discs would be entered corresponding to the characters entered via a computer keyboard for a password.  I first clicked on my Leap-15.6 user name.  That made the edit control for the password appear.  At first I thought that I had only the LXDE option for the type of desktop session into which I could enter.  But eventually at this stage of the login process near the lower-right-hand corner of that login screen I noticed a small icon appearing like a gear.  I clicked on it and saw a list of choices for the desktop session which included the Plasma (X11), LXDE, and some other choices plus one new choice for me of “GNOME on Xorg”.  With LXDE selected in the list of desktop-session options there, as indicated by a white disc on its left side, I could enter my Leap-15.6, regular-user password, probably briefly press down on computer keyboard’s “Enter” key, and then see an entry into the LXDE.  Gratefully there I finally I saw that the pointer did not disappear, but remained in view even after all of the LXDE desktop shortcut icons were displayed!  The cause for the appearance and remaining of the pointer arrow over the LXDE window would have been among my above actions 1, 3, and 4.  And the causes for the change of the display manager, or login screen, which I have begun to use, were my above actions 3 and 4.

I do not think I had to make these kinds of changes, which have all been external to openSUSE, kernel-default- and virtualbox-...-related source codes, after my year-2022 and year-2023 upgrades of openSUSE Leap.  Therefore its seems at least possible that such source codes could be prepared so that such changes external to such source codes would not have to be made.  But, writing figuratively and as one saying goes, it seems possible that there could be “more than one way to skin a cat.”

The “trio” of messages, including the strong one of “unsupported hypervisor” of VirtualBox 7.0.18, that I reported in my “bugzilla” report numbered 1227357 also appeared after performing my above actions 1-4, still using VirtualBox 7.0.18.  But so far, despite the look of severity of the message “unsupported hypervisor,” gratefully that message does not seem to be of any consequence in the LXDE of my Leap-15.6 installation

with version 6.4.0-150600.23.7.3.x86_64 of kernel default running,

the Graphics Controller of VirtualBox 7.0.18 set to VMSVGA (Virtual “Machine” Super Video Graphics Array), and

with my relying on the VirtualBox Guest Additions which I assume are included by openSUSE in that version of kernel-default and depending well on the installed software packages virtualbox-kmp-default 7.0.18_k6.4.0_150600.21-lp156.1.4 and virtualbox-guest-tools 7.0.18-lp156.1.6!

The desktop of my Plasma (X11) desktop session presently does not look good, in my opinion, with widget or taskbar icons on an otherwise missing widget bar or taskbar and some desktop shortcuts labeled with black- instead of white-colored labels.  And after clicking on the iguana-looking software “button” located on the lower-left-hand side of the Leap-15.6 window, which is equivalent to a Windows operating system’s “Start button,” the texts which subsequently appeared there were all in black-colored text.  But 1) I guess that otherwise the functions of applications or computer programs in a Plasma (X11) desktop session of my Leap-15.6 installation might work well.  And 2) I do not expect to be using the Plasma (X11) desktop session much of the time; instead in openSUSE Leap installations I have mainly been using the LXDE desktop session.  And 3) the pointer arrow has I think always been visible in Plasma (X11) desktop sessions of my Leap-15.6 installations after my two upgrades to them from my Leap-15.5 installation.

Sorry, I omitted a hyphen (-) in my above, July 11, 2024 posting; that is I should have written "kernel default" as instead "kernel-default".

Corrections concerning especially colors: On my GNU’s Not Unix (GNU) Display Manager (gdm) login screen, leading to my choice of the type of desktop session, the white-colored discs corresponding to the characters in my Leap-15.6, regular-user password are entered into a nearly rectangularly shaped edit control with a blue-colored border and a gray-colored interior.  Before entering my password’s characters via presses of the keys on my computer’s keyboard, the word “Password” could be seen inside that nearly rectangularly shaped edit control.