VirtualBox problems with kernel 5.13
_(Sorry for messing up the threading with my first attempt at sending this.)_ --------- First of all, many thanks to Larry Finger for all his hard work. It must be frustrating for him, but I really appreciate all his work at maintaining VirtualBox for openSUSE. Second, I understand the issues with Oracle and their development process and attitude. If you can use something else besides VirtualBox as Larry suggests, then do it. But the problem is that most users still love VirtualBox. As the maintainer of the GeckoLinux spins, I can say from experience that the vast majority of users expect VirtualBox support, so although I hate it myself I basically have to deal with it and make sure it works. It would be nice if issues like this were considered as blocking issues so that new kernels don't appear in Tumbleweed until VirtualBox is known to work with them. Fortunately, Larry's advice of sticking with the 5.12 kernel is an easy solution for now, I'm glad there are no mismatches with the KMP version numbers. Also, many thanks to Ben Holmes for the kernel command line workaround, I'll give that a try on my next reboot.
On 7/14/2021 9:00, S. wrote:
First of all, many thanks to Larry Finger for all his hard work. It must be frustrating for him, but I really appreciate all his work at maintaining VirtualBox for openSUSE.
Indeed.
Second, I understand the issues with Oracle and their development process and attitude. If you can use something else besides VirtualBox as Larry suggests, then do it. But the problem is that most users still love VirtualBox. As the maintainer of the GeckoLinux spins, I can say from experience that the vast majority of users expect VirtualBox support, so although I hate it myself I basically have to deal with it and make sure it works. It would be nice if issues like this were considered as blocking issues so that new kernels don't appear in Tumbleweed until VirtualBox is known to work with them.
I do not support delaying the kernel for everyone just to accommodate Oracle's way of (not) doing things. Users of specific software that frequently breaks with new kernels should configure their system to keep an old kernel or two around, IMO. -- Jason Craig
On 7/14/21 8:23 PM, Jason Craig wrote:
On 7/14/2021 9:00, S. wrote:
First of all, many thanks to Larry Finger for all his hard work. It must be frustrating for him, but I really appreciate all his work at maintaining VirtualBox for openSUSE.
Indeed.
Second, I understand the issues with Oracle and their development process and attitude. If you can use something else besides VirtualBox as Larry suggests, then do it. But the problem is that most users still love VirtualBox. As the maintainer of the GeckoLinux spins, I can say from experience that the vast majority of users expect VirtualBox support, so although I hate it myself I basically have to deal with it and make sure it works. It would be nice if issues like this were considered as blocking issues so that new kernels don't appear in Tumbleweed until VirtualBox is known to work with them.
I do not support delaying the kernel for everyone just to accommodate Oracle's way of (not) doing things. Users of specific software that frequently breaks with new kernels should configure their system to keep an old kernel or two around, IMO.
The good news is that Oracle has created a patch that fixes the problem. It was just over an hour from the time their fix was published until I was building and testing a local version of VB. The fix was pushed to OBS about 2 hours ago. It will take a few days for the fix to propagate through OBS, but when it does, all of you will have full VB capabilities on all kernels. As for me, I can now get back to my regular life. Larry
Am Donnerstag, 15. Juli 2021, 04:54:42 CEST schrieb Larry Finger:
The good news is that Oracle has created a patch that fixes the problem. It was just over an hour from the time their fix was published until I was building and testing a local version of VB.
The fix was pushed to OBS about 2 hours ago. It will take a few days for the fix to propagate through OBS, but when it does, all of you will have full VB capabilities on all kernels.
As for me, I can now get back to my regular life.
Thank you so much for your ongoing effort in VirtualBox. I use it regularly for testing builds and installations, I would be lost without you fixing it on nearly every kernel change! Thank you Axel
Hi Larry I much appreciate the effort you spend in fixing Oracle' s shortcomings / sluggishness!!!! Like others here on the list I can't really change to alternatives. (Read: I don't dare potentially breaking many things that I've tweaked into the config of VB - and I don't even remember all of the little tweaks accumulated over the years :-) ) For others holding back an update due to this issue: The "few days for the fix to propagate through OBS" don't seem over yet -TW 20210716 still suffers from it. So I've resorted to apply the kernel parameter "randomize_kstack_offset=off" which indeed does the trick! br Juergen Am Donnerstag, 15. Juli 2021, 04:54:42 CEST schrieb Larry Finger:
On 7/14/21 8:23 PM, Jason Craig wrote:
On 7/14/2021 9:00, S. wrote:
First of all, many thanks to Larry Finger for all his hard work. It must be frustrating for him, but I really appreciate all his work at maintaining VirtualBox for openSUSE.
Indeed.
Second, I understand the issues with Oracle and their development process and attitude. If you can use something else besides VirtualBox as Larry suggests, then do it. But the problem is that most users still love VirtualBox. As the maintainer of the GeckoLinux spins, I can say from experience that the vast majority of users expect VirtualBox support, so although I hate it myself I basically have to deal with it and make sure it works. It would be nice if issues like this were considered as blocking issues so that new kernels don't appear in Tumbleweed until VirtualBox is known to work with them.
I do not support delaying the kernel for everyone just to accommodate Oracle's way of (not) doing things. Users of specific software that frequently breaks with new kernels should configure their system to keep an old kernel or two around, IMO.
The good news is that Oracle has created a patch that fixes the problem. It was just over an hour from the time their fix was published until I was building and testing a local version of VB.
The fix was pushed to OBS about 2 hours ago. It will take a few days for the fix to propagate through OBS, but when it does, all of you will have full VB capabilities on all kernels.
As for me, I can now get back to my regular life.
Larry
On 7/18/21 4:03 PM, Mailings wrote:
Hi Larry
I much appreciate the effort you spend in fixing Oracle' s shortcomings / sluggishness!!!! Like others here on the list I can't really change to alternatives. (Read: I don't dare potentially breaking many things that I've tweaked into the config of VB - and I don't even remember all of the little tweaks accumulated over the years :-) )
For others holding back an update due to this issue: The "few days for the fix to propagate through OBS" don't seem over yet -TW 20210716 still suffers from it. So I've resorted to apply the kernel parameter "randomize_kstack_offset=off" which indeed does the trick!
It will take a while to propagate, but there are no more review hurdles. Larry
Am Montag, 19. Juli 2021, 00:01:13 CEST schrieb Larry Finger:
On 7/18/21 4:03 PM, Mailings wrote:
Hi Larry
I much appreciate the effort you spend in fixing Oracle' s shortcomings / sluggishness!!!! Like others here on the list I can't really change to alternatives. (Read: I don't dare potentially breaking many things that I've tweaked into the config of VB - and I don't even remember all of the little tweaks accumulated over the years :-) )
For others holding back an update due to this issue: The "few days for the fix to propagate through OBS" don't seem over yet -TW 20210716 still suffers from it. So I've resorted to apply the kernel parameter "randomize_kstack_offset=off" which indeed does the trick!
It will take a while to propagate, but there are no more review hurdles.
Looks like it is in the 20210717 snapshot: ==== virtualbox ==== Subpackages: virtualbox-guest-tools virtualbox-guest-x11 - Add file "fix_random_stack_failure.patch" to fix CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT problem with kernel 5.13 as shown in boo#118105. - Add file "fixes_for_5.14.patch" to fix builds on kernel 5.14. Cheers Axel
Am Montag, 19. Juli 2021, 00:01:13 CEST schrieb Larry Finger:
On 7/18/21 4:03 PM, Mailings wrote:
Hi Larry
I much appreciate the effort you spend in fixing Oracle' s shortcomings / sluggishness!!!! Like others here on the list I can't really change to alternatives. (Read: I don't dare potentially breaking many things that I've tweaked into the config of VB - and I don't even remember all of the little tweaks accumulated over the years :-) )
I comes along nicely, if you need to to supply a home for bitten apples, and still handles hibernation better/nicer that libvirt. I'm hibernating my running VMs before backing them up for consistency reasons, and for libvirt, this was a major undertaking. It boiled down to building libvirt/qemu from Factory for Leap, and still needs some fiddling with reattaching usb devices after hibernation.
For others holding back an update due to this issue: The "few days for the fix to propagate through OBS" don't seem over yet -TW 20210716 still suffers from it. So I've resorted to apply the kernel parameter "randomize_kstack_offset=off" which indeed does the trick!
It will take a while to propagate, but there are no more review hurdles.
Thank you, Larry, for providing the fix. Much appreciated. I hereby confirm, that VB with the randomize stack fix applied is doing fine again with 5.13.2 without any kernel command line dances.. Best, Pete
On 14. 07. 21, 17:00, S. wrote:
and make sure it works. It would be nice if issues like this were considered as blocking issues so that new kernels don't appear in Tumbleweed until VirtualBox is known to work with them.
I will never postpone new kernels due to ignorance of nvidia, oracle, or any other company. It's not like the new kernel is released and they should adapt because they didn't know until then. They know, in most cases, as soon as -rc1 is released which gives them 6-8 weeks (!) to adapt. And still they repeatedly fail to. I saw evidence Larry and others let them know quite early in the development cycle w/o any feedback until the final release. So IMO there is no point to wait any longer, as users wouldn't complain to them and they wouldn't be pushed to release a fix earlier anyway. What we could do, is to add a support to libzypp for something like major-1 to be also specified in multiversion.kernels (/etc/zypp/zypp.conf). So that it keeps also 5.12.latest when 5.13.any is installed for example. We currently support only generic "latest" and "oldest", neither usable in this very context, IMO. thanks, -- js suse labs
Jiri Slaby wrote:
What we could do, is to add a support to libzypp for something like major-1 to be also specified in multiversion.kernels (/etc/zypp/zypp.conf). So that it keeps also 5.12.latest when 5.13.any is installed for example. We currently support only generic "latest" and "oldest", neither usable in this very context, IMO.
Interesting idea, thanks for thinking of alternate solutions. I've always configured my system to keep multiple kernel versions, but I wasn't aware that it also was keeping multiple versions of the virtualbox-kmp-default module too, so that makes it considerably safer. I mistakenly assumed that even if I had an old kernel version installed that there would only be the latest version of virtualbox-kmp-default.
On Thu, 15 Jul 2021 14:19:21 +0200, S. B. wrote:
Jiri Slaby wrote:
What we could do, is to add a support to libzypp for something like major-1 to be also specified in multiversion.kernels (/etc/zypp/zypp.conf). So that it keeps also 5.12.latest when 5.13.any is installed for example. We currently support only generic "latest" and "oldest", neither usable in this very context, IMO.
Interesting idea, thanks for thinking of alternate solutions.
I've always configured my system to keep multiple kernel versions, but I wasn't aware that it also was keeping multiple versions of the virtualbox-kmp-default module too, so that makes it considerably safer. I mistakenly assumed that even if I had an old kernel version installed that there would only be the latest version of virtualbox-kmp-default.
Your reply spotted another potential problem, actually; Jiri's idea with "major-1" won't work for KMPs because those version numbers are $PKGVER_k$KENELVER... Takashi
On 15. 07. 21, 15:06, Takashi Iwai wrote:
Your reply spotted another potential problem, actually; Jiri's idea with "major-1" won't work for KMPs because those version numbers are $PKGVER_k$KENELVER...
But kmps are not removed by purge-kernel. Only kernels are. And kmps are removed because their kernel-version is going. So if we keep major-1 kernel, its KMP will stay too as their "Requires" are staying... Or am I missing something? thanks, -- js suse labs
On Mon, 19 Jul 2021 12:51:35 +0200, Jiri Slaby wrote:
On 15. 07. 21, 15:06, Takashi Iwai wrote:
Your reply spotted another potential problem, actually; Jiri's idea with "major-1" won't work for KMPs because those version numbers are $PKGVER_k$KENELVER...
But kmps are not removed by purge-kernel. Only kernels are. And kmps are removed because their kernel-version is going. So if we keep major-1 kernel, its KMP will stay too as their "Requires" are staying...
Hrm, I thought that KMPs (at least on TW) are also multi-versioned with Provides: multiversion(kernel) and get purged similarly. But I might be wrong, need verification of the actual behavior. Takashi
participants (9)
-
Axel Braun -
Hans-Peter Jansen -
Jason Craig -
Jiri Slaby -
Larry Finger -
Mailings -
S. -
S. B.
-
Takashi Iwai