Package Details: virtualbox-ext-oracle 6.1.36-1

Git Clone URL: (read-only, click to copy)
Package Base: virtualbox-ext-oracle
Description: Oracle VM VirtualBox Extension Pack
Upstream URL:
Keywords: virtualbox
Licenses: custom:PUEL
Submitter: seblu
Maintainer: seblu (eworm)
Last Packager: eworm
Votes: 1358
Popularity: 3.22
First Submitted: 2010-12-24 16:48 (UTC)
Last Updated: 2022-07-21 10:19 (UTC)

Pinned Comments

seblu commented on 2019-04-25 17:41 (UTC)

There is no version dependency on this package on purpose! You could read comments back from 2011 to understand why.

Latest Comments

jongeduard commented on 2022-01-28 02:02 (UTC) (edited on 2022-01-28 02:11 (UTC) by jongeduard)

Oh yeah that's confusing, but also logical!: So I installed this on my Manjaro system (since I decided to migrate VirtualBox and all my VMs that have on it away from Windows - to make room for other hypervisors there as well), but as many know, Manjaro keeps a bit older versions of packages compared to vanilla Arch (which I am a lot more used to).

So Now I see how XHCI, etc. could not be working and things crash. Hmm good reasons to start always preserving "built" packages here as well (actually there's not so much to build on this propriatary binary thing).

Luckily simply modifying the version number in the above direct download link from the virtualbox download site simply still gives you the older download that you need.

Note that simply double clicking the file does not work. VirtualBox asks you for permissions but fails with a wrong message that your password is wrong. I really had to explicitly run a sudo VirtualBox command with the package file path as it's parameter.

alerque commented on 2022-01-20 19:04 (UTC)

@ram Never expect miss-matched ext packs to work. The real solution there would have been to upgrade your virtualbox rather than downgrade this, but that just shows you have your system in some unsupported partial-upgrade scenario. Downgrading this to match worked but the important point isn't that their is anything wrong with the new version, just that they have to match.

ram commented on 2022-01-20 09:14 (UTC)

hi! happy 2022!

I had problems with usb-ehci not working using vbox 6.1.30 and ext-oracle 6.1.32. manual downgrade to ext-oracle 6.1.30 made it work.

cheers + happy hacking

alerque commented on 2022-01-19 10:35 (UTC)

For those interested, here is a patch that should apply cleanly via git am to almost any version of this package (it should rebase easily on the master branch even when it gets bumped) that will version lock the built package to VB:

From 5fa2ca3d0511ef0d15075705b6d396f3dfe5df09 Mon Sep 17 00:00:00 2001
From: Caleb Maclennan <>
Date: Tue, 18 Jan 2022 16:05:31 +0300
Subject: [PATCH] Lock to matched version

Signed-off-by: Caleb Maclennan <>
 PKGBUILD | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/PKGBUILD b/PKGBUILD
index 9bbb182..4416794 100644
@@ -7,13 +7,14 @@ pkgdesc='Oracle VM VirtualBox Extension Pack'
 optdepends=('rdesktop: client to connect vm via RDP')

 prepare() {
   # shrink uneeded cpuarch

alerque commented on 2022-01-18 13:10 (UTC) (edited on 2022-01-18 13:13 (UTC) by alerque)

I understand why this package does not lock the virtualbox dependency to the same version (since as an AUR package it would block system updates using pacman), but I think that only makes sense for AUR packages. If you happen to host your own package repository or use one that packages this, having the version locked (i.e. depends=("virtualbox=$pkgver")) makes a lot of sense. It will block system updates until the package repository has the proper matching version. This may make sense for systems where VB usage is important or if you know the repository will be updated to match [community] bumps.

Harvey commented on 2021-10-25 12:06 (UTC)

Is it possible that there is no support for 32bit systems anymore? I have a WinXP 32bit VM that refuses to install the expansion pack in the VM. Version 6.1.26 did work, though.

kaido8903 commented on 2021-10-23 22:37 (UTC)

hello friends I had the same error from Daniel-I everything is due to compactness between versions the virtualbox-ext-oracle is not compact with the version of virtual box that you download from the official repositories ... to be clearer we must validate our version of virtualbox with the following command

VBoxManage -v

in my case I have version 6.1.26r145957 of virtualbox

on the next virtualbox page you will find the old builds

here each release has its respective extension pack

In my case, as I mentioned above, I have version 6.1.26 for which I downloaded the following extension pack

once we download it, we only install it with the following command in the location where it is located

sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-6.1.26.vbox-extpack

jrichard326 commented on 2021-10-21 15:24 (UTC)

With update to Virtualbox 6.1.28. I rebuilt and installed this package and all is well.

zeroconf commented on 2021-10-21 14:10 (UTC)

installed with virtualbox-bin 6.1.26-1, but still VirtualBox shows no extension pack installed :(

Daniel-I commented on 2021-10-21 13:57 (UTC) (edited on 2021-10-21 14:08 (UTC) by Daniel-I)

In hindsight, could the issue be related to version matching?

VirtualBox and all it's other packages are v6.1.26 while this package has been updated to 6.1.28... so perhaps this package update was made ahead of VirtualBox (in my Manjaro/pamac repositories anyway) being updated, and will be relevant once VirtualBox itself is updated to 6.1.28?

I wasn't sure how to downgrade an AUR package initially, but found a post that helped me to navigate the snapshots, download the three 6.1.26 package files, and run makepkg -scri... which successfully restored a working extension within Virtualbox!

jrichard326 commented on 2021-10-21 10:23 (UTC)

Same as Daniel-I. I was able to get my VM running by disabling USB 3.0

ngoonee commented on 2021-10-21 08:38 (UTC)

Same issue as reported by Daniel-l. Prevents my VM from starting up. Downgrading to the previous version helps as a workaround (just needed a quick Office job).

Daniel-I commented on 2021-10-20 22:49 (UTC) (edited on 2021-10-20 23:23 (UTC) by Daniel-I)

I received an update notification from pamac (GUI) that this package was updated today and selected to update.... I received a number of errors (all in the "Configuring virtualbox-ext-oracle..." section) and thought it best to provide the entire pamac log here to assist with troubleshooting.

Checking virtualbox-ext-oracle dependencies...
Synchronizing package databases...
Resolving dependencies...
Checking inter-conflicts...
Checking keyring...
Checking integrity...
Loading packages files...
Checking file conflicts...
Checking available disk space...
Installing m4 (1.4.19-1)...
Installing autoconf (2.71-1)...
Installing flex (2.6.4-3)...
Installing bison (3.8.1-1)...
Installing fakeroot (1.26-1)...
Installing pkgconf (1.8.0-1)...
Installing automake (1.16.5-1)...
Running post-transaction hooks...
Arming ConditionNeedsUpdate...
Updating the info directory file...
Cloning virtualbox-ext-oracle build files...
Generating virtualbox-ext-oracle information...

Building virtualbox-ext-oracle...
==> Making package: virtualbox-ext-oracle 6.1.28-1 (Wed 20 Oct 2021 04:59:45 PM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading Oracle_VM_VirtualBox_Extension_Pack-6.1.28.vbox-extpack...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 10.6M  100 10.6M    0     0  20.6M      0 --:--:-- --:--:-- --:--:-- 20.7M
==> Validating source files with sha256sums...
    Oracle_VM_VirtualBox_Extension_Pack-6.1.28.vbox-extpack ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
==> Starting prepare()...
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "virtualbox-ext-oracle"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Adding install file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: virtualbox-ext-oracle 6.1.28-1 (Wed 20 Oct 2021 04:59:46 PM)
==> Cleaning up...

Checking keyring...
Checking integrity...
Loading packages files...
Checking file conflicts...
Checking available disk space...
Configuring virtualbox-ext-oracle...
Progress state: NS_ERROR_FAILURE
Error while configuring virtualbox-ext-oracle
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.1.28.vbox-extpack"
Error while configuring virtualbox-ext-oracle
VBoxManage: error: VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=0000000000000000 ErrInfo='Helper version mismatch - expected 0x30000 got 0x3'
Error while configuring virtualbox-ext-oracle
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager
Error while configuring virtualbox-ext-oracle
VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 1424 of file VBoxManageMisc.cpp
Error while configuring virtualbox-ext-oracle
Error: virtualbox-ext-oracle: command failed to execute correctly
Transaction successfully finished.

I'm not sure what was supposed to happen with the first error (where it "failed to install"), but I can say it likely wasn't because the file did not exist, as it definitely does exist. (Note: the timestamp of the vbox-extpack is 7 min older as I thought I'd try remove/rebuild the package to see if that made a difference... which it didn't.)

$ ls -la /usr/share/virtualbox/extensions
total 1696
drwxr-xr-x 2 root root    4096 Oct 20 17:06 .
drwxr-xr-x 5 root root    4096 Oct 20 17:06 ..
-rw-r--r-- 1 root root 1728407 Oct 20 17:06 Oracle_VM_VirtualBox_Extension_Pack-6.1.28.vbox-extpack

When I open VirtualBox and open Preferences-> Extensions I see extension highlighted and if I mouse over it, it seems to repeat error #2 from the log.

This reminded me that the previous version of this package did not auto-register and I had to add it manually. So I tried the following steps and reached the same end result: (1) uninstalled the extension via pamac... (2) opened VirtualBox, removed the extension entry in Preferences->Extensions, and closed the app... (3) reinstalled the extension via pamac... same errors... (4) opened VirtualBox and found the extension was re-added with the same error on mouse-over (error #2 from the pamac log)

Musikolo commented on 2021-08-18 01:01 (UTC)

@ElijahLynn, unless I'm missing something, it should "just work". You can learn more about the extension pack at

I hope it helps!


ElijahLynn commented on 2021-08-17 23:24 (UTC) (edited on 2021-08-17 23:31 (UTC) by ElijahLynn)

Are there any specific instructions here after install? I don't see the Extension showing up in vbox preferences under extensions. Should it "just work"?

Update: it appears that I needed to reboot for it to show up.

drankinatty commented on 2020-10-18 10:22 (UTC) (edited on 2020-10-18 10:28 (UTC) by drankinatty)

Thinking more about it, the guest-additions module fail to build problem isn't with this package, the problem is with the guest-additions not patched as part of AUR virtualbox-bin.

graysky commented on 2020-10-13 14:03 (UTC)

Your post install script fails.

natrio commented on 2020-08-27 20:05 (UTC) (edited on 2020-08-28 19:04 (UTC) by natrio)

Test build 139990 was deleted from server and since than package can't be built. Using Oracle_VM_VirtualBox_Extension_Pack-6.1.13-140091.vbox-extpack it builds and works fine.

UPD: Before the kernel panic on a frozen VM wakeup.

daniarla commented on 2020-08-27 16:57 (UTC)

Seems like there is a new version or they simply removed it because the download link is broken.

ppenguin commented on 2020-08-21 20:50 (UTC) (edited on 2020-08-21 20:57 (UTC) by ppenguin)

Is there a reason why the virtualbox package doesn't propose the extension pack of the same version as an optional dependency and offers a warning or a blocker in relation to wrong versions? It seems a missed opportunity (at best) or, worse, a usability regression which causes unnecessary inconvenience and could be solved by available functionality in pacman/packages? Otherwise it would defeat the purpose of having a package for the extension pack?

mallee commented on 2020-08-21 09:49 (UTC) (edited on 2020-08-21 12:14 (UTC) by mallee)


Under section titled "VirtualBox 6.1.12 Oracle VM VirtualBox Extension Pack"

In italics "Please install the same version extension pack as your installed version of VirtualBox."

Extension Pack 6.1.13.X is for VirtualBox 6.1.13 which are both almost certainly test/alpha/beta releases of what will eventually be release 6.1.14. If you have VirtualBox 6.1.12-X installed, then you need extension pack 6.1.12 not 6.1.13 or any other later version.

cytomax55 commented on 2020-08-20 00:08 (UTC)

The virtualbox version on arch is 6.1.12-4

The version for the AUR extension pack is

This is causing Virtualbox to not load VMs

Uninstalling this package and manually installing

fixes the problem..

just my 2 cents

gunslingerfry commented on 2020-08-18 21:09 (UTC)

philster10260 this fixed it for me as well. Thanks!

philster10260 commented on 2020-08-13 14:33 (UTC)

This update broke all of my Win7 VMs, and downgrading to USB 1.1 is totally unacceptable, duh. I was able to recover by uninstalling all my virtualbox packages and reinstalling all of them EXCEPT this one. Then I downloaded the last working extension pack from here:

and manually installed it using "VBoxManage" from a "su" shell.

Everything is working now :)

dml commented on 2020-08-13 11:17 (UTC)

I have the same problem. Workaround: disable ehci\xhci usb controller in virtual machine settings (only ohci allowed). I hope oracle fix this in future updates.

anova commented on 2020-08-13 11:11 (UTC)

After updating this to 6.1.13.-1 my VM crash on startup with this error:

Failed to load R0 module /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/VBoxEhciR0.r0: SUP_IOCTL_LDR_OPEN failed (VERR_INVALID_PARAMETER). Failed to load ring-0 module 'VBoxEhciR0.r0' for device 'usb-xhci' (VERR_INVALID_PARAMETER).

Please help :)

eworm commented on 2020-08-12 22:05 (UTC)

I geuss you are still running linux 5.7.12 with virtualbox-host-modules-arch from [community]? I missed to rebuild the latter... Probably your issue is unrelated to the extension pack. Please update and try again.

dml commented on 2020-08-12 21:40 (UTC)

just reboot

eworm commented on 2020-08-12 21:39 (UTC)

Only virtualbox 6.1.12-4 available in official ARCH repository right now. With virtualbox-ext-oracle I get error: "RTR3InitEx failed with rc=-1912 (rc=-1912)"

Did you reload modules (or just reboot)?

dml commented on 2020-08-12 21:32 (UTC)

Only virtualbox 6.1.12-4 available in official ARCH repository right now. With virtualbox-ext-oracle I get error: "RTR3InitEx failed with rc=-1912 (rc=-1912)"

kruzah commented on 2020-01-04 21:19 (UTC)

@reliveyy Please read the Arch Linux repo news here:

reliveyy commented on 2020-01-04 19:24 (UTC) (edited on 2020-01-04 19:25 (UTC) by reliveyy)

I installed this pack and got two error messages in the end:

:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
error: missing 'dmxproto' dependency for 'libdmx'
error: missing 'xf86dgaproto' dependency for 'libxxf86dga'

But when I test it with VBoxManage list extpacks, I got some expected results:

Extension Packs: 1
Pack no. 0:   Oracle VM VirtualBox Extension Pack
Version:      6.1.0
Revision:     135406
Description:  Oracle Cloud Infrastructure integration, USB 2.0 and USB 3.0 Host Controller, Host Webcam, VirtualBox RDP, PXE ROM, Disk Encryption, NVMe.
VRDE Module:  VBoxVRDP
Usable:       true
Why unusable:

I have no idea about the meaning of the error messages.

rogierschouten commented on 2020-01-02 14:16 (UTC)

@fukawi2 thank you, that works

fukawi2 commented on 2020-01-02 03:12 (UTC)

@rogierschouten Running makepkg -cfi twice worked for me. I had to manually install the extension pack using the GUI afterwards though.

rogierschouten commented on 2019-12-26 09:58 (UTC)

When installing, I get this error:

VBoxManage: error: Manifest mismatch: 'linux.x86/' not found in the 2nd manifest VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackFileWrap, interface IExtPackFile, callee nsISupports VBoxManage: error: Context: "Install(fReplace, __null, ptrProgress.asOutParam())" at line 1360 of file VBoxManageMisc.cpp

phw commented on 2019-12-16 23:49 (UTC)

With the update to Virtualbox 6.1 from official repos this package installation works again for me.

stdcall commented on 2019-12-15 08:25 (UTC)

I'm getting same as @Raymo111. Reverting back to old version.

Raymo111 commented on 2019-12-13 01:09 (UTC)

@djnightchild Ok, good to know.

djnightchild commented on 2019-12-13 00:57 (UTC)


This is a bug on the original source as well, we need to wait for Oracle to fix this.

Raymo111 commented on 2019-12-12 23:17 (UTC)

error: command failed to execute correctly

I'm getting this error when I makepkg.

Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.1.0.vbox-extpack"
VBoxManage: error: Failed to load the main module ('/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/'): VERR_FILE_NOT_FOUND - /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/ undefined symbol: RTVfsFileQuerySize
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager
VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 1361 of file VBoxManageMisc.cpp

whezzel commented on 2019-12-12 22:41 (UTC) (edited on 2019-12-12 22:50 (UTC) by whezzel)

I am receiving the same error as @mocambo.

The package installs, but I have to disable USB support before I can boot my VM.

I tried what @Noeljunior suggested, but it did not make a difference

I have reverted to 6.0.14 until this can be resolved.

Noeljunior commented on 2019-11-29 12:35 (UTC)

@mocambo, try this:

chmod -R u+rwX,g+rwX,o+rX '/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/'

mocambo commented on 2019-07-17 22:20 (UTC) (edited on 2019-07-17 22:28 (UTC) by mocambo)

How can it be solved ? Thanks !

Installing virtualbox-ext-oracle (6.0.10-1)...


Progress state: NS_ERROR_FAILURE

VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.0.10.vbox-extpack"

VBoxManage: error: Failed to load the main module ('/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.x86/'): VERR_FILE_NOT_FOUND - /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.x86/ undefined symbol: _ZN22RTCRestBinaryParameter19setProducerCallbackEPFiPS_PvjyPjES1_y

VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager

VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 1361 of file VBoxManageMisc.cpp

Error: command failed to execute correctly

Transaction successfully finished.

Rhinoceros commented on 2019-05-11 01:43 (UTC)

FWIW this package builds perfectly for me now. Perhaps the certificate was fixed? In any case, IMO the out-of-date flag can be removed.

DragonX256 commented on 2019-05-01 04:03 (UTC)

Guys, URL stays, as I saw it on Where did you get changes to

WFV commented on 2019-04-27 14:44 (UTC)

thanks dstclair and andreagi

andreagi commented on 2019-04-27 01:57 (UTC)

I had to change the source URL to:$pkgver/Oracle_VM_VirtualBox_Extension_Pack-$pkgver.vbox-extpack

to solve this issue:

curl: (60) SSL: no alternative certificate subject name matches target host name '' More details here:

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. ==> ERROR: Failure while downloading Aborting...

dstclair commented on 2019-04-27 01:57 (UTC)

The download link changed. It appears to be now.

seblu commented on 2019-04-25 17:41 (UTC)

There is no version dependency on this package on purpose! You could read comments back from 2011 to understand why.

rbl commented on 2019-04-25 15:45 (UTC)

Yes, please add a version dependency. This updated to 6.0.6 while Virtualbox remained on 6.0.4, breaking my install and forcing me to manually uninstall and reinstall the downgraded extension pack.

ivoshm commented on 2019-04-18 15:20 (UTC) (edited on 2019-04-18 15:21 (UTC) by ivoshm)

Will be possible change dependency from depends=('virtualbox') to depends=("virtualbox=$pkgver") to force same version? Thanks.

bennypr0fane commented on 2019-03-01 22:10 (UTC)

It installed for me just now even though I'm using kernel 4.19

unnilquadium commented on 2019-01-07 17:22 (UTC)

According to the official source for virtualbox, the current version is 6.0.0. I believe this package is incorrectly flagged as out-of-date as of 2019-01-07.

liOnux commented on 2019-01-04 08:42 (UTC)

YAY flag it "Out Of Date" like yaourt. I think it's because I use LTS kernel 4.19.

ajkerzner commented on 2019-01-01 19:04 (UTC)

I agree with drankinatty - it's up-to-date. Also, an important note on the use of yaourt: do NOT use yaourt. See for alternatives and reasoning, as yaourt is no longer maintained (see ).

drankinatty commented on 2018-12-31 07:21 (UTC) (edited on 2018-12-31 07:22 (UTC) by drankinatty)

This package is NOT out of date. You must wait to install until after you install Linux-4.20. Then both virtualbox-bin_6.0.0 and these packages install and run fine.

dml commented on 2018-12-29 20:33 (UTC)

To solve current problem: yaourt -R virtualbox-ext-oracle yaourt -S virtualbox-ext-oracle-5

dinth commented on 2018-12-28 09:43 (UTC) (edited on 2018-12-28 09:46 (UTC) by dinth)

"As zerophase already stated, the extension can't currently be installed on stable because it already is v6"

Shouldnt ver 6.0.0 be included in virtualbox-ext-oracle-beta for now, until Virtualbox 6.0 enters mainline Arch repository? It's weird that right now the addon package is newer (and incompatible) than the package it should add onto, therefore rendering it useless. And then Virtualbox in mainline is also useless for most users, as its no longer possible to install relevant version of Oracle addons from AUR.

Corubba commented on 2018-12-27 11:12 (UTC)

Can we please stop these "me too" comments with the same error message over and over again? As zerophase already stated, the extension can't currently be installed on stable because it already is v6, but the virtualbox v6 package hasn't been moved out of community-testing yet.

And don't even get me started on manjaro.

obelix1502 commented on 2018-12-27 10:59 (UTC)

I also have the same error on Manjaro testing: Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.0.0.vbox-extpack" VBoxManage: error: Failed to load the main module ('/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/'): VERR_FILE_NOT_FOUND - /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/ undefined symbol: _ZNK16RTCRestArrayBase9baseCloneEv VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 1211 of file VBoxManageMisc.cpp

nrw commented on 2018-12-27 09:18 (UTC)

Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.0.0.vbox-extpack" VBoxManage: error: Failed to load the main module ('/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/'): VERR_FILE_NOT_FOUND - /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/ undefined symbol: _ZNK16RTCRestArrayBase9baseCloneEv VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 1211 of file VBoxManageMisc.cpp

ArthurBorsboom commented on 2018-12-27 08:46 (UTC)

I noticed the same error as zerophase.

scan commented on 2018-12-27 02:19 (UTC)


zerophase commented on 2018-12-27 00:16 (UTC) (edited on 2018-12-27 00:17 (UTC) by zerophase)

Gives error:

(1/1) upgrading virtualbox-ext-oracle [-----------------------------------] 100% 0%... Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-6.0.0.vbox-extpack" VBoxManage: error: Failed to load the main module ('/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/'): VERR_FILE_NOT_FOUND - /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/ undefined symbol: _ZNK16RTCRestArrayBase9baseCloneEv VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManagerWrap, interface IExtPackManager VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 1211 of file VBoxManageMisc.cpp

Believe it is since Arch has not upgraded to 6.0 yet.

Vakili73 commented on 2018-12-24 17:04 (UTC)

new version released. this is an old version.

DragonX256 commented on 2018-08-15 15:43 (UTC)

Whoops, nevermind. They fixed it.

DragonX256 commented on 2018-08-15 13:57 (UTC)

Provided URL isn't working. This > URL is correct. Check for this.

WFV commented on 2018-05-03 00:57 (UTC)

@ Flubbadub, thanks for the info re checksum, that worked for me

infomaniac50 commented on 2018-04-30 23:45 (UTC) (edited on 2018-04-30 23:47 (UTC) by infomaniac50)

It seems only the Windows host matches the current Sources. Everything else is on 5.2.10_122088.

Flubbadub commented on 2018-04-27 20:07 (UTC) (edited on 2018-04-27 20:08 (UTC) by Flubbadub)

For anyone else with the checksum issue the correct one is 5eef217dbe0a8e8caf383ea8db83344517af0f9093041b5345c8468a427b327b

You can see from that there are 2 versions of the extension pack & the one with the lower number has the old hash, while the one which is currently being served on the URL for the PKGBUILD is a newer one (bugfix I guess).

ricardofunke commented on 2018-04-27 17:54 (UTC)

Got checksum failed

macieks commented on 2018-01-16 20:54 (UTC) (edited on 2018-01-16 20:54 (UTC) by macieks)

Version 5.2.5 seems to be deleted from the HTTP server. Latest is 5.2.6:

WFV commented on 2018-01-16 19:31 (UTC) (edited on 2018-01-16 22:12 (UTC) by WFV)

had to edit the PKGBUILD $pkgver to install, then it works. EDIT: 5.2.6 is up there now, thanks seblu.

Marcel_K commented on 2018-01-16 19:00 (UTC)

Should be 5.2.6 (maintenance releases are always even-numbered).

oldgaro commented on 2018-01-16 18:48 (UTC) (edited on 2018-01-16 23:44 (UTC) by oldgaro)


seblu commented on 2017-12-20 17:37 (UTC)

1) IIRC to not pull virtualbox deps during build. 2) No, cf previous comments. We don't care of non-arch users here.

commented on 2017-12-20 16:47 (UTC)

Two questions: 1. why is depends array in the package() function and not global? 2. can the maintainer maintain the corresponding virtualbox version dependency? it should be as easy as writing depends=('virtualbox>=whatever_the_ext_version_is'). this way it won't break the setup for non-arch users.

commented on 2017-10-23 23:03 (UTC)

Hi @seblu , you have to add version dependency of virtualbox for this package, because says: "Please install the extension pack with the same version as your installed version of VirtualBox". That is not correct to use virtualbox-ext-oracle with any version of virtualbox.

zeroflag commented on 2017-10-23 21:24 (UTC) (edited on 2017-10-23 21:29 (UTC) by zeroflag)

@seblu @eworm Since versioned dependencies are not used in Arch, the package maintainer, committer should've checked the versions compatibility prior committing such crippled update. The philosophy adopted by Archlinux is KISS. But for some reason, immature community members stick to the "stupid" part only. This is not a playground, or is it... @giogziro95 Thanks for the provided PKBUILD, mate, very much appreciated!

mxfm commented on 2017-10-23 05:03 (UTC)

Recent update 5.1=>5.2 has broken my virtualbox because of version mismatch. @seblu @Scimmia this issue should be somehow fixed, or this package should have not been updated to version 5.2 without corresponding update of virtualbox from main repos. Saying that we coudn't not do versioned dependecies because thay are broken in Arch is nonsense. If this is true, than pacman should be fixed. I am amazed how often arch people blame users and not crippled features. By the way, this update breaks policy of not supporting partial updates, because what essentially is done is exactly partial update. I would expect that virtualbox and ext pack to be kept in syns.

giogziro95 commented on 2017-10-21 10:50 (UTC)

Here's a PKGBUILD for 5.1.2, if anybody's interested:

seblu commented on 2017-10-21 09:40 (UTC)

We do not use versioned dependencies in Arch. I remember this was suggested and tested years ago and it breaks the upgrades.

giogziro95 commented on 2017-10-21 01:18 (UTC) (edited on 2017-10-21 11:09 (UTC) by giogziro95)

Scimmia, in this case, it's the other way around — the VirtualBox version is lower than the Extension Pack version. And it's broken after the Extension Pack update because of the version mismatch, so it's a good idea not to update the Extension Pack only. In order to avoid the problem you've mentioned, this can be used instead: depends=('virtualbox>=VERSION')

Scimmia commented on 2017-10-21 01:05 (UTC)

scan, that doesn't really have anything to do with this package, which is just the extention pack. giogziro95, that would make updating a massive pain in the ass for most people. You wouldn't be able to update virtualbox without uninstalling this first.

giogziro95 commented on 2017-10-21 00:44 (UTC) (edited on 2017-10-21 11:08 (UTC) by giogziro95)

In order to avoid the version mismatch, please add package version in the "virtualbox" dependency like this: depends=('virtualbox=VERSION') That way, pacman will try to update the "virtualbox" package if it's possible, or otherwise, it'll give an error. Thanks.

commented on 2017-10-20 18:00 (UTC)

Update: The Guest Additions image with the 5.2.0 release fails to work with recent Linux guest kernels. Please try this image which we believe fixes the problem. For experimental Linux 4.14 support, please try this image. Both should work on all older guest systems too: please file a report on the bugtracker if they do not.

amos commented on 2017-10-19 14:16 (UTC)

Yes, but still this should be marked as dependency virtualbox>=5.2 so it isn't installed as long as it is incompatible.

khampf commented on 2017-10-19 10:52 (UTC) (edited on 2017-10-19 10:54 (UTC) by khampf)

I second gcavalio, what's up with this being 5.2 and incompatible with community? (edit: ok 5.2 got released yesterday, community will probably update shortly, )

gcavallo commented on 2017-10-18 22:47 (UTC)

VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-5.2.0.vbox-extpack" VBoxManage: error: VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=0000000000000000 ErrInfo='VirtualBox version mismatch - expected 5.2 got 5.1' Virtualbox is still at 5.1 in the repo, 5.2 is only in testing.

sotoleni commented on 2017-10-17 12:14 (UTC)

When I execute the "VBoxWindowsAdditions-amd64.exe", it appear a message box saying: File System error (-1073741819) Anyone had the same problem? Thank you Toni P.D: With version: virtualbox-ext-oracle 5.1.30-1

Scimmia commented on 2017-09-18 15:51 (UTC)

vk496, the version in the official repository is 5.1.28, so there's no issue here.

vk496 commented on 2017-09-18 14:52 (UTC)

I had problems with this version (USB proxy) in Virtualbox 5.1.26. I recommend downgrade to always match the version of oficial repository (5.1.26-1) Salu2

vegangaro commented on 2017-07-19 03:32 (UTC)

VirtualBox is saying this extension is outdated Thanks, anyway!

heichblatt commented on 2017-05-02 09:51 (UTC)

The following patch would bring this package up to date: --- % git diff diff --git a/PKGBUILD b/PKGBUILD index 68b34c9..a5f1b6d 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -1,6 +1,6 @@ # Maintainer: Sébastien Luttringer pkgname=virtualbox-ext-oracle -pkgver=5.1.20 +pkgver=5.1.22 pkgrel=1 pkgdesc='Oracle VM VirtualBox Extension Pack' arch=('any') @@ -10,7 +10,7 @@ options=('!strip') install=virtualbox-ext-oracle.install source=("$pkgver/Oracle_VM_VirtualBox_Extension_Pack-$pkgver.vbox-extpack") noextract=("Oracle_VM_VirtualBox_Extension_Pack-$pkgver.vbox-extpack") -md5sums=('f7150f14f39e4be55ff07351f3fd7b54') +md5sums=('78b01ef9443f0bb1e31489ee7855135a') prepare() { # shrink uneeded cpuarch ---

m3thodic commented on 2017-04-25 05:43 (UTC)

@jamesan thank you!

commented on 2017-04-25 04:00 (UTC)

@jamesan: thanks for sharing. @seblu: can you please update package install script!!

drankinatty commented on 2017-04-24 23:09 (UTC)

@jamesan, you are hired, you are the top candidate to inherit this package... I saw that new license on VBoxManage install on SuSE, but didn't take time to translate that into the post-install here. Great job!

mms commented on 2017-04-24 13:31 (UTC)

@jamesan ... neat, thanks for sharing!

jamesan commented on 2017-04-21 11:31 (UTC) (edited on 2017-04-21 11:53 (UTC) by jamesan)

tl;dr: package installs/upgrades complete with errors and the extension pack is not successfully added to VirtualBox. Either manually install the extension pack using the CLI VBoxManage command or the VirtualBox GUI after the erroneous install/upgrade or replace the package's post_install() function with prior to install/upgrade: post_install () { VBoxManage extpack install --accept-license=$(sha256sum /usr/share/licenses/virtualbox-ext-oracle/PUEL | head --bytes=64) "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-${1%%-*}.vbox-extpack" >/dev/null } ---- The `VBoxManage extpack install` command fails when run within a script (non-interactively). When run interactively, it requires user acceptance of its license and outputs how to run it non-interactively -- namely, by adding the argument, --accept-license=$HASH, where $HASH is derived to equal the SHA256 hash value of the text file version of the extension pack license (the extracted ./ExtPack-license.txt in the extpack archive file, also installed by this package to /usr/share/licenses/virtualbox-ext-oracle/PUEL). I can confirm this derivation holds true for at least version 5.1.20. Without changes, upgrading or installation fails at the post_install() VBoxManage command with pacman outputting an "error: command failed to execute correctly" message and the extension pack is not added to VirtualBox. With the above change, the package installs without exception and VirtualBox recognises the new extension pack.

drankinatty commented on 2017-03-21 02:14 (UTC)

As was generally the case, it was the end-user doing something stupid. I had an old version of the guest-additions installed that conflicted with the auto-build of the new modules. 5.1.18 works just fine. Sorry for the noise.

ranger commented on 2017-03-18 11:37 (UTC) (edited on 2017-03-18 11:38 (UTC) by ranger)

@drankinatty, is your host and your guest arch linux? you need virtualbox-ext-oracle for your host only.

Det commented on 2017-03-18 07:00 (UTC)

You say "Build fails for both 5.1.18 and 5.1.16."?

drankinatty commented on 2017-03-18 03:54 (UTC)

Note: when bumping the version to 5.1.18, building/installing the extension pack package worked fine, but when attempting to build the kernel modules for an Arch guest with the 4.10 kernel, I ran into a build failure. Reported upstream:

ranger commented on 2016-11-22 16:31 (UTC)

@yan12125, I had the same problem but upgrading to the latest version of virtualbox-ext-oracle solved the problem.

yan12125 commented on 2016-11-22 15:52 (UTC)

Hello seblu, I know there's already an out-of-date flag, while things are somewhat different this time. With virtualbox 5.1.10, virtual machines refuse to start with older extension packs: $ vboxmanage startvm win7 Waiting for VM "win7" to power on... VBoxManage: error: The device helper structure version has changed. VBoxManage: error: If you have upgraded VirtualBox recently, please make sure you have terminated all VMs and upgraded any extension packs. If this error persists, try re-installing VirtualBox. (VERR_PDM_DEVHLPR3_VERSION_MISMATCH) VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole virtualbox has just entered [community] 90 minutes ago, so I just more people will be affected by this issue. For others come here, perlsite's comment below (on 2016-07-01 18:32) is helpful. Just change pkgver=5.1.10 and md5sum to ac90d8356746754eadc3f28ef77174f0

WFV commented on 2016-10-30 21:40 (UTC) (edited on 2016-10-30 23:47 (UTC) by WFV)

I'm getting these errors when updating this package: error: 'jre8-openjdk-headless-8.u112-1': description file is missing error: 'jre8-openjdk-headless-8.u112-1': file list is missing Yet the jre8-openjdk-headless-8 directory does exist in /var/lib/pacman/local and isn't empty, and pacman -Qi shows it is version .u112-1. Happens using pacaur and yaourt, pacaur gives a little more info in the error. What can I do to remedy it? Thanks. EDIT: my mistake, had to set default java enviro to 8 today after -Syyu, all is well.

brain_death commented on 2016-10-20 18:35 (UTC)

For the latest version, use: pkgver=5.1.8 md5sums=('79a603d85d38a5c793673ddd7f2f166b')

emilburzo commented on 2016-09-16 16:19 (UTC)

For the latest version, use: pkgver=5.1.6 md5sums=('d01ce44646623ee90cecda322c7f34f9')

emilburzo commented on 2016-07-16 15:52 (UTC)

For the latest version, use: pkgver=5.1.0 md5sums=('06c5c47fd1d21bf6701a2f3b2146c7e1')

pgoetz commented on 2016-07-16 10:22 (UTC)

rdesktop is woefully out of date. I would add remmina as an optional dependency and perhaps drop rdesktop altogether. There's also gnome-rdp, although I haven't tried it and don't know what state it's in.

grawity commented on 2016-07-07 05:22 (UTC)

I found the difference. Apparently having TAR_OPTIONS="--xattrs" in the environment causes tar to use a format different from the default.

perlsite commented on 2016-07-01 18:32 (UTC)

Well, as workaround just use the "Download snapshot", extract in /tmp/vbep open the PKGBUILD and change to "pkgver=5.0.24" and "md5sums=('f576d8521e6315b507ae7daab495c1e6')" respectively. Keep only PKGBUILD and virtualbox-ext-oracle.install files. Delete all the other inside /tmp/vbep run: makepkg and then: sudo pacman -U virtualbox-ext-oracle-5.0.24-1-any.pkg.tar Done.

j1simon commented on 2016-06-29 19:09 (UTC)

Why this package in your repository ($repo/$arch) is outdated? $ pacman -Sl seblu | grep virtualbox seblu virtualbox-ext-oracle 5.0.20-1

seblu commented on 2016-06-14 20:35 (UTC) (edited on 2016-06-14 20:36 (UTC) by seblu)

I appreciate your comment but it works perfectly for me since years.

grawity commented on 2016-06-14 05:32 (UTC)

I appreciate the attempts to "shrink" the extpack file, but VirtualBox isn't actually able to import it after the repacking. (In fact I don't think it has worked in the last *year* or so.) The install process always fails with: VBoxManage: error: RTVfsFsStrmNext failed: VERR_TAR_UNSUPPORTED_PAX_TYPE It seems that VirtualBox only understands --format=gnu and --format=ustar, *not* the default 'pax' format. (The original file uses GNU tar format.)

Rainmaker commented on 2016-03-11 09:40 (UTC)

@seblu. I am the current maintainer of virtualbox-bin in AUR. As virtualbox-bin and virtualbox-ext-oracle are related (a newer version of virtualbox-bin without an updated virtualbox-ext-oracle will not work), may I suggest making eachother co-maintainer?

bartki commented on 2015-12-07 11:00 (UTC) (edited on 2015-12-07 11:01 (UTC) by bartki)

@mabra: 'fakeroot' is a member of the package group 'base-devel', which is a prerequisite for building packages. Therefore it is not necessary to specify it as a build dependency.

mabra commented on 2015-12-06 22:14 (UTC)

Dependeny to 'fakeroot' is wether checked nor mentioned!

thirtythreeforty commented on 2015-11-23 05:25 (UTC)

It is now actually out-of-date, as the newly-packaged VirtualBox 5.0.10 complains about the 5.0.8 extension pack.

Mikaela commented on 2015-09-18 14:06 (UTC)

Sorry for flagging out-of-date, pamac hadn't checked for updates and I missed the last updated time.

hmrodrigues commented on 2015-08-18 18:02 (UTC)

Oh right, I'm sorry I miss read it when pacman installed. Sorry my bad.

dkaylor commented on 2015-08-18 15:21 (UTC)

@hugao Not much point, virtualbox in community is still out-of-date. Although virtualbox-bin in aur is. But how many are using it? No votes.

hmrodrigues commented on 2015-08-18 11:08 (UTC)

@seblu can you update to 5.0.2?

Scimmia commented on 2015-08-18 00:33 (UTC)

fakeroot is part of base-devel, which is assumed to be installed at build time.

seblu commented on 2015-08-17 21:13 (UTC)

Is this a question?

mzimmerman commented on 2015-08-17 20:01 (UTC)

fakeroot required for build

dkaylor commented on 2015-07-17 07:40 (UTC)

Updating your own package? Because nothing has been updated here, and you're not the maintainer.

mbostwick commented on 2015-07-17 06:57 (UTC)

updating the package version to 5.0.0, and adding the new md5sum of the file. Here is the new md5sum, 3aa4a320f7bf64ddfa02e86e51eb5038

hschletz commented on 2015-03-06 14:03 (UTC)

The PKGBUILD contains a misleading comment: "shrink uneeded cpuarch" should be "remove unneeded support for non-Linux OS".

ranger commented on 2014-12-14 00:24 (UTC)

@Glenster I repeat: this package is not the guest additions, it is an extension pack package for the host and only for the host. Read the Description. It is needed by the host to provide usb support for the guest. You have to install this in your host-debian. Anyway, if you have more questions we can help you at the forums.

seblu commented on 2014-12-13 23:13 (UTC)

yes, please ask for help on forums or mailing lists, not in AUR comments.

Glenster commented on 2014-12-13 23:00 (UTC)

@ranger: Archlinux is the guest, and that's where I need to install the guest additions, because I get a message from the guest as follows when I check the box in its settings (before starting the guest) to enable USB 2.0: "On the USB page, USB 2.0 is currently enabled for this virtual machine. However, this requires the Oracle VM VirtualBox Extension Pack to be installed. Please install the Extension Pack from the VirtualBox download site. After this you will be able to re-enable USB 2.0. It will be disabled in the meantime unless you cancel the current settings changes." @ Musikolo: Thanks for clearing up my misunderstandings. I have now built and installed the AUR and it seemed to give no errors. I then went back to the wiki and went through the steps there ( But at the end of it all I still get the error message above. Any further ideas, anyone?

ranger commented on 2014-12-13 19:08 (UTC)

@Glenster, you have arch as guest in vbox right? Then you don't need this package in archlinux, you have to install it in you host (Debian)

Musikolo commented on 2014-12-13 19:02 (UTC)

@Glenster This is an AUR package. You have to build it yourself and then install it. More info at In addition, please, use "pacman -Syu" instead of "pacman -Syy" to get full update of your system.

Glenster commented on 2014-12-13 18:56 (UTC)

Hello, I'm a beginner with Archlinux. I have installed an Archlinux VM on Virtualbox running on Debian. The networking is working fine and I have run "pacman -Syy" and reinstalled pacman with "pacman -S pacman" I located the package by searching on the term "virtualbox" at However, when I run "pacman -S virtualbox-ext-oracle" in the VM I get this error: "error: target not found: virtualbox-ext-oracle" Could someone tell me what I am doing wrong? Thank you.

dixi_minga commented on 2014-08-29 05:00 (UTC)

oh, sorry, my fault; I had a look in my Backups; I lost group membership one month ago because of removing and reinstalling virtualbox I did not recognize it, because my USB-Devices were still listed in the USB Settings sorry for the suspicion

seblu commented on 2014-08-29 02:17 (UTC)

How could you loose a group membership because of this package? Fortunately we hunt duplicates on our spare time, my main mistake is to not have killed it quickly.

dixi_minga commented on 2014-08-29 01:34 (UTC)

Now it works, I lost my vboxusers group membership with the new package. I know it's "only" AUR; but I'm not very happy, that the "Duplicate" was simply deleted.

seblu commented on 2014-08-29 00:37 (UTC)

@dixi_minga: It was removed as duplicate. Could you be a little more specific, why this one is not working for you?

dixi_minga commented on 2014-08-28 19:59 (UTC)

I cant find anymore the package virtualbox-extension-pack; this was the only one for me, which works ?

msx commented on 2014-08-19 09:46 (UTC)

Thanks for automating the install of the extension :)

hybrid commented on 2014-07-26 05:04 (UTC)

Well I don't particularly prefer building my packages myself. But I do if the package I want frustrates me - always pulling in an unnecessary and unwanted dependency counts as frustrating in my mind. So thank you for your tip with "makepkg -d" but I already figured out my way of creating the package the way I want it. But what's up with that "That's damn faster"? My complaint is not about speed (but if it was I would ask as to why you are actually unpacking the extpack, then rm the created files and repacking it instead of for instance piping it throught tar and use the -X/--exclude switch or anything but actually decompressing, altering files and compressing again), my complaint is about keeping things simple and without unneeded stuff. So far I still couldn't come up with a sigle scenario in which a user has successfully installed virtualbox yet would run into trouble with this package if it hadn't that -dkms makedep. And this is the only package I've come across that finds that "-dkms trick" necessary. Really, I would like to understand in which case this trick is useful and why. But reducing build time is not a valid reasoning in a package like this in my mind. Your next statement about eworm's package raises the question: What should be in charge of keeping track of packages and/or it's files? A distribution's package manager or should third party tools such as VBoxManage be trusted to manipulate files while wielding root privileges? While that could actually be an interesting question it is too abstract for this comment section. And I understand that you're just trying to comply with virtualbox by letting vbox handle it's ext-pack-files, even though they're not tracked by the package manager. I can even accept that approach if that's the only official option given by vbox and if one is worried about things breaking in vbox if not installed the "official way". But please give the idea of forcing dkms on the virtualbox package a second thought. Because as great as dkms can be for servers as questionable it's usefulness is for desktops and medium workstations and more importantly: There is still no way for pacman to keep track of files created through dkms. And there is no official vbox rule I am aware of that would force one to use virtualbox specifically with dkms. So no need to hurry into a technology that isn't yet fully worked through just because it's cool. If however you as the maintainer deem dkms really necessary I feel like the virtualbox package would be the proper place to dep on dkms and not this pkg which only relies on vbox. And again, in that case I would like to know who that would be necessary for to force dkms on all users. Not to troll, just to learn. Lastly just for the record (not a perfect example, but one I quickly came up with): For example the nvidia package deps on a specific linux-package version range just like the virtualbox package. Yet other packages like nvidia-utils or opencl-nvidia don't seem to be in need for a -dkms trick. Also the nvidia package copies and tracks the module directly, bypassing the installation routine. Just one of many packages that deal with these issues that way. best regards

seblu commented on 2014-07-24 08:05 (UTC)

I will probably remove this dep soon, as virtualbox will dep on virtualbox-host-dkms. Nonetheless, this package takes care of this, to reduce the build time in a chroot; If you prefer build your package with makepkg, I suggest you to use "makepkg -d" instead of creating your own package. That's damn faster. eworm's package is a fork (or duplicate) which bypass the virtualbox official way for installing external modules., by dropping somes files directly inside the virtualobx directory.

hybrid commented on 2014-07-24 06:54 (UTC)

Honestly I fail to see the need of virtualbox-host-dkms makedeps too. Correct me if I'm wrong/missing something, but you said you included it only so virtualbox-host-modules won't be triggered to pull the arch stock kernel. But why would this package need to take care of this? Basically this package here tries to "fix" dependencies higher up in the dependency tree. And that part doesn't make a lot of sense to me. Plus this is only the case if someone is using a non-stock kernel to which there is no adapted virtualbox-host-modules package but in that case they wouldn't be able to install virtualbox in the first place. Even if there are such cases that require that "virtualbox-host-dkms trick" I (again, just my personal opinion, I may be wrong) would deem that a special and rare case that should better be treated in a special package, for example virtualbox-ext-oracle-dkms. I was using this package for a long time but this in my (and I assume by far most scenarios) pointless dependency that's always pulled by this package led me to create my own pkgbuild maybe like two years ago when this -dkms shennanigans started. Just set up a new computer here and accidentally installed this package and was reminded of this issue here. I see that this package here and eworm's are coexisting for a little over a year now. Maybe this package here should be renamed to something like virtualbox-ext-oracle-dkms?

seblu commented on 2014-03-27 15:53 (UTC)

build in a chroot is not an atypical way of building a package. All released packages should be build inside a chroot. Learn to use devtools to do accordingly. Btw it's a makedepends, not a depends of the package. You can still use makepkg -d, if you want to avoid this deps during build.

dhaines commented on 2014-03-27 15:01 (UTC)

If it's there for a particular atypical setup (building in chroot), should it be there in the AUR for general consumption? That seems to be adding unnecessary packages to a lot of people's machines when very few of them actually need them.

seblu commented on 2014-03-27 14:21 (UTC)

$ wget -qO- ''|md5sum 25b70fa71d9320e2836b9be138457ee0 - Good from my home. Bad from my office. There is probably a replication issue between Oracle mirrors. I already see that in the past. The md5sum is correct. @djhaines: Right, it doesn't require it to build. But the virtualbox deps pull virtualbox-host-modules, which pull linux kernel. Putting this makedeps deps avoid a kernel to be fetched when I build the binary package in a chroot.

dhaines commented on 2014-03-27 13:47 (UTC)

I'm pretty sure that this shouldn't require virtualbox-host-dkms to build. I note that the PKGBUILD states "use virtualbox-host-dkms dep to avoid to pull linux kernel in chroot", but that (A) doesn't make a lot of sense and (B) doesn't seem to be true, as I've commented out the makedepends and it still seems to work without any issues.

cyrxi commented on 2014-03-27 13:44 (UTC)

The md5sum on the VirtualBox website/in the PKGBUILD *is* correct, but it's for Oracle_VM_VirtualBox_Extension_Pack-4.3.10-93012.vbox-extpack (i.e. the last minute update) and not the Oracle_VM_VirtualBox_Extension_Pack-4.3.10.vbox-extpack version pulled down by the PKGBUILD.

vinadoros commented on 2014-03-27 12:40 (UTC)

Thanks MonkeyWrench32, your md5sum does work properly for installing the 4.3.10 extensions. I'm not sure why Virtualbox's website has posted the wrong md5sum...

venom commented on 2014-03-27 09:54 (UTC)

Got the same error like MonkeyWrench32. Changing the md5sum worked for me too

seblu commented on 2014-03-27 09:27 (UTC)

MonkeyWrench32 commented on 2014-03-27 04:12 (UTC)

md5sum failed. Here is the correct one: ec0a3d2f9ea4a6f7041586bd21520a6a

seblu commented on 2014-02-26 21:09 (UTC)

You really should read the PKGBUILD file before makepkg it, AUR is wild place.

benjarobin commented on 2014-02-26 20:50 (UTC)

Why virtualbox-host-dkms is into makedepends. To build the package you don't need this package...

Scimmia commented on 2014-01-18 14:10 (UTC)

That makes it a pain to upgrade, you would have to uninstall and reinstall this package every time vbox is upgraded instead of just upgrading it when needed.

alerque commented on 2014-01-18 07:31 (UTC)

Please do add the exact version dependency so that upgrades of the main package prompt a conflict that we then know to go fix. Thanks. depends=("virtualbox=${pkgver}")

swiftgeek commented on 2013-10-21 18:40 (UTC)

But do not bump pkgrel :D

stmc commented on 2013-10-21 18:29 (UTC)

add to pkgbuild: depends=("virtualbox=${pkgver}")

kullfar commented on 2013-10-21 05:16 (UTC)

BTW, it can be fixed by explicit version in "Dependencies", can not it be?

Scimmia commented on 2013-10-21 02:13 (UTC)

@ngoonee, that's because this package was update to 4.3 while virtualbox in the repos is still 4.2.18. You shouldn't update this package until virtualbox itself is updated.

ngoonee commented on 2013-10-21 02:11 (UTC)

Get this error from post_install. Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.3.0.vbox-extpack" VBoxManage: error: VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=0000000000000000 ErrInfo='Helper version mismatch - expected 0x10001 got 0x10000' VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ExtPackManager, interface IExtPackManager VBoxManage: error: Context: "int handleExtPack(HandlerArg*)" at line 1126 of file VBoxManageMisc.cpp

FredBezies commented on 2013-10-15 16:54 (UTC)

Will be soon out of date, as VirtualBox 4.3.0 was released on 15 october :

archlinuxomane commented on 2013-09-10 08:54 (UTC)

@reed1 What's your virtualbox version? Had the same error message, reason was that I had updated the ext-pack to 2.18 but virtualbox was still 2.16.

eworm commented on 2013-09-10 07:28 (UTC)

I do not get this, so I suppose you need to reboot or shutdown guests, reload the new host modules and then start the guests.

reed1 commented on 2013-09-10 01:33 (UTC)

@eworm When I fired up a VM with USB Controller enabled, if I disable it the error disappear. It's not like that before, probably after I upgraded the kernel. I reinstalled virtualbox and this aur package, nothing works.. :(, I haven't restared my machine tho, can't restart now ~ ❯ VBoxManage list extpacks Extension Packs: 1 Pack no. 0: Oracle VM VirtualBox Extension Pack Version: 4.2.18 Revision: 88780 Edition: Description: USB 2.0 Host Controller, VirtualBox RDP, PXE ROM with E1000 support. VRDE Module: VBoxVRDP Usable: true Why unusable:

eworm commented on 2013-09-09 11:19 (UTC)

@reed1: You get this when doing what? % VBoxManage list extpacks Extension Packs: 1 Pack no. 0: Oracle VM VirtualBox Extension Pack Version: 4.2.18 Revision: 88780 Edition: Description: USB 2.0 Host Controller, VirtualBox RDP, PXE ROM with E100 support. VRDE Module: VBoxVRDP Usable: true Why unusable:

reed1 commented on 2013-09-09 10:52 (UTC)

I got verr_pdm_devhlpr3_version_mismatch :(

eworm commented on 2013-05-28 10:55 (UTC)

Sure this may end up in conflicts. But that is still broken design by Virtualbox. Installing the files to /var/lib is not the right way either. Quoting the Filesystem Hierarchy Standard [0] about /var: > /var contains variable data files. This includes spool directories and files, > administrative and logging data, and transient and temporary files." and about /var/lib: > This hierarchy holds state information pertaining to an application or the > system. State information is data that programs modify while they run, and > that pertains to one specific host. I think the right way would be to make Virtualbox install files to ~/.VirtualBox/ExtensionPacks, while still accepting packages installed globally by pacman to /usr/lib/virtualbox/ExtensionPacks. [0]

seblu commented on 2013-05-28 10:41 (UTC)

@eworm: Firefox is a good example. Packages providing extensions are installed globally (in /usr) and users one are installed in there home. Virtualbox install user extensions in /usr too, asking for super cow power and bypassing pacman. So, removing and readding this extensions by Vbox GUI will create conflict with next vbox package update. Nothing new. I started looking to define a new vbox extension path outside /usr (e.g: /var/lib/) to avoid all conflicts with pacman. w&s. $ find /var/abs -name *install|wc -l 1506

techlive commented on 2013-05-28 08:27 (UTC)

I second @eworm, system-wide files should be managed by pacman, this is how Arch works.

eworm commented on 2013-05-24 06:33 (UTC)

I do not agree. I think my example is relevant and valid. Take whatever package you like, usually there is no install script run by pacman after general package installation. Ok, back to firefox, it's a good example: A user can install extension. These extensions are installed on a per user basis, in user's home directory. I am fine with that. Virtualbox extensions however are installed globally in a world readable directory in /usr. Thus I think the files should be managed by pacman. About the different package... Well, I tried to contribute my changes to your packages. But it's all about choice: We do have a different point of view and I made it my way. Users now may choose what they prefer.

seblu commented on 2013-05-23 21:58 (UTC)

The provided as installer by firefox have the same purpose as pacman. Here we speak of a GUI provided by Virtualbox, after it's installation, to hot add (official or not) extensions into /usr or remove it without talking to pacman. Your example is not relevant. I love the idea to have all files in /usr managed by pacman, so your argument is challenging. But allowing users to re-add/add/remove extensions by the virtualbox GUI is convenient and not in our hands. I've the same logic in Your prompt pushing of a different package is _not_ smart and don't help to improve things for both packages.

eworm commented on 2013-05-23 20:02 (UTC)

As Sébastien does not like the idea... I've uploaded my own package to AUR:

eworm commented on 2013-05-23 19:40 (UTC)

I see it does. But that is not really a good reason to rely on that mechanism, no? Or did you download firefox.tar.gz and ran some crappy script? pacman should know about every single file installed to /usr, everything else is just broken.

seblu commented on 2013-05-23 19:35 (UTC)

Yes Christian, it was already discussed in the past. In short, vbox use its own install/removal mechanism for extensions.

eworm commented on 2013-05-23 19:29 (UTC)

Any good reason why this package just owns a binary blob and copies some files outside package management while installing? I have a new PKGBUILD that handles that the right way:

seblu commented on 2013-03-10 18:04 (UTC)

Look in previous comments.

graysky commented on 2013-03-10 16:45 (UTC)

virtualbox-ext-oracle.install directs pacman to run the following on install: VBoxManage extpack install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-${1%%-*}.vbox-extpack" >/dev/null In doing so, modifications outside of the package itself are done to the filesystem. Is there a way to have VBoxManage redirect the output of that command to the $pkgdir/right/path thus keeping these files owned by the package?

lpapp commented on 2013-02-17 14:29 (UTC)

@Marcel_K: then perhaps someone should check.

seblu commented on 2013-01-27 16:20 (UTC)

When reinstall, it remove old extpack before install again. So I don't see why you have an issue.

rafaelff commented on 2013-01-27 02:51 (UTC)

In the install file, please modify the post_upgrade() adding the '--replace' flag to VBoxManage extpack install, otherwise it might failt to install the extension in VBox. Message: "VBoxManage: error: Extension pack 'Oracle VM VirtualBox Extension Pack' is already installed. In case of a reinstallation, please uninstall it first" Steps to reproduce: - installed this package - reinstalled (as it didn't show up before in VBox) - removed '> /dev/null' to get error message.

Marcel_K commented on 2012-11-15 13:11 (UTC)

You may not redistribute this binary, as you can read in several earlier comments.

lpapp commented on 2012-11-15 12:46 (UTC)

Why is this core package not in the community repository? This is essential for proper USB working!

spider-mario commented on 2012-09-23 14:10 (UTC)

Oh, OK. Sorry.

commented on 2012-09-22 07:58 (UTC)

@spider-mario: It's not about AUR, it's about [community].

spider-mario commented on 2012-09-22 07:47 (UTC)

I think it’s OK. The binaries are not redistributed, the PKGBUILD just automates the download from Oracle’s website, so they can still “keep track of how many people are downloading these binaries”.

commented on 2012-09-18 14:15 (UTC)

@muflone: Please, read the comments, at least the ones from yesterday.

muflone commented on 2012-09-18 13:45 (UTC)

Please update this package to the version 4.2.0

felixonmars commented on 2012-09-17 17:23 (UTC)

Oh, sorry to hear that :(

seblu commented on 2012-09-17 17:21 (UTC) Look into section 7. It's dead.

seblu commented on 2012-09-17 17:15 (UTC)

We must ask permission to Oracle. I will look into this.

felixonmars commented on 2012-09-17 17:07 (UTC)

Is there any chance that this package grants by InnoTek Systemberatung GmbH to re-distribute from binary?

seblu commented on 2012-09-17 17:00 (UTC)

I will update this package when I will move virtualbox 4.2 out of testing.

graysky commented on 2012-09-17 16:58 (UTC)

Yeah, the official package which !=4.2 when I posted that.

felixonmars commented on 2012-09-17 16:47 (UTC)

Arch package is out.

seblu commented on 2012-09-17 16:25 (UTC)

He means official arch package!

allspark commented on 2012-09-17 15:06 (UTC)

what 'ARCH' packages do you mean? and virtualbox-bin are version 4.2

graysky commented on 2012-09-17 07:23 (UTC)

Not out-of-date until the ARCH packages for 4.2 are released.

commented on 2012-09-14 13:14 (UTC) New PKGBUILD.

mrohnstock commented on 2012-08-07 09:23 (UTC)

ok, found my issue... forget it.

mrohnstock commented on 2012-08-07 09:21 (UTC)

build works, but can't install the package: 0%... Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.1.18.vbox-extpack": The installer failed with exit code 1: VBoxExtPackHelperApp: error: The owner is not root: '/usr/lib'

seblu commented on 2012-04-04 08:28 (UTC)

@la_poigne: this let me detect new version and push a pkg upgrade in case.

la_poigne commented on 2012-04-03 16:59 (UTC)

The build version changed. There are a symlink on the download page, so you don't need to specify the build version on the pkgbuild.

seblu commented on 2012-04-03 15:32 (UTC)

kfgz commented on 2012-04-03 15:20 (UTC)

LC_ALL=C wget -O /dev/null "${source[0]}" --2012-04-03 17:19:56-- Resolving Connecting to||:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: [following] --2012-04-03 17:19:57-- Resolving, Connecting to||:80... connected. HTTP request sent, awaiting response... 404 Not Found 2012-04-03 17:19:57 ERROR 404: Not Found.

seblu commented on 2012-04-03 15:03 (UTC)

$ source PKGBUILD $ wget -O /dev/null "${source[0]}" --2012-04-03 17:02:33-- Resolving Connecting to||:80... connected. HTTP request sent, awaiting response... 302 Moved Temporarily Location: [following] --2012-04-03 17:02:33-- Resolving, Connecting to||:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10062879 (9,6M) [application/x-virtualbox-vbox-extpack] Saving to: `/dev/null' 100%[==========================================================================================================================================================================>] 10 062 879 19,6M/s in 0,5s 2012-04-03 17:02:34 (19,6 MB/s) - `/dev/null' saved [10062879/10062879]

kfgz commented on 2012-04-03 14:25 (UTC)

Download link is broken.

commented on 2012-02-27 02:27 (UTC)

@DasFox: > is this really necessary? Yes, it is, and it is common in Linux and Unix. This way it can be used by every user. See the file permissions which are 644 (rw-r--r--). Every package gets installed by pacman this way. The home directory (~) is only meant for the user's own files like documents, music files, etc., and configurations. Btw., it's not installed under /root, but under / (also called "root directory"). > I forgot to mention at the end of the install in the terminal there should be a message telling the end-user where the extension is installed. Totally not necessary, since this is not done with any other package and not common. If you want to know, what's installed where, run pacman -Ql <package name>. I'd suggest reading and learning a bit more about the Linux basics, particularly about the file permissions, the Filesystem Hierarchy Standard (FHS) and package managers. The Wiki and the Forums are a good start, or even better some other websites and books about Linux.

commented on 2012-02-27 02:01 (UTC)

I forgot to mention at the end of the install in the terminal there should be a message telling the end-user where the extension is installed. I was not aware of what /path it had been installed to, then we have to go digging in /var/lib/pacman/local to see where it's at in the pkg directory files... THANKS

commented on 2012-02-27 01:58 (UTC)

Hi, As an end-user you can download the extenstion pack from Oracle, place it in your $HOME and install this, but since this is being installed into /usr/share it is owned by root and you need to run Virtualbox as root to install this, is this really necessary? I'm not sure if all of this is common on other distros with it in a /root path owned by root, needing to be installed by root... Also is /usr/share really the correct path for this? If it's ok to place it in this path owned by root then it should at least be given 'wheel' permissions so a user in group wheel can access it as a user not root? THANKS

commented on 2011-11-06 18:22 (UTC)

@mikers: How many times do I need to explain this? No versioned dependencies in AUR! Not even in makedepends! Keep your system regularly up-to-date and you won't have any problems. Otherwise edit the PKGBUILD locally by yourself. And makedepends are not needed here, because there doesn't need to be built anything. Makedepends is for packages which are needed to build (compile) a package, but not for running this software, and which can be uninstalled after the package is built. This is not the case here. And if it was the case, what sense does it make to build a package with a newer version than the installed one? It makes no sense, because the package could then easily be broken. And usually there is a reason why a package is not moved from [testing] to the stable repos. @seblu: It would be nice if you would follow the stable repos and not [testing] resp. [community-testing].

chungy commented on 2011-11-06 17:17 (UTC)

Hey I know this is a rather discussed topic already, but what if this package had a makedepends=("virtualbox-$pkgver")? As the current version of VirtualBox has still not left testing in the main repositories, this will at least stop automated AUR wrappers from building this package, but it will not prevent upgrading either virtualbox or virtualbox-ext-oracle.

trusktr commented on 2011-10-14 12:09 (UTC)

I don't really know about that, but you seem to have a good point cyberpatrol.

commented on 2011-07-20 10:25 (UTC)

No, please, not again a versioned dependency! This just causes big trouble with updating the system like discussed very often. @monson: Arch Linux is a rolling release distro which has only one (the newest) version of each package in the repos. So it can be assumed that everybody has the newest version installed. Keep your system up-to-date and regularly run `pacman -Syu` or even better `yaourt -Syua` and you won't have any problems with that. With versioned dependencies you regularly need to manually uninstall this package to be able to run a `pacman -Syu` and manuall reinstall it afterwards.

monson commented on 2011-07-20 04:15 (UTC)

To be convenient to most people, I think it's better to modify to depends=("virtualbox=$pkgver"), as the "virtualbox_bin" PKGBUILD already provides=("virtualbox=${pkgver}").

mukhametshin commented on 2011-07-19 23:23 (UTC)

qs9rx: Now virtualbox_bin is already in repo. Just try to update virtualbox_bin first, and this package hereafter, it should work. However I'm sure seblu will fix it soon.

seblu commented on 2011-07-19 18:35 (UTC)

yes it did not check. You can find why in previous comment.

qs9rx commented on 2011-07-19 14:42 (UTC)

Proceed with installation? [Y/n] (1/1) checking package integrity [#########################################################] 100% (1/1) checking for file conflicts [#########################################################] 100% 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (1/1) upgrading virtualbox-ext-oracle [#########################################################] 100% 0%... Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.1.0.vbox-extpack": VBoxExtPackRegister returned VERR_VERSION_MISMATCH, pReg=00000000 ErrInfo='VirtualBox version mismatch - expected 4.1 got 4.0' error: command failed to execute correctly --------------------------------------------- pacman -Qs gives me local/virtualbox 4.0.12-1 local/virtualbox-additions 4.0.12-1 local/virtualbox-ext-oracle 4.1.0-1 So I guess it did not check for the needed vbox version which is not in the repositories yet (just released today).

Det commented on 2011-06-25 20:20 (UTC)

By the way, what cyberpatrol said about all the files in "$startdir" automatically being symlinked into "$srcdir" was not entirely accurate. Only the ones listed in the source=() section are (thus passing the integrity check first).

seblu commented on 2011-06-25 12:22 (UTC)

We are on the same wavelength. I was not sure about deprecation (will be removed) of startdir even though I had no doubt of the fact that it was necessary to use ${src/pkg}dir. it may seem paradoxical but not. I proposed a patch on pacman-dev, to update man page of PKGBUILD.

Det commented on 2011-06-25 03:27 (UTC)

I'm not quite picking up what you're saying but what I _think_ you mean is that you checked the pacman/makepkg source code and there was a cd command to 'src', am I right? You also said that "$startdir" was being used there (even though it's otherwise deprecated), which would makes this all really simple and easy, since: "$startdir/src" = "$srcdir" (and "$startdir/pkg" = "$pkgdir"). But again, if you meant something else then please do enlighten me.

seblu commented on 2011-06-25 01:02 (UTC)

@det: i test this when i've done my first package, but before your suggestion i never take time to read makepkg source how it was done and if my conclusions was correct. Proof against the experience...

Det commented on 2011-06-25 00:30 (UTC)

And a simple 'pwd' in the beginning of a(ny) function is a simple way to find out the default build directory (even package() functions are executed from "$srcdir").

seblu commented on 2011-06-24 20:41 (UTC)

ok thx.

commented on 2011-06-24 20:24 (UTC)

$startdir is deprecated. In case of doubt the wiki and every developer who has said that several times on the mailing lists are right. And, btw., every file in $startdir is symlinked to $srcdir. So there's no need to use $startdir, no matter if it's deprecated or not.

seblu commented on 2011-06-24 19:38 (UTC)

I will clean this in next release. About deprecation of startdir, this is not written in man page of PKGBUILD, but it's written on the wiki (who is right?). In source code, startdir is used, so i don't think it's deprecated! But here, I agree it's unnecessary. About build()/package()/whatever() functions, i don't find any informations in manual or wiki about where it should when function is run. In source code, there is a cd in src before every function call. Thanks for the suggestions!

Det commented on 2011-06-24 19:07 (UTC)

Great, yet simple package. Just one suggestion. You don't need to define "$srcdir" or "$startdir" (deprecated) in the beginning of the build()/package()/whatever() function since that's where the commands are already being executed in ("$srcdir"). After that you don't need the quotes there either.

adlaiff6 commented on 2011-06-17 00:28 (UTC)

Yes, I still get those. someonerandom: do you have /usr on a separate partition?

seblu commented on 2011-05-20 09:09 (UTC)

do you have those messages if you run as root: VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack" VBoxManage extpack install /usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.0.8.vbox-extpack

someonerandom commented on 2011-05-20 07:13 (UTC)

@adlaiff6: same for me!

adlaiff6 commented on 2011-05-17 07:39 (UTC)

resolving dependencies... looking for inter-conflicts... Targets (1): virtualbox-ext-oracle-4.0.8-1 Total Download Size: 0.00 MB Total Installed Size: 3.39 MB Proceed with installation? [Y/n] (1/1) checking package integrity [########################################] 100% (1/1) checking for file conflicts [########################################] 100% 0%... Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to uninstall "Oracle VM VirtualBox Extension Pack": The installer failed with exit code 1: VBoxExtPackHelperApp: error: Failed to rename the extension pack directory: VERR_NOT_SAME_DEVICE VBoxManage: error: rcExit=1 error: command failed to execute correctly (1/1) upgrading virtualbox-ext-oracle [########################################] 100% 0%... Progress state: NS_ERROR_FAILURE VBoxManage: error: Failed to install "/usr/share/virtualbox/extensions/Oracle_VM_VirtualBox_Extension_Pack-4.0.8.vbox-extpack": Extension pack 'Oracle VM VirtualBox Extension Pack' is already installed. In case of a reinstallation, please uninstall it first error: command failed to execute correctly

uberGeek commented on 2011-03-23 01:49 (UTC)

@seblu: you're welcome!

seblu commented on 2011-02-17 20:07 (UTC)

@cyberpatrol: thanks!

commented on 2011-02-17 19:38 (UTC)

@seblu: It is out-of-date. Version 4.0.4 is out.

seblu commented on 2011-02-17 19:24 (UTC)

@uberGeek: please don't mark this package out-of-date until it's not out-of-date!

emphire commented on 2011-02-07 16:08 (UTC)

@vigilandy: If you would like to change the dependencies on your own machine, try customizepkg-new. It automates changes to packages and integrates with yaourt.

vigilandy commented on 2011-02-07 11:55 (UTC)

@cyberpatrol: I see, thanks for the clarification.

commented on 2011-02-07 11:17 (UTC)

@vigilandy: Qt should not be a dependency of this package, because this package depends on virtualbox from [community] and qt is already an optional dependency of virtualbox. It's an optdepend, because it's only necessary if the VirtualBox GUI is used.

vigilandy commented on 2011-02-07 05:45 (UTC)

I was getting the following error when running: "VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/",) failed: cannot open shared object file: No such file or directory" I resolved it by installing the qt package. Shouldn't this be a dependency?

alphazo commented on 2011-01-30 22:02 (UTC)

For info, it crashes the same way with VirtualBox 4.0.2-4 from [Community-Testing].

seblu commented on 2011-01-26 18:02 (UTC)

@alphazo: i've a blue sceen with a ehci issue. i will add some comment on you br

seblu commented on 2011-01-26 15:01 (UTC)

you should see something like this with lsusb. [root@archibal ~]# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet

alphazo commented on 2011-01-26 07:26 (UTC)

But what if my USB HD webcam only works in EHCI mode. How can I check that EHCI is running fine? VBox log only mentions EHCI one time at the beginning. 00:00:02.380 [/PDM/Devices/VBoxEhci/] (level 3) 00:00:02.380 Path <string> = "/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/" (cb=97) 00:00:02.380 R0SearchPath <string> = "/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64" (cb=83) 00:00:02.380 RCSearchPath <string> = "/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64" (cb=83) 00:00:02.380 00:00:02.380 [/PDM/Drivers/] (level 2) When I connect a USB flash drive, VBox log says: 00:00:31.944 VUSB: attached '00007f1a34046ad0[proxy 090c:1000]' to port 1 00:00:31.948 OHCI: USB Operational 00:00:41.907 PCNet#0: Init: ss32=1 GCRDRA=0x0669d420[64] GCTDRA=0x0669d020[64] 00:00:42.945 PIT: mode=2 count=0x4ad (1197) - 996.81 Hz (ch=0) 00:01:09.988 Switching Gl mode on 00:01:10.024 Switching Gl mode off 00:01:10.385 Switching Gl mode on 00:01:10.422 Switching Gl mode off 00:05:53.113 USB: Successfully reset device pProxyDev=00007f1a34046ad0[proxy 090c:1000] And when I connect the webcam I get: 00:05:53.880 OHCI: USB Suspended 00:06:17.830 VUSB: attached '00007f1a35ac3f60[proxy 06f8:300b]' to port 1 00:06:17.836 OHCI: USB Operational None of them say EHCI. Is this normal?

seblu commented on 2011-01-25 23:45 (UTC)

module add only USB 2.0 (EHCI). without you have only UHCI and OHCI. If you vbox crash without the module, it' seems to be a bug relative to virtuabox himself and not only its extension.

alphazo commented on 2011-01-25 23:20 (UTC)

It crashes the same way when I remove this package. Now webcam is expected to run at USB High-Speed. I noticed that when I install the virtualbox-ext-oracle I do see it under Extension but I no longer see EHCI settings under USB. Is this normal? How do I check that ext-oracle is fully working? BTW, I run 2.6.37 from [Testing]

seblu commented on 2011-01-25 22:30 (UTC)

VirtualBox crash if you remove this package?

alphazo commented on 2011-01-25 22:23 (UTC)

Don't know if my bug is related to this package but VirtualBox crashes badly when connecting USB webcams. See my report on Oracle bug tracker:

seblu commented on 2011-01-22 15:44 (UTC)

@cyberpatrol: currently i follow virtualbox_bin.

commented on 2011-01-22 15:35 (UTC)

@seblu: Thanks. But, please, follow the stable virtualbox in [community], not in [community-testing], if it goes there first. @Musikolo: pacman -Syu does the job without the need of a versioned dependency in an AUR package.

Musikolo commented on 2011-01-22 09:37 (UTC)

@seblu: I don't know whether it will help to find a hybrid solution, but wouldn't be enough by doing this? depends=("virtualbox" >= 4) Please, let me know if I'm wrong, but with this, the problem of upgrading with pacman -Syu should be fix and, also, pleople having virtualbox-3.x will be force to upgrade to 4.x. Best regards!

seblu commented on 2011-01-22 01:48 (UTC)

@cyberpatrol, lrm: you're right. i will fix.

lrm commented on 2011-01-22 01:29 (UTC)

I'm with cyberpatrol. The versioned dependency just causes trouble and doesn't save anyone from anything. If someone updates their aur without doing pacman -Syu first then they deserve what they get, IMO :).

commented on 2011-01-21 22:49 (UTC)

@seblu: Your impression is wrong. But I know the reason for this updating issue. I explained it quite detailed, and I've tested it, at least with the =. I don't know, yet, if I can downgrade both packages and test it again. But I don't think that this is necessary, if you read Mektub's and shivmeister's latest comments. Shivmeister is, btw., an Arch Linux developer. So I guess you can believe him, if you don't believe me. Mektub has already tried it with >= and he had to remove the version number, because it didn't work for him with >=. And shivmeister explained to you why versioned dependencies are sometimes needed and why they should be avoided otherwise. And you just need to think logical. Then you will see why also >= can't work. And keep in mind the issue is not updating only this package with yaourt. The issue is a complete system update with pacman -Syu or clyde -Syua which is simply not possible. These are facts and not my ego. And another point: If you really want to become a TU then you should know that.

seblu commented on 2011-01-21 22:01 (UTC)

@cyberpatrol: long time ago? This package have 3 weeks... Please be serious. I don't test every cases. I invite you to try and tell me if their is issues. I have the impression that you want us to do it your way and not otherwise.

commented on 2011-01-21 21:31 (UTC)

@seblu: Did you test it with pacman -Syu when virtualbox in [community] was updated, too? Just updating virtualbox-ext-oracle with yaourt could bring wrong results, which don't help with this issue. This issue has to do with circular dependencies. Btw., it's long ago that virtualbox was updated from 3 to 4 and this update is/was done by pacman -Syu, too. So there's definitely no need anymore for this versioned dependency. It was infact not needed before to get a correct transition from 3 to 4, just because of the rolling release and because there's only one version of a package in the repos. It can be expected from Arch users to update their systems regularly and not only update one single package from AUR. So it's definitely the best to remove these versioned dependency, and it's btw. Arch plolicy. Believe me.

seblu commented on 2011-01-21 20:59 (UTC)

so, i make a test with a fake 4.0.3 version of virtualbox... rwolf ~/scm/archrep/virtualbox_bin $ yaourt -U virtualbox_bin-4.0.3-1-x86_64.pkg.tar.xz resolving dependencies... looking for inter-conflicts... Targets (1): virtualbox_bin-4.0.3-1 Total Download Size: 0,00 MB Total Installed Size: 129,80 MB Proceed with installation? [Y/n] checking package integrity... (1/1) checking for file conflicts [########################################################################################] 100% (1/1) upgrading virtualbox_bin [########################################################################################] 100% :: Unloading VirtualBox kernel modules [BUSY] [DONE] :: Recompiling VirtualBox kernel modules [BUSY] [DONE] :: Reloading VirtualBox kernel modules [BUSY] [DONE]

seblu commented on 2011-01-21 20:55 (UTC)

ok i will test

Mektub commented on 2011-01-21 20:41 (UTC)

@seblu:>= does not work. Thats the line I changed to be able to update.

seblu commented on 2011-01-21 19:07 (UTC)

@cyberpatrol: firstly i make this version condition to avoid users from 3.x to setup this extentions before update in virtualbox 4.0, because install script needs a virtualbox version >= 4 ! So a good versioning is at least >=4 not without any version condition. Regarding release rolling schema, you're right, we have only one version at the same time in repository. But we also have to manage correclty transition between our version. Your initial request was about that. So, have one package at a time, is not synonymous with "forget everything about the past". Why do you want to change this dependency? It's free and without pain and escape someone with version 3.x to mistaken using this package? I think it's wiser to keep it for now. About >=, i hope to not be false. In next virtualbox update, pacman allow setup of this new version, because there is no conflict. virtualbox-ext-oracle need a version more recent than itself. Same things for this package update. Time is a chatterbox who speak without being questioned. W&S

commented on 2011-01-21 18:48 (UTC)

@seblu: Sorry, I must have missed this change, but I don't think that >= works, because the previous installed version is <=. So >= has at least theoretically the same effect than =. Why don't you just remove this? Arch Linux is a rolling release distro with only one version of a package in the repos. I repeat myself.

seblu commented on 2011-01-21 18:36 (UTC)

@cyberpatrol: As you can see, the first time you speek about this dependency issue, i updated the package and changing = to >=. Reading later comments, this decision seems to be fair and take in consideration the both point of view. This is why i left >=. So what's wrong with >=? On new version of virtualbox package, you will be able to update virtualbox without removing previous virtualbox-ext-oracle. On new version of virtualbox-ext-oracle, you need to have new virtualbox version setup before (what we want).

commented on 2011-01-21 18:18 (UTC)

@seblu: The versioned dependency: depends=("virtualbox>=$pkgver") => depends=("virtualbox")

seblu commented on 2011-01-21 16:19 (UTC)

@mektub: Which changement? What's wrong?

Mektub commented on 2011-01-21 14:20 (UTC)

I had to change PKGBUILD to be able to update my system. I don't know if I did it the right way. Someone more knowledgeable should take a look at it, something is wrong with the packaging of virtualbox-ext-oracle.

lrm commented on 2011-01-20 18:56 (UTC)

Is there a specific reason I have to uninstall this package to update my system? I'm no expert, but that is very annoying. If there is a good reason then so be it, but I'd love to know what it is. Thanks!

schivmeister commented on 2011-01-20 13:20 (UTC)

And why in the world does this have a versioned dependency again? Please get rid of that. It does not make any sense and is _wrong_, unless someone shows us why. Arch is rolling-release and there is only one version of a package at a time. We use versioned dependencies for people upgrading from CD installations that may be older than supported.

juanmah commented on 2011-01-20 06:48 (UTC)

I endorse what @cyberpatrol says, and I think that a solution shall to be found, because the current behaviour of this package is annoying. But I don't think that this is a versioning problem, because of my case is that I have virtualbox_bin, and not virtualbox, and there is a conflict. A fast check at suggest that we have to use virtualbox in community, and if you want extras we have to install this package. Am I right?, because I am not sure of this. If i is true, it is necessary to INFORM users what they have to do, because the normal procedure of pacman is broken. And this is not because users do not know what to do, but to save time.

commented on 2011-01-19 22:59 (UTC)

I do comprehend the most obvious. I have explained it.

commented on 2011-01-19 22:52 (UTC)

I will not waste any more of my precious time, if you can't comprehend the most obvious.

commented on 2011-01-19 20:33 (UTC)

@wantilles: But this doesn't mean, that these versioned dependencies are necessary in this case. The most important reason why these versioned dependencies need urgently be removed from this package is simply because the system can't be updated by pacman -Syu. This is reason enough to remove them. It's really not nice to always force the user to first uninstall this package and then, after the system update, reinstall this package again. The other reason is simply because if this package is updated every user should also update virtualbox. You can expect that every user, at least every Arch user, knows that he has to do so. The best is updating the whole system regularly and not only a single package. Updating a single package can always break something. See Gentoo's revdep-rebuild, which should be run after every update. And because there's only one version of a package in the repos it simply isn't necessary to have versioned dependencies in this package. It's simply not necessary. If someone updates only this package without using his eyes and brain then it's his own fault and not a wrong dependency. It's different on Gentoo where several older versions are kept in the portage tree and where a new package version can be put into a different slot. In this case versioned dependencies are useful and necessary, but not on Arch Linux.

commented on 2011-01-19 19:32 (UTC)

Version dependencies are discouraged. That does not mean that if they are NECESSARY, you should not use them. And yes, each virtualbox extension REQUIRES a base virtualbox base package OF THE EXACT SAME VERSION - NOT something OLDER.

commented on 2011-01-19 19:30 (UTC)

I never said that it does not happen. I said that it is the wrong reason to change correct deps -> to wrong deps -> in a binary distro like Arch. If we were a source distro, like Gentoo, then yes, it would be a correct reason to do something about this.

commented on 2011-01-19 17:26 (UTC)

@wantilles: I am right, because I tested it. pacman -Syu doesn't work and pacman -Syud is the worst thing you can do if it's possible anyway. And versioned dependencies are discouraged anyway. Arch Linux is not Gentoo where you can put different versions into different slots. Arch Linux has only one version of one package in the repos. And if a package is updated then it can be assumed that the dependencies are updated, too. So you can assume that everybody has the latest versions installed. If someone only updates virtualbox-ext-oracle without updating virtualbox, he's on his own.

commented on 2011-01-19 17:16 (UTC)

Cyberpatrol is wrong. You never change correct dependencies, to wrong ones, because the package has not been built yet. You can built the package with -d switch.

commented on 2011-01-19 06:01 (UTC)

@cyberpatrol:you are right. i meet the problem too. have to delete virtualbox-ext-oracle and then packer -Syu.

commented on 2011-01-19 03:03 (UTC)

It would be nice if you would change the line depends=("virtualbox=$pkgver") to depends=("virtualbox") It's because the system can't be updated neither with clyde -Syua nor with pacman -Syu, because it always says that virtualbox-ext-oracle requires virtualbox=4.0.0 even if the latest version in the repos is 4.0.2. And Arch Linux is a rolling release system with only one, the latest, version in the repos. So it can be assumed, that everybody regularly runs a full system update and has the latest version installed. If not, it's the user's problem. The problem is that virtualbox can't be updated from 4.0.0 to 4.0.2 because virtualbox-ext-oracle 4.0.0 is installed and requires virtualbox 4.0.0. So pacman can't update virtualbox and can't resolve the dependency. And virtualbox-ext-oracle can't be updated from 4.0.0 to 4.0.2 because virtualbox 4.0.0 is still installed and can't be updated to 4.0.2. This problem might not appear if virtualbox-ext-oracle would be in [extra], too.

commented on 2011-01-18 14:09 (UTC)

I agree seblu, it's all very strange. That line in my fstab is from about three years ago, so I don't doubt that it's outdated now. But none of the threads in the vbox forums were of any use in solving the greyed out usb devices problem. Their mods just repeat to install the extension pack and make user a member of the vboxusers group, reboot and then usb should work. It's only when checking the groups that I noticed the ID change. Anyway, thank you for maintaining the virtualbox packages. They are very useful to me and I would be lost without them.

seblu commented on 2011-01-18 10:56 (UTC)

strange. i believe new virtualbox use /dev/bus/usb instead of /proc/bus/usb.

commented on 2011-01-18 08:14 (UTC)

I changed from AUR package virtualbox_bin to the community virtualbox and installed this package too. My usb devices were all greyed out after the change. The answer was to make myself a member of the vboxusers group again & to alter a line my fstab (old vbox had its group as 110, new verson as devgid=108) none /proc/bus/usb usbfs devgid=108,devmode=0664 0 0 All worked fine on reboot.

seblu commented on 2011-01-08 20:08 (UTC)

Please also note, there is an issue with Qt librairies and community packages. virtualbox_bin is not affected. So currently, virtualbox_bin is a workaround for peoples which are affected by this issue.

seblu commented on 2011-01-08 20:06 (UTC)

@cyberpatrol: I're wrong. I maintain the two packages. Believe me.

commented on 2011-01-08 19:39 (UTC)

@seblu: I haven't read jarryson's PKGBUILD yet, but virtualbox_ext_oracle has nothing to do with virtualbox_bin, because these extensions are already included in virtualbox_bin as far as I know. So if I'm right virtualbox_ext_oracle is only needed with virtualbox from [community].

seblu commented on 2011-01-08 15:57 (UTC)

@jarryson i will add strip option in next release. Thanks. But, i have 2 issues with you PKGBUILD: 1- You suppose VirtualBox store its Extension in /usr/lib/virtualbox/ExtensionPacks/. But if you use virtualbox_bin package, path is /opt/VirtualBox/ExtensionPacks. This is difficult (impossible?) to know at packaging time the right path. 2- Why do you want to code again something when it's done geniously by software developer and there is no difference?

jarryson commented on 2011-01-08 15:38 (UTC)

Maybe extract the content will be better? PKGBUILD:

commented on 2011-01-06 21:08 (UTC)

missing deps " -> virtualbox=4.0.0 " ?

seblu commented on 2010-12-27 20:45 (UTC)

@alphazo: this comment still has no connection with this package...

alphazo commented on 2010-12-27 15:48 (UTC)

USB EHCI has been fixed in virtualbox 4.0.0-3. No longer need to manually add the udev rule.

seblu commented on 2010-12-27 00:10 (UTC)

@alphazo: This bug is not on oracle extensions (which add support of USB 2.0). USB 1.O is bundled without extension pack. USB devices are greyed without pack installed. So this should be fixed in upstream package.

alphazo commented on 2010-12-26 23:51 (UTC)

Apparently virtualbox package from community repo will have the fix tomorrow.

alphazo commented on 2010-12-26 23:22 (UTC)

Ok so I got it working by using the udev rule found here For some reasons my user was not part of vboxusers group. I added it to it and USB was back (after rebooing with the above udev rule). This should be added to the PKGBUILD.

alphazo commented on 2010-12-26 22:58 (UTC)

Looks like there is a missing udev rule in order to get USB host working I tried to manually install the rule but still no luck. I also tried to use the udev rule found in virtualbox-sun PKGBUILD from AUR but no luck as well.

alphazo commented on 2010-12-26 21:11 (UTC)

I'm moving from Virtualbox 3.x (PUEL edition from AUR that supports USB) to 4.x (Base version (GPL) from Community and this package (PUEL) for additional support such as USB). My 3.x was fully working including USB host. I've uninstalled Vbox 3.x and installed the following packages: - virtualbox 4.0.0-2 - virtualbox-additions 4.0.0-1 - virtualbox-ext-oracle 4.0.0-2 Extension pack shows up in Virtualbox extension manager (USB host). I've also installed guest additions and verified that USB host was enabled under VM's configuration. My XP VM starts but I'm unable to select any of my USB devices (everything is grayed out). Is there any additional step to go through in order to get access to USB devices?

seblu commented on 2010-12-26 00:30 (UTC)

@mektub: No you are right! I'm sorry. After checking conscientiously, this message appears if vbox modules are not loaded. Fixed in -2. Thanks!

Mektub commented on 2010-12-26 00:25 (UTC)

Sorry,seblu, my bad... Mektub

Mektub commented on 2010-12-25 21:47 (UTC)

After installing it says: ... Please recompile the kernel module and install it by sudo /etc/init.d/vboxdrv setup I think it should be /etc/rc.d/vboxdrv setup

seblu commented on 2010-12-25 14:57 (UTC)

@cryptocrack: will be done on next update @ngoonee: yes it should.

ngoonee commented on 2010-12-24 22:50 (UTC)

@maintainer - so if we have the repo version of virtualbox4 and this package it completely replaces virtualbox_bin?

lfleischer commented on 2010-12-24 22:35 (UTC)

You should use `install -D` instead of mkdir(1) and cp(1) in the package() function.