You’re making some bad assumptions (particularly about the importance of keeping systems up to date).
But the “wall of text” approach makes it very difficult to identify what your actual issues are.
Please try to provide only the relevant technical information and a clear problem statement so people can try to help you with your issue(s). If more information is needed, we’ll ask, but it is somewhat unclear to me what even your issue is.
Give us the ‘short version’. 
Has this forum policies against AI generated posts?
Read the forum FAQ regarding AI generated content.
A relatively short, so-called bugzilla “bug” report has been filed which concerns the main remaining issue in this posting: ‘Bug 1263982’ entitled ‘“Devices, Upgrade Guest Additions…” failed in Leap-16.0 “guest” in VirtualBox 7.2.8 ’. It is located on https://bugzilla.opensuse.org/show_bug.cgi?id=1263982 on the Internet.
I noticed from my hand-produced notes that, at least for a while, in version 15.6 of Leap I had the successful operation of VirtualBox Guest Additions (VBGA) with the software package virtualbox-guest-tools installed. So I decided to try to produce well-working VBGA in my Leap-16.0 “guest” installation with kernel-default 6.12.0-160000.28.1 running in it, virtualbox-guest-tools 7.2.6-lp160.1.1, virtualbox-kmp-default 7.2.6_k6.12.0_160000.28-lp160.1.1 installed in it, and all of that in VirtualBox 7.2.8. But in those circumstances I still had a failure via “Devices, Upgrade Guest Additions…” in attempting to produce VBGA. So I uninstalled virtualbox-guest-tools from my Leap-16.0 installation. One might think that installing a software package and then uninstalling that software package would return the computer software to its original working state. But that was not the case in this instance for me!–Between my Windows-11, “guest” operating system and my Leap-16.0 “guest” installation I lost the functions of the copying and “pasting” of text and the sharing of folders in a folder shared by those two operating systems! It took me quite a while to learn what to do and to recover those functions of well-working VBGA. For a while I had VirtualBox 7.2.6 installed and kernel-default 6.12.0-160000.28.1 running and after, as a “root” user, entering the command
/sbin/rcvboxadd quicksetup all
, saw the message reading as
“Building the Guest Additions 7.2.8 modules for kernel 5.14.21-150500.55.65-default”.–Those reported circumstances made quite a mismatch with my real circumstances at that time! The gratefully successful procedure for me to get back to well-working VBGA included, as a “root” user, my entering the command
/opt/VBoxGuestAdditions-7.2.8/uninstall.sh
. (I think that some people might call my situation “having ‘broken’ VBGA”, with that “breaking” apparently somehow caused by my installing virtualbox-guest-tools and later uninstalling it.). Afterward I could, in a step-by-step manner, work my way back to having working VBGA in VirtualBox 7.2.6 and finally later in VirtualBox 7.2.8.
Sorry, I had some earlier mistaken thinking and writing, especially in my paragraph which began with ‘On https://www.virtualbox.org/wiki/Changelog-7.2 I found a so-called “Changelog” …’ That is the announcement in a “Changelog” by Oracle Corporation people of support in a version of VirtualBox for a particular group of Linux kernels is insufficient to allow one to think that all of the Linux kernels within that range of Linus kernels issued by openSUSE would be supported by that version of VirtualBox.–Instead there should be a more specific announcement there for support of openSUSE or OpenSUSE Leap- kernels. That has been Oracle Corporation’s convention for announcing support for openSUSE or OpenSUSE beginning with Leap 15.4, as far I could determine. And, as you can see in the table below, there has been a lag in time between the issuance of a new version of openSUSE and Oracle Corporation’s announcement of support for the kernels in that version of openSUSE in a later-issued version of VirtualBox.
| Column 1 | Column 2 | Column 3 | Column 4 | E |
|---|---|---|---|---|
| Leap version | Leap release date* | First reported VirtualBox version supporting the Leap version of column one’s kernels** | Release date of the VirtualBox version in column 3 | Time lag in days, (column 4 minus column 2) in days |
| 15.4 | June 8, 2022 | 7.0.4r154605 | November 18, 2022 | 163 days |
| 15.5 | June 7, 2023 | 7.0.12r159484 | October 17, 2023 | 132 days |
| 15.6 | June 12, 2024 | 7.0.20r163906 | July 16, 2024 | 34 days |
| 16.0 | October 1, 2025 | None, as of May 3, 2026 | As of May 3, 2026, no past release date | >214 days |
*The release dates for versions 15.5 and 15.6 of openSUSE Leap are given under the heading Leap 15.x Series and, for Leap 16.0, under the heading Leap 16.x Series, all on https://en.wikipedia.org/wiki/OpenSUSE. One way I found the release date for Leap 15.4 was by reading some of the WorldWide Web page with the Uniform Resource Locator (URL) https://www.phoronix.com/news/openSUSE-Leap-15.4.
**For the release date for a version 4.0 through 7.2 of VirtualBox click on a hyperlink for the principal number of that version, for example, 7.0, in a list of those principal version numbers on https://www.virtualbox.org/wiki/Changelog-7.2.
In fact, as shown the above table, a version of VirtualBox supporting the openSUSE, Leap-16.0 kernels has yet to be announced by Oracle Corporations in one of its “Changelogs” for a future version of VirtualBox.
Now I present some history plus some reasoning of my own toward at least partly understanding the matter of the support for openSUSE-Leap, Linux kernels in some versions of VirtualBox. I assume that Oracle Corporation obtains a version of a Linux kernel from somewhere on the Internet like among the “Kernel.org git repositories” on https://git.kernel.org/, or, for older Linux kernels, the “The Linux Kernel Archives” on https://www.kernel.org/ or from the Comprehensive TeX Archive Network (CTAN) of https://ctan.org/. There is a hint that Oracle Corporation might have to modify those source kernels to make them work with their VirtualBox codes because Oracle Corporation periodically announces general support in VirtualBox “Changelogs” for a specific version or set of versions of the Linux kernel.
The late Larry Finger wrote to me on June 14, 2021, “Although Leap 15.3 has just been released, its kernel (5.3) is relatively ancient, since 5.13” (probably kernel version 5.13) “will be released in about 2 weeks. The choice of old kernels in Leap is due to the decision to base those versions on what is used in SLE” (SUSE Linux Enterprise).
“In the ‘old’ days, merely checking the kernel version using a couple of macros was sufficient to determine the code to use when the kernel had changed; however, that puts the SUSE and openSUSE developers in a bind. After all, even users that want the stability and maintenance contracts of SLE need to be able to run” SLE “on new hardware. As a result some drivers and other kernel changes need to be borrowed from kernels newer than” kernel-version “5.3, a process called backporting. Oracle” Corporation “releases their code with some changes to handle the backporting found for Ubuntu and Fedora.”
And, slightly earlier on June 8, 2021, the late Larry Finger wrote me, “openSUSE has backported a number of kernel API” (probably standing for Application Programming Interface) “changes into their kernels. In the openSUSE official builds, we patch the Oracle code to handle these cases. In fact, that is the major part of my duties as VirtualBox maintainer” (presumably for openSUSE).
My Mozilla Firefox Web browser’s search “engine’s” “Search Assist” informed me that contracts of companies or else corporations with SLE are based on SLE’s products, including SLE Server (SLES) and SLE Desktop (SLED), rather than on the kernel versions used in those products. Furthermore from “Search Assist,” “This allows for flexibility in kernel updates without affecting the contractual obligations” between SLE and the companies purchasing SLE’s products and/or the services in its products. Nevertheless, based on Larry Finger’s above-quoted writing to me, I suppose that there still might be some backporting of code from newer kernels into the relatively old kernels used in those SLES and SLED software products. And, again from Larry Finger, the openSUSE code is based on the SLE code, presumably including its kernels.
Based on Larry Finger’s above-quoted writing it appears that adaptations could be made in either VirtualBox or openSUSE Leap code so that those codes can “work well together”. Again based both on the above-quoted writing of the late Larry Finger to me and, in the “Changelogs” for individual versions of VirtualBox, the absence of announcements of support for Leap versions 15.2-15.3, I suppose that Larry Finger, instead of Oracle Corporation, was making the adaptations in at least the openSUSE, Leap-15.2 to -15.3 codes to “work” well with some versions of VirtualBox. Then, beginning with Leap 15.4, it appears that Oracle Corporation, instead of Larry Finger, was making the adaptations in its VirtualBox codes for Leap 15.4-15.6 during the years of 2022-2024. In fact, Larry Finger very unfortunately died on June 21, 2024 at 84 years outside his mother’s womb. The cause of his unfortunate death was not directly stated in his obituary on https://www.echovita.com/us/obituaries/mo/smithville/larry-finger-18230101. But that obituary includes the sentence “In lieu of flowers, donations are requested to be made to the American Cancer Society.” Speculation: That sentence gives me an impression that perhaps Larry Finger might have unfortunately suffered with cancer and even died as the result of cancer; and perhaps he and/or his family members might have wanted other people to financially contribute to the American Cancer Society toward research against cancer and/or toward other people’s fights against cancer. Suppose further that Larry Finger, due to suffering with cancer, might have been unable to keep up with his work load of adapting openSUSE code to work with VirtualBox code and that, instead, Oracle Corporation might have kindly begun adapting its VirtualBox code to work with openSUSE code for the Leap versions 15.4-15.6 during the years 2022-2024. Now in the year 2026 there is a question whether Oracle Corporation will continue to adapt its VirtualBox codes to “work” with openSUSE, Leap-16 codes, as it did with openSUSE, Leap-15.4 to -15.6 codes. The successes of each of the following methods for the “building” of VirtualBox Guest Additions likely depends on those codes “working well together:”–“Devices, Upgrade Guest Additions…”, “Devices, Insert Guest Additions CD” (Compact Disc) “image…”, or by mounting Oracle Corporation’s VBoxGuestAdditions.iso file and within its so-opened contents executing the file VBoxLinuxAdditions.run. But if those VirtualBox and Leap-kernel codes are not made to “work well together” in the future, I could instead hopefully rely on the VirtualBox Guest Additions that come with the Linux kernels and/or the software package virtualbox-kmp-default supplied through online, openSUSE, Leap-16.0 repositories. Another method, which has at least sometimes gratefully worked well for me, has been to have VirtualBox Guest Additions “built” via “Devices, Upgrade Guest Additions…” in VirtualBox 7.2.6 and then to upgrade VirtualBox to version 7.2.8. Then perhaps VirtualBox 7.2.8 may have become like an “heir” to the VirtualBox Guest Additions “built” in VirtualBox 7.2.6’s Leap-16.0 installation; or else the VirtualBox Guest Additions included with the relevant Linux kernels and/or the software package virtualbox-kmp-default may have included those VirtualBox Guest Additions and/or the relevant kernel modules to allow for VirtualBox Guest Additions to work well in Leap 16.0 in VirtualBox 7.2.8.
The posting entitled “No precompiled guest kernel modules for Virtualbox in Leap 16” was posted as a so-called “bug”, or a problem in computer software, on May 5, 2025 on https://bugzilla.suse.com/show_bug.cgi?id=1242207 on the Internet. Despite “Leap 16” appearing in that title, the operating system posted near the top of that posting is Leap 16.0. Since May 5, 2025 on April 16, 2026 .ko kernel modules were distributed in the software package virtualbox-kmp-default, version 7.2.6_k6.12.0_160000.28-lp160.1.1 from an openSUSE, online repository for Leap 16.0. Kernel modules were also reported in that same “bug” posting to, in effect, have been produced in “16.1”, which probably meant in a Leap-16.1 operating system, an operating system which, as of May 3, 2026, was yet to be publicly released. So there is a question why the originally posted “bug” in that posting was, by May 3, 2026, not reported as having been fixed or solved. And furthermore it seems to me that that “bug” posting no longer has anything to do with the reason why “Devices, Upgrade Guest Additions…” could not be used to produce VirtualBox Guest Additions in Leap 16.0 with the Linux kernel-default 6.12.0-160000.28.1 running in my Leap-16.0, “guest” operating system in VirtualBox 7.2.8. Rather here I present the case for the cause of that problem likely having been an incompatibility between the computer codes for VirtualBox 7.2.8 and the versions 6.12.0-160000.28.1 and 6.12.0-160000.29.1 of kernel-default and/or virtualbox-kmp-default 7.2.6_k6.12.0_160000.28-lp160.1.1.
It seems that it is not really that Leap 16.0, aside from the kernels used in it, is incompatible with VirtualBox 7.2.8, but rather that at least an early version of kernel-default which has been available from a Leap-16.0, computer-software repository has been incompatible with VirtualBox 7.2.8. (And probably all of kernel-default’s subsequent versions for Leap 16.0 will be incompatible with VirtualBox 7.2.8 regarding “Devices, Upgrade Guest Additions…”, until or unless someone will modify VirtualBox 7.2.8’s or Leap-16.0’s kernel-default’s code to make those two codes “work well together.”) First keep in mind that the Leap-15.6 versions of kernel-default were compatible with VirtualBox 7.0.20-7.2.6, a fact which comes from both Oracle Corporation’s notice of support for the Leap-15.6 Linux kernels in the “Changelog” for VirtualBox 7.0.20 and my experience, at least for kernel-default, using Leap 15.6 in VirtualBox 7.0.20-7.2.6. I could demonstrate the incompatibility between the Leap-16.0 Linux kernel-default 6.12.0-160000.28.1 and VirtualBox 7.2.8 being the cause of the failing of “Device, Upgrade Guest Additions…” in the following separate tests with the same version 6.12.0-160000.28.1 of kernel-default running separately in the VirtualBox versions 7.2.6 and 7.2.8.
| Column 1 | Column 2 |
|---|---|
| VirtualBox version | Success or failure in producing VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…” |
| 7.2.6r172322 | Success on May 4, 2026 |
| 7.2.8r173730 | Failure on May 4, 2026 |
A not-very-surprising result was that there was also a failure for “Devices, Upgrade Guest Additions…” after “booting” Leap 16.0 in VirtualBox 7.2.8 with another Leap-16.0 kernel-default version 6.12.0-160000.29.1. More interesting was the result of the success in “Devices, Upgrade Guest Additions…” after “booting” Leap 16.0 in VirtualBox 7.2.8 with the last Leap-15.6 kernel-default version 6.4.0-15060.23.92.1.–In VirtualBox 7.2.8 the success in “Device, Upgrade Guest Additions…” after “booting” Leap 16.0 with the last version of kernel-default used in Leap 15.6 and the failure in “Device, Upgrade Guest Additions…” after “booting” Leap 16.0 with each one of two of the early versions of kernel-default provided for Leap 16.0 suggest that the VirtualBox-7.2.8 code included the effects of the Leap-15.6 backporting of kernel-default code used in VirtualBox 7.2.6, but did not include the effects of the newer backporting of code in some versions of kernel-default provided for Leap 16.0! That is very consistent with no one yet having made or modified a version of VirtualBox to support the versions of the Linux kernel-default supplied for use in Leap 16.0, or vice versa, no one yet having modified the Linux kernels distributed for Leap 16.0 to “work completely well” with a version of VirtualBox. But again, this is not a catastrophic matter, since the VirtualBox Guest Additions included in the versions of kernel-default and/or virtualbox-kmp-default for Leap 16.0 so far have often provided the functions of having wide windows for Leap 16.0 to use and, between my Windows-11, “host” and Leap-16.0, “guest” operating systems, the copying and “pasting” of text and the sharing of files and folders via a folder those two systems share.
Again, you need to give us the ‘short version’. This stream-of-consciousness writing is not going to get you any help, because it’s difficult to follow and contains many tangents that probably aren’t really relevant to the core issue (whatever that may be).
Start with a clear problem statement. What is your issue? 2-3 sentences at most.
Let those in the community who need more information ask for what they need, rather than just spamming information that is not necessary. Your big issue here is that you’re providing too much information that’s likely not relevant to the issue. Bringing up conversations with a (sadly now deceased) developer from 5 years ago isn’t going to really be relevant to a problem today because things have changed.
Continuing to attempt to bury the community under reams of text isn’t going to be productive.
From my May 4, 2026 posting in this so-called “thread” of postings I want to correct the following sentence of
‘That is very consistent with no one yet having made or modified a version of VirtualBox to support the versions of the Linux kernel-default supplied for use in Leap 16.0, or vice versa, no one yet having modified the Linux kernels distributed for Leap 16.0 to “work completely well” with a version of VirtualBox. ‘
to instead read as
That is very consistent with no one yet having made or modified a version newer than version 7.2.6 of VirtualBox to support the versions of the software package Linux kernel-default supplied for use in Leap 16.0 or, in the opposite direction, no one yet having modified the versions of the software package Linux kernel-default distributed for Leap 16.0 to “work completely well” with a version newer than version 7.2.6 of VirtualBox.
The kmps of Virtualbox 7.2.8. do not build for Leap:
https://build.opensuse.org/package/show/Virtualization/virtualbox
So use, as I do, Virtualbox 7.2.6.
So is your problem statement that you are wondering why 7.2.8 isn’t available on Leap 15.6? If so, then Sauerland’s answer would apply.
It’s not always necessary to have the latest and greatest version of everything in order to have functionality. So unless there’s specific functionality you need in 7.2.8 that isn’t present in 7.2.6, then don’t worry about it.
Otherwise, in 1 or 2 sentences, describe what the functionality is that’s missing that you need.
There are also problems with other linux guest in Virtualbox 7.2.8…
This is a Oracle Problem:
https://forums.virtualbox.org/index.php
The correction I wanted to make to a sentence in the last paragraph of my May 4, 2026 posting in this so-called “thread” of postings needed some context. And sorry, I was missing the word “result” in the first sentence of that last paragraph in my May 4, 2026 writing. So now, to include some context, I include the early part of that last paragraph of my May 4, 2026 writing, along with the previously omitted word “result” in its first sentence, along with the last, corrected sentence in my writing below. The text below should follow the three-row-by-two-column table in the last paragraph of that May 4, 2026 writing of mine.
“A not-very-surprising” result “was that there was also a failure for “Devices, Upgrade Guest Additions…” after “booting” Leap 16.0 in VirtualBox 7.2.8 with another Leap-16.0 kernel-default version 6.12.0-160000.29.1. More interesting was the result of the success in “Devices, Upgrade Guest Additions…” after “booting” Leap 16.0 in VirtualBox 7.2.8 with the last Leap-15.6 kernel-default version 6.4.0-15060.23.92.1.–In VirtualBox 7.2.8 the success in “Device, Upgrade Guest Additions…” after “booting” Leap 16.0 with the last version of kernel-default used in Leap 15.6 and the failure in “Device, Upgrade Guest Additions…” after “booting” Leap 16.0 with each one of two of the early versions of kernel-default provided for Leap 16.0 suggest that the VirtualBox-7.2.8 code included the effects of the Leap-15.6 backporting of kernel-default code used in VirtualBox 7.2.6, but did not include the effects of the newer backporting of code in some versions of kernel-default provided for Leap 16.0!” Regarding just successfully “building” VirtualBox Guest Additions via “Devices, Upgrade Guest Additions…”, that is very consistent with no one yet having made or modified a version newer than version 7.2.6 of VirtualBox to completely support the versions of the software package Linux kernel-default supplied for use in Leap 16.0 or, in the opposite direction, no one yet having modified the versions of the software package Linux kernel-default distributed for Leap 16.0 to “work completely well” with a version newer than version 7.2.6 of VirtualBox.
This is an Virtualbox problem.
Once more:
Goto the virtualbox forum and ask there.
Leap 16.0 guest on a Leap 16.0 host is working as expected, there is not Virtualbox 7.2.8 for Leap (guest or host) at this time build by openSUSE.
So install Virtualbox 7.2.6 on your host.
In response to poster Sauerland’s May 6, 2026 posting the WorldWide Web page with the Universal Resource Locator (URL) https://build.opensuse.org/package/live_build_log/Virtualization/virtualbox:kmp/16.0/x86_64 has some overlap with my situation, particularly the line there reading as
“ 37s] ERROR: modpost: “is_endbr” [/home/abuild/rpmbuild/BUILD/virtualbox-kmp-7.2.8-build/VirtualBox-7.2.8/modules_build_dir/default/vboxdrv/vboxdrv.ko] undefined!”.
In answer to the administrator’s May 6, 2026 question of
“So is your problem statement that you are wondering why 7.2.8 isn’t available on Leap 15.6?”,
my answer is, assuming by “7.2.8” you meant VirtualBox 7.2.8, no, by now I have “pretty-much” abandoned Leap 15.6, having replaced a data backup which included my Leap-15.6 “guest” installation in VirtualBox 7.2.6 with on May 5, 2026 a data backup including my present, Leap-16.0 “guest” installation in VirtualBox 7.2.8. VirtualBox 7.2.8 was released on April 21, 2026 (https://www.virtualbox.org/wiki/Changelog-7.2), the same day on which my basic upgrade from Leap 15.6 to Leap 16.0 was completed. In fact I installed VirtualBox 7.2.8 in my “host”, Windows-11 operating system later on that same day of April 21, 2026. A remaining, yet minor-because-it can-be-avoided problem with my Leap-16.0, “guest” installation in VirtualBox 7.2.8 has been that I could not install VirtualBox Guest Additions by either “Devices, Upgrade Guest Additions…” or “Devices, Insert Guest Additions CD” (Compact Disc) “image…” The so-called bugzilla “bug” report ‘Bug 1263982’ entitled
‘“Devices, Upgrade Guest Additions…” failed in Leap-16.0 “guest” in VirtualBox 7.2.8 .’
first filed on May 4, 2026 on https://bugzilla.opensuse.org/show_bug.cgi?id=1263982, briefly discusses the “Devices, Upgrade Guest Additions…” part of that problem in five sentences, aside from the title of that “bug” posting. I have included here in my May 4, 2026 posting some history of how that problem of “building” VirtualBox Guest Additions in openSUSE, Leap, “guest” installations in VirtualBox has been “tackled” by, on the openSUSE side, the late Larry Finger and later during at least the years 2022-2024, on the Oracle Coproration side, by the Oracle Corporation producer and/or distributor of VirtualBox. And because “Devices, Upgrade Guest Additions…” on May 4, 2026 did not produce VirtualBox Guest Additions for Leap 16.0 as a “guest” operating system for me in VirtualBox 7.2.8, it is clear that, as of May 4, 2026, no one, on either the openSUSE or Oracle Corporation side of the matter, has yet made openSUSE, Leap-16.0 and VirtualBox 7.2.8 compatible in this respect. That turns out to be not a functional problem in Leap 16.0 because VirtualBox Guest Additions apparently come with some combination of the modern Linux kernels, as the late Larry Finger instructed me in probably the year 2021, and/or the software package kernel-kmp-default. And though I prefer to have VirtualBox Guest Additions “built” via “Devices, Upgrade Guest Additions…” or “Devices, Insert Guest Additions CD image…”, in the absence of those working methods in VirtualBox 7.2.8 with some early versions of Leap-16.0 kernel-default, I can rely on either the VirtualBox Guest Additions from those Leap-16.0 versions of kernel-default and/or virtualbox-kmp-default 7.2.6_k6.12.0_160000.28-lp160.1.1 or from the VirtualBox Guest Additions perhaps “inherited” from their production in VirtualBox 7.2.6 with the Leap-16.0 kernel-default 6.12.0-160000.28.1.
Again, as I here in my May 4, 2024 posting quoted from the late Larry Finger’s writing to me in the year 2021, think that the major issue for why in the year 2026 that Leap-16.0 kernels have not yet worked with VirtualBox 7.2.8 with “Devices, Upgrade Guest Additions…” may likely be that not all of the previous backporting of code in SLE computer software has been performed on either the openSUSE or VirtualBox side of the computer codes. Briefly reviewing what Larry Finger wrote me, one reason SLE backported computer code from newer versions of the Linux kernel was to accommodate new hardware in older Linux kernels. We can be assured that backporting is still being used in SLE.–For example, from https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-update-backporting.html, a Web page copyrighted by SUSE in the year 2026, “SUSE extensively uses backports, for example for the migration of current software fixes and features into released SUSE Linux Enterprise packages.” But I struggled in my brain with the following question.–In order to accommodate new computer hardware in its Linux kernels why wouldn’t SLE just use modern kernels in its computer codes instead of backport code from newer kernel versions into older kernel versions? Or in other words why would SLE developers want to avoid changing the version number of the Linux kernel it is using at the time? Today, with the help of Mozilla Firefox’s DuckDuckGo’s search “engine’s” “Search Assist” I may have found a clue to the answer to this question. But first I point out two things concerning my openSUSE Leap “guest” operating systems. 1) The version number of such an updated kernel is different from the version of the kernel running before I accept the installation of the updated kernel. 2) After I agreed to have a kernel update installed in an openSUSE Leap installation, there had to be a “rebooting” of that Leap operating system in order for the updated kernel to become effective and be running in my Leap installation. Without quoting from “Search Assist’s” “answer” to me, I now explain what I read of that “answer” to my question in my own words. SLE has a process called kernel live patching to keep its running kernel. Though that process was explained to me concerning updates to computer security, I assume that such kernel live patching could also be used to deal with new computer hardware on the market. Then, with that assumption, the process of kernel live patching could allow the computer code to deal with hardware relatively new on the market to be implemented without “rebooting” the operating system.–And, based on my experience with openSUSE Leap kernels, avoiding the “rebooting” of the operating system could then mean that the version number of the running kernel would not, and probably could not easily be changed during that running of the Linux kernel.–So then to keep the kernel version the same, but yet to make it function with the new hardware on the market, some computer code for such accommodation would have to transferred or “backported” from a new version of the kernel, which already has that accommodation for the new hardware in it, back to the older and running version of the Linux kernel. And SLE computer software then becomes the basis for openSUSE Leap computer software, as shown by the following statement: “From Leap 15.3 onwards, SUSE also (in addition to the sources) contributes the SUSE Linux Enterprise (SLE) binary packages back to the openSUSE community, where they form the base of openSUSE Leap” (https://www.suse.com/c/closing-the-leap-gap-src/). In this paragraph my main idea concerning one reason why the version number of a Linux kernel may be desired to be kept constant might not match reality. So, if possible, it could be interesting to have a direct communication with an SLE code writer to learn if my thinking here actually matches reality or not, though I, of course, do not promise to have such direct communication.
“Search Assist” gave me two other reasons for the backporting of computer code between a new version of a kernel to an older version of the kernel. Partly rephrased by me, those reasons are 1) to continue to use an otherwise stable and well-tested Linux kernel while adding support for new computer hardware on the market and 2) to allow for returning to the previous, stable Linux kernel if problems in the code result from such backporting of computer code into that stable Linux kernel. Perhaps stability in their computer software is of great importance to SLE employees who want to continue to have money coming into their company or corporation from users who do not have to otherwise complain to SLE due to the failing SLE computer code.