Page 1 of 1

VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 15. Nov 2017, 15:11
by Computersenior
Hallo Zusammen,
ich bekam den Hinweis, es steht eine neue Version von Virtualbox zur Verfügung.
Als ehemaliger Windows Nutzer habe die neue Version nach Deinstallation meiner alten Version installiert.
Virtualbox im Grafikmodus startet nicht und bringt keine Fehlermeldung, im Terminal wird diese Fehlermeldung eingeblendet:

VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen("/usr/lib/virtualbox/VBoxRT.so",) failed: <NULL>

VirtualBox: Tip! It may help to reinstall VirtualBox.


Auch die vorgeschlagene Reinstallation brachte keine Änderung.
Mein System : Linux Mint 18.2 64 bit
Cinnamon Version: 3.4.6
Kernel Version: 4.10.0-33
Intel Core Dou E7400 2.8x2 gHz
Speicher : 1,9 GiB
Festplatte : 640 GB

Kann jemand helfen?

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 17. Nov 2017, 20:00
by socratis
Check that your permissions are they are supposed to be.
Hint: compare them with a fresh install.

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 19. Nov 2017, 18:09
by Computersenior
I tryed to start virtualbox also as root and it dos not work.

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 21. Nov 2017, 17:54
by socratis
I din't say to check/change your access level (user/root), I said check the permissions in the operating system. Something is not right, usually in the "/usr" directory.

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 16. Dec 2017, 14:31
by Computersenior
Hallo,
my problem is solved. I use VMWare insted of Virtualbox.
Thanks for helping

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 16. Dec 2017, 14:36
by socratis
That's not a solution; you *do* realize that, right?
But of course you do! You are a "Computer Senior"! Not even a Sophomore! Can't wait for you to get that Masters degree. And a PhD! You definitely deserve one! (or two)

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 3. May 2018, 20:23
by imuw3Aak
First of all, @socratis: This person probably means 'senior' as in 'senior citizen'. You should seriously reconsider how you talk to people on the Internet. Someone with your attitude should not be site moderator anywhere.

@Computersenior

Ich hatte das gleiche Problem, weil ich beim manuellen Installieren einer anderen Anwendung ausversehen den Besitzer des Systemverzeichnisses /usr geändert habe. Das ist lange Zeit unbemerkt geblieben, weil das neben VirtualBox bei keiner weiteren Anwendung zu Problemen geführt hat. Um das Problem zu behen, muss der Besitzer und die Gruppe von /usr wieder zurück auf 'root' geändert werden. Das geht z.B. mit folgendem Befehl im Terminal.

sudo chown root:root /usr

Evtl. muss das auch für weitere, betroffene Unterverzeichnisse von /usr gemacht werden: /usr/lib, /usr/include, /usr/share, ... (alle, die nicht dem Besitzer 'root' gehören).

Wenn man das nicht von Hand wieder reparieren kann/will, ist eine Neuinstallattion wahrscheinlich die beste Lösung.

I had the same problem, after accidentally changing the ownership of /usr when I manually Installed another application. This went annoticed for a while, because I wasn't aware of it and it didn't seem to cause problems with any other application besides VirtualBox. To fix this, change the owner and group of /usr back to 'root'. This can be done with the following command in the terminal.

sudo chown root:root /usr

This possibly needs to be done as well for affected subdirectories of /usr like /usr/lib, /usr/include, /usr/share, ... (all dirs that aren't owned by root).

If you don't feel comfortable with doing this by hand, re-installing the whole operating system is probably the best option.

Also, do NOT just change the ownership of /usr back to root:root recursively (chown -R root:root /usr), this will break your entire system.

Re: VirtualBox 5.2.0 unter Linux Mint 18.2

Posted: 4. May 2018, 00:24
by socratis
imuw3Aak wrote:This person probably means 'senior' as in 'senior citizen'.
I seriously doubt that. After you've had so many years of experience you know how to distinguish a "senior" from a "script kiddie". In the case that I did, I shouldn't have. But this user was seriously crossing the "troll" line as well, when they suggested that "the solution is to switch to another program". Seriously?
imuw3Aak wrote:You should seriously reconsider how you talk to people on the Internet.
I've been talking to people on the Internet for almost 30 years now (come next year). I've seen a thing or two, and 99% of the responses I've gotten have been a big "Thank you!". Then there's the occasional 1%...
imuw3Aak wrote:Someone with your attitude should not be site moderator anywhere.
Thank you for the advice. I'll seriously consider it in my next job application as a forum moderator. Truth of the matter is that you don't apply to become a moderator, the existing moderators ask you to, because they see your attitude and your level of knowledge. And I'm sorry, but I trust their judgement with a combined experience of 100,000 posts and 50 years on the forums, more that any single-post, first-day, user's opinion. They tend to have more... 'gravitas'.
imuw3Aak wrote:This possibly needs to be done as well for affected subdirectories of /usr like /usr/lib, /usr/include, /usr/share, ... (all dirs that aren't owned by root).
imuw3Aak wrote:Also, do NOT just change the ownership of /usr back to root:root recursively (chown -R root:root /usr), this will break your entire system.
True, very true on both accounts. VirtualBox's Hardening does not allow certain directories to have relaxed permissions, it's a (theoretical) security problem. And if they're not the expected ones, VirtualBox refuses to launch. Why no other apps do that? Because no one came out with a theoretical security paper for Minesweeper that could (in theory) compromise the system (host). I do have to stress the "theoretical" part. But, after that happened, VirtualBox could not sit back and not take any measures against this theoretical threat. Hence, the Hardening.
imuw3Aak wrote:If you don't feel comfortable with doing this by hand, re-installing the whole operating system is probably the best option.
Although that sounds drastic, but definitely the 100% for sure approach, it's a little bit brute-force. That why I suggested to the OP:
socratis wrote:Hint: compare them with a fresh install.
I should have amended that, to include "... a fresh install in a VM".

I often compare my core system directories with a fresh installation of my host's OS, updated to the same level as my host. Then compare the output of "ls -alR /" for the host and the (twin) guest. It's another way to skin a cat...