Ein apt full-upgrade gerade eben ergab gleich mehrere Fehler:
Autoinstall of module virtualbox/7.2.6 for kernel 6.19.5-1-siduction-amd64 (x86_64)
Building module(s)....(bad exit status: 2)
Failed command:
make -j12 KERNELRELEASE=6.19.5-1-siduction-amd64 -C /lib/modules/6.19.5-1-siduction-amd64/build M=/var/lib/dkms/virtualbox/7.2.6/build
Error! Bad return status for module build on kernel: 6.19.5-1-siduction-amd64 (x86_64)
Consult /var/lib/dkms/virtualbox/7.2.6/build/make.log for more information.
Autoinstall on 6.19.5-1-siduction-amd64 failed for module(s) virtualbox(10).
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
run-parts: /etc/kernel/postinst.d/dkms exited with return code 1
dpkg: Fehler beim Bearbeiten des Paketes linux-image-6.19.5-1-siduction-amd64 (--configure):
»altes postinst-Betreuerskript des Paketes linux-image-6.19.5-1-siduction-amd64«-Unterprozess mit Exit-Status 1 fehlgeschlagen
libiw30t64:amd64 (30~pre9-20) wird eingerichtet ...
libreoffice-uiconfig-calc (4:26.2.1-1) wird eingerichtet ...
libwbclient0:amd64 (2:4.23.6+dfsg-1) wird eingerichtet ...
libaec0:amd64 (1.1.6-1) wird eingerichtet ...
libcolord2:amd64 (1.4.8-3) wird eingerichtet ...
python3-platformdirs (4.9.2-1) wird eingerichtet ...
libcpupower1 (6.18.15-1) wird eingerichtet ...
colord-data (1.4.8-3) wird eingerichtet ...
libgeotiff5:amd64 (1.7.4-2) wird eingerichtet ...
libpthreadpool0:amd64 (0.0~git20251020.0e6ca13-1.1) wird eingerichtet ...
libkf6notifications-data (6.23.0-1) wird eingerichtet ...
libinput-bin (1.31.0-1) wird eingerichtet ...
libsidplayfp6:amd64 (2.16.1-1) wird eingerichtet ...
gcc-12-base:amd64 (12.5.0-8) wird eingerichtet ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-image-siduction-amd64:
linux-image-siduction-amd64 hängt ab von linux-image-6.19.5-1-siduction-amd64 (= 6.19-5); aber:
Paket linux-image-6.19.5-1-siduction-amd64 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes linux-image-siduction-amd64 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
.
.
.
nfs-mountd.service is a disabled or a static unit not running, not starting it.
nfsdcld.service is a disabled or a static unit not running, not starting it.
Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.
A dependency job for nfs-server.service failed. See 'journalctl -xe' for details.
invoke-rc.d: initscript nfs-kernel-server, action "restart" failed.
× nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: failed (Result: exit-code) since Sun 2026-03-01 11:20:23 CET; 11s ago
Duration: 17min 45.574s
Invocation: b8edbc4e23844f96bb959eae09a43ca3
Docs: man:rpc.nfsd(8)
man:exportfs(8)
Main PID: 1750 (code=exited, status=0/SUCCESS)
Mem peak: 472K
CPU: 599us
Mär 01 11:20:23 Master2 systemd[1]: nfs-server.service: Control process exited, code=exited, status=127/n/a
Mär 01 11:20:23 Master2 systemd[1]: nfs-server.service: Control process exited, code=exited, status=127/n/a
Mär 01 11:20:23 Master2 systemd[1]: nfs-server.service: Failed with result 'exit-code'.
Mär 01 11:20:23 Master2 systemd[1]: Stopped nfs-server.service - NFS server and services.
Mär 01 11:20:23 Master2 systemd[1]: Dependency failed for nfs-server.service - NFS server and services.
Mär 01 11:20:23 Master2 systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Mär 01 11:20:34 Master2 systemd[1]: Dependency failed for nfs-server.service - NFS server and services.
Mär 01 11:20:34 Master2 systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Mär 01 11:20:35 Master2 systemd[1]: Dependency failed for nfs-server.service - NFS server and services.
Mär 01 11:20:35 Master2 systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Failed to restart nfs-kernel-server, ignoring.
.
.
.
Autoinstall of module virtualbox/7.2.6 for kernel 6.19.5-1-siduction-amd64 (x86_64)
Building module(s)....(bad exit status: 2)
Failed command:
make -j12 KERNELRELEASE=6.19.5-1-siduction-amd64 -C /lib/modules/6.19.5-1-siduction-amd64/build M=/var/lib/dkms/virtualbox/7.2.6/build
Error! Bad return status for module build on kernel: 6.19.5-1-siduction-amd64 (x86_64)
Consult /var/lib/dkms/virtualbox/7.2.6/build/make.log for more information.
Autoinstall on 6.19.5-1-siduction-amd64 failed for module(s) virtualbox(10).
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 1
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-headers-6.19.5-1-siduction-amd64.postinst line 11.
dpkg: Fehler beim Bearbeiten des Paketes linux-headers-6.19.5-1-siduction-amd64 (--configure):
»altes postinst-Betreuerskript des Paketes linux-headers-6.19.5-1-siduction-amd64«-Unterprozess mit Exit-Status 1 fehlgeschlagen
pipewire-bin (1.4.10-1+b1) wird eingerichtet ...
gvfs-daemons (1.59.90-2) wird eingerichtet ...
dbus-user-session (1.16.2-4) wird eingerichtet ...
libreoffice-common (4:26.2.1-1) wird eingerichtet ...
Replacing config file /etc/libreoffice/registry/main.xcd with new version
libavfilter11:amd64 (7:8.0.1-3+b2) wird eingerichtet ...
ure-java (4:26.2.1-1) wird eingerichtet ...
calibre-bin (9.4.0+ds+~0.10.5-1) wird eingerichtet ...
libreoffice-l10n-de (4:26.2.1-1) wird eingerichtet ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-headers-siduction-amd64:
linux-headers-siduction-amd64 hängt ab von linux-headers-6.19.5-1-siduction-amd64 (= 6.19-5); aber:
Paket linux-headers-6.19.5-1-siduction-amd64 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes linux-headers-siduction-amd64 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
.
.
.
Fehler traten auf beim Bearbeiten von:
linux-image-6.19.5-1-siduction-amd64
linux-image-siduction-amd64
linux-headers-6.19.5-1-siduction-amd64
linux-headers-siduction-amd64
needrestart is being skipped since dpkg has failed
Fehler: Sub-process /usr/bin/dpkg returned an error code (1)
Virtualbox scheint mit dem neuen Kernel ein Problem zu haben. Hängen die anderen Fehler damit zusammen?
Kann mir jemand weiter helfen?
Ich hab' die patches aus
<https://github.com/VirtualBox/virtualbox/issues/467>
zusammen mit ein paar kleinen Modifikationen in das aktuelle
virtualbox-dkms_7.2.6-dfsg-3+b2_amd64.deb Debian Paket
eingebaut. Grund für den Fehler ist eine Namespace Restriction,
die für den aktuellen Kernel aktiviert wurde, sich aber umgehen lässt.
Das modifizierte Paket, welches für alle 6.18 und 6.19 Kernel funktionieren
sollte, kannst Du innerhalb der nächsten 24 h von
<https://wormhole.app/nAZqY4#yn7EzAcAnq-v-hXBTBrEGg>
herunterladen. Da alles Source Code Modifikationen sind, die für jeden neuen
Kernel übersetzt werden, hatte ich keine Bedenken, sie hochzuladen. Falls
Zweifel bestehen, kann ein diff auf die aktuelle Debian Version diese beseitigen.
Nach dem Herunterladen sollte zunächst die md5 Prüfsumme durch
$ md5sum virtualbox-dkms_7.2.6-dfsg-3+b2c_amd64.deb
als
3e41f7db51e955227921bfee84e36317 virtualbox-dkms_7.2.6-dfsg-3+b2c_amd64.deb
bestätigt werden. Dann kann das Paket durch
$ sudo dpkg -i virtualbox-dkms_7.2.6-dfsg-3+b2c_amd64.deb
installiert werden. Es überschreibt Version 7.2.6-dfsg-3+b2 zugunsten von Version 7.2.6-dfsg-3+b2c
und baut die Module für alle installierten Kernel. Falls das aktuelle Debian Paket (mit Korrektur)
irgendwann veröffentlicht wird, wird es diese temporäre Version spurlos überschreiben. Sollte
der link nach 24 h auslaufen, kann ich ihn auf Wunsch gerne aktualisieren.
Vielleicht kannst Du Den Topic mit Hinweis auf virtualbox-dkms und Kernel 6.19 aktualisieren.
vielen Dank für die schnelle und tolle Hilfe, das hat funktioniert. :D
Nach der Installation noch ein dpkg --configure -a und alles funktioniert wieder wie gehabt.
Gern geschehen, falls andere Benutzer ebenfalls gute Erfahrungen damit machen,
kann towo sich vielleicht überlegen, vorübergehend das Paket unter siduction
zur Verfügung zu stellen, bis eine offizielle Debian Version vorliegt.
Quote from: Teriarch on 2026/03/01, 13:03:05
<https://wormhole.app/nAZqY4#yn7EzAcAnq-v-hXBTBrEGg>
Schade das der Link nicht mehr geht. Hab hier das selbe Problem und diesen thread gerade erst gesehen...
<https://wormhole.app/LOWm1B#_d-wsKpkVVJMCuufEyVlrw>
Quote from: Teriarch on 2026/03/02, 21:18:19
<https://wormhole.app/LOWm1B#_d-wsKpkVVJMCuufEyVlrw>
Danke, hat geklappt.
Quote from: Teriarch on 2026/03/01, 13:03:05
<https://github.com/VirtualBox/virtualbox/issues/467>
Könntest du das Paket noch einmal bereit stellen?
<https://wormhole.app/bLrJDK#rFHJdWkV2AR-Vkv2CCmVHQ>
Quote from: Teriarch on 2026/03/04, 13:40:15
<https://wormhole.app/bLrJDK#rFHJdWkV2AR-Vkv2CCmVHQ>
Danke
@Teriarch: Danke für Deinen fix.
Leider gelingt es hier seit dem 01.03. zu verschiedenen Zeitpunkten nicht, die Datei runterzuladen.
Sie hat stets nur 0 Bytes und es erscheint die Fehlermeldung:
Es tut uns Leid! Es gab ein Problem mit der Dateiübertragung
Security error when calling GetDirectory
Diese Meldung tritt sowohl mit firefox als auch mit chromium auf.
Vielleicht mache ich ja reproduzierbar stets den selben Fehler, nur welchen?
Gibt es noch eine andere Quelle?
@paco
Ich kann den Fehler rekonstruieren, wenn ich in Firefox den sog. privaten Modus
aktiviere. Kannst Du nachschauen, ob dieser bei Dir aktiv ist und ihn für's
Herunterladen ggfs. ausschalten?
@Teriarch: Danke für Deinen Tipp, manchmal sind die Lösungen so einfach, wenn man weiß wie. ;-)
Da wäre ich nie drauf gekommen, hat perfekt funktioniert.
Bitte nochmal bereitstellen :-[
Danke.
<https://wormhole.app/Ppa3pz#owQ2LsHmAbpMPsUc7sCZoQ>
Das ging schnell :)
Vielen Dank.
Wird das Problem evtl. auch mal per per apt full-upgrade gelöst? :-\
@bevo
< Wird das Problem evtl. auch mal per per apt full-upgrade gelöst?
Klar. Aber der direkte Zugriff auf lebenswichtige Funktionen des Kernels wurde in 6.19
nicht ohne Grund verwehrt:
"CR4 directly impacts CPU memory management and security policies.
Modifying reserved bits or setting invalid bit combinations will cause the
processor to raise an exception, often resulting in a system crash
(e.g., "UNEXPECTED_KERNEL_MODE_TRAP")."
Und eine der Funktionen (oder Methoden, wie der gebildete Informatiker
von heute sagen würde), deren Zugriff verwehrt wurde, ist z.B.
"cr4_update_irqsoff". Die Verwendunng dieser Funktion ist in Zukunft
lediglich kvm & Co. Modulen erlaubt.
Da nun virtualbox das Rad nicht neu erfinden wollte, hat man sich eines
Tricks bedient, der kernelseitig schwer zu verhindern ist. Für den Aufruf
der Funktion ist nur ihre Adresse relevant. Lass uns nachschauen:
$ grep cr4_update_irqsoff /usr/src/linux-headers-6.19.6-1-siduction-amd64/Module.symvers
0x00000000 cr4_update_irqsoff vmlinux EXPORT_SYMBOL_GPL module:kvm,kvm-amd,kvm-intel
Und wie ich schon sagte: Nur noch für kvm & Co. direkt aufrufbar. Aber die Adresse kann
aus dem User Space bezogen werden (und damit erst recht aus dem Kernel Space):
$ sudo grep cr4_update_irqsoff /proc/kallsyms
ffffffff812a9b40 T cr4_update_irqsoff
Im Kernel lautet die relevante Funktion __symbol_get, und so verschafft man sich zunächst
im vbox Patch ihre Adresse, bildet sie auf eine wrapper Funktion ab und ersetzt alle vormaligen
Direktaufrufe durch diese wrapper Funktion:
SUPDrv-linux.c: void *pfnCr4UpdateIrqsoff = __symbol_get("cr4_update_irqsoff");
Das funktioniert wegen
$ sudo grep __symbol_get /proc/kallsyms
ffffffff813ded30 T __symbol_get
und wegen
$ grep __symbol_get /usr/src/linux-headers-6.19.6-1-siduction-amd64/Module.symvers
0x00000000 __symbol_get vmlinux EXPORT_SYMBOL_GPL
unterliegt __symbol_get keiner Namespace Restriction.
Aufgrund dieser kritischen Umgehung ist es umso wichtiger, alles bis ins kleinste
Detail zu überprüfen (siehe den letzten Eintrag zu <https://github.com/VirtualBox/virtualbox/issues/467>).
Und danach hat das Debian Team natürlich noch die Entscheidung über die Paketaufnahme zu treffen.
Das sollte die Verzögerung, nach der Du frugst, ausreichend erklären.
In der Zwischenzeit kannst Du meine vorläufige Zusammenstellung der Patches unter
<https://wormhole.app/X6Rmal#VmFvHWpfwu2Akg35VyiQMA>
herunterladen.
HTH
Hallo,
ich bin heute erst auf diesen thread gestoßen. Da die dateien im link nach 24h gelöscht werden, gehe alle links ins leere. bitte noch einmal bereitstellen, da das heute update das problem immer noch nicht behoben hat.
Danke.
<https://wormhole.app/3DqYbv#BxrXjAcAdhvd4LhM8kWz_Q>
md5sum: 3e41f7db51e955227921bfee84e36317 virtualbox-dkms_7.2.6-dfsg-3+b2c_amd64.deb
Esrtmal Danke an Teriarch für Deine Mühe, das alles als "deb" zusammen zu packen! Das ist auf jeden Fall die schönere Methode!
Da die meisten ja das Paket virtualbox-dkms ja schon "halb" installiert haben, vielleicht hier noch ein Tipp, damit Teriarch nicht jedesmal die Datei freigeben muss:
In dem zitierten <https://github.com/VirtualBox/virtualbox/issues/467> wird ein patchfile erwähnt, das sich zwar auf RedHat bezieht, aber für Debian auch (z.T.) funktioniert. Die zu patchenden Dateien liegen in /var/lib/dkms/virtualbox/7.2.6/source und da kann man das Patchfile anwenden. Also:
- Download von <https://github.com/rpmfusion/VirtualBox-kmod/blob/master/kernel-6.19.patch>
- cd /var/lib/dkms/virtualbox/7.2.6/source
- patch -p0 < <wo_immer_das_liegt>kernel-6.19.patch
- dpkg --configure virtualbox-dkms
Der Patch enthält auch die Änderungen für die Client-Kernelmodule, daher meckert er die Dateien noch an, weil er sie nicht findet. Die Dateien für das Host-Kernelmodul sind dann aber alle dabei.
Hat zumindest bei mir so geklappt.
@glimfindel
Zwei Bemerkungen zu Deinem ansonsten guten Vorschlag:
Der von Dir erwähnte kernel-6.19.patch patch bricht ab, da er
in /var/lib/dkms/virtualbox/7.2.6/source das vboxguest Unterverzeichnis
nicht findet, bevor er zu vboxnetadp und vboxnetflt kommt. Das lässt sich
aber durch Entfernen leicht korrigieren.
Außerdem ist die von Nepenthe0 zu recht beanstandete Logik nicht korrigiert,
was im Falle von undefiniertem CONFIG_KPROBES zum Abbruch führt (trifft
für den Siduction Kernel aber nicht zu).
Ich habe den vollständigen Patch gegen alle 6.18/6.19 Kernel und Kprobe Varianten
getestet, und konnte in keinem Fall einen Fehler feststellen. Wenn Bedarf besteht, kann
ich auch den vollständigen Patch gegen die 7.2.6 Sourcen zur Verfügung stellen, aber
ich hoffe immer noch, dass Oracle endlich die Korrektur vornimmt.
Nachtrag zur Installation des Patches:
Sicherstellen, dass Paket virtualbox-dkms in Version 7.2.6-dfsg-3+b2 installiert ist:
$ dpkg -l|grep virtualbox-dkms
ii virtualbox-dkms 7.2.6-dfsg-3+b2 amd64 x86 virtualization solution - kernel module sources for dkms
Ins Verzeichnis /usr/src wechseln:
$ cd /usr/src
Folgenden patch ins /tmp Verzeichnis kopieren:
diff -Nurp --no-dereference aaa/virtualbox-7.2.6/r0drv/linux/initterm-r0drv-linux.c bbb/virtualbox-7.2.6/r0drv/linux/initterm-r0drv-linux.c
--- aaa/virtualbox-7.2.6/r0drv/linux/initterm-r0drv-linux.c 2026-01-27 13:58:09.000000000 +0100
+++ bbb/virtualbox-7.2.6/r0drv/linux/initterm-r0drv-linux.c 2026-02-20 16:40:35.000000000 +0100
@@ -60,6 +60,11 @@ static DECLARE_TASK_QUEUE(g_rtR0LnxWorkQ
* This is a special mm structure used to manage the kernel address space. */
struct mm_struct *g_pLnxInitMm = NULL;
+#if RTLNX_VER_MIN(6,19,0)
+/** Pointer to __flush_tlb_all kernel symbol. */
+void (*g_pfnLinuxFlushTlbAll)(void);
+#endif
+
/**
* Pushes an item onto the IPRT work queue.
@@ -136,6 +141,11 @@ DECLHIDDEN(int) rtR0InitNative(void)
printk("rtR0InitNative: g_pLnxInitMm=%p\n", g_pLnxInitMm);
RTR0DbgKrnlInfoRelease(hKrnlInfo);
+# if RTLNX_VER_MIN(6,19,0)
+ g_pfnLinuxFlushTlbAll = __symbol_get("__flush_tlb_all");
+ if (!RT_VALID_PTR(g_pfnLinuxFlushTlbAll))
+ printk("rtR0InitNative: can't load __flush_tlb_all\n");
+# endif
}
else
printk("rtR0InitNative: RTR0DbgKrnlInfoOpen failed: %d\n", rc);
@@ -151,6 +161,12 @@ DECLHIDDEN(void) rtR0TermNative(void)
{
IPRT_LINUX_SAVE_EFL_AC();
+# if RTLNX_VER_MIN(6,19,0)
+ if (RT_VALID_PTR(g_pfnLinuxFlushTlbAll))
+ symbol_put_addr(g_pfnLinuxFlushTlbAll);
+ g_pfnLinuxFlushTlbAll = NULL;
+#endif
+
rtR0LnxWorkqueueFlush();
#if RTLNX_VER_MIN(2,5,41)
destroy_workqueue(g_prtR0LnxWorkQueue);
diff -Nurp --no-dereference aaa/virtualbox-7.2.6/r0drv/linux/memobj-r0drv-linux.c bbb/virtualbox-7.2.6/r0drv/linux/memobj-r0drv-linux.c
--- aaa/virtualbox-7.2.6/r0drv/linux/memobj-r0drv-linux.c 2026-01-27 13:58:09.000000000 +0100
+++ bbb/virtualbox-7.2.6/r0drv/linux/memobj-r0drv-linux.c 2026-02-20 16:41:06.000000000 +0100
@@ -2108,6 +2108,17 @@ DECLHIDDEN(int) rtR0MemObjNativeMapUser(
return rc;
}
+#if defined(IPRT_USE_ALLOC_VM_AREA_FOR_EXEC) || defined(IPRT_USE_APPLY_TO_PAGE_RANGE_FOR_EXEC)
+static void rtR0MemObjLinuxFlushTlbAll(void)
+{
+# if RTLNX_VER_MIN(6,19,0)
+ if (RT_LIKELY(RT_VALID_PTR(g_pfnLinuxFlushTlbAll)))
+ g_pfnLinuxFlushTlbAll();
+# else
+ __flush_tlb_all();
+# endif
+}
+#endif
DECLHIDDEN(int) rtR0MemObjNativeProtect(PRTR0MEMOBJINTERNAL pMem, size_t offSub, size_t cbSub, uint32_t fProt)
{
@@ -2128,7 +2139,7 @@ DECLHIDDEN(int) rtR0MemObjNativeProtect(
set_pte(papPtes[i], mk_pte(pMemLnx->apPages[i], fPg));
}
preempt_disable();
- __flush_tlb_all();
+ rtR0MemObjLinuxFlushTlbAll();
preempt_enable();
return VINF_SUCCESS;
}
@@ -2174,7 +2185,7 @@ DECLHIDDEN(int) rtR0MemObjNativeProtect(
flush_icache_range((uintptr_t)pMemLnx->Core.pv + offSub, cbSub);
# if defined(RT_ARCH_AMD64) || defined(RT_ARCH_X86) /* flush_tlb_kernel_range is not exported, but __flush_tlb_all is. */
preempt_disable();
- __flush_tlb_all();
+ rtR0MemObjLinuxFlushTlbAll();
preempt_enable();
# else
flush_tlb_kernel_range((uintptr_t)pMemLnx->Core.pv + offSub, cbSub);
diff -Nurp --no-dereference aaa/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c bbb/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c
--- aaa/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c 2026-01-27 13:57:17.000000000 +0100
+++ bbb/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c 2026-02-21 18:42:48.000000000 +0100
@@ -193,6 +193,12 @@ static void (*g_pfnKvmDi
/** Pointer to the KVM hardware specific module. */
struct module *g_pKvmHwvirtModule;
#endif
+# if RTLNX_VER_MIN(6,19,0)
+/** Function pointer to cr4_update_irqsoff(). */
+static void (*g_pfnCr4UpdateIrqsoff)(unsigned long set, unsigned long clear);
+/** Function pointer to cr4_read_shadow(). */
+static unsigned long (*g_pfnCr4ReadShadow)(void);
+# endif
/** Module parameter.
* Not prefixed because the name is used by macros and the end of this file. */
@@ -395,6 +401,28 @@ static int supdrvLinuxInitKvmSymbols(voi
void *pfnDisable = __symbol_get("kvm_disable_virtualization");
if (pfnDisable)
{
+# if RTLNX_VER_MIN(6,19,0)
+ void *pfnCr4UpdateIrqsoff = __symbol_get("cr4_update_irqsoff");
+ void *pfnRr4ReadShadow = __symbol_get("cr4_read_shadow");
+
+ if ( pfnCr4UpdateIrqsoff
+ && pfnRr4ReadShadow)
+ {
+ g_pfnCr4UpdateIrqsoff = pfnCr4UpdateIrqsoff;
+ g_pfnCr4ReadShadow = pfnRr4ReadShadow;
+
+ printk(KERN_INFO "vboxdrv: Found extra KVM hardware-virtualization symbols\n");
+ }
+ else
+ {
+ printk(KERN_WARNING "vboxdrv: Failed to find extra KVM hardware-virtualization symbols\n");
+
+ if (pfnCr4UpdateIrqsoff)
+ symbol_put_addr(pfnCr4UpdateIrqsoff);
+ if (pfnRr4ReadShadow)
+ symbol_put_addr(pfnRr4ReadShadow);
+ }
+#endif
/*
* Try to obtain a reference to kvm_intel/kvm_amd module in addition to the
* reference to the kvm module. If we fail, we will not try to use KVM for
@@ -466,6 +494,18 @@ static void supdrvLinuxTermKvmSymbols(vo
symbol_put_addr(g_pfnKvmDisableVirtualization);
g_pfnKvmDisableVirtualization = NULL;
}
+# if RTLNX_VER_MIN(6,19,0)
+ if (g_pfnCr4UpdateIrqsoff)
+ {
+ symbol_put_addr(g_pfnCr4UpdateIrqsoff);
+ g_pfnCr4UpdateIrqsoff = NULL;
+ }
+ if (g_pfnCr4ReadShadow)
+ {
+ symbol_put_addr(g_pfnCr4ReadShadow);
+ g_pfnCr4ReadShadow = NULL;
+ }
+#endif
if (g_pKvmHwvirtModule)
{
module_put(g_pKvmHwvirtModule);
@@ -1146,6 +1186,37 @@ SUPR0DECL(int) SUPDrvLinuxLdrDeregisterW
}
EXPORT_SYMBOL(SUPDrvLinuxLdrDeregisterWrappedModule);
+#if RTLNX_VER_MIN(5,8,0)
+/**
+ * Wrapper function for cr4_update_irqsoff() which was
+ * exported only for KVM starting from kernel 6.19.
+ */
+static void supdrvLinux_cr4_update_irqsoff(unsigned long set, unsigned long clear)
+{
+# if RTLNX_VER_MIN(6,19,0)
+ if (g_pfnCr4UpdateIrqsoff)
+ g_pfnCr4UpdateIrqsoff(set, clear);
+# else
+ cr4_update_irqsoff(set, clear);
+# endif
+}
+
+/**
+ * Wrapper function for supdrvLinux_cr4_read_shadow() which was
+ * exported only for KVM starting from kernel 6.19.
+ */
+static unsigned long supdrvLinux_cr4_read_shadow(void)
+{
+ unsigned long cr4 = 0;
+# if RTLNX_VER_MIN(6,19,0)
+ if (g_pfnCr4ReadShadow)
+ cr4 = g_pfnCr4ReadShadow();
+# else
+ cr4 = cr4_read_shadow();
+# endif
+ return cr4;
+}
+#endif /* 5.8.0 */
#if defined(RT_ARCH_AMD64) || defined(RT_ARCH_X86)
RTCCUINTREG VBOXCALL supdrvOSChangeCR4(RTCCUINTREG fOrMask, RTCCUINTREG fAndMask)
@@ -1153,10 +1224,10 @@ RTCCUINTREG VBOXCALL supdrvOSChangeCR4(R
# if RTLNX_VER_MIN(5,8,0)
unsigned long fSavedFlags;
local_irq_save(fSavedFlags);
- RTCCUINTREG const uOld = cr4_read_shadow();
- cr4_update_irqsoff(fOrMask, ~fAndMask); /* Same as this function, only it is not returning the old value. */
- AssertMsg(cr4_read_shadow() == ((uOld & fAndMask) | fOrMask),
- ("fOrMask=%#RTreg fAndMask=%#RTreg uOld=%#RTreg; new cr4=%#llx\n", fOrMask, fAndMask, uOld, cr4_read_shadow()));
+ RTCCUINTREG const uOld = supdrvLinux_cr4_read_shadow();
+ supdrvLinux_cr4_update_irqsoff(fOrMask, ~fAndMask); /* Same as this function, only it is not returning the old value. */
+ AssertMsg(supdrvLinux_cr4_read_shadow() == ((uOld & fAndMask) | fOrMask),
+ ("fOrMask=%#RTreg fAndMask=%#RTreg uOld=%#RTreg; new cr4=%#llx\n", fOrMask, fAndMask, uOld, supdrvLinux_cr4_read_shadow()));
local_irq_restore(fSavedFlags);
# else
# if RTLNX_VER_MIN(3,20,0)
Patch anwenden:
$ sudo patch -p1 < /tmp/patch
Neu übersetzen:
$ sudo dpkg-reconfigure virtualbox-dkms
$ sudo depmod -a
HTH
Update:
Since virtualbox-dkms in latest version 7.2.6-dfsg-3.2 still won't play nice with kernel 6.19,
here is what you can do (follow instructions step by step):
Either d-u or
$ sudo apt-get update; sudo apt-get install virtualbox-dkms
produces an error and leaves you with a broken package. Remove the package:
$ sudo apt-get remove virtualbox-dkms
If any other virtualbox related package is already installed, the removal features package
virtualbox-source instead. Ignore that for the moment, we will get rid of it soon enough.
Change to the /tmp directory and download virtualbox-dkms:
$ cd /tmp; apt-get download virtualbox-dkms
Make sure it's version 7.2.6-dfsg-3.2. Unpack it, but leave it unconfigured:
$ sudo dpkg --unpack virtualbox-dkms_7.2.6-dfsg-3.2_amd64.deb
Save the following patch with name "patch" into /tmp.
diff -Nurp --no-dereference aaa/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c bbb/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c
--- aaa/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c 2026-03-26 16:57:27.000000000 +0100
+++ bbb/virtualbox-7.2.6/vboxdrv/linux/SUPDrv-linux.c 2026-03-29 15:06:51.629825960 +0200
@@ -190,15 +190,15 @@ static bool g_fEnabledHw
static int (*g_pfnKvmEnableVirtualization)(void);
/** Function pointer to kvm_disable_virtualization(). */
static void (*g_pfnKvmDisableVirtualization)(void);
+/** Pointer to the KVM hardware specific module. */
+struct module *g_pKvmHwvirtModule;
+#endif
# if RTLNX_VER_MIN(6,19,0)
/** Function pointer to cr4_update_irqsoff(). */
static void (*g_pfnCr4UpdateIrqsoff)(unsigned long set, unsigned long clear);
/** Function pointer to cr4_read_shadow(). */
static unsigned long (*g_pfnCr4ReadShadow)(void);
# endif
-/** Pointer to the KVM hardware specific module. */
-struct module *g_pKvmHwvirtModule;
-#endif
/** Module parameter.
* Not prefixed because the name is used by macros and the end of this file. */
@@ -467,14 +467,27 @@ static int supdrvLinuxInitKvmSymbols(voi
unregister_kprobe(&KernProbe);
return VINF_SUCCESS;
}
+ else
+ printk(KERN_WARNING "vboxdrv: Failed to find or obtain reference for the KVM module\n");
}
+ else
+ printk(KERN_WARNING "vboxdrv: Cannot determine KVM module name for this CPU architecture\n");
}
+ else
+ printk(KERN_WARNING "vboxdrv: The address of the found 'find_module' symbol isn't valid\n");
unregister_kprobe(&KernProbe);
}
+ else
+ printk(KERN_WARNING "vboxdrv: Failed to register kprobe for 'find_module', rc=%d\n", rc);
symbol_put_addr(pfnDisable);
}
+ else
+ printk(KERN_WARNING "vboxdrv: Failed to find 'kvm_disable_virtualization'\n");
symbol_put_addr(pfnEnable);
}
+ else
+ printk(KERN_WARNING "vboxdrv: Failed to find 'kvm_enable_virtualization'\n");
+
return VERR_NOT_FOUND;
}
@@ -1186,13 +1199,14 @@ SUPR0DECL(int) SUPDrvLinuxLdrDeregisterW
}
EXPORT_SYMBOL(SUPDrvLinuxLdrDeregisterWrappedModule);
+#if RTLNX_VER_MIN(5,8,0)
/**
* Wrapper function for cr4_update_irqsoff() which was
* exported only for KVM starting from kernel 6.19.
*/
static void supdrvLinux_cr4_update_irqsoff(unsigned long set, unsigned long clear)
{
-#if RTLNX_VER_MIN(6,19,0) && defined(SUPDRV_LINUX_HAS_KVM_HWVIRT_API)
+#if RTLNX_VER_MIN(6,19,0)
if (g_pfnCr4UpdateIrqsoff)
g_pfnCr4UpdateIrqsoff(set, clear);
#else
@@ -1207,7 +1221,7 @@ static void supdrvLinux_cr4_update_irqso
static unsigned long supdrvLinux_cr4_read_shadow(void)
{
unsigned long cr4 = 0;
-#if RTLNX_VER_MIN(6,19,0) && defined(SUPDRV_LINUX_HAS_KVM_HWVIRT_API)
+#if RTLNX_VER_MIN(6,19,0)
if (g_pfnCr4ReadShadow)
cr4 = g_pfnCr4ReadShadow();
#else
@@ -1215,6 +1229,7 @@ static unsigned long supdrvLinux_cr4_rea
#endif
return cr4;
}
+#endif /* 5.8.0 */
#if defined(RT_ARCH_AMD64) || defined(RT_ARCH_X86)
RTCCUINTREG VBOXCALL supdrvOSChangeCR4(RTCCUINTREG fOrMask, RTCCUINTREG fAndMask)
@@ -2014,18 +2029,19 @@ SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxH
* See @bugref{10209#c12} and onwards for more details.
*/
Assert(fCtxHook || !RTThreadPreemptIsEnabled(NIL_RTTHREAD));
- kernel_fpu_begin();
# if RTLNX_VER_MIN(6,15,0) /* fpregs_unlock may do more than just preempt_enable, so only when necessary now. */
- if (fCtxHook)
-# endif
- {
-# if RTLNX_VER_MIN(6,15,0)
- if (!irqs_disabled())
- fpregs_unlock();
+ /* Always disable IRQs and explicitly lock the FPU state. */
+ unsigned long fSavedIrqs;
+ local_irq_save(fSavedIrqs);
+ kernel_fpu_begin();
+ if (!fCtxHook)
+ fpregs_lock();
+ local_irq_restore(fSavedIrqs);
+ Assert(!irq_fpu_usable());
# else
- preempt_enable();
+ kernel_fpu_begin();
+ preempt_enable();
# endif
- }
return false; /** @todo Not sure if we have license to use any extended state, or
* if we're limited to the SSE & x87 FPU. If it's the former,
* we should return @a true and the caller can skip
@@ -2044,17 +2060,17 @@ SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHoo
/* HACK ALERT! See SUPR0FpuBegin for an explanation of this. */
Assert(!RTThreadPreemptIsEnabled(NIL_RTTHREAD));
# if RTLNX_VER_MIN(6,15,0) /* fpregs_unlock may do more than just preempt_enable, so only when necessary now. */
- if (fCtxHook)
-# endif
- {
-# if RTLNX_VER_MIN(6,15,0)
- if (!irqs_disabled())
- fpregs_lock();
+ /* Always disable IRQs and explicitly unlock the FPU state. */
+ unsigned long fSavedIrqs;
+ local_irq_save(fSavedIrqs);
+ if (!fCtxHook)
+ fpregs_unlock();
+ kernel_fpu_end();
+ local_irq_restore(fSavedIrqs);
# else
- preempt_disable();
-# endif
- }
+ preempt_disable();
kernel_fpu_end();
+# endif
# endif
}
SUPR0_EXPORT_SYMBOL(SUPR0FpuEnd);
Change to /usr/src and apply the patch:
$ cd /usr/src; sudo patch -p1 < /tmp/patch
Configure virtualbox-dkms:
$ sudo dpkg --configure virtualbox-dkms
Now you are all set:
$ dpkg -l|grep virtualbox-dkms
ii virtualbox-dkms 7.2.6-dfsg-3.2 amd64 x86 virtualization solution - kernel module sources for dkms
Finally get rid of virtualbox-source:
$ sudo apt-get remove virtualbox-source
And if that's not good enough you can download via the link (valid for 24 hours)
<https://wormhole.app/3DZ4xW#V2BPAeJWNZt4wQyk0DS5gw>:
md5sum 9a3e6a314061be37976dc24ead321154 virtualbox-dkms_7.2.6-dfsg-3.2b_amd64.deb
and install it:
$ sudo apt-get install virtualbox-dkms_7.2.6-dfsg-3.2b_amd64.deb
HTH
PS.:
I'll try to keep the link up to date for the next couple of days. so recheck once in a while.
Quote from: Teriarch on 2026/03/24, 18:57:17
Update:
Since virtualbox-dkms in latest version 7.2.6-dfsg-3.1 still won't play nice with kernel 6.19,
here is what you can do (follow instructions step by step):
...
...
HTH
Perfect :)
It seems as if Oracle woke up finally ...
I just installed a virtualbox-dkms 7.2.6-dfsg-3.2 during a d-u which works fine with kernel 6.19.10-1-siduction-amd64.
It works as long as CONFIG_KPROBES is set during kernel compilation:
$ grep KPROBES /usr/src/linux-headers-7.0-rc6-siduction-amd64/.config
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
But fails, if not. The patched version compiles no matter what, but could
have problems when used by virtualbox. Maybe someone in the audience
with kernel 6.19.x w/unset CONFIG_KPROBES can tell.
BTW.: Current version 7.2.97 of virtualbox on github also compiles w/o problems.
Hallo Teriarch,
ich war beim heutigen Update wieder mal zu schnell mit der Enter Taste und habe dadurch das Paket virutalbox-dkms 7.2.6-dfsg-4 installiert, das leider immer noch nicht funktioniert.
virtualbox (7.2.6-dfsg-4) wird eingerichtet ...
Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.
Job for virtualbox.service failed because the control process exited with error code.
See "systemctl status virtualbox.service" and "journalctl -xeu virtualbox.service" for details.
invoke-rc.d: initscript virtualbox, action "restart" failed.
× virtualbox.service - Virtualbox kernel modules
Loaded: loaded (/usr/lib/systemd/system/virtualbox.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2026-04-08 10:14:26 CEST; 10ms ago
Duration: 1h 2min 31.079s
Invocation: 1dd8a2c854b64d1397133cd8c797b031
Process: 12525 ExecStart=/etc/init.d/virtualbox start (code=exited, status=1/FAILURE)
Mem peak: 2.5M
CPU: 32ms
Könntest du bei Gelegenheit nochmal eine gepatchte Version zur Verfügung stellen? Vielen Dank!
@harley-peter
Kein Problem, kannst Du mir zuvor Deinen Output von
$ ls -la /lib/modules
zeigen. Mit Version 7.2.6-dfsg-4 von virtualbox-dkms sollte die Übersetzung
der Kernelmodule durchlaufen, falls CONFIG_KPROBES=Y (was bei dem
siduction Kernel der Fall ist). Ohne Modifikation werden mit jeder neuen
Version von virtualbox-dkms zunächst die alten Kernelmodule von allen
installierten Kerneln gelöscht. Falls in Folge bei auch nur einem Kernel
CONFIG_KPROBES nicht gesetzt ist, bricht die Installation ab, und
virtualbox-service kann selbst für diejenigen Kernel die Module nicht laden
(da vorher gelöscht), für welche die Installation erfolgreich gewesen wäre
(wie für den Siduction Kernel). Darauf weist Deine Fehlermeldung hin.
Falls also obiger Output mehrere Kernel zeigt, kannst Du vielleicht mit
$ grep KPROBES /usr/src/linux-header/other_kernel/.config
meine Vermutung bestätigen.
@Teriarch:
mit dem heutigen Update funktioniert Virtualbox wieder.
ls -la /lib/modules
insgesamt 0
drwxr-xr-x 1 root root 300 10. Apr 12:08 .
drwxr-xr-x 1 root root 2908 10. Apr 12:15 ..
drwxr-xr-x 1 root root 14 10. Apr 12:15 6.10.12-1-siduction-amd64
drwxr-xr-x 1 root root 496 8. Apr 10:14 6.17.12-1-siduction-amd64
drwxr-xr-x 1 root root 496 8. Apr 10:14 6.18.11-1-siduction-amd64
drwxr-xr-x 1 root root 496 8. Apr 10:14 6.19.10-1-siduction-amd64
drwxr-xr-x 1 root root 496 8. Apr 10:14 6.19.11-1-siduction-amd64
drwxr-xr-x 1 root root 496 10. Apr 12:07 6.19.11-2-siduction-amd64
Ich weiß nicht, wo 6.10.12-1-siduction-amd64 herkommt denn der Kernel-remover zeigt mir keinen 6.10 Kernel an.
rep KPROBES /usr/src/linux-header/other_kernel/.config
grep: /usr/src/linux-header/other_kernel/.config: Datei oder Verzeichnis nicht gefunden
ls /usr/src/
linux-headers-6.17.12-1-siduction-amd64 linux-headers-6.19.10-1-siduction-amd64 linux-headers-6.19.11-2-siduction-amd64 python3.13 virtualbox.tar.bz2
linux-headers-6.18.11-1-siduction-amd64 linux-headers-6.19.11-1-siduction-amd64 python3.12 virtualbox-7.2.6
@harley-peter
> mit dem heutigen Update funktioniert Virtualbox wieder.
ja, wie ich bereits sagte Version 7.2.6-dfsg-4 von virtualbox-dkms
sollte ohne patch mit allen aktuellen Kernel Versionen, für die
CONFIG_KPROBES=Y gesetzt ist (insb. den Siduction Kernel)
funktionieren. Da ich nicht wusste, welche "anderen" Kernel bei
Dir noch installiert sind, habe ich dafür den Metanamen "other_kernel"
als Platzhalter für weitere Kernel benutzt (so wie es in der in der Mathematik
zuweilen üblich ist, die Variable n als Platzhalter für natürliche Zahlen 1,2,3,...
wie in "n + n = 2*n" zu verwenden, ohne damit zu implizieren, dass "n"
[als Buchstabe] selbst eine natürliche Zahl ist).
Der Patch ist nur noch notwendig, falls weitere Kernel ohne CONFIG_KPROBES=Y
vorhanden sind, damit die Übersetzung nicht abbricht, und das System nicht in einen
unkonfigurierten Zustand gerät. Es ist wahrscheinlich, dass für solche Kernel die
Module zwar laden, aber bei Benutzung virtualbox selbst stecken bleibt und ein Reboot
notwendig wird. Dafür spricht die letzte Bemerkung aus
<https://github.com/VirtualBox/virtualbox/issues/467>:
> shmerl last week:
> @philipmw: The fix is not in 7.2.6, only in the upcoming versions.
P.S.:
Vielleicht kannst Du vermöge
$ dpkg -l|grep linux-image
verifizieren, dass Kernel 6.10.12-1-siduction-amd64 nicht mehr installiert ist.
in diesem Fall lässt sich durch
$ sudo rm -rf /lib/modules/6.10.12-1-siduction-amd64
mit wenig Aufwand die Leiche im Keller schnell beseitigen.
@Teriarch:
Sorry, dass other_kernel als Platzhalter gedacht war, soweit habe ich nicht mitgedacht. ::)
Da musst du dich nicht entschuldigen. Als ich /usr/src/linux-header/other_kernel/.config las, musste ich auch erstmal verblüfft nachschauen, ob das so stimmen kann oder was gemeint sein könnte. Insbesondere der Slash zwischen header und other war für mich irritierend. Ich hätte da eher was in der Form /usr/src/linux-headers-6.xx.yy-z-siduction-amd64/.config erwartet. Naja, gibt Schlimmeres.
edlin
Update:
According to <https://github.com/VirtualBox/virtualbox/issues/467>
a Debian package supporting recent kernels with unset CONFIG_KPROBES is available from
<https://download.virtualbox.org/virtualbox/7.2.8/virtualbox-7.2_7.2.8-173730~Debian~trixie_amd64.deb>
Let's hope we find that version in Debian repositories soon.
PS.: As if I guessed it: Version 7.2.8 is available and fully functional as far as I can tell.