LinuxQuestions.org - VirtualBox on Kernel 5.4.x

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - VirtualBox on Kernel 5.4.x (https://www.linuxquestions.org/questions/slackware-14/virtualbox-on-kernel-5-4-x-4175665409/)

VirtualBox on Kernel 5.4.x

Hi,

Virtualbox 6.0.14 kernel modules did not compile against the latest 5.4.x kernel in slackware-current. The attached patch worked for me.

There are multiple copies of cdefs.h and the-linux-kernel.h, os if your copies aren't hard linked, you may have to copy the patched file over the other copies.

More details can be found here:

https://www.virtualbox.org/ticket/18...=0&cnum_hist=2

I note there are other builds on the VB site that that fix this, too.

Cheers,

===Rich

Code:

diff -ur vboxhost.old/vboxdrv/include/iprt/cdefs.h vboxhost/vboxdrv/include/iprt/cdefs.h

--- vboxhost.old/vboxdrv/include/iprt/cdefs.h        2019-02-02 12:26:56.000000000 +0000

+++ vboxhost/vboxdrv/include/iprt/cdefs.h        2019-12-02 23:07:00.385091894 +0000

@@ -1166,7 +1166,7 @@

  * Tell the compiler that we're falling through to the next case in a switch.

  * @sa RT_FALL_THRU  */

 #if RT_GNUC_PREREQ(7, 0)

-# define RT_FALL_THROUGH()      __attribute__((fallthrough))

+# define RT_FALL_THROUGH()      __attribute__((__fallthrough__))

 #else

 # define RT_FALL_THROUGH()      (void)0

 #endif



diff -ur vboxhost.old/vboxdrv/r0drv/linux/the-linux-kernel.h vboxhost/vboxdrv/r0drv/linux/the-linux-kernel.h

--- vboxhost.old/vboxdrv/r0drv/linux/the-linux-kernel.h        2019-09-11 10:59:56.000000000 +0100

+++ vboxhost/vboxdrv/r0drv/linux/the-linux-kernel.h        2019-12-02 23:34:24.912085621 +0000

@@ -336,7 +336,11 @@

 # endif

 #endif

 

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)

+/* XXX The 5.4 kernel has no interface anymore to make kernel pages execcutable */

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)                                

+# define MY_SET_PAGES_EXEC(pPages, cPages)  do {} while (0) 

+# define MY_SET_PAGES_NOEXEC(pPages, cPages) do {} while (0)    

+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)

 # define MY_SET_PAGES_EXEC(pPages, cPages)    set_pages_x(pPages, cPages)

 # define MY_SET_PAGES_NOEXEC(pPages, cPages)  set_pages_nx(pPages, cPages)

 #else



diff -ur vboxhost.old/vboxdrv/r0drv/linux/thread2-r0drv-linux.c vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c

--- vboxhost.old/vboxdrv/r0drv/linux/thread2-r0drv-linux.c        2019-01-23 11:39:29.000000000 +0000

+++ vboxhost/vboxdrv/r0drv/linux/thread2-r0drv-linux.c        2019-12-02 23:35:58.608085263 +0000

@@ -36,6 +36,9 @@

 #include <iprt/errcore.h>

 #include "internal/thread.h"

 

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)

+    #include <uapi/linux/sched/types.h>

+#endif

 

 RTDECL(RTTHREAD) RTThreadSelf(void)

 {



diff -ur vboxhost.old/vboxnetflt/linux/VBoxNetFlt-linux.c vboxhost/vboxnetflt/linux/VBoxNetFlt-linux.c

--- vboxhost.old/vboxnetflt/linux/VBoxNetFlt-linux.c        2019-09-12 13:21:27.000000000 +0100

+++ vboxhost/vboxnetflt/linux/VBoxNetFlt-linux.c        2019-12-02 23:31:34.265086272 +0000

@@ -924,8 +924,13 @@

    for (i = 0; i < skb_shinfo(pBuf)->nr_frags; i++)

    {

        skb_frag_t *pFrag = &skb_shinfo(pBuf)->frags[i];

+# if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)

+        pSG->aSegs[iSeg].cb = pFrag->bv_len;

+        pSG->aSegs[iSeg].pv = VBOX_SKB_KMAP_FRAG(pFrag) + pFrag->bv_offset;

+# else /* < KERNEL_VERSION(5, 4, 0) */

        pSG->aSegs[iSeg].cb = pFrag->size;

        pSG->aSegs[iSeg].pv = VBOX_SKB_KMAP_FRAG(pFrag) + pFrag->page_offset;

+# endif /* >= KERNEL_VERSION(5, 4, 0) */

        Log6((" %p", pSG->aSegs[iSeg].pv));

        pSG->aSegs[iSeg++].Phys = NIL_RTHCPHYS;

        Assert(iSeg <= pSG->cSegsAlloc);

@@ -940,8 +945,14 @@

        for (i = 0; i < skb_shinfo(pFragBuf)->nr_frags; i++)

        {

            skb_frag_t *pFrag = &skb_shinfo(pFragBuf)->frags[i];

+# if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)

+            pSG->aSegs[iSeg].cb = pFrag->bv_len;

+            pSG->aSegs[iSeg].pv = VBOX_SKB_KMAP_FRAG(pFrag) + pFrag->bv_offset;

+# else /* < KERNEL_VERSION(5, 4, 0) */

+

            pSG->aSegs[iSeg].cb = pFrag->size;

            pSG->aSegs[iSeg].pv = VBOX_SKB_KMAP_FRAG(pFrag) + pFrag->page_offset;

+# endif /* >= KERNEL_VERSION(5, 4, 0) */

            Log6((" %p", pSG->aSegs[iSeg].pv));

            pSG->aSegs[iSeg++].Phys = NIL_RTHCPHYS;

            Assert(iSeg <= pSG->cSegsAlloc);

Kudos to you @rahrah! For pointing out the upstream discussion, for the patch which have worked great and for bringing my dev env back on duty.

Others have pointed that VirtualBox 6.0.15 testbuild also worked with kernel 5.4.1. But to install a testbuild one need to uninstall the stable one then install the testbuild. Once the stable build is released from the testbuild, then the testbuild should also be uninstalled so the stable can be installed again. Too much hassle...

The patch you suggest does the job for VirtualBox 6.0.14 with no testbuild involved, which is a much more elegant solution IMHO.

For future reference, to apply the patch, copy de contents of the OP, save to "/opt/VirtualBox/src/vboxhost/kernel541.patch" then run:

Code:

# cd /opt/VirtualBox/src/vboxhost

# patch -p1 <kernel541.patch

# vboxconfig

Then you're done. Just open VirtualBox and run your VMs as usual.

Pleased it worked out for you!

===Rich

https://www.linuxquestions.org/questions/slackware-14/virtualbox-on-kernel-5-4-x-4175665409

Thanks a lot, Rahrah!
The patch works fine with vbox 6.0.14 and kernel 5.4.1

@denydias

Quote:

Others have pointed that VirtualBox 6.0.15 testbuild also worked with kernel 5.4.1. But to install a testbuild one need to uninstall the stable one then install the testbuild. Once the stable build is released from the testbuild, then the testbuild should also be uninstalled so the stable can be installed again. Too much hassle...

Nope,
just install 6.0.15 over 6.0.14. No need to uninstall first old (stable) and install next a new version (testbuild) and then when it come repead uninstall/install with new stable version.

The above patch appears to be written for the host.

I think I've got this problem on a guest.

Is their a patch readily available for the guest or do I need to hack the patch?

Alex

I decided to download https://www.virtualbox.org/download/....15-135274.iso

uninstalled 6.0.14
rebooted for good measure
Mounted the 6.0.15 iso
ran VBoxLinuxAdditions.run
rebooted for good measure

Problem fixed. Will try and remember to uninstall/install 6.0.15 when it comes out of test.

Quote:

Originally Posted by Aeterna (Post 6064965)

Nope,
just install 6.0.15 over 6.0.14. No need to uninstall first old (stable) and install next a new version (testbuild) and then when it come repead uninstall/install with new stable version.

That's not what testbuild documentation says. Quoting:

Installing Linux test builds
Test builds for Linux hosts are generally packed up in a shell script installer with the extension ".run". To install them, you first need to remove your existing VirtualBox installation (but not your virtual machines - they will continue to work with the test build) and then execute the installer. To remove the test build again, execute the installer with the parameter "uninstall" on the command line.

Edit: btw, I tried to install 6.0.15 testcase on top of 6.0.14 stable without uninstalling it first. It doesn't worked for me tough.

Quote:

Originally Posted by denydias (Post 6065136)

You are correct. Sorry. However, I only followed uninstall/install/uninstall/install routine only for RC but I never had any issues with client VM when just updating installation to test or upgrading test to official installation

I followed the uninstall/install route. It eventually worked for me.

On two guests the uninstall took about 20 minutes to run. When finished it appeared to have removed a lot more than what I was expecting. I got ktown installed on these failing VirtualBox hosts. I'd lost the following -

in init 4 the ability to type in a password on the plasma login dialog
in init 4 the ability to move the mouse on the plasma login dialog
in init 3 eth0 was missing
in init 3 couldn't mount a previously downloaded VBoxGuestAdditions.iso got error "can't open blockdev"
in init 3 couldn't start udev because of missing modules

A sorry mess.

At this stage I thought I should try to reinstall the kernel packages by running

Code:

slackpkg reinstall kernel*

the packages to install were still in the cache. This was successful.

Rebooted and all the above problems went away, though when I booted to init 4 just got a black screen.

Booted to init 3 which now allowed me to

mount the testcase VBoxGuestAdditions.iso for 6.0.15
run VBoxLinuxAdditions.run

Rebooted to init 4 everything now in working order.

Quote:

Originally Posted by aikempshall (Post 6065234)

in init 4 the ability to type in a password on the plasma login dialog
in init 4 the ability to move the mouse on the plasma login dialog
in init 3 eth0 was missing
in init 3 couldn't mount a previously downloaded VBoxGuestAdditions.iso got error "can't open blockdev"
in init 3 couldn't start udev because of missing modules

A sorry mess.

At this stage I thought I should try to reinstall the kernel packages by running

Code:

slackpkg reinstall kernel*

mount the testcase VBoxGuestAdditions.iso for 6.0.15
run VBoxLinuxAdditions.run

Rebooted to init 4 everything now in working order.

Interesting. This is what I did.
attached VBoxGuestAdditions_6.0.15-134636.iso through VM host to all VM clients (3xlinux, and Windows 8.1, BSDs either do not support VB or require different setup for the upgrade)
start VM client
mount iso
from iso run
sudo sh VBoxLinuxAdditions.run

Installer automatically removed previous version of VBoxGuestAdditions and installed new (6.0.15) version.
reboot

That is all, took 5 min without any issues.
I run VM on a 5yrs old laptop and VM host is Slackware-current, though I doubt that distro matters.

I don't know why @aikempshall have so much trouble or why @denydias could not update VM host without uninstalling previous version first (this actually seems fishy).

Unless you are running VM installation from sbo, I don't see why you would have so much problems.

Quote:

Originally Posted by Aeterna (Post 6065384)

I don't know why @aikempshall have so much trouble or why @denydias could not update VM host without uninstalling previous version first (this actually seems fishy).

What looks fishy to me is someone finding fishy other people statements about their very own experience.

Maybe, and just maybe, VirtualBox 6.0.15 is a testbuild at this moment because the varying results it produces. Also maybe, and just maybe, the definition of testbuild is something that works for you in a different way that works for others.

Quote:

Originally Posted by Aeterna (Post 6065384)

For me it could have been because of one or more of these -

which kernel is in use generic, huge or some other. On one of my guests I had huge and on the others I had generic.
which VBoxGuestAdditions was being upgraded. Not gone back to look, but I seem to remember I might have had 6.0.1 on some guests and 6.0.14 on others

Agreed should be a short task and complete without issue. In Slackware we seem to be ahead of the crowd here - no complaints.

The post I'm sure will help people. I'd never heard of testcase VBoxGuestAdditions builds before. Certainly helped me.

Don't know how many minutes it took me on the final guest, it wasn't long.

virtualbox on kernel 5.4.xx

Quote:

Originally Posted by denydias (Post 6064753)

Code:

# cd /opt/VirtualBox/src/vboxhost

# patch -p1 <kernel541.patch

# vboxconfig

Then you're done. Just open VirtualBox and run your VMs as usual.

Thank you both, rahrah and denydias: with your patch and instructions, now VirtualBox 6.0.14 play very very well for me.

Just thought I'd throw this in. I running VirtualBox Version 6.1.0 r135406 with kernel 5.4.3 no issues. This is on a Slackware64-current host and using a clean Slackware64-current guest. I previously had testing 6.0.15-135299 installed.

For as long as I have been using it, installing VirtualBox from the .run file "for all distributions" first removes the old installation from /opt/VirtualBox and that has not changed. Moreover, it unconditionally uninstalls it, whether upgrading or downgrading, it runs the uninstaller.

What the advice is probably trying to cover is VirtualBox installed from another source. You wouldn't want to have, say, a clever distro package (or their rpms or debs) installed then use their .run file to install the official binaries to /opt.

If you have shares to access them easily don't forget to

sudo adduser <username> vboxsf

If it fails the guest additions are not in place do

shutdown -r 0

If adduser works also do a shutdown -r 0 This needs to be done.

This will fix your shares, screen resolution, mouse integration <copy/paste>

Ken

Works on other Linux distros as well!

I registered to give a big Thank You to the OP. I had the issue that the 6.0.14 virtualbox kernel modules would not build for Linux kernel 5.4.10 on Artix Linux (Arch without systemd). While the kernel modules would build for Virtualbox 6.1.0, this is a no-go for me as the new VboxSVGA driver simply does not work for my Windows 7 virtual machines (3D acceleration completely broken for me).

The patch here worked like a charm!

@rahrah
Thanks for this post.

This patch works for me.