[abgehakt] VirtualBox: Automatisches Rebuild VBox-Guest-Additions nach Kernel-Upgrade

[TomL]

Moin @ all

Gibt es eigentlich eine Möglichkeit, dass die Guest-Additions automatisch nach oder mit einem Kernel-Upgrade erstellt werden? Im Moment ist es so, dass nach dem Update der Vollbild-Modus nicht mehr geht, VGA oder SVGA o.ä. ist dann eingestellt, die Mouse reagiert auch anders. Ich muss dann jeweils manuell die Additions neu erstellen und rebooten, und dann gehts wieder. Auf meinen Rechnern ist das nicht so das Problem, aber auf den anderen schon, weil die User das nicht selber können.

[ThorstenS]

Ich nehme die offz. Paket und bin nach dieser Anleitung vorgegangen: https://www.linuxtechi.com/install-virt ... 9-stretch/
Damit habe ich die von dir erwähnten Probleme nicht.

[mludwig]

Für automatische Kernel-Module sind die DKMS-Pakete gedacht, hier virtualbox-dkms (für den Host) und virtualbox-guest-dkms (für den Gast).

Damit das funktioniert muss vorher dkms und build-essential installiert sein. Für das Paket dkms ist linux-headers-xxxx nur als empfohlen (Recommends) drin, aber wer den kernel nicht selber kompiliert sollte das auf jedenfall auch die Header-Pakete passend zum eigenen Kernel mit installieren. Dann sollte er automatisch mit jedem Kernel-Upgrade die Module neu erstellen.

Die Beschreibung im Ubuntu-Wiki ist übrigens besser als bei Debian *hüstel* https://wiki.ubuntuusers.de/DKMS/

[hikaru]

Wenn das zum Kernel passende Headers-Paket installiert ist (kommt automatisch über das entsprechene Metapaket, z.B. linux-headers-amd64), dazu virtualbox-guest-dkms und das zur entsprechenden VBox-Funktion passende Modulpaket (für Bildschirmanpassung virtualbox-guest-x11), dann wird das Modul beim Kernel-Upgrade automatisch für den neuen Kernel gebaut.

[owl102]

Seit VirtualBox 5.1 wird DKMS nicht mehr verwendet: https://www.pro-linux.de/news/1/23625/o ... s-aus.html

Stattdessen wird beim Start von VirtualBox geprüft, ob die Module zum Kernel passen und ggf. neu gebaut. Merkwürdig, daß das bei TomL nicht funktioniert, und eigentlich sollte es dann auch eine Fehlermeldung geben. (Und ein Log, wo man nachschauen kann, was warum nicht geklappt hat.)

[hikaru]

Seit VirtualBox 5.1 wird DKMS nicht mehr verwendet: https://www.pro-linux.de/news/1/23625/o ... s-aus.html

Was macht dann virtualbox-guest-dkms?

Wenn ich mir die (leider spärlich dokumentierten) Veröffentlichungshinweise zu 5.1b1 anschaue, dann vermute ich, dass VBox seitdem lediglich ohne dkms funktionieren KANN, das aber nach wie vor eine Option ist, die auch für die Pakete von Debian benutzt wird. [1]

[1] https://forums.virtualbox.org/viewtopic ... 15&t=77998

[towo]

Wenn ich mir die (leider spärlich dokumentierten) Veröffentlichungshinweise zu 5.1b1 anschaue, dann vermute ich, dass VBox seitdem lediglich ohne dkms funktionieren KANN, das aber nach wie vor eine Option ist, die auch für die Pakete von Debian benutzt wird. [1]

Falsch, Upstream wird kein dkms mehr bei Virtualbox benutzt. Einzig in Debian wird dieses Paket weiterhin gebaut, weshalb die Debian-Version von VBox eigentlich als ein Fork anzusehen ist.

[hikaru]

So eine Änderung sollte sich doch in den Debian-Patches niederschlagen. Ich sehe nichts Passendes.

[rendegast]

So eine Änderung sollte sich doch in den Debian-Patches niederschlagen. Ich sehe nichts Passendes.

In der debian.tar.xz finden sich
virtualbox-dkms.dkms
virtualbox-guest-dkms.dkms
als template für eine mit Modul-Version ausgestattete dkms.conf.

Problem bei der Geschichte,
gelegentlich gibt/kann es Konflikte mit in misc/ erstellten Modulen vom virtualbox-Startskript.
Diese sind händisch zu lösen. (Tools rm / dkms / depmod)


Wird das Kernelmodul-Quellverzeichnis des oracle-Virtualbox mit einer solchen dkms.conf ausgestatten,
so kann auch dabei mit dkms gearbeitet werden.
Problem: Die dkms.conf muß bei jedem Upgrade angepaßt werden. Frage ist, wann?
Vor dem Upgrade, damit der aktuelle kernel direkt mit Modul ausgestattet wird und beim Neustart nicht der Modulbau des Startskripts läuft (<-> misc/) <-> eventuell gibt es Probleme mit dem Entfernen des dkms-Moduls.



Alternativ kann der Mechanismus des Startskripts auch für andere, nichtlaufende Kernel durchgeführt werden.
Dafür sollten Umgebungsvariablen gesetzt werden, mache ich hier derart:

Code: Alles auswählen

...

/bin/ls -1 /lib/modules | sort -V -r | while read VICKER; do
    [ "x$(uname -r)" = "x$VICKER" ] && continue		# in Verbindung mit obigem 'vboxdrv.sh setup' waere das redundant

    KERN_DIR=/lib/modules/$VICKER/build
    MODULE_DIR=/lib/modules/$VICKER/misc
    export KERN_DIR
    export MODULE_DIR
    export VICKER

    KERNELRELEASE=$VICKER
    KERN_VER=$VICKER
    export KERNELRELEASE
    export KERN_VER

    echo "02work $VICKER $KERN_DIR $MODULE_DIR ---------------------------------"
    # Test auf schon vorhandenes + AKTUELLES Modul?
    #./.usr.lib.virtualbox.vboxdrv.sh_WORK setup-module
    /usr/lib/virtualbox/vboxdrv.sh setup-module

    VICKER=; KERN_DIR=;MODULE_DIR=
    KERNELRELEASE=; KERN_VER=
done

...

(Entsprechende Tests auf laufende VM usw. drumherum)
Das Funktionieren hängt vom Startskript ab,
da solche Nutzung von oracle nicht vorgesehen ist, könnte sich die Art der Variablenzuweisung ändern.
Es finden beim Bauvorgang keine Tests statt, es wird einfach drübergebügelt.

[hikaru]

In der debian.tar.xz finden sich
virtualbox-dkms.dkms
virtualbox-guest-dkms.dkms
als template für eine mit Modul-Version ausgestattete dkms.conf.

Aber es gibt in debian/patches keine Änderungen mit Bezug auf dkms, die den Upstream-Code verändern würden. Oracle hat an VBox nichts geändert, das die Verwendung von dkms verhindern würde.
Debian benutzt lediglich weiterhin eine vorhandene Funktionalität, die auch Oracle früher genutzt hat und nun eben nicht mehr nutzt. Dass Virtualbox (nicht Oracle) kein dkms mehr benutzt und die Pakete von Debian wegen der fortgesetzten Nutzung von dkms deshalb als Fork einzustufen sind halte ich daher für eine Fehleinschätzung.

[TomL]

Moin @ all

Im Moment muss ich gestehen, dass mich das gerade ein wenig überfordert... ... sorry... ich liefere zur Sicherheit lieber aber noch mal ein paar vergessene Infos nach.

Weils unter Stretch (ohne Backports) damals keine brauchbare Version gab, habe ich ein deb-Paket direkt von Oracel verwendet, und zwar 5.1.22
Weils zeitweise Berichte über große Probleme eine höheren Folge-Version gab, bin ich zunächst dabei geblieben
Weil die installierte Version auf all unseren System supergut läuft, bin ich bis heute immer noch dabei geblieben

... also gehts nachwievor immer noch um die 5.1.22.

Jetzt habe ich gerade mal nachgesehen, auf meinem PC wurden (von mir nicht direkt bemerkt) die "Treiber" passend zum apt full-upgrade des Kernels irgendwie im Hintergrund neu erstellt, was ich jetzt gerade erst unter /var/log festgestellt habe. Also dieser Autmatismus scheint zu funktionieren, ohne das ich da was für unternommen habe. Natürlich habe ich dkms, build-essentials und linux-headers installiert... aber sonst habe ich dafür nix getan.
In der VM sind die Pakete auch installiert, aber da läuft dieser Automatismus offensichtlich nicht. Das Log selber ist ne Katastrophe ...(und das Journal in dem Fall auch, ich krieg das jetzt rückblickend nicht mehr zeitlich auseinanderdividiert, wie der Kernel-Upgrade sich zum nächsten Start darstellt und dann der von mir manuell angestoßene Update der VBOx-Treiber. Das VOX-Install-Log selber enthält nur Angaben zum letzten Vorgang des neuerstellens, Fehlermeldungen von "davor" finde ich nicht.

Ich würde jetzt zu dem Schluss kommen, dass ich jetzt einfach auf das nächste Kernelupgrade warten muss, um speziell dann nach Fehlermeldungen beim Booten der VM zu suchen, bevor ich die Treibererstellung manuell selber angestoßen habe... und zwar auf beiden Maschinen... echt und virtuell.

Wäre das ein passendes Fazit? Oder gibts einen besseren Ansatz?

ps
Gibts eigentlich immer noch gute Gründe, nicht auf eine aktuelle Version upzudaten....?... aktuell ist gerade 5.2.4

[rendegast]

Gibt es eigentlich eine Möglichkeit, dass die Guest-Additions automatisch nach oder mit einem Kernel-Upgrade erstellt werden? Im Moment ist es so, dass nach dem Update der Vollbild-Modus nicht mehr geht, VGA oder SVGA o.ä. ist dann eingestellt, die Mouse reagiert auch anders. Ich muss dann jeweils manuell die Additions neu erstellen und rebooten,

Du könntest
/usr/share/virtualbox/VBoxGuest-Additions.iso
den VM verfügbar machen, als cdrom einbinden oder als Freigabe (oracles shared-Folder?)
Ein cron-Job testet
'VBoxLinuxAdditions.run --info' resp. darin enthaltene Variablen
label=
INSTALLATION_VER=
auf Änderung und läßt das Skript gegebenenfalls laufen.
Gleicherart für eine windows-VM.




Machen die GuestAdditions wirklich schon bei einem minor-Update 5.X.Y -> 5.X.Z solche Probleme?

[breakthewall]

Als kleine Randnotiz:
Die Treiber für VirtualBox bzw. insbesondere die Guest-Additions, wandern ab Version 4.16/4.17 in den Linux-Kernel. Ab dann ist das nicht länger optional, womit zukünftig auch das Rebuild entfällt.

[TomL]

Ein cron-Job testet
'VBoxLinuxAdditions.run --info' resp. darin enthaltene Variablen
label=
INSTALLATION_VER=
auf Änderung und läßt das Skript gegebenenfalls laufen.
Gleicherart für eine windows-VM.

Das wird m.M.n. nicht funktionieren.... und für Windows ist das ja eh irrelevant, weils in Windows keinen Kernelwechsel gibt.

Was wahrscheinlich funktionieren würde, wäre, wenn ich die Guest-Addititons, die ich derzeit via CDRom fliegend einbinde, einfach in die VM z.B. nach /opt kopieren würde und bei jedem VM-System-Start via service-unit die Rückgabe von

Code: Alles auswählen

uname -r
4.9.0-5-amd64

mit einer vorhandenen Status-Datei vergleichen würde. Sind die Inhalte unterschiedlich, starte ich den Compiler, erstelle danach die Status-Datei erneut und mach anschliessend sofort einen systemctl reboot. *hmmm*... das würde wahrsscheinlich gehen, ist aber sehr aufwändig. Im Moment weiss ich nicht, ob ich dafür alleine mit einer Oneshot-Unit auskommen würde, weil ja in der Unit entschieden werden müsse, ob der Inhalt der Statusdatei anders als aktuell ermittel ist.... und nur dann kompilieren, ansonsten "tu nix"... *hmmm*