staging.inyokaproject.org

Nach dem Update auf Ubuntu 25.04 funktionieren die ganzen Virtuallen Maschinen in der VirtualBox nicht mehr:

AMD-V is diabled in the BIOS (or by the hostOS) (VERR_SVM_DISABLED). ResultCode: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {6ac83d89-6ee7-4e33-8ae6-b257b2e81be8}

Im Netz ist zu lesen, daß dies ein Problem ab Linux Kernel 16.12 sei, welcher nun standardmäßig die KVM started. Dies solle man duch Eintrag von "kvm.enable_virt_at_load=0" in der /etc/default/grub beheben können:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash kvm.enable_virt_at_load=0"

+ reboot hilft aber nicht.

Welche anderen Möglichkeiten gibt es VirtaulBox mit Ubuntu 25.04 wieder zum laufen zu bekommen?

Wurde

sudo update-grub 

nach der Änderung in /etc/default/grub ausgeführt?

Führe folgenden Befehl in einem Terminal aus und zeige uns die vollständige Ein- und Ausgabe hier im Forum als Codeblock formatiert:

cat /etc/default/grub

(Benutze Kopieren Strg + C und Einfügen Strg + V . Im Terminal braucht es zusätzlich die ⇧ -Taste.)

dentaku schrieb:

Im Netz ist zu lesen, daß dies ein Problem ab Linux Kernel 16.12 sei,

Wenn dem so wäre, würden meine Arch-VMs mit Kernel 6.15.4 nicht in VBox 7.1.10 unter Arch mit Kernel 6.15.4 laufen (und vmm-libvirt-VMs laufen auch).

Vielleicht machst Du erstmal, was dasteht und Grundvoraussetzung ist, AMD-V im UEFI enablen (vielleicht bist Du drin gewesen und hast Setup Defaults geladen, was oft genug HW-Virtualisierungsunterstützung disabled). Dann checkst Du, welche VBox-Version installiert ist. Mit altem Mist kommst Du nicht weiter.

Ich habe seit Jahren nichts im BIOS geändert - VirtualBox lief ja bisher problemlos. Der Inhalt von grub (ohne Kommentarzeilen:

>
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash kvm.enable_virt_at_load=0"
GRUB_CMDLINE_LINUX=""
>

Ich habe hier nur den Teil "kvm.enable_virt_at_load=0" hinzugefügt, sonst nichts.

was war an

schwarzheit schrieb:

zeige uns die vollständige Ein- und Ausgabe hier im Forum als Codeblock formatiert:

nicht zu verstehen?

Und warum beantwortest du meine erste Frage nicht?

dentaku schrieb:

Ich habe seit Jahren nichts im BIOS geändert

UEFI. Die Msg. ist eindeutig und würde, wenn sich KVM und VBox in die Quere kommen, anders lauten. Du kannst Dich auch weiter sperren und nicht überprüfen und ggf. so noch ewig nicht lösen.

VirtualBox lief ja bisher problemlos.

Einer der häufigsten User-Sprüche: "vorhin ging's noch".

Erfahren wir denn nun, welche VBox-Version installiert ist? Alles andere als unwichtig, gerade auch bei diesem Problem (Changelogs scheinst Du nicht zu lesen).

Im BIOS ist "SVM" enabled, also Virtualisierung aktiviert. Die VirtualBox Version ist die die mit Ubuntu 25.04 kam/aktualisiert wurde: 7.0.20-dfsg-1.2

Ich habe keine andere VirtualBox Version installiert und kann keine "change logs" lesen, wenn Ubuntu sich aktualisiert - es werden ja unzählige Pakete bei einer Ubuntu-Aktualisierung geändert/entfernt/hinzugefügt.

dentaku schrieb:

Die VirtualBox Version ist die die mit Ubuntu 25.04 kam/aktualisiert wurde: 7.0.20-dfsg-1.2

Selbst schuld.

VirtualBox: Repository in Ubuntu hinzufuegen

Ich warte immernoch auf die Beantwortung meiner Fragen!

von.wert schrieb:

Wenn dem so wäre, würden meine Arch-VMs mit Kernel 6.15.4 nicht in VBox 7.1.10 unter Arch mit Kernel 6.15.4 laufen (und vmm-libvirt-VMs laufen auch).

Doch, doch. 6.15.4 ist ja niedriger als der Kernel 16.12 aus der Zukunft. 😈

Bis dahin dauert's vermutlich nicht viel länger als von 2.x zu 3.x. 😉 Aber Fx hat da exponential mehr Fahrt aufgenommen. Oder der Detonator. 😀

In den VBox-Changelogs taucht dieses KVM-Problem für 7.0.20 und 7.1.4, beide 2024-10-15, auf. Entwarnungen in späteren Versionen hat es zwar nicht gegeben, man könnte also annehmen, das Problem besteht noch oder es besteht nicht mehr und Oracle hat's bloß nicht dokumentiert.

VBox ist auch bekannt dafür, daß gefixtes später wieder auftaucht, auch wiederholt, ich nenne nur das für VBox nicht aktiv haben dürfende Hyper-V in Windows-Hosts.

Jedenfalls habe ich vorhin testweise nacheinander VMM-VMs gebootet und beendet gehabt, danach eine VBox-VM. Problemlos (das hat nicht immer so ausgesehen). Witzigerweise habe ich dann länger in einer VBox-VM gearbeitet und erst nach deren Shutdown bemerkt, daß ich doch noch eine VMM-VM laufen gehabt habe, also gleichzeitig - und das auch noch ein Debian aarch64, also eine KVM-Architekturemulation.

Kleiner Test:

$ lsmod | grep kvm
kvm_intel             434176  0
kvm                  1388544  1 kvm_intel
irqbypass              12288  1 kvm
$ 

Also warum manche unbedingt an uraltem Zeug aus multiverse (!) festhalten, statt die Orginalquelle einzubinden, verschließt sich mir völlig.

Unglaublich - es hat sich nichts hier geändert: unverschämte Antworten von "Experten". Danke für nichts.

dentaku schrieb:

Unglaublich - es hat sich nichts hier geändert: unverschämte Antworten von "Experten". Danke für nichts.

Dann fragen wir halt engelsgeduldig nochmal:

• Hast du nach deiner Änderung in /etc/default/grub ein sudo update-grub gefahren?

Erst dann ist die Änderung nämlich wirksam. Das stand übrinx in der allerersten der „unverschämten Antworten“, für die du dich ausdrücklich nicht-bedankt hast.

--ks

@Kreuzschnabel

3x fragen ist noch nicht geduldig genug?

Wer nicht mitmachen will muss sich halt selber kümmern. ¯\_(ツ)_/¯

dentaku schrieb:

Unglaublich - es hat sich nichts hier geändert

Richtig. Manche können immer noch nichts allein lösen, noch nicht mal aus Antworten lernen oder überhaupt zielführend vorgehen.