VirtualBox startet nach 'pkg upgrade' nicht mehr

[KB]

Well-Known Member
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]
 
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?
 
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.
 
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
 
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
 
Aber grundsätzlich ist es immer wieder VirtualBox, was irgendwelche seltsamen Dinge macht - oder nicht macht - oder auch Schlimmeres verursacht
 
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
 
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.
 
5.2.20 r125587
....
Jedenfalls kann ich also auf meinem PC bestätigen, dass die 5.2.20 auf FreeBSD 11.2 wieder unauffällig läuft.

ja - kann ich auch bestätigen.
Aber eine FreeBSD Maschine mit VirtualBox an Bord macht immer so'n komisches Bauchgefühl
bei Updates und Upgrades ;-)
 
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 ....
 
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 ....
 
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 ....
 
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.
 
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?
 
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. :)
 
So, nun will ich auch mal wieder antworten. Bei Versuchen Packages zu installieren kommt folgende Meldung:

Newer FreeBSD version for package sagasu:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1102000
- running kernel: 1101001
Allow missmatch now?[Y/n]:

Da ich für weitere Untersuchungen erst einmal keine Zeit hatte, habe ich den Missmatch zugelassen und anschließend wurde VirtualBox installiert und läuft soweit ich das beurteilen kann auch fehlerfrei.

Und hier ein Auszug aus dem Output von 'freebsd-update IDS':

Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 11.2-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
/.cshrc has SHA256 hash eea9447d7bd1a70643a8cef437a8bf6126d1f16a0f5fdfa757585674b187c19c, but should have SHA256 hash fa230e789d405c1da676eb0a0d75c6c9af8eabab32c643cf76509bb093080c9e.
/.profile has SHA256 hash 2a29fe5f3adbbd640c82a8b32418ffa30e2d6e0f20ed77cb6eb52aae5f373733, but should have SHA256 hash 6728e112cbdc360f08c65a8db43455122411a672ed8eb74c69e97907bc1e1343.
/COPYRIGHT has SHA256 hash e32913bf27b8fa188382ad4e96efd6a01e46bcdd21f151b1acca72f07cceb77d, but should have SHA256 hash baafb8bc4882614caae3d5c1138df7c18a19849ff6807434b84074f172f94154.
/bin/[ has SHA256 hash d7ff510a1c8e899df0b08e06a866be597f63b9d2a78767fc907c17aba47d8574, but should have SHA256 hash d43054dc4a2cfc6434472e9a44303fe9624b4560b2e7035b0462b3b0cfbcd12a.
...

Die komplette Meldung möchte ich euch nicht antun ... :zitter:
Hier ist irgendwas gehörig schiefgelaufen ...

Viele Grüße,
[KB]
 
Zurück
Oben