VirtualBox

Ticket #7878 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Unable to install extpack on AMD64 (wrong directory permissions) => Fixed in SVN

Reported by: cromo Owned by:
Priority: major Component: other
Version: VirtualBox 4.0.0 Keywords: extpack extensions
Cc: Guest type: Windows
Host type: Linux

Description

I am unable to install the vbox-extpack. It fails with:

Failed to locate the main module ('VBoxPuelMain').
 
Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ExtPackManager
Interface: IExtPackManager {2451b1ba-ab1c-42fb-b453-c58433bea8c7}
Callee: IExtPackFile {b6b49f55-efcc-4f08-b486-56e8d8afb10b}

What is weird, if I run VirtualBox as root user extension seems just fine and shows no erros in Preferences Dialog.

I use an up-to-date Ubuntu 10.10 AMD64.

Change History

comment:1 Changed 3 years ago by cromo

Also please not that if I install the extpack as root user using VBoxManage, no error is reported at the time of installing, but an exclamation mark is still shown in Preferences Dialog in GUI and an attempt to run a VM preconfigured with USB 2.0 support fails with "Implementation of the USB 2.0 controller not found!"

comment:2 Changed 3 years ago by klaus

Just as a data point: works for me (Debian Lenny amd64). Both as regular user (gksu authentication) and as root.

comment:3 Changed 3 years ago by klaus

Are you sure that this isn't just a truncated download of the extension pack? Checking the MD5/SHA256 sums against  http://download.virtualbox.org/virtualbox/4.0.0/MD5SUMS or  http://download.virtualbox.org/virtualbox/4.0.0/SHA256SUMS should tell.

comment:4 Changed 3 years ago by patrick.steiner

I can confirm the same problem on an centos 5.5 x86

comment:5 Changed 3 years ago by cromo

I checked the md5sum and it's correct.

comment:6 Changed 3 years ago by cromo

BTW. when attempting to install as regular user I am not asked for credentials - no gksu authentication window appears. I guess it could be somehow related to the failure?

comment:7 Changed 3 years ago by cromo

Patrick, if you're on x86 then it's a different issue - have a look here:  http://goo.gl/SVSuR

comment:8 Changed 3 years ago by TheHidden

I'm experiencing the same problem. I'm on Ubuntu 10.04 x86. I already tried to install the libstdc++5 (for which i had to activate the lucid-backport sources) but to no avail. That is clearly not the problem. I also can only install the extension as root, for whom it will work perfectly (even without libstdc++5 installed btw, instead, have libstdc++6 installed). But as soon as i start up VirtualBox 4.0.0 as the normal user (and yes he's in the vboxusers group) the extension is marked with an exclamation mark and claims being unable to locate the VBoxPuelMain module.

comment:9 Changed 3 years ago by frank

The libstdc++5 is not required (this was a Beta bug). To debug this problem, could you do the following: Make sure that no VBoxSVC daemon is running. Then do

strace -s128 -v -o ~/log -f /usr/lib/virtualbox/VBoxSVC

Then, in another console do

VirtualBox

and try to install the ExtPack (or if it is installed, to re-install). Then terminate the GUI and wait 10 seconds. Then abort the VBoxSVC strace. Attach the compressed log to this ticket.

comment:10 Changed 3 years ago by TheHidden

I found the cause for my error, and maybe it's the cause for others too! My umask settings prevented the correct behavior. I didn't attach the log, since i'm not sure if it will help with the other problems.

I performed the strace and grep'ed the logfile for VBoxPuelMain noticing a Permission denied error for the VBoxPuelMain.so. I checked the permission on the file, which where fine, as well as all permissions along the file path except for the

/usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.x86

directory and all other directories in the Oracle_VM_VirtualBox_Extension_Pack folder.

$ ls -lah /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/
insgesamt 164K
drwxr-xr-x 10 root dark_emperor 4,0K 2010-12-24 15:43 .
drwxr-xr-x  3 root root         4,0K 2010-12-24 15:43 ..
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 darwin.amd64
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 darwin.x86
-rwxr-xr-x  1 root dark_emperor 9,4K 2010-12-24 15:43 ExtPack-license.html
-rwxr-xr-x  1 root dark_emperor  22K 2010-12-24 15:43 ExtPack-license.rtf
-rwxr-xr-x  1 root dark_emperor 8,8K 2010-12-24 15:43 ExtPack-license.txt
-rwxr-xr-x  1 root dark_emperor  20K 2010-12-24 15:43 ExtPack.manifest
-rwxr-xr-x  1 root dark_emperor    6 2010-12-24 15:43 ExtPack.signature
-rwxr-xr-x  1 root dark_emperor  456 2010-12-24 15:43 ExtPack.xml
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 linux.amd64
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 linux.x86
-rwxr-xr-x  1 root dark_emperor  48K 2010-12-24 15:43 PXE-Intel.rom
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 solaris.amd64
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 solaris.x86
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 win.amd64
drwx------  2 root dark_emperor 4,0K 2010-12-24 15:43 win.x86

I had changed the general umask in /etc/profile from the original ubuntu setting 0022 to 0077 for security purposes. And that was what blocked the normal users from using it.

I reinstalled it as root while having set root's umask to 0022 during the operation, and that did the trick for me (and i know, that i could have simply chmod'ed the permissions, but i was testing). Every other user can now use it too.

Actually i'm quite happy that i have to do it this way, since users now can't introduce a potentially harmful future extension without checking with me first.

Sorry for the inconvenience.

comment:11 Changed 3 years ago by cromo

TheHidden - well, funny enough I also have the umask changed here to 077 from defaults 022 - although only for my home user in ~/.profile and not globally in /etc/profile. But the reason it failed to me is that I installed the extpack as root root by using sudo without any extra options so it used the user's 077 umask anyway. The solution was to run it with sudo -i or su. Thanks!

comment:12 Changed 3 years ago by frank

  • Summary changed from Unable to install extpack on AMD64 to Unable to install extpack on AMD64 (wrong directory permissions) => Fixed in SVN

Yes, the extension pack installer should indeed override the umask setting. This will be fixed in the next maintenance release.

comment:13 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use