Hello
Why every kernel update will break virtualbox?
Before you could at least to a vboxconfig and kernel modules was compiled
but now there is always the error
Qt FATAL: FATAL: The application binary appears to be running setuid, this is a security hole.
Aborted
and you must deinstall and install again virtualbox to solve 
Is there no other solution???
I have not had this issue - what VirtualBox do you have - this is my install
zypper se -si virtualbox
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------------+---------+-------------------------------------+--------+--------------------------
i+ | virtualbox | package | 6.1.14-lp152.2.5.1 | x86_64 | openSUSE-Leap-15.2-Update
i+ | virtualbox-kmp-default | package | 6.1.14_k5.3.18_lp152.41-lp152.2.5.1 | x86_64 | openSUSE-Leap-15.2-Update
i+ | virtualbox-qt | package | 6.1.14-lp152.2.5.1 | x86_64 | openSUSE-Leap-15.2-Update
zypper se -si kernel
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+-----------------------+---------+----------------------+--------+--------------------------
i+ | kernel-default | package | 5.3.18-lp152.50.1 | x86_64 | openSUSE-Leap-15.2-Update
i+ | kernel-default | package | 5.3.18-lp152.47.2 | x86_64 | openSUSE-Leap-15.2-Update
i+ | kernel-firmware | package | 20200107-lp152.2.3.1 | noarch | openSUSE-Leap-15.2-Update
i+ | kernel-macros | package | 5.3.18-lp152.50.1 | noarch | openSUSE-Leap-15.2-Update
i | purge-kernels-service | package | 0-lp152.4.1 | noarch | openSUSE-Leap-15.2-Oss
When you describe what Virtualbox you have,
You have to describe where it’s from (You have a choice to download and install from the Oracle website or from openSUSE repos)
And you may need to describe what version of Virtualbox you’re running.
If you are running a current version of Virtualbox, you shouldn’t have the problem you’re describing… If installed from the Oracle website, your install should have included dkms and if you installed from openSUSE, your updates should always install pre-built kernel modules that match the kernel from that repo.
So, I suspect you may be running an old version of Virtualbox, likely downloaded from the Oracle website…
TSU
It’s not that, Oracle’s VirtualBox is breaking when the Linux Kernel is updated – it’s the simple fact that, Oracle’s VirtualBox dives quite deep into the Kernel and therefore, one has to be careful and, ensure that, the Oracle VirtualBox version is compatible with the Kernel version being used …
[HR][/HR]Bottom line:
[HR][/HR]Which Linux Kernel are you using with the installed openSUSE Leap distribution?
Where did you pick up the installed Oracle VirtualBox packages?
How are you installing the Linux Kernel patches?
?
What are the details?
What exactly, and in what part of “the kernel?”
It’s pretty clear that Virltualbox alters nothing that is in the initrd (Is am impossibility) and any kernel mode functionality is implemented in kernel modules.
A kernel update normally affects what is in the initrd and possibly patches the kernel modules, and if installed DKMS normally patches the kernel modules to attach to the new kernel when an update happens so that the kernel module doesn’t have to be re-compiled completely (openSUSE chooses to compile for the User as a convenience, not a necessity).
AFAIK Virtualbox like most virtualization stays within the specified areas set out by the kernel and doesn’t stray from those areas.
TSU
Hi
Then why is a pig to build at times, why did the openSUSE Virtualbox maintainer want to dump it, why does it need so much patching to build on openSUSE?
If you’re referring to the recent issues related to 6.14(?)
You’re talking about a very exceptional time when Virtualbox rebuilt itself from the ground up and is not typical of normal times.
And, it wasn’t just Virtualbox, if you remember KVM and Xen also had their issues as the kernel decided at approximately the same time to close a few nasty security holes.
The kernel project has its peculiar perspectives sometimes… It does what it wants or thinks should be done and not necessarily with close co-operation with vendors. Everyone else has to catch up and figure out how to make what they do work with the kernel, not the other way around.
It was a perfect storm of changes in both the kernel and the Virtualbox app itself, and can’t be blamed on some kind of Virtualbox on its own making changes in the kernel (Repeating, no Virtualbox install can do that, AFAIK it’s an architectural impossibility and if you watch an installation there’s no indication of anything like that).
TSU
Hi
But with open source, a fix is always in the making… 5 days for a fix to appear for IOMMU on Tumbleweed, the first glitch I’ve had with qemu…
Bottom line, it gives the end user a bad taste, but that’s always an issue with third party products…
But what the kernel did in this case was different.
I forgot who our VBox maintainer was, but because he packages VBox for openSUSE, he saw the kernel problem probably before anyone else… as much as a month before the kernel’s official release.
But, for whatever reason… I suspect that VBox didn’t have the community expertise to deal with kernel API issues… nothing was done for that month. Remember that VBox is a tiny little fish compared to the resources of all the other major virtualization technologies. Every other virtualization technology has a major patron with enormous finances and talent. Virtualbox is a step child or Oracle who cares very little for how Virtualbox does or doesn’t. Everything Virtualbox accomplishes is a credit to its community. But, in this case, the extra time VBox had been given was frittered away as nothing was done.
When the kernel was officially released, it took all the virtualization technologies by surprise. IIRC it took about 3 weeks(certainly not a single week) for KVM to resolve, and only after that the other virtualization technologies seemed to have a template solution to work off of. But, it still took took VMware more than a month more to come up with their solution and Virtualbox a while after that.
This was a multi-month pause when every virtualization technology was put on hold and couldn’t install on the current kernel of the time. Virtualbox wasn’t alone, and if there was any blame put on the openSUSE build, it wouldn’t have been right to do so. This was an upstream problem where a lot of smart people still took a long time to come up with answers.
TSU