VirtualBox 3.1.8 fails when started as user. When started as root the command (VirtualBox) succeeds. Reproducible: Always Steps to Reproduce: 1. VirtualBox 2. 3. Actual Results: peter@Phenom_X4_9950 ~ $ VirtualBox VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/opt/VirtualBox/VirtualBox.so",) failed: VBoxVMM.so: cannot open shared object file: No such file or directory Expected Results: The VirtualBox application. peter@Phenom_X4_9950 ~ $ id uid=1000(peter) gid=100(users) groups=100(users),7(lp),10(wheel),11(floppy),16(cron),18(audio),19(cdrom),27(video),35(games),85(usb),250(portage),1004(plugdev),1007(peter),1008(vboxusers),1010(svnusers)
Any chance you have /opt on a separate partition being mounted with nosuid?
(In reply to comment #1) > Any chance you have /opt on a separate partition being mounted with nosuid? > No, the entry in fstab is: /dev/mapper/vg-lv--opt /opt ext3 noatime 1 2
Enabling the keyword '~amd64' and the successive emerge of 'virtualbox-bin' resulted in the installation of 'virtualbox-bin-3.2.10-r1' and 'virtualbox-modules-3.2.10' which could be started in a normal fashion as an user. Disabling the keyword '~amd64' and the successive emerge of 'virtualbox-bin' resulted in the installation of 'virtualbox-bin-3.1.8' and 'virtualbox-modules-3.1.8' which could NOT be started in a normal fashion as an user.
Same problem here. VirtualBox was running fine - until since I upgraded glibc. Root cause seems to be a mismatch between glibc 2.11.2-r3(2.2) and VirtualBox. See also http://aur.archlinux.org/packages.php?ID=9753
Same issue. Worked until glibc update. Haven't tried as root. 3.2.10-r1 works. System is mostly stable amd64.
virtualbox-3.2.10 is our next stable candidate. I suggest you add that version to package.keywords for the time being.
app-emulation/virtualbox-bin-3.2.10-r1 here As user i get : [code] which: no VirtualBox in (/opt/bin) basename: missing operand Try `basename --help' for more information. Unknown application - [/code] as root it works ! My user is in vboxusers group! [code] groupmems -g vboxusers --list root kollin [/code]
upgrading to 3.2.10-r1 seems to have fixed it for me.
Upstream bug is here: http://www.virtualbox.org/ticket/7623
This forum post has a workaround: http://forums.gentoo.org/viewtopic-t-851870-highlight-vboxvmm.html.
(In reply to comment #5) > Same issue. Worked until glibc update. Haven't tried as root. 3.2.10-r1 works. > > System is mostly stable amd64. > The VirtualBox problem was apparently exposed by the recent glibc fix to how shared libraries are searched for when executing suid binaries. VirtualBox was relying on the old insecure behavior and now it needs to be updated upstream; this seems to have already been done in version 3.2.10. Incidentally, there is another workaround suggested by upstream, which doesn't involve having to clutter your /lib with a bunch of VBox-related symlinks -- just edit the .so libraries themselves so that they look for other libraries in the appropriate directory: http://www.virtualbox.org/ticket/7623#comment:8
(In reply to comment #11) > Incidentally, there is another workaround suggested by upstream, which doesn't > involve having to clutter your /lib with a bunch of VBox-related symlinks -- > just edit the .so libraries themselves so that they look for other libraries in > the appropriate directory: > http://www.virtualbox.org/ticket/7623#comment:8 > There is a problem with the above workaround: the original RPATH on the .so files is 7 characters long ($ORIGIN), so we are limited to 7 characters for the new path. This is too short to fit "/opt/VirtualBox". The workaround for the workaround is to create a symlink in / (with a short name), pointing to /opt/VirtualBox, then using chrpath to point to that. The following *will* work for app-emulation/virtualbox-bin-3.1.8: # emerge -va app-admin/chrpath # ln -s /opt/VirtualBox /vbox # chrpath --replace /vbox /opt/VirtualBox/*.so I suggest creating a virtualbox-bin-3.1.8-r1 ebuild that implements the above.
Another (maybe obvious to some) work-around here, especially for users where upgrading to 3.2 is not an option (e.g. palm-sdk 1.4 users), switching from app-emulation/virtualbox-bin-3.1.8 to app-emulation/virtualbox-ose-3.1.8 also solves the issue. I had to remove by ~/.VirtualBox, though, to solve VERR_CFGM_VALUE_NOT_FOUND errors.
virtualbox-3.2.12 is now stable. Closing this bug.
