VirtualBox: Unable to locate imported symbol ‘memset’

Nach der Installation von VirtualBox-6.1.34-150636*.’deb\|rpm’ (Filedate 2022-03-23) in entsprechenden Linux-Distributionen kommt es nach Startversuch einer beliebigen VM zu folgender VBox-Ausgabe:

Failed to load R0 module /usr/lib/virtualbox/VBoxDDR0.r0: Unable to locate imported symbol 'memset' for module 'VBoxDDR0.r0' (VERR_SYMBOL_NOT_FOUND).
Failed to load ring-0 module 'VBoxDDR0.r0' for device 'pci' (VERR_SYMBOL_NOT_FOUND).
 
 
Result Code:  NS_ERROR_FAILURE (0x80004005)
Component:  ConsoleWrap
Interface:  IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

Als temporären Workaround oder auch generell kann man die Paketversion deinstallieren und die .run-Version installieren (wer Testbuilds installiert wie ich, macht das eh):

VitualBox: Installation ueber .run

Ein Zurückgehen auf die veraltete 6.1.32 ist weder notwendig noch empfehlenswert.

Update 2022-04-21: Es sind neue Builds für virtualbox-6.1_6.1.34-150636* nachgeschoben worden (.1 für .deb, -2 für .rpm).

Arch Linux 2022.01.01, Image in VBox nicht UEFI-faehig

Um in einer VBox-VM statt im CSM-Mode (Compatibility Support Module, das UEFI verhält sich, als sei es ein BIOS) im UEFI-Mode zu booten, ist lediglich im “VM VirtualBox Manager” unter System → Motherboard → Extended Features “Enable EFI (special OSes only)” zu aktivieren. Alternativ in einem Terminal:

1
vboxmanage modifyvm "VM name" --firmware efi

Selbstverständlich muß das zu bootende Image so oder hybrid erstellt worden sein (ein installiertes System sowieso). Das einfache Bootmenu von Arch Linux erscheint dann wie folgt:

Nicht so beim aktuellen Image archlinux-2022.01.01-x86_64.iso. Die Arch-Einträge fehlen, schlicht da das Image in VBox-VMs im UEFI-Mode nicht boot-fähig ist. Nativ soll es OK sein.

Man kommt nur in die EFI Shell oder das rudimentäre UEFI-Menu. Änderungstests in letzterem oder im VM-Manager sind erfolglos. Andere UEFI-fähige Distributions-Images, bspw. ein mit isorespin.sh angepaßtes Lubuntu oder das aktuelle EndeavourOS booten anstandslos, ebenso Arch-Images davor.

Ursächlich soll systemd 250.1-1 sein, es gibt einen Bugreport dazu bei archlinux.org. So es so ist, müßte dann, da Upstream, jedoch einer bei systemd erstellt werden.

Erhärtet wird es, da ein User ein Image mit systemd 249.x erstellt hat, das entsprechend boot-fähig ist. Jener bietet es zwar zum Download an, ein OS-Image von irgendjemandem verändert, so nett es gemeint ist, würde ich jedoch nicht verwenden.

Ebensogut könnte es ein Zusammenspiel mehrerer Faktoren, d.h. mit VBox sein, würde also (auch) dorthin gehören. Freilich nutze ich prinzipiell die jeweils aktuelle Version, sprich Testbuilds, derzeit 6.1.31 (das letzte ist knapp 4 Wochen alt, jetzt könnte so langsam mal wieder was kommen, manchmal gibt’s 3 Versionen pro Woche). In besagten Threads wird 6.1.30 final verwendet.

Wer jetzt Arch Linux in einer VBox-VM mit UEFI installieren will (mit CSM gibt es kein Problem), kann 2021.12.01 heranziehen – hat dann natürlich erheblich zu aktualisieren, was bei arch durch permanente Updates aber ohnehin der Fall ist – oder mit 2022.01.01 in der EFI Shell folgendes aufrufen:

1
FS1:\EFI\BOOT\BOOTx64.EFI

Das installierte System scheint keine UEFI-Boot-Probleme mit aktuellem systemd in VBox-VMs zu haben.

Update 1: Zwischenzeitlich ist upstream ein Bugreport für systemd erstellt worden.

Update 2: Der Commit boot: Fix readdir_harder() on VirtualBox für systemd ist 2022-01-10 Spätabend hinzugefügt worden, Arch Linux liefert systemd 250.2-2 damit in testing bereits aus. Das Februar-Image sollte dann dahingehend problemlos boot-fähig sein.

Update 2022-01-18: Die heutige (eigentlich vom 13.) Final VBox 6.1.32 löst zwar das Problem, Arch Linux 2022.01.01 zeigt im UEFI-Mode das vollständige Menu und kann folgerichtig booten. Jedoch bringt VBox 6.1.33-149396 das Problem zurück.

Update 2022-02-01: archlinux-2022.02.01-x86_64.iso funktioniert dahingehend korrekt.
FYI: Das wenige Stunden zuvor von testing nach extra gewanderte archinstall 2.3.1 ist enthalten.

Streams in vlc abspielen

Streams einer bekannten Videoplattform sind dafür vorgesehen, im Browser zu laufen. Um darüber hinausgehendes zu verhindern, werden ständig neue technische Rafinessen ersonnen (man denke nur an Fragmentierung des Videos, separate Audiospuren etc.).

vlc hat man bis vor geraumer Zeit durch Aufruf des Stream-URLs noch nutzen können. Derzeit stockt die Wiedergabe jedoch aller paar Sekunden – unbrauchbar. In Foren wird nach Lösungen gefragt. Tips, man solle doch smplayer nehmen (ohnehin nur ein Frontend für mplayer oder mpv), verkennen, daß dieser selbst derartige Streams gar nicht abrufen kann, sondern sich eines bekannten Zusatz-Tools bedient.

Ich betone, es soll ausschließlich um die Wiedergabe des temporär nur dafür im Cache gehaltenen Streams gehen. Also das, was ein Browser auch nur macht, aber ein Player technisch besser könnte, wenn ihm kein Bein gestellt wird (die Systembelastung ist merklich geringer, insbesondere unter Linux, dort haben Browser i.d.R. keine wirkliche Hardware-Beschleunigung).

vlc nutzt für Quellen entsprechende Playlists, eine Art Profile. Arch-based sind sie unter “/lib64/vlc/lua/playlist/” abgelegt, in debian-basierten Systemen unter “/usr/lib/x86_64-linux-gnu/vlc/lua/playlist/”. Default sind es .luac-Files. Es werden jedoch nicht nur Kompilate, also Binaries, erkannt, sondern auch .lua-Files.

Man benötigt keine neue vlc-Version (auch ein 4.0er nightly-snap soll nicht helfen), man kann das entsprechende .luac-File durch ein .lua-File (logscherweise raw) ersetzen.

In EndeavourOS ist das Problem damit behoben, ebenso in einer LFocal-VM (dort hat es bisher gar nicht abgespielt werden können), in einer Debian-testing-VM stockt es noch. Es sind unterschiedliche vlc-Versionen. Generell funktioniert es also – derzeit – wer es wirklich braucht (für mich ist es lediglich eine interessante technische Problemstellung gewesen), müßte in letzterem weitersuchen, bspw. Konfigurationen (VM, vlc,…) vergleichen.

VBox: shared clipboard in v6.1.4

In VirtualBox v6.1.4 funktioniert das shared Clipboard zwischen Linux-Host und Linux-Guests nicht (paste ist ausgegraut). Genaugenommen bereits seit VBoxGuestAdditions_6.1.3-135994.iso, zumindest habe ich das Fehlverhalten dort schon bemerkt gehabt, es aber für’s Erste mit dem zu der Zeit gerade neu installierten Host mit anderer Linux-Distribution in Verbindung gebracht. Ursächlich sind aber tatsächlich die GA. Seit 9 Tagen gibt es auch Bugreport und Diskussion(en), wie dem zu begegnen wäre.

Es sind auch wirklich nur die GA, d.h. man kann 6.1.2, die vorige Final, installieren, sicherlich auch ein 6.1.3er dev-build vor obiger Version, so man noch hat.

Seit nicht mal einer Stunde gibt es (endlich wieder) ein aktuelles trunk dev-snapshot (VBoxGuestAdditions_6.1.97-136310.iso), so eine typische Versionsnummer .97 dafür. Damit funktioniert Linux-Host <> Linux-Guest wieder einwandfrei. VirtualBox-6.1.97-136310-Linux_amd64.run muß man nicht installieren.

Lieber mögliche neue Bugs als sichere alte Bugs. ;-)

Update: Statt des Snapshots kann seit 2020-03-04 das jeweils aktuelle 6.1.5er Testbuild verwendet werden.

VBox: stuttering in yt

VMs in VBox eignen sich für wirklich vieles, aber nicht gerade für yt. In Firefox (und wohl auch Chromium) starten Videos nicht wirklich, es wird scheinbar ewig gebuffert. Man muß mehrfach stoppen und starten, bis es weiter geht…ein wenig.

(Nicht nur) in diesen Browsern gibt es unter Linux keine Hardware-Unterstützung durch die GPU, geplant ist bislang auch nichts (nicht mal im closed source Chrome). D.h., das Rendering hat die CPU in Software zu übernehmen. In nativen Linux-Installationen macht sich das nicht bis kaum bemerkbar, so man nicht gerade eine Schippe Sand als CPU hat. In VBox-VMs allerdings eben schon, zumal die GPU-Treiber VBoxSVGA und VMSVGA dahingehend auch nicht die stärksten sind.

In altägyptischen Flash-Zeiten hat es mal den Workaround gegeben, per Rechtsklick (oder auch kleiner Konfigurationsdatei) im Video HW-Unterstützung zu deaktivieren, also das, was eh nicht da ist. Flash, ohnehin nie für Videos gedacht, ist aber tot (und nein, solchen Dreck installieren wir auch nicht, User ohne Plan aus einem bestimmtem Forum), mithin auch diese Einstellmöglichkeit.

Das problematische OpenGL in Hardware ausknipsen hilft bei diesem Fehlerbild auch nicht. Auch nicht, den Original-Firefox zu verwenden statt des Kompilats der jeweiligen Linux-Distribution (in debian gibt es gerade mal ein Problem, was so umgehbar ist). Alles bereits ausprobiert.

In Fx’ “about:config” gibt es mehrere Probanden, die zu testen wären. Ohne die Ursache zu kennen, ist das aber eher ein trial & error. Defaults eines frischen Profils bringen auch nichts.

Nun hat das Ganze früher mal ohne zu stottern funktioniert. Da es für mich aber keine Priorität hat (ja, das gibt es, User ohne Plan aus einem bestimmtem Forum), bin ich dem bislang nicht nachgegangen.

Um zum Punkt zu kommen, yt streamt in VP8/VP9. Eine Hardware-Unterstützung gibt es dafür bisher kaum, wohl aber für H.264. Als Linux- und OSS-Verfechter würde man natürlich lieber ein freies Format verwenden, an der Stelle muß man abwägen.

Allein Codecs installiert zu haben, genügt nicht. Dem Browser muß gesagt werden, daß er H.264 verwenden, d.h. von yt anfordern soll. Gibt’s sicherlich auch eine Möglichkeit unter “about:config”, denn etwas anderes wird das Fx-Add-on h264ify auch nicht verändern. Als Quickfix mag es genügen – und es funktioniert einwandfrei.

Btw., wenn man ein Add-on zum Ändern des User Agents installiert hat, kann man auch eine brauchbare Kombination aus OS und Browser ermitteln, dann wird H.264/mp4 gestreamt und man braucht nichts extra.

VirtualBox: libvpx5, libvpx6

virtualbox.org bietet derzeit Ubuntu-deb-Pakete nur für die letzten “LTS”-Versionen an. Üblicherweise sind diese auch für die normalen Versionen dazwischen nutzbar, sofern Abhängigkeiten erfüllt werden. So hat man VBox 6.0.14 für Bionic auch unter Cosmic und Disco installieren können. In Eoan schlägt dies allerdings fehl, da “libvpx5 (>= 1.6.0)” durch libvpx6 ersetzt worden ist.

Möglichkeiten – oder, nicht und:

  • Manuelle Installation von libvpx5 aus Disco in Eoan:
    1
    2
    
    wget http://archive.ubuntu.com/ubuntu/pool/main/libv/libvpx/libvpx5_1.7.0-3_amd64.deb
    sudo dpkg -i libvpx5_1.7.0-3_amd64.deb

    Updates dafür gibt es so natürlich keine, man muß sich selbst darum kümmern. Vor allem sollte man diese Geschichte nicht vergessen und sie wirklich nur als temporäre Sache sehen und libvpx5 bei nicht-mehr-Nutzung wieder purgen.

  • Für Eoan gibt’s 6.0.14-dfsg mit der Abhängigkeit “libvpx6 (>= 1.6.0)” in den Ubuntu-Repositories. Bis Ubuntu wie üblich wieder abgehängt wird, kann man diese Version installieren, vorher aber tunlichst die virtualbox.org-Version deinstallieren.
  • Alternativ zu deb-Paketen kann man .run installieren (für Updates gilt dasselbe). Benötigt man Testbuilds (bspw. ist VBox 6.0.15-134529 mit Kernel 5.4-rc7 im Host kompatibel), kommt man sowieso nicht umhin.

Update 2019-12-11: VBox 6.1.0 liegt auch als .deb für Eoan vor, d.h. dort ist libvpx5 keine Abhängigkeit.

VBox 6.0.13 laeuft mit Kernel 5.3 im Host

Vor zwei Tagen ist Kernel 5.3 erschienen, die ersten Distributionen beginnen, ihn auszuliefern. Klar, keine verstaubten á la Long Term Sleeping, sondern die, die stets vorn dran sind, so arch bzw. arch-basierte wie endeavouros.

Mit VirtualBox hat man bis gestern auch keine 5.3rc nutzen können. Mit Testbuild VirtualBox-6.0.13-133347-Linux_amd64.run (GA 6.0.13-133316, EP 6.0.13-133347) wird nun ordentlich gebaut, VMs starten und laufen. Tests mit endeavouros und siduction als Hosts.

Btw., VBox 6.1.0b1 ist erschienen (dev-snapshots auf der testbuilds-site sind bereits höher, mehr bleeding edge geht dann aber nicht). Wie ich vor 4 Wochen schon geschrieben habe, VBoxVGA ist nun entfernt worden, es ist also auf VBoxSVGA oder, dort, wo es nicht crashed, VMSVGA zu wechseln.

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.

endeavouros, das Image

endeavouros logo
Spielt man mit Links, kann man mit ein wenig Phantasie endeavouros bereits ziehen, auch wenn auf der Website noch nicht offiziell verkündet. Ich bin fair und verrate ihn nicht. :-p

Jedoch weise ich auf bekannte Probleme der Installation hin. Diese hat es auch bei der dritten Vorabversion gegeben (neben kleineren Geschichten). Gerade was die Partitionierung oder (von mir sowieso abgelehntes) Dualboot angehen, sollte man bedacht vorgehen.

Genaugenommen ist das Ganze mit den Problemen noch kein Final Release, aber sei’s drum! Von einer Verschlüsselung derzeit noch abgesehen (ursächlich diese Calamares-Version, upstream zu beheben) ist alles umgehbar.

Tip von mir noch zu einer Installation in einer VBox-VM: Sowohl CSM/MBR als auch UEFI/GPT sollten möglich sein, jedoch sollte als virtuelle GPU VBoxSVGA, nicht VMSVGA (der VMware-Treiber) gewählt werden. Bei letzterer bleibt das Booten einfach stehen.

Nachtrag: So, jetzt ist endeavouros offiziell freigegeben.

Btw., auf Nachfrage Interessierter nach einem Torrent meint Bryanpwo, Project Leader, “Later this week (…).”. Dabei wäre es gerade direkt nach Freigabe, also jetzt, besonders sinnvoll. Man merkt, wie der Server (Strato…) in die Knie geht.

Eine knappe halbe Stunde danach ;) hat das Team weitere Links auf github bereitgestellt, auch zu endeavouros-2019.07.15-x86_64.torrent. Prima.

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.