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.

Bodhi Linux…Gruss aus der Gruft

Möglicherweise denkt der Eine oder Andere, ich hätte einen uralten Bodhi-Linux-Blogpost ‘rausgekramt. Tatsächlich ist nach langem Siechtum und einem dortigem Fahnehochhalten-Artikel letzten Juni heute Bodhi Linux 5.1.0 released worden.

Symptomatisch: je weniger Manpower, desto mehr Versionen.

Bodhi Linux setzt bekanntlich auf Ubuntu Long Term Sleeping auf, hier also 18.04. Wenn dessen offizielle Flavors wie Lubuntu EoS erreicht haben, also in 1 Jahr, ist automatisch Schluß mit x86_32. Wozu dann jetzt noch eine solche Bodhi-Version?

Read more “Bodhi Linux…Gruss aus der Gruft”

arch: initramfs-linux-fallback.img, errors during the build

Mit in arch aktiviertem testing wird derzeit mittels mkinitcpio initramfs-linux-fallback.img mit einer error-Msg gebaut:

~$ sudo mkinitcpio -p linux
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.5.5-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.5.5-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: wd719x
==> WARNING: Possibly missing firmware for module: aic94xx
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
cp: cannot stat '(builtin)': No such file or directory
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
~$

Warning, daß errors… ;) Wie man sieht, tatsächlich nur für fallback, nicht normal. Das Gleiche ergibt sich, wenn man für einen etwaigen Notfall linux-lts-image (das wäre 5.4, so weit sind andere Distributionen noch nicht mal) installiert hat. An der Kernel-Version liegt es also nicht.

Postings über die Jahre mit dieser Ausgabe sind durchwachsen. Einer meint, er habe den Komprimierer in “/etc/mkinitcpio.conf” geändert. Gut, kann man ja mal probieren – vielleicht gibt’s mit default gzip ja ein Problem – so am halboffenen Herzen, grin. Interessant ist’s allemal (xz dürfte die beste Komprimierungsrate haben, dafür dauert dann mkinitcpio deutlich länger, man braucht auch gar nicht komprimieren, wenn man cat setzt), löst aber das Problem nicht.

In anderen Threads wird von nvidia oder VBox gesprochen. Hier nix nvidia, sondern nouveau. VBox ist freilich vor zwei Tagen in v6.1.4 erschienen (wie üblich habe ich sämtliche 6.1.3er Testbuilds installiert gehabt, ohne Trara). Schrittweise Testdeinstallation von virtualbox-host-modules-arch, des ExtensionPacks und VBox’ selbst…außer Spesen nix gewesen.

Um es nun ;) kurz zu machen, ursächlich ist kmod 27-1. Mit 26-3 läuft mkinitcpio sauber durch.

  1. Installation von kmod-26-3-x86_64.pkg.tar.xz aus dem PackageCache:
    1
    
    sudo pacman -U /var/cache/pacman/pkg/kmod-26-3-x86_64.pkg.tar.xz
  2. kmod in “/etc/pacman.conf” mit “IgnorePkg = kmod” auf hold setzen.
  3. initramfs*.img neu bauen:
    1
    
    sudo mkinitcpio -p linux

Wenn man sowas macht, muß man

  • auf Abhängigkeiten achten (andere Pakete, die ggf. mit gedowngradet werden müssen),
  • diese Änderung im Hinterkopf behalten, denn die stellt selbstverständlich keine Dauerlösung dar, sprich nach Bugfixing ist wieder der Paketeintrag von IgnorePkg zu nehmen.

Hat man den Paketzwischenspeicher bereits geleert gehabt, kann man sich kmod über archlinux.org/packages ziehen (solange es da in 26-3 noch liegt, grin).

Btw., es gibt zwar ein Helferlein namens downgrade, Installationen aus AUR sollte man allerdings auf persönlich wirklich unverzichtbares minimieren. Und so selten, wie derartiges in arch trotz Rolling Release Distribution und aktiviertem testing vorkommt…das ist QA!

Update: Ein zwischenzeitlich erfolgtes Update von mkinitcpio fixt obiges Problem. Ergo in “/etc/pacman.conf” die “IgnorePkg”-Zeile wieder mit “#” auskommentieren und mit pacman aktualisieren.

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.

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 arch-based und mit 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.

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).

Ubuntu: Kernel-Inkonsistenzen

Das muß mir mal jemand erklären…

PackagePPAReleaseUpdatesProposed
bionic/linux4.15.0-44.474.15.0-20.214.15.0-43.464.15.0-44.47
bionic/
linux-hwe
4.18.0-14.15
~18.04.1
4.18.0-13.14
~18.04.1
4.18.0-14.15
~18.04.1
cosmic/linux4.18.0-14.154.18.0-10.114.18.0-13.144.18.0-14.15
disco/linux4.18.0-11.124.19.0-11.12

…nicht wirklich.

Nach dem Desaster vor einem Jahr (1, 2, 3), bei dem Canonical (sicherlich nicht nur) bei mir jegliche Reputation verloren hat (Unbrauchbarmachung von Hardware – nur wer auf CSM only gesetzt gehabt hat, ist auf entsprechenden Boards dem GAU entgangen – und vor allem der Umgang mit dem massiven Problem), ist man dort seitdem von Konservatismus beseelt, sozusagen ins Gegenteil verfallen (wenn man mal annimmt, bislang seien sie up-to-date gewesen, zumindest in ihrem Rahmen).

Read more “Ubuntu: Kernel-Inkonsistenzen”

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.

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”

Lubuntu 18.04 Bionic Beaver torrents

Torrents für das heutige Release Lubuntu Bionic Beaver:

Kerndaten:

  • Kernel: 4.15 (bereits EOS seitens der Kernel-Entwickler, dafür will ausgerechnet Canonical tatsächlich 5 Jahre Support (liegt in main) in dafür nötiger Eigenverantwortung bieten – aktuell ist 4.16(.4), in Entwicklung 4.17, derzeit rc2)
  • XServer: 1.19
  • Mesa: 18.0.0~rc5 (aktuell ist 18.0.0)
  • systemd: 237 (aktuell ist 238)

Artful erreicht 2018-07-19 EoS, bis dahin muß gedistupgradet worden sein. Das erste Bionic-Pointrelease ist für 2018-07-26 geplant. Ab dann können träge “LTS”-User von Xenial offiziell distupgraden.

·

2020-08-13: Pointrelease 5 mit Focal-HWE.

2020-02-12: Pointrelease 4 mit Eoan-HWE.

2019-08-08: Pointrelease 3 mit Disco-HWE (Kernel und XServer) soll um eine Woche verschoben im Laufe des Tages erscheinen.

2019-02-14: Live-Images auf Pointrelease 2 aktualisiert, enthalten HWE aus Cosmic (aber bleiben “LTS”-altbacken).

2018-07-26: Live-Images auf PR 1 aktualisiert. Alternate-Images bleiben bei 0.

2018-05-08: Das 2018-10-18 (siehe Paket distro-info-data) erscheinende 18.10 hat heute den Codename Cosmic Cuttlefish erhalten. Offensichtlich hat sich das Gerücht “Cosmic Canimal”, das selbst auf cdimage.ubuntu.com über Ubuntu und den diversen Derivaten steht – immer noch – nicht bewahrheitet (das wäre auch ziemlich albern gewesen, vermutlich werden aber eher lizenzrechtliche Gründe dagegen gestanden haben – und zu OSS paßt derartige Werbung für ein kommerzielles (Fremd-)Produkt auch nicht).