VBox: shared folders crashen VMs

Seit VBox v6.0.10 lassen Shared Folders VMs crashen, Windows-VMs, wohlgemerkt, Linux-VMs sind nicht betroffen. Host spielt dabei keine Rolle. Beim versuchten Öffnen eines Shared Folders verkleinert sich das Bild der VM auf einen Ausschnitt, gefolgt von einem nur kurz zu sehenden Systemcrash (so einen mit Smiley). Es ist sogar möglich, daß man nicht mehr auf einen (anderen) virtuellen Desktop des Hosts kommt und man sinnvollerweise über eine virtuellen Konsole rebootet. So das gelingt.

Dies ist reproduzierbar bis inkl. 6.0.11-132407. Ursächlich sind nicht VBox selbst, das Extension Pack sowieso nicht, sondern die Guest Additions, die das SF-Modul beinhalten. GA installiert und SF aktiviert zu haben, zeigen noch nichts, erst beim Öffnen gibt’s einen brachialen Absturz. Um das nicht aus Versehen auszulösen, ist das Deaktivieren von SF erstmal naheliegend.

Mit aktuellem VBoxGuestAdditions_6.0.97-132468.iso scheint das Problem behoben worden zu sein. Das Öffnen eines Shared Folders und diverser Files darin funktioniert wieder wie gewohnt.

Auch, wenn man gemeinhin versionsgleich arbeiten sollte, man braucht nicht die Development Snapshots aller drei Teile installieren, also nicht von VBox und ExtPack, nur genannte GuestAdds.

2019-09-03: Nach mehreren Testbuilds ist nun 6.0.12 final erschienen.
2019-08-10: Mit dem GA-Testbuild 6.0.11-132500 vom -09 ist das Problem auch behoben.

VirtualBox: certificate verification failed

Derzeit, 2019-04-27, hat download.virtualbox.org ein SSL-Zertifikatsproblem (nicht virtualbox.org selbst). Entsprechend schlagen Updates oder eine Installation aus dieser Paketquelle fehl. Wie ich bereits heute morgen geschrieben habe, kann bis zur Behebung statt https das non-secure-Protokoll http verwendet werden.

Wer nach meiner Anleitung VirtualBox: Repository in Ubuntu hinzufuegen gegangen ist oder dies gerade vorhat, kann sozusagen als Punkt 2 1/2 ausführen:

1
2
sudo sed -i s/https/http/g /etc/apt/sources.list.d/virtualbox.list
sudo apt update

Haben die Admins (sicherlich nicht vor Montag) das Problem behoben, sollte man selbstverständlich auf https zurückgehen:

1
2
sudo sed -i s/http/https/g /etc/apt/sources.list.d/virtualbox.list
sudo apt update

Btw., was das (temporäre) http angeht, ja, nicht schön (Ubuntu-User sollten sich mal diesbzgl. die Mainserver und offiziellen Mirrors ansehen, haarsträubend), aber zumindest oracle_vbox*.asc kommen weiter über https.

Update 2019-04-29: Problem behoben. Ich lasse den Post stehen…für’s nächste Mal. ;) Zumindest ist es ein gutes Beispiel, wofür man das Urgestein sed nutzen kann.

VirtualBox: Kernel 5.0 nun auch im Guest

VirtualBox 6.0.4 kommt mit Kernel 5.0.x zurecht – aber nur im Host. In einer Linux-VM bislang nur ohne GuestAdditions, auch nicht mit 6.0.5er Testbuilds oder auch 6.0.97er Development Snapshots – bis heute.

Endlich (und wir sind schon bei Kernel 5.0.4, 5.1 liegt bereits als rc2 vor) werden mit VBoxGuestAdditions_6.0.5-129577.iso die Module gebaut (Nachtrag: mittlerweile sind höhere Testbuilds erschienen). Es können damit aktuelle Kernels in Virtual Machines bzw. auch entsprechend aktuelle Linux-Distributionen (antergos, siduction) in VMs genutzt oder getestet werden (selbst LDisco ist seit kurzer Zeit nach ewigem Stillstand auf aktuellen Kernel gewechselt – mit 5.1 wird das allerdings bis zum Release nichts mehr).

Die GA allein sollten zwar genügen, ich setze freilich seit langem insgesamt aktuelle Testbuilds von VBox, GA und EP ein (so nicht gerade mal ein Release aktueller sein sollte…für einen kurzen Zeitraum).

Update 2019-04-16: VBox 6.0.6 ist erschienen.

Xenial-Kernel baut nicht mit VBox 6.0.4

Kurzhinweis: Nach diversen User-Berichten (genauer seit Tagen immer wieder gleichen Anfragen) sollen im Host Kernel-Module der Ubuntu-Kernel-Version 4.4.0-143.169 nicht mit VBox 6.0.4 gebaut werden können.

Lösungsmöglichkeiten:

  • Vorgänger-Kernel verwenden
  • Nachfolger-Kernel 4.4.0-144.170 (proposed) installieren
  • HWE-Stack installieren, also mit derzeit Cosmic-Kernel 4.18.0-16.17 oder 4.18.0-17.18 (proposed)
  • Mainline-Kernel 5.0.4 installieren

Ferner natürlich noch Distupgrade auf Bionic.2 oder besser saubere Installation von Bionic.2 oder Cosmic (oder gleich LDisco daily build).

VirtualBox: Installation ueber .run

Altägyptisch oder bleeding edge. Aktuelles Beispiel: In siduction wird anders als in sid Kernel 4.20 installiert (towo ist da glücklicherweise agil). Wer VirtualBox aus den debian-Repositories nutzt, bekommt bislang nur 5.2.22, das jedoch inkompatibel zu Kernel 4.20 ist.

VBox 6.0.0 ist kompatibel zu Kernel 4.20. Man kann zwar das VBox-Repo einbinden, daraus aber nur für debian stable und oldstable installieren, was im Normalfall unter sid(uction) wegen Dependencies fehlschlägt. Für Ubuntu gebaute Pakete in debian installieren ist auch nicht die gescheiteste Idee (auch wenn die für Bionic momentan laufen sollen).

Dann sollte man so flexibel sein und die .run-Files nutzen, statt wie ein User im siduction-Forum zu jammern, er wolle nur installieren, was “über apt oder dpkg” geht, und deshalb bei der letzten 4.19 bleiben (von der Paketverwaltung abgesehen, was er meint und womit er natürlich Recht hat, erntet er meinerseits dennoch Unverständnis, man fährt doch keine bleeding-edge-RRD, um ausgerechnet beim Kernel stehenzubleiben bzw. zurückzugehen). Fremdpakete aus Sicht der Distribution sind es so und so, aber in diesem Fall bzw. aus Sicht VBox’ sind sie das Original.

Das Ganze ist auch nicht schwieriger, mehr noch, man kann das so unter diversen Distributionen durchführen, bspw. unter siduction und antergos die jeweils selben .run-Files (braucht sie also auch nur 1x ziehen) und bis auf sudo vs. root-Terminal gleich. Zudem kann man Testbuilds nutzen, die ihrerseits ggf. Fixes ggü. dem letzten Release enthalten. Der einzige Nachteil ist lediglich, daß man sich selbst um neue Versionen kümmern muß (und das Interesse für derlei setze ich bei Usern, die bewußt brandaktuelle Distributionen fahren, voraus).

Ich selbst nutze seit längerem VirtualBox*.run unter (bis vor einiger Zeit noch Lubuntu,) siduction, antergos (die gemischte Groß-/Kleinschreibung für solche Namen ist übrigens kein ständiger Fehler meinerseits, falls das jemand annimmt, sondern jeweilige Eigenschreibweise). Insbesondere durch die nicht aufhörenden Probleme mit dem Lubuntu-Host seit Kernel 4.15 (nur dort, nicht in siduction und antergos, reproduzierbare Freezes unterschiedlicher VMs und das Suchen nach den Ursachen) haben mich das jeweils aktuelle Testbuild installieren lassen, mittlerweile mache ich das standardmäßig (nur nicht, wenn das Release gerade mal neuer ist) und fahre damit sehr gut. Natürlich weiß ich, was das bedeutet und kann damit umgehen.

.

Installation VirtualBox 7.0.14 über .run

  1. Ein ggf. installiertes Extension Pack deinstallieren:
    1
    
    sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
  2. Eine ggf. installierte VBox-deb-Version deinstallieren:
    1
    2
    
    killall -9 virtualbox 
    sudo apt purge virtualbox*
  3. Zum Kompilieren der Kernel-Module nötige Pakete installieren:
    1
    
    sudo apt install build-essential dkms linux-headers-$(uname -r)
  4. VirtualBox*.run ziehen:
    1
    2
    
    cd ~/Downloads/
    wget https://download.virtualbox.org/virtualbox/7.0.14/Oracle_VM_VirtualBox_Extension_Pack-7.0.14.vbox-extpack
  5. Aktuelle VBox-Version installieren:
    1
    
    sudo sh Virt*
  6. Weiter geht es in meinem Tutorial VirtualBox: Repository in Ubuntu hinzufügen mit Punkt 8, “Entsprechende Version des Extension Packs ziehen”.

Soll ein so installiertes VBox wieder deinstalliert werden, sollte zuerst wie oben geschrieben das Extension Pack deinstalliert werden, danach VBox selbst (das EP bliebe anderenfalls erhalten, aber nicht nutzbar):

1
sudo sh Virt* uninstall

.

Update 2024-01-16: Aktualisiert auf v7.0.14.
Update 2023-10-17: Aktualisiert auf v7.0.12.
Update 2023-07-18: Aktualisiert auf v7.0.10.
Update 2023-04-17: Aktualisiert auf v7.0.8.
Update 2023-01-17: Aktualisiert auf v7.0.6.
Update 2022-11-18: Aktualisiert auf v7.0.4.
Update 2022-10-19: Aktualisiert auf v7.0.2.
Update 2022-10-10: Aktualisiert auf v7.0.0, VBox-6.x-Schiene entfernt.
Update 2022-09-29: VBox-7.0-Schiene hinzugefügt.
Update 2022-09-01: Aktualisiert auf v6.1.38.
Update 2022-07-20: Aktualisiert auf v6.1.36.
Update 2022-04-19: Aktualisiert auf v6.1.34.
Update 2022-01-18: Aktualisiert auf v6.1.32.
Update 2021-11-22: Aktualisiert auf v6.1.30.
Update 2021-10-19: Aktualisiert auf v6.1.28.
Update 2021-07-28: Aktualisiert auf v6.1.26.
Update 2021-07-20: Aktualisiert auf v6.1.24.
Update 2021-04-29: Aktualisiert auf v6.1.22.
Update 2021-04-20: Aktualisiert auf v6.1.20.
Update 2021-01-19: Aktualisiert auf v6.1.18.
Update 2020-10-20: Aktualisiert auf v6.1.16.
Update 2020-09-04: Aktualisiert auf v6.1.14.
Update 2020-07-14: Aktualisiert auf v6.1.12.
Update 2020-06-05: Aktualisiert auf v6.1.10.
Update 2020-05-14: Aktualisiert auf v6.1.8.
Update 2020-04-09: Aktualisiert auf v6.1.6.
Update 2020-02-20: Aktualisiert auf v6.1.4.
Update 2020-01-15: Aktualisiert auf v6.1.2.
Update 2019-12-11: Aktualisiert auf v6.1.0.
Update 2019-10-15: Aktualisiert auf v6.0.14.
Update 2019-09-03: Aktualisiert auf v6.0.12.
Update 2019-07-16: Aktualisiert auf v6.0.10.
Update 2019-05-14: Aktualisiert auf v6.0.8.
Update 2019-04-16: Aktualisiert auf v6.0.6.
Update 2019-01-28: Aktualisiert auf v6.0.4.
Update 2019-01-15: Aktualisiert auf v6.0.2.

VirtualBox 6.0.0 final

Nach 3 Betas und diesmal nur 1 Release Candidate ist die Final von VirtualBox 6.0.0 erschienen. Das Offensichtliche sind natürlich die grafischen Design-Änderungen des VM VitualBox Managers, das Wichtigere ist unter der Haube zu finden. x86_32 als Host ist nun endgültig Geschichte.

Changelog.

Mein Tutorial VirtualBox: Repository in Ubuntu hinzufuegen habe ich selbstverständ-
lich wie immer angepaßt.

Die Python ist gefunden

Irgendwas ist anders…

$ sudo sh Virt*
Verifying archive integrity... All good.
Uncompressing VirtualBox for Linux installation.............
VirtualBox Version 5.2.23 r127309 (2018-12-08T13:13:52Z) installer
Installing VirtualBox to /opt/VirtualBox
Python found: python, installing bindings...
 
VirtualBox has been installed successfully.

Python found? Echt jetzt? ;-)

Na klar ist Python installiert, immer schon, in quasi jeder Linux-Distribution, aber diese Routine hat bis jetzt stets was von “Python 2.x not found: python, not installing bindings” erzählt. Bekannte fehlerhafte Ausgabe seit Ewigkeiten, funktioniert hat das trotzdem (Python 2.x und 3.x sind üblicherweise parallel installiert, da es immer noch auf 2.x aufsetzende Programme gibt).

Liegt’s an ewig währenden Transitions in sid(uction) oder gar an einem nicht mehr für möglich gehaltenen Fix in VBox (ungerade Versionsnummern wie 5.2.23 sind Testbuilds)? Oder ist der Fix ein Versehen und bei der nächsten Version dürfen wir die liebgewonnene Ausgabe wieder begrüßen? ;-)

Warnung vor Liquorix-Kernel

Vor längerer Zeit habe ich auf Liquorix-Kernel hingewiesen (speziell für 32-bit-Maschinen Pentium M, erste Atom-Serien, VMs). In bestimmten Grenzen mögen diese noch eine Alternative darstellen, im Hinblick auf nach wie vor nicht mehr funktionierende 32-bit-Versionen (die letzten in VBox-VMs sind 4.15.x gewesen) und Steven Barretts offensichtliches Desinteresse, sein Produkt zu fixen, muß ich das eher insgesamt in Frage stellen.

Read more “Warnung vor Liquorix-Kernel”

Ubuntu-(Mainline-)Kernel 4.12 mit VirtualBox 5.1.22

Auch VirtualBox läuft derzeit nicht mit Kernel 4.12 im Host (im Guest kann man einen aktuellen Testbuild der GuestAdditions installieren).

Dank eines Postings im siduction-Forum kann man VBox 5.1.22 für Kernel 4.12 patchen:

  1. Wechsel des Verzeichnisses:
    1
    
    cd /usr/share/virtualbox/src
  2. Ziehen des Patchfiles:
    1
    
    sudo wget http://paste.siduction.org/20170629003423 -O vbox.patch
  3. Ausführen des Patches:
    1
    
    sudo patch -Np0 < vbox.patch
  4. Installation (Mainline-)Kernel 4.12.

Update 2017-07-17: Durch Fixes in VirtualBox 5.1.24 benötigt es keinen Patch mehr für Kernel 4.12 und 4.13rc in Host/VM.

Lubuntu 16.04 zerrissene Grafik in VBox

Lubuntu 16.04 Final (!) bringt live in einer VBox-VM gebootet reproduzierbar mit dem Loginscreen eine völlig zerstörte Grafikausgabe im Kinoformat. Übliche Bootoptionen wie nomodeset oder xforcevesa helfen nicht. Will man ohnehin installieren, kann man dies mit Alternate install Images, die es glücklicherweise von Lubuntu noch gibt (vor 5 Jahren im Zuge der Anerkennung als offizielles Ubuntu-Derivat von Lubuntu als letztem Derivat noch eingeführt).

Als Live-System sowie generell (es gibt noch mindestens ein weiteres gravierendes Problem, überhaupt müssen sich Lubuntu-Devs in den letzten Jahren fragen lassen, ob sie auch nur ein Minimum üblicher Tests vor einem Release laufen lassen, ich erinnere da an doppelte network-manager-Icons oder schlechter gar keines, nicht haltende Tastaturbelegungen etc.) bieten sich jedoch Lubuntu 16.04.1 Daily Builds an.

Diese muß man nicht komplett neu laden. zsync hat vor zwei Wochen gegenüber x86-/x86_64-Finals je etwa 400 MiB gezogen.

Lubuntu bootet damit mit normaler Grafik. Sofern man von den witzigen 720×400 absieht, aber die kann man nun Dank im Kernel integriertem vboxvideo-Modul einfach ändern, auch ohne die Guest Extensions installiert zu haben (was man wegen der anderen Treiber, Shared Folders und c&p Host<>Guest natürlich trotzdem durchführt).

16.04.1 Final ist übrigens für 2016-07-21 geplant.
·

Nachtrag: Mit Pointrelease 1 ist das Problem unter damaliger VBox-Version erneut aufgetreten, jedoch nicht mehr mit v5.1.8, ebenso nicht mit Yakkety und aktueller VBox.

Dort, wo es auftritt, wechselt man kurz mit [rctrl] + [F1] auf die erste virtuelle Konsole tty1 der Lubuntu-VM und mit [rctrl] + [F7] wieder zurück.