Bug 427266

Summary: Virtualbox cannot be started on x86-64: Callee RC: NS_ERROR_FACTORY_NOT_REGISTERED (0x80040154)
Product: [openSUSE] openSUSE 11.1 Reporter: Joop Boonen <joop.boonen>
Component: OtherAssignee: Martin Kudlvasr <mkudlvasr>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P3 - Medium CC: kontakt, novell.admin, suse-tux
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 11.1   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Starting VirtualBox after the user was added to the vboxusers group

Description Joop Boonen 2008-09-18 08:26:45 UTC
This bug is related to repo: 
http://download.opensuse.org/repositories/Virtualization:/VirtualBox/openSUSE_11.0/


When i try to creae a new virual machine as a user i get the following error:
 Callee RC:  NS_ERROR_FACTORY_NOT_REGISTERED (0x80040154)

When i try the same as root it works fine.

According to link: http://vbox.innotek.de/pipermail/vbox-dev/2008-August/000770.html
this issue can be solve by:
<quote>
./configure --disable-hardened
</quote>

I saw this is not configured i the specfile (virtualbox-ose.spec)
Comment 1 Stephan Binner 2008-09-18 08:47:10 UTC
}-Tux-{ fixed it already and will release a new package today. Until then you can run it as root.
Comment 2 Stephan Binner 2008-09-18 09:24:32 UTC
*** Bug 426409 has been marked as a duplicate of this bug. ***
Comment 3 Marcus Hüwe 2008-09-18 16:55:33 UTC
You can find a fixed version in the Virtualization:VirtualBox repository. Sorry for the inconvenience.
Comment 4 Joop Boonen 2008-09-18 18:00:08 UTC
I'm sorry but as a normal user I still get an error on x86_64. I didn't check on ix86 32 yet.

The error is:
VirtualBox
VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib64/virtualbox/VirtualBox.so",) failed: VBoxDDU.so: cannot open shared object file: No such file ordirectory


As root VirtualBox can be started without a problem.
Comment 5 Marcus Hüwe 2008-09-18 19:11:30 UTC
Should be fixed with the new release (2.0.2-6.1) or does the problem still occur?
Comment 6 Joop Boonen 2008-09-18 19:42:50 UTC
I've just tested release virtualbox-ose-2.0.2-6.1 on both a 32 bits as 64 bits system works like a breeze. Thank you for your effort.

As far as I'm concerned this "bug" has been resolved.
Comment 7 Jakub Rusinek 2008-09-18 21:39:15 UTC
* starts without root privileges
* doesn't crash because of QGTKStyle
* is able to start VM

you fixed the bug.
Comment 8 Zsolt Sági 2009-01-15 13:16:31 UTC
Still occurs in the 64 bit version of the final openSUSE11.1 (see the attached image).
Comment 9 Zsolt Sági 2009-01-15 13:17:38 UTC
Created attachment 265325 [details]
Starting VirtualBox after the user was added to the vboxusers group
Comment 10 Zsolt Sági 2009-01-26 23:47:17 UTC
I mean Virtualbox cannot even be started on x86-64.
Comment 11 Martin Kudlvasr 2009-01-28 14:45:45 UTC
I use vbox on my x86-64 machine with os11.1 and vbox from os11.1. I have never seen the error message you describe. Can you add more information, please? Vbox logs?
Comment 12 Zsolt Sági 2009-01-28 19:11:24 UTC
OK, I started it from commandline:

tamas@milleniumfalcon:~/.VirtualBox> VirtualBox
Wrong owner (0) of '/tmp/.vbox-tamas-ipc'.
Wrong owner (0) of '/tmp/.vbox-tamas-ipc'.

It was the problem. Then I did this:

tamas@milleniumfalcon:~/.VirtualBox> su
Jelszó:
milleniumfalcon:/home/tamas/.VirtualBox # ls -la /tmp/.vbox-tamas-ipc/
összesen 304
drwx------  2 root  root    4096 jan 15 13.56 .
drwxrwxrwt 43 root  root  299008 jan 28 19.48 ..
srwx------  1 root  root       0 jan 15 13.56 ipcd
-rw-------  1 root  root       6 jan 15 13.56 lock
milleniumfalcon:~ # chown tamas:users -R /tmp/.vbox-tamas-ipc


And now VirtualBox runs without any problem. Even the sound works, much better than in openSUSE 11.0. Afterwards I exited the whole VirtualBox, removed the directory /tmp/.vbox-tamas-ipc, and restarted virtualbox, in order to observe, if it will be able to generate the new directory with appropriate permissions. And it was able! What generated that old and restrictive directory? I didn't do it manually. So, my problem is solved, but I don't know the orginal reason to help you avoiding this incident in the future.
Comment 13 Martin Kudlvasr 2009-01-28 20:09:33 UTC
You said you were running vbox as root. So the tmp directory was created with root permissions. Regular user vbox was not able to delete them later.

If you su to root, the tmp dir is still created with your name, but root (0) permissions. As the tmp dir is not deleted on vbox exit ...
The PUEL version does the same thing.

I'm lowering the severity since we already have a solution. I am going to work on the fix ...
Comment 14 Martin Kudlvasr 2009-02-04 15:10:15 UTC
virtualbox was was taking the username from environment variables. I patched it to prefer username (as in getpwuid). Now root virtualbox creates his own tmp dir. Fixed in factory.