Unable to install module vboxhost/6.1.14_OSE for kernel 5.4.64-1-MANJARO: Missing kernel headers

At section Install the Extension Pack(Optional):
Currently installation of extension pack is advised as:
pamac build virtualbox-ext-oracle
This is fine as long as you have the same version of VirtualBox as Arch has, but stable can lag behind in that, which may lead to similar errors as the one described in this thread until stable catches up.

As @j77h pointed out, there is the aur/virtualbox-ext-oracle-manjaro package, which from the dates seems to align with stable.
In short pamac build virtualbox-ext-oracle-manjaro should also be mentioned with the notification that the version of the extension pack should always match the version of VirtualBox.

1 Like

Done. Please verify?




I added that in that after 1 (one) TL2 user said he couldn’t. I just wanted confirmation…


It should be fine.

A bit of nitpick, but aur/virtualbox-bin-guest-iso is linked above it, which is a different package, an installer ISO for guest utils. Even then is there a reason it is advised above community/virtualbox-guest-iso?

Feel free to copy-paste and DM me what you want it to be exactly


P.S. But I’m going to
:bed: :zzz: :wave:

We need to clarify a few points.

  1. The wiki is at wiki.manjaro.org : VirtualBox - Manjaro Linux
    It’s separate from the forum, so nothing like a “wiki post”.
    To edit it we need a separate login, and we need to ask for it by email.
    (See here: Basic Submission Rules - Manjaro Linux)

  2. There is a HowTo in the Tutorials section of this forum
    [HowTo] VirtualBox - Installation - USB - Shared Folder
    made by @linux-aarhus. It’s more up-to-date than the wiki page.
    That’s not a wiki post either. (Well, it could be, but he didn’t mention it,
    and I’m on TL2 so I can’t see an edit button even if it is.)

  3. We I should have checked virtualbox-ext-oracle-manjaro more carefully.
    AUR (en) - virtualbox-ext-oracle-manjaro
    There is nothing on that page that says it’s an ‘official’ Manjaro production,
    so it’s not guaranteed to be always there.
    It was 2 days late for the 2020-09-11 stable update.
    (Edit: it would be great if Manjaro maintainers would make it part of their update process, but until then — )
    We still need to check versions before installing.
    yay and pikaur both can use -Ssa to search in the AUR, e.g.
    pikaur -Ssa virtualbox-ext-oracle
    With that command, they list each package that has “virtualbox-ext-oracle” in any part of the name or description (so they get the manjaro one as well), and show its version number.

  1. I meant the Announcement wiki post on this forum
  2. See above
    3. :dog2: up the wrong :deciduous_tree: (I’m just an editor here on the site, not a package maintainer nor am I a wiki editor yet…)


My last reply was to everyone here in general – don’t take it as personal :wink:

1 Like

You are not alone with the current VirtualBox issues. I use virtualbox daily - as I use Visual Studio on Windows 10 for contract work.

I have had several issues lately with the combo Nvidia, VirtualBox, extension pack and kernel modules - even on pure Arch.

I was on the brink of insanity - until I got it working - running Arch with zen kernel and no Nvidia card.

Because this is a manual action - the installer cannot know which users to add to vboxusers group.

It has never really been an issue with the extension pack so a :+1: to @j77h for the improvements to the VirtualBox topic with relation to the extension pack.


Been using it for years without much problem – nvidia340, standard LTS kernel (HP Z400).

Except that I had troubles installing the extension pack
when the AUR one was the wrong version.
The ext-pack install needs sudo/root
but when the VBox GUI asked for a password
it didn’t accept either mine or root’s.

Then discovered how to start the GUI with sudo,
with the /usr/lib/ path:
sudo /usr/lib/virtualbox/VirtualBox

But this command that I saw 2 days ago is a simpler way to do it:
sudo vboxmanage extpack install --replace <name>.vbox-extpack

Between mid-July and yesterday I didn’t start any VM.
Did something else go wrong during that time, and I missed it?
Sorry, no need to answer, don’t want to waste your time with useless questions.

But the OP already had vbox running previously, it wasn’t a new install.

And why was this in the wiki post on the update page? :
sudo usermod --append --groups vboxusers $USER

Seems like someone else also got dropped out of vboxusers unexpectedly,
but there’s no mention of why or how.
I looked in the testing page and it’s not mentioned there either.

Not asking for an answer to this either, it’s not worth the effort of finding out. :wink:


This never happens without user intervention - my guess is a group.pacnew

I also updated the wiki page earlier today to reflect the added knowledge on the extension pack.

1 Like

For the benefit of everyone else, that’s the real actual wiki at wiki.manjaro.org

I scanned my update logs and the last /etc/group.pacnew was more than a year ago.

But recently there was dicussion in the update forum about dealing with pacnew files promptly,
and some less-experienced users got into cleaning up their old ones.
("sudo DIFFPROG=meld pacdiff" is a good way to review and merge pacnew files.)

@MrE, I know your problem is solved, but if you don’t know had it happened, it could happen again.
Not being in the vboxusers group means that vboxusers
was not listed in your /etc/group and/or /etc/gshadow files.
One possibility is that you recently edited one or both of those files,
and vboxusers was accidentally left out of one or both.
Not saying you did that. :slight_smile:
Just mentioning it in case you weren’t aware of the possibility.

If anyone completely replaces /etc/group with /etc/group.pacnew, they would be dropped out of all groups, and would have many more problems, such as not being able to use sudo … if I understand it right.

1 Like


In the Aug/28 update, for the first time I read suggestions about pacdiff and started using it very carefully; that’s when I discovered that I had a lot of .pacnew in both computers.

Also, I saw that the new shadow.pacnew only had one entry, with the risk of leaving me without access to the system; I think I mentioned it in that announcement:

Solved .
After using * sudo pacdiff , I managed to find and get rid of all those old .pacnew files, then I reboot my system … cut …

I also found that some previous update, wreaked havoc on the shadow file; no wonder many people have complained that they cannot enter with their passwords, that new “/etc/shadow.pacnew” comes only with the “root” account:


I discard that shadow.pacnew.

I can certainly tell you that I checked the differences very carefully, and I did not see that my user will be missing from the groups during that update.

Also, and during the Sept/8 update my virtualbox was working correctly.

It was after the Sept/11* update that the problem started, so I deduce that this update removed my user from the group.

But, I think I found something strange in my PC at work, I found a file group.pacnew-
With a “dash” at the end, I don’t remember if I renamed it or if the Aug/28 or Sep/11 update left it as evidence of the update.

Although its date is prior to the Aug/28 update; and since the beginning of the year I have not had problems with the virtualbox in my work, the VM is a windows 10 that I use daily and even from home via RDP.


  • not Sep/9, but Sept/11

Addendum. So, the Sept/11 update didn’t give any warning that it would update the group file; so there’s a good chance it will happen again (hopefully not).

Where did you do this search in the logs? :thinking:

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.