VirtualBox 7.1.0 beta 1 released/update final

VBox-Logos merged

21 1/2 Monate nach Release von VirtualBox 7.0.0 ist 7.1.0 beta 1 erschienen. Auf den ersten Blick fällt das neue Logo auf, ob nun unter about im installierten Programm oder auf dem Cover des User Manuals. Man verabschiedet sich von der blau-weißen Box hin zu einem Flat Icon in neuer Farbgebung. Ist das bisherige Logo wahrlich altbacken, ist das neue vielleicht ein wenig zu modern, nunja.

Interessanter sind technische und Frontend-Neuerungen. Nur oberflächlich betrachtet mögen sie nicht sonderlich stark ausfallen. Zudem ist es eben die erste Beta (bei 7.0.0 sind es insgesamt drei und ein RC gewesen). So kommt bspw. die offizielle Unterstützung von macOS im Host auf AS hinzu. Die gibt es zwar bereits, aber nur in den 7.0er Testbuilds, nicht in Finals.

Dabei handelt es sich nicht um eine Emulation einer anderen Architektur (wie es qemu könnte). macOS auf AS ist arm-based, so müssen es auch etwaige VMs sein. Anders ist es auch beim originalen VBox für x64 nicht. Man kann also kein Win11/x64 in einer VBox/arm-VM laufen lassen, sondern müßte ein Win11/arm heranziehen. Offiziell zu kaufen gibt es das freilich bislang nicht (die Notebooks mit brandaktuellem Snapdragon X bringen Win11/arm mit, in 24h2, übrigens).

Linux/aarch64 oder eine entsprechende BSD sollten sich jedoch installieren lassen – oder technisch gesehen auch das macOS des Hosts, wie das auch mit Parallels möglich ist.

Hätte ich einen AS-Mac (den ich aber nur kaufen würde, um macOS nicht zu nutzen, sondern Asahi), wäre VBox 7.1.0b1 bereits installiert und in einer VM eine Linux-Distribution, vorzugsweise Arch.

VM VBox Manager

Grundlegende Änderungen im User Interface hat es von 6.1.x auf 7.0.x gegeben. Man bleibt jedoch nicht stehen. Im 7.1er VM VBox Manager (nun auf aktuellem Qt basierend – für den Screenshot ist es ein installiertes VBox 7.1.0b1 in einer VBox-7.0.20-Arch-VM in einem Arch-Host, was man real sicher nicht machen würde) kann man schneller auf Optionen zugreifen. Steht man auf einem Tab wie General, kann man auch die weiteren wie System etc. sehen, jenachdem, wie groß das Fenster gezogen ist.

Die weiteren wichtigsten Neuerungen und Änderungen können im Release Post nachgelesen werden.

Unter https://download.virtualbox.org/virtualbox/7.1.0_BETA2/ (aktualisiert 2024-08-20) können Pakete für im Host unterstützte Linux-Distributionsversionen, GA und EP gezogen werden.

·

Update 2024-10-15: VirtualBox 7.1.4 ist erschienen.
Update 2024-09-27: VirtualBox 7.1.2 ist erschienen.
Update 2024-09-11: VirtualBox 7.1.0 ist erschienen.

Die Schritt-für-Schritt-Anleitungen

sind entsprechend aktualisiert

Citrix WorkSpace app: Zertifikate unter Linux

Die proprietäre Citrix Workspace app for Linux krankt seit jeher daran, nur einige Zertifikate mitzubringen, meist nicht das benötigte. Eigentlich könnten sie’s auch ganz lassen und stattdessen die im System befindlichen verwenden. Das wäre saubere, konforme Arbeit.

Es existieren etliche Anleitungen im Netz. Folgend eine, die funktioniert (getestet in einer Debian-testing-VM und bereits mehrfach die Version aktualisiert – abgesehen von apt gilt dies im Prinzip auch für andere Distributionen).

  1. Installation des Pakets ca-certificates, falls nicht ohnehin installiert:
    sudo apt install ca-certificates
  2. Wechseln in das Directory mit dem icaclient-Paket (Direktlink ist nicht möglich, da dynamisch erzeugt).
  3. Installation von icaclient:
    sudo apt install ./icaclient*_amd64.deb
  4. Umbenennen des Citrix-eigenen cacerts-Directorys (für Vorsichtige, man könnte das auch gleich löschen):
    sudo mv /opt/Citrix/ICAClient/keystore/cacerts{,_orig}
  5. Erzeugen eines Softlinks:
    sudo ln -s /etc/ssl/certs /opt/Citrix/ICAClient/keystore/cacerts
  6. Zertifikatsspeicher aktualisieren:
    sudo /opt/Citrix/ICAClient/util/ctx_rehash

Anmerkung: Innerhalb der Installationsroutine des ICAClients gibt es eine Abfrage zu app protection component. Will man seine Entscheidung später revidieren, ist der ICAClient (wie auch unter Redmonds System) neu zu installieren.

User mißverstehen die Technologie oft, erwarten gleiches Funktionieren, als würde nicht auf einem Citrix-Server, sondern lokal ausgeführt werden. Für Video und dergleichen ist die Technologie nicht ausgelegt, entsprechend kann das bis zum Standbild ‘runtergehen (ich habe es erlebt, daß manche allen Ernstes yt-Videos über WSpApp haben sehen wollen…mit 1 Bild aller 2 Sekunden…).

Man kann es allerdings mit HDX RealTime Media Engine abmildern, insb. für MS Teams.

VBox-Kernel-Module bauen nicht mit Linux 6.4.10

Mit dem aktuellem Linux-Kernel 6.4.10 (2023-08-11) im Host können keine VirtualBox-Kernel-Module gebaut werden (Bugreport). Das betrifft sowohl 7.0.10-158379 (2023-07-13) als auch Testbuild 7.0.11-158681 (2023-08-04). Den Development Snapshot 7.0.97-158691 habe ich nicht getestet, da nur 7 h neuer als der Testbuild und damit ebenso zu alt.

Einstweilen Zurückgehen auf Kernel 6.4.9 – hier besteht das Problem noch nicht – wäre zwar eine Möglichkeit (aber keine für mich, Kernel ist Grundlage, so wichtig mir Virtualisierung auch ist).

Erste Linux-Distributionen, die VBox ausliefern, haben einen Patch eingepflegt, ganz vorn wie immer Arch Linux in die in den Arch-Repositories befindliche VBox-Version 7.0.10-2.

Wo dies noch nicht geschehen ist, z.B. in den .run-Versionen, kann man mit root-Rechten selbst editieren:

# sed -i 's/#if RTLNX_VER_MIN(6,5,0)/#if RTLNX_VER_MIN(6,4,0)/g' /usr/src/vboxhost-7.0.10/vboxnetflt/linux/VBoxNetFlt-linux.c
# /sbin/vboxconfig

Btw., man kann natürlich auch libvirt/VMM nutzen.

·

Update 2023-08-16: Im heutigem Testbuild VirtualBox-7.0.11-158813-Linux_amd64.run ist das Problem gefixt.

Audio-Aussetzer beim Player-Start

Beim Doppelklick auf ein Audio- oder Video-File startet der entsprechend eingestellte Player, z.B. vlc, dieser lädt das A/V-File und spielt es ab. Seit geraumer Zeit gibt es jedoch gleich zu Beginn eine Art Aussetzer, es scheint, als würde der Player stolpern.

Ursache ist das schlafen Legen der SPU, die da offensichtlich nicht mit dem Aufwecken von jetzt auf gleich klar kommt. Für das jeweilige Sound-Modul kann man dies abfragen, hier für snd_hda_intel:

$ cat /sys/module/snd_hda_intel/parameters/power_save

Ergibt dies erwartbar 1, ist der Sleep Mode aktiv. Man kann ihn deaktivieren, hier wieder für Intel:

$ echo "options snd_hda_intel power_save=0" | sudo tee -a /etc/modprobe.d/alsa-base.conf

OpenWrt 22.03.x

Nachdem vor 3 Tagen ein Security Fix für wolfSSL erschienen ist (dies hat anfangs Abhängigkeitsfehler beim Update bereitet, die im Laufe des frühen Abends behoben worden sind), was man einzeln hat einspielen können bzw. müssen, ist nun mit weiteren Fixes und Updates OpenWrt 22.03.1 erschienen. Für die einzelnen Chipsets bzw. Devices sind sie heute über den Tag verteilt auf den Server gelegt worden.

Wie üblich ist die neue Version noch einige Tage mit “Work-in-progress release!” gekennzeichnet.

2022-10-12: wip-Kennzeichnung entfernt.
2022-10-15: OpenWrt 22.03.2.
2023-01-05: OpenWrt 22.03.3.
2023-04-11: OpenWrt 22.03.4.
2023-04-28: OpenWrt 22.03.5.
2023-10-13: OpenWrt 23.05.0.

VirtualBox 7.0.0 final

Nach 3 Betas und diesmal keinem Release Candidate ist die Final von VirtualBox 7.0.0 (akt. 7.0.8) erschienen. Hinzugefügt worden sind u.a. virtuelles Secure Boot, virtuelles TPM 1.2/2.0, und virtuelle IOMMU. Mit UEFI, vSB und vTPM ist nun auch Windows 11 ohne weitere Tricks in VMs möglich, sofern die anderen willkürlichen Anforderungen (Core i gen 8, 64 GiB vSSD/vHDD, 4 GiB RAM) erfüllt sind. Zudem ist der Wizard zur Erstellung von VMs überarbeitet worden.

Die Schritt-für-Schritt-Anleitungen

sind entsprechend aktualisiert.

Wer das Repository hinzugefügt hat, muß VBox 6.x deinstallieren und explizit 7.x installieren:

$ sudo apt purge virtualbox*
$ sudo apt install virtualbox-7.0

Wechsel Wayland zu XServer

Mit Ubuntu 22.04 wird der Display-Server bekanntlich default von X11 (xorg) auf Wayland gewechselt – nicht nur bei einer Neuinstallation, auch bei einem Distupgrade. Seitdem und insbesondere seit erstem Pointrelease (hier wird Focal-Usern das Distupgrade angeboten) schlagen in einem bekannten Forum permanent Hilfeersuchen der unterschiedlichsten Art auf, die freilich allesamt in Inkompatibilitäten zu Wayland ursächlich sind.

Um nicht ständig neu den Wechsel zurück auf XServer erklären zu müssen, hier die Möglichkeiten:

Über den Loginscreen:
Wechsele auf dem Loginscreen, bevor Du Dich anmeldest, über das stilisierte Zahnrad von Wayland zu XServer, hier betitelt mit “Ubuntu” und “Ubuntu on xorg”!

Im Terminal:

  1. Starte den Editor:
    $ sudo nano /etc/gdm3/custom.conf
  2. Entferne aus
    #WaylandEnable=false

    das Doppelkreuz am Anfang!

  3. Speichere und beende den Editor!
  4. Reboote:
    $ sudo reboot

Google Chrome: Pubkey nicht verfuegbar

Derzeit gibt es unter Ubuntu wieder Ausgaben wie diese:

Err: http://dl.google.com/linux/chrome/deb stable InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E88979FB9B30ACF2
(...)
W: GPG error: http://dl.google.com/linux/chrome/deb stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E88979FB9B30ACF2
E: The repository 'http://dl.google.com/linux/chrome/deb stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Wieder sagt es schon, das Problem ist alles andere als neu. Googles verlinkter linux_signing_key.pub ist erneut veraltet, ohne, daß er gewechselt worden ist. Hinzu kommt, daß apt-key deprecated ist, sprich veraltet, soll demnächst nicht mehr funktionieren. Nur, daß das in dem Fall bereits so ist.


Nachfolgendes Vorgehen habe ich bereits in einem Linux-Forum beschrieben, hier im Blog kann ich es jedoch ggf. anpassen.

  1. Google-Fremdquellen entfernen:
    $ sudo rm sudo rm /etc/apt/sources.list.d/*google*.list*
  2. Aktuellen gpg-Key ziehen und direkt ins Verzeichnis schreiben:
    $ sudo mkdir /root/.gnupg/
    $ sudo gpg --no-default-keyring --keyring /usr/share/keyrings/google.gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys E88979FB9B30ACF2
  3. Gewünschte Google-Fremdquellen mit gpg-Pfad hinzufügen:
    • Google Chrome:
      $ echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/google.gpg] http://dl.google.com/linux/chrome/deb/ stable main' | sudo tee /etc/apt/sources.list.d/google_chrome_stable.list
    • Google Earth:
      $ echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/google.gpg] http://dl.google.com/linux/earth/deb/ stable main' | sudo tee /etc/apt/sources.list.d/google_earth_stable.list
  4. Paketquellen, Paketquelleninhalte und installierte Pakete aktualisieren:
    $ sudo apt update && sudo apt full-upgrade

2024-04-10: Pubkey aktualisiert

Chromium: fehlendes SSE3-Flag

Der Start eines aktuellen Chromiums oder dessen Code nutzender anderer Browser auf AMD Phenom II X6/4/3/2 ist nicht möglich, es kommt zu folgender Ausgabe:

The hardware on this system lacks support for the sse3 instruction set.
The upstream chromium project no longer supports this configuration.
For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/1123353

CPUs haben Befehlssätze, denen Befehlssatzerweiterungen hinzugefügt worden sind. Die wohl bekannteste dürfte MMX sein (was man eben 1997 unter Multimedia verstanden hat), die damals dem Pentium 1 auch im Produktnamen erkennbar als z.B. Pentium 166 MMX beigegeben worden ist.

Fragt man heute unter Linux mit

$ lscpu

oder gefiltert

$ lscpu | grep Flags

ab, wird eine ziemliche Menge solcher Befehlssatzerweiterungen gelistet. So gibt es bspw. SSE-Flags in Versionen. Genannte Phenoms haben zwar die Erweiterungen SSE1, SSE2, SSE3 und SSE4a (typische Mogelpackung AMDs, es liegt nicht SSE4 zugrunde, sondern es ist SSE3 plus 4 zusätzlicher Befehle), aber das Flag sse3 wird nicht ausgegeben, sondern bei diesen CPUs dessen alternative Bezeichnung pni.

D.h., Software kann SSE3 nutzen, wenn es allerdings deren Vorhandensein über Flag sse3 abfragt, fehlt für diese eben SSE3.

Das Ganze erinnert mich an Pentium M Banias und Dothan FSB100, denen das PAE-Flag fehlt (Ubuntu ab 12.04 ist damals 2 Jahre lang nicht ohne Tricks installierbar gewesen, ich habe hier diesbzgl. mehrere Posts geschrieben gehabt). Eine der Möglichkeiten ist das Hinzufügen des Flags in /proc/cpuinfo gewesen (ich habe es damals anders gelöst, die PAE-Abfrage aus dem jeweiligen Paket umgebogen). Dies können sich Phenom-User auch heute zu Nutze machen.

“/proc/cpuinfo” kann nicht direkt geändert werden. Daher kopieren wir deren Inhalt in eine neue Datei und fügen das Flag “sse3” hinzu (Kleinschreibung). Diese binden wir dann entsprechend ein.

#!/bin/sh
# 2022-09-05

$ sed 's/flags\t*:/& sse3/' /proc/cpuinfo > /tmp/cpuinfo_sse
$ mount -o bind /tmp/cpuinfo_sse /proc/cpuinfo
$ mount -o remount,ro,bind /proc/cpuinfo

exit

Man kann diese 3 Befehlszeilen (entnommen aus fake-pae.conf im Paket fake-pae von Bernd Kreuss und entsprechend angepaßt) einzeln über c&p ausführen (mount jeweils mit root-Rechten), man kann sinnvollerweise das Ganze als z.B. “/usr/local/bin/sse3flag.sh” speichern, mit

$ sudo chmod +x /usr/local/bin/sse3flag.sh

ausführbar machen und mit root-Rechten aufrufen. Letzteres bietet sich im Autostart an.

Dazu erstellt man eine Service Unit “/etc/systemd/system/sse3flag.service” mit folgendem Inhalt:

[Unit]
Description=add the SSE3 flag

[Service]
Type=simple
ExecStart=/usr/local/bin/sse3flag.sh

[Install]
WantedBy=multi-user.target

Mit

$ systemctl enable --now sse3flag.service

wird der Service permanent aktiviert (übersteht also Reboots) und gleich gestartet. Eine erneute lscpu-Abfrage gibt nun auch “sse3” aus. Da ich eine richtige ]:-) CPU habe, habe ich zum Test spaßeshalber “sse6” ;-) gesetzt – funktioniert.