Skip to main content
Topic: The constant incompatibilities of virtualbox -- how to cure them (Read 455 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The constant incompatibilities of virtualbox -- how to cure them

Virtualbox, artix-modules, kernel and headers, seem like a dog chasing its tail all the time.  I'd say more than 50% of the time recently with upgrades applied vb doesn't work.  I hate having to use the stupid thing but I am constantly testing new distros and installers, in case I find something as good as artix, obarun, void.

What if vb was built from arch-source and placed on the galaxy repository so only when the kernel and modules upgrade would be uploaded would a new version be applied.  This way they would all constantly be a match.  Or if somehow a dummy pkg or link can prevent a premature update, maybe?

I'm sorry I haven't managed to learn pkging yet so I can assist, and I have learned to manage holding things back or reverting something when it is incompatible but it is all this required rebooting to get the damn non-free thing to work that is annoying.  It also will look bad for new users who haven't learned the trick.

Just a friendly suggestion for when there might be some free time to think about it.

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #1
Simple solution, use dkms.

We basically only have packaged modules for the iso releases.
There is no fixed maintainer for modules, and we usually skip uneven kernel releases.

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #2
Simple solution, use dkms.

We basically only have packaged modules for the iso releases.
There is no fixed maintainer for modules, and we usually skip uneven kernel releases.

DKMS didn't do anything for 6.0.0-1 a few weeks ago.  I only use DKMS and had to downgrade VB back to 5.2.22-3 for a few weeks until everything sorted itself out (eventually)

See thread here

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #3
If you use dkms from arch, I think, you also have to use the arch kernel/headers and follow it, instead of artix.
Basically it is like running arch with nothing to do with artix as far as VB is concerned.  If you do so everything synchs.  If kernel in arch changes to 4.21, headers too, then dkms modules, but artix is still on 4.20 for a few weeks (for a good reason because when those kernels go massively out for use all kinds of crap pops up) and you are using the artix kernel you break virtualbox.

Oh well, ,maybe I'll have to keep publishing a chart with the current combination of kernel, vb, and modules that work together.

Today is:

local/linux 4.20.2.artix1-1
local/linux-headers 4.20.2.artix1-1
local/virtualbox 6.0.0-3
local/virtualbox-guest-modules-artix 6.0.0-5
local/virtualbox-host-modules-artix 6.0.0-5

If you upgrade any of those now you will break virtualbox

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #4
Ok I'm flipping the DKMS modules to modules-artix to see how it goes.

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #5
Remind me not to do that again:

Code: [Select]
RTR3InitEx failed with rc=-1912 (rc=-1912)

The VirtualBox kernel modules do not match this version of VirtualBox. The installation of VirtualBox was apparently not successful. Executing

'/sbin/vboxconfig'

may correct this. Make sure that you do not mix the OSE version and the PUEL version of VirtualBox.

where: supR3HardenedMainInitRuntime what: 4 VERR_VM_DRIVER_VERSION_MISMATCH (-1912) - The installed support driver doesn't match the version of the user.

Back to the same error.

This is the combo I have working again:

Code: [Select]
virtualbox 6.0.0-3
virtualbox-guest-iso 6.0.0-1
virtualbox-host-dkms 6.0.0-3
linux 4.20.artix1-1
linux-headers 4.20.artix1-1

The guest additions are flaky and bomb out sometimes when doing clipboard operations but I can at least do everything else.



Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #8
I had to totally go back to 5.22.  6 is just too much of a regression right now.  Guest additions constantly crashing.  When they don't, bidirectional clipboard access no longer works (other things like shared local folders seem ok), video tearing and flashing....

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #9
6.0.2 is out, try this.

I use 6.0.2 and no problems:

virtualbox-ext-oracle 6.0.2-1
virtualbox-guest-dkms 6.0.2-1
virtualbox-guest-iso 6.0.2-1
virtualbox-host-dkms 6.0.2-1
linux-zen 4.20.3.zen2-1

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #10
I was on 6.0.2

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #11
Today is:

local/linux 4.20.2.artix1-1
local/linux-headers 4.20.2.artix1-1
local/virtualbox 6.0.0-3
local/virtualbox-guest-modules-artix 6.0.0-5
local/virtualbox-host-modules-artix 6.0.0-5

If you upgrade any of those now you will break virtualbox

This still holds true (last valid combination) for those using artix modules, if the kernel is upgraded to 4.20.4 vb will be broken.
Just an update

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #12
this broke on me today, my stupid fault though, so if you going to ignore kernel updates make sure you ignore linux-header updates as well  ::)

Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #13
New working combination with artix modules:

local/linux 4.20.4.artix1-1
local/linux-headers 4.20.4.artix1-1
local/virtualbox 6.0.2-1
local/virtualbox-guest-modules-artix 6.0.2-4
local/virtualbox-host-modules-artix 6.0.2-4


Re: The constant incompatibilities of virtualbox -- how to cure them

Reply #14
All current upgrades work:

local/linux 4.20.4.artix1-1
local/linux-headers 4.20.4.artix1-1
local/virtualbox 6.0.4-1
local/virtualbox-guest-modules-artix 6.0.2-4
local/virtualbox-host-modules-artix 6.0.2-4