• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

VirtualBox startet nach 'pkg upgrade' nicht mehr

[KB]

Well-Known Member
Themenstarter #1
Hallo!

Nach einem Upgrade der installierten Packages startet VirtualBox (nun in der Version virtualbox-ose-5.2.18_1) nicht mehr, sondern wird mit folgender Fehlermeldung beendet:

VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen("/usr/local/lib/virtualbox/VBoxRT.so",) failed: /usr/local/lib/virtualbox/VBoxRT.so: Undefined symbol "lio_listio"

VirtualBox: Tip! It may help to reinstall VirtualBox.
Ein wenig Recherche führte mich dann zu folgendem Ticket: https://www.virtualbox.org/ticket/16759

Hier wird empfohlen bzw erwartet die Verzeichnisse '/usr' und '/usr/lib' mit 'chown' auf 'root:root' zu setzen.
Mal abgesehen davon, dass ich jetzt nicht ohne Weiteres die Folgen dieser Änderung einschätzen kann, funktioniert dies unter FreeBSD (zumindestens auf meinem System) so nicht. Da es die Gruppe root zumindestens auf meinen Systemen nicht gibt.

Ist evtl. noch jemand über dieses Verhalten gestolpert, kann etwas dazu sagen und/oder hat auf die Schnelle eine sinnvolle Lösung parat?

Vielen Dank im Voraus,
[KB]
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#2
Nein, das funktioniert nicht. Das Problem ist, dass VBoxRT.so das Symbol lio_listio nicht auflösen kann. Es also nicht im System existiert. Das ist ein Syscall, der von der libc bereit gestellt wird: https://www.freebsd.org/cgi/man.cgi?query=lio_listio Wenn der nicht existiert, ist das System wahrscheinlich inkonsistent. Ist das vielleicht noch ein FreeBSD 11.1?
 

Vril

Well-Known Member
#4
Also bei mir hat in einem anderen -aber ähnlichen Fall- die Deinstallation von VirtualBox
und statt virtualbox-ose die Benutzung der Kommandozeilenversion geholfen,
also virtualbox-ose-nox11.

Ausserdem ist die von Dir benutzte 5.1.8 nicht die aktuellste Version.
Aktuell kannst Du Dir die Version 5.1.20 z.B. mit
Code:
 portmaster -i emulators/virtualbox-ose-nox11
kompilieren und linken.

Edit: Es kann sein, dass bei den Binaries nicht immer die neuesten Versionen zu finden sind - deshalb ist es eine gute Idee, bei so Problem-Ports wie VirtualBox selbst zu kompilieren.
 

Andy_m4

Well-Known Member
#5
Hier wird empfohlen bzw erwartet die Verzeichnisse '/usr' und '/usr/lib' mit 'chown' auf 'root:root' zu setzen.
Da der erste Tip der auch von VirtualBox selbst kommt ist, VirtualBox zu reinstallieren.

Ist evtl. noch jemand über dieses Verhalten gestolpert, kann etwas dazu sagen und/oder hat auf die Schnelle eine sinnvolle Lösung parat?
Also bei mir läuft VirtualBox 5.2.18_1 unter einem FreeBSD 11.2 ohne Probleme.

Es kann sein, dass bei den Binaries nicht immer die neuesten Versionen zu finden sind
Ist auch hier so. In den Ports findet sich bereits Version 5.2.20
 
Gefällt mir: Vril

Vril

Well-Known Member
#6
Da der erste Tip der auch von VirtualBox selbst kommt ist, VirtualBox zu reinstallieren.


Also bei mir läuft VirtualBox 5.2.18_1 unter einem FreeBSD 11.2 ohne Probleme.


Ist auch hier so. In den Ports findet sich bereits Version 5.2.20
Ich meinte zuvor ja auch 5.2.20 .. und natürlich nicht 5.1.20 - Tippfehler von mir
 

Vril

Well-Known Member
#7
Aber grundsätzlich ist es immer wieder VirtualBox, was irgendwelche seltsamen Dinge macht - oder nicht macht - oder auch Schlimmeres verursacht
 

KobRheTilla

used register
#8
Hier wird empfohlen bzw erwartet die Verzeichnisse '/usr' und '/usr/lib' mit 'chown' auf 'root:root' zu setzen.
Dieser Tipp ist nutzlos. Die Berechtigungen der Systemverzeichnisse sind per default korrekt und benötigen keine Anpassungen.
Sie gehören immer dem Superuser und sind für Gruppe und World lesbar und ausführbar (chdir).

Rob
 

pit234a

Well-Known Member
#10
5.2.20 r125587
ist bei mir aus den Paketen gebaut worden, die ich auf "latest" gesetzt habe. System ist FreeBSD 11.2-RELEASE-p4.
Tatsächlich hatte ich zuvor nach einigen Updates (unter 11.1 mit "quarterly") erhebliche Eskapaden von VB erlebt, bis hin zum Untergang einiger Maschinen.
Mit der neuen Version und dem neuen FreeBSD konnte ich die wichtigsten VMs wieder einbinden, also neue Maschinen angelegt und vorhandene virtuelle Festplatten erfolgreich eingebunden. Bei zwei Windows-Guests gelangen adhoc auch die neuen Guest-Additions(G-As). Ein älteres GNU-Linux hat diese nicht mehr als Paket verfügbar und mit dem Einspielen der mitgelieferten G-As von der .iso habe ich schlechte Erfahrungen gemacht. Mit dieser VM lebe ich also ohne die G-As, was nicht so dramatisch ist, weil es nur eine Testinstallation ist.

Jedenfalls kann ich also auf meinem PC bestätigen, dass die 5.2.20 auf FreeBSD 11.2 wieder unauffällig läuft.
 
Gefällt mir: Vril

[KB]

Well-Known Member
Themenstarter #12
Ok, erst einmal vielen Dank für die zahlreichen Infos und Ratschläge.
Nun wollte ich dem Rat folgen und die notwendigen Ports selbst kompilieren, da die VirtualBox-Version (VirtualBox-5.2.20) dort tatsächlich neuer ist.
Leider nicht mit Erfolg. Der Build des Ports 'virtualbox-ose-kmod' wird z.B. gar nicht erst gestartet:

/!\ ERROR: /!\

Ports Collection support for your FreeBSD version has ended, and no ports are
guaranteed to build on this system. Please upgrade to a supported release.

No support will be provided if you silence this message by defining
ALLOW_UNSUPPORTED_SYSTEM.
Jetzt wird ganz verückt ...
Der Portstree wurde mit 'portsnap fetch update' aktualisiert und der Kernel sollte eigenlich auch auf dem aktuellen Stand sein:

FreeBSD xxxxxxxxx 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
Ich verstehe mein System gerade nicht mehr!
Vielleicht lösche ich mal des '/usr/ports'-Verzeichnis und installiere den Portstree mal komplett neu ....
 

[KB]

Well-Known Member
Themenstarter #13
Nö, bringt keine Änderung, also jetzt mal den Kernel-Sourcetree neu laden und Kernel bauen.
Wenn auch das nix bringt, stehe ich auch dem Schlauch ....
 

[KB]

Well-Known Member
Themenstarter #17
Auch mit neu geladene Kernelsourcen und anschließend selbst gebauten GENERIC-Kernel keine Änderung ...

virtualbox-ose-kmod läßt sich nicht bauen. Das gibt es doch nicht!

Also, weiterforschen ....
 
Gefällt mir: Vril

pit234a

Well-Known Member
#18
ist es denn keine Option für dich, auf "latest" zu wechseln und es als Paket zu nutzen?
Ich weiß, dass ich selbst auch immer wieder für "quarterly" entschied und auch immer noch votiere, weil ich damit "mehr Ruhe habe". Derzeit gibt es aber einige Dinge, die eben mit aktuellen Programmen gefixt sind und das Umstellen auf "latest" ist deshalb durchaus sinnvoll.
Wie häufig man dann tatsächlich updatet, ist ja wieder eine andere Frage.
"latest" bewegt sich halt viel schneller, als "quarterly".

Einfach in /etc/pkg/FreeBSD.conf die URL ändern: url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest" und dann alle Pakete aktualisieren.
Das sind natürlich etliche Abhängigkeiten, die dann neu gebaut werden, aber als Paket geht es ja recht flott.

Zumindest bei mir ist das auf zwei vollkommen unterschiedlichen Rechnern (32 und 64 Bit-Mehrkern) glücklich verlaufen.
 

Vril

Well-Known Member
#19
Du bist auch sicher, dass das Kernel-Modul von deinen früheren VirtualBox Installationen nicht noch irgendwo auf dem System herumgeistert oder gar mittels Eintrag in der /boot/loader.conf beim Start geladen wird?
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#21
Reinstallationen, Rumgefummel mit Kernelmodulen und ähnliches wird nichts bringen. Denn wie oben schon gesagt ist lio_listio() ein Syscall. Wenn Syscalls nichts aufgelöst werden können, ist etwas grundsätzlich im Eimer. Meistens ist das System inkonsistent, sprich die Binarys, Bibliotheken, Kernel und so weiter passen nicht sauber zusammen. Ich würde dann auch da ansetzen, zum Beispiel mit einem:
Code:
freebsd-update IDS
Und dann die Ausgabe mal hier herein. :)