Virtualbox funktioniert nicht mehr - DKMS Kernelmodul lässt sich nicht installieren

Kein Plan

Lt. Commander
Registriert
Juni 2007
Beiträge
1.126
Hallo Leute.

Ich habe hier ein Problem mit Virtualbox. Benutze LinuxMint seit ca. einem Jahr nativ auf dem PC. Darauf ist Virtualbox über die Anwendungsverwaltung installiert und hat normal funktioniert. Vor einiger Zeit, von einem Tag auf den anderen kam ein Problem.

Beim Starten einer VM kommt nun ein Fehler: Kernel driver not installed (rc=-1908)
The VirtualBox Linux kernel driver is either not loaded or not set up correctly. Please reinstall virtualbox-dkms package and load the kernel module by executing

'modprobe vboxdrv'

as root.

If your system has EFI Secure Boot enabled you may also need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them. Please see your Linux system's documentation for more information.

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT.
Anscheinend ist mit irgendeinem Treiber etwas nicht mehr in Ordnung. Habe versucht Vbox zu entfernen und neu zu installieren. Sowohl bei der Deinstallation als auch bei der Installation kommen Fehler, die auf DKMS hinweisen. Z.B beim Entfernen über die Anwendungsverwaltung kommt „Die Paketoperation ist gescheitert“
installArchives() failed: (Lese Datenbank ...

(Lese Datenbank ... 5%%

(Lese Datenbank ... 10%%

(Lese Datenbank ... 15%%

(Lese Datenbank ... 20%%

(Lese Datenbank ... 25%%

(Lese Datenbank ... 30%%

(Lese Datenbank ... 35%%

(Lese Datenbank ... 40%%

(Lese Datenbank ... 45%%

(Lese Datenbank ... 50%%

(Lese Datenbank ... 55%%

(Lese Datenbank ... 60%%

(Lese Datenbank ... 65%%

(Lese Datenbank ... 70%%

(Lese Datenbank ... 75%%

(Lese Datenbank ... 80%%

(Lese Datenbank ... 85%%

(Lese Datenbank ... 90%%

(Lese Datenbank ... 95%%

(Lese Datenbank ... 100%%

(Lese Datenbank ... 746987 Dateien und Verzeichnisse sind derzeit installiert.)

Entfernen von virtualbox-qt (6.1.38-dfsg-3~ubuntu1.22.04.1) ...

virtualbox-dkms (6.1.38-dfsg-3~ubuntu1.22.04.1) wird eingerichtet ...

Removing old virtualbox-6.1.38 DKMS files...

Deleting module virtualbox-6.1.38 completely from the DKMS tree.

Loading new virtualbox-6.1.38 DKMS files...

Building for 6.5.0-14-generic

Building initial module for 6.5.0-14-generic

Error! Bad return status for module build on kernel: 6.5.0-14-generic (x86_64)

Consult /var/lib/dkms/virtualbox/6.1.38/build/make.log for more information.

dpkg: Fehler beim Bearbeiten des Paketes virtualbox-dkms (--configure):

installiertes virtualbox-dkms-Skript des Paketes post-installation-Unterprozess gab den Fehlerwert 10 zurck

dpkg: Abhngigkeitsprobleme verhindern Konfiguration von virtualbox:

virtualbox hngt ab von virtualbox-dkms (>= 6.1.38-dfsg-3~ubuntu1.22.04.1) | virtualbox-source (>= 6.1.38-dfsg-3~ubuntu1.22.04.1) | virtualbox-modules; aber:

Paket virtualbox-dkms ist noch nicht konfiguriert.

Paket virtualbox-source ist nicht installiert.

Paket virtualbox-modules ist nicht installiert.

Paket virtualbox-dkms, das virtualbox-modules bereitstellt, ist noch nicht konfiguriert.



dpkg: Fehler beim Bearbeiten des Paketes virtualbox (--configure):

Abhngigkeitsprobleme - verbleibt unkonfiguriert

Trigger fr desktop-file-utils (0.26+mint1+vanessa) werden verarbeitet ...

Trigger fr hicolor-icon-theme (0.17-2) werden verarbeitet ...

Trigger fr gnome-menus (3.36.0-1ubuntu3) werden verarbeitet ...

Trigger fr man-db (2.10.2-1) werden verarbeitet ...

Trigger fr shared-mime-info (2.1-2) werden verarbeitet ...

Trigger fr mailcap (3.70+nmu1ubuntu1) werden verarbeitet ...

Fehler traten auf beim Bearbeiten von:

virtualbox-dkms

virtualbox

virtualbox-dkms (6.1.38-dfsg-3~ubuntu1.22.04.1) wird eingerichtet ...

Removing old virtualbox-6.1.38 DKMS files...

Deleting module virtualbox-6.1.38 completely from the DKMS tree.

Loading new virtualbox-6.1.38 DKMS files...

Building for 6.5.0-14-generic

Building initial module for 6.5.0-14-generic

Error! Bad return status for module build on kernel: 6.5.0-14-generic (x86_64)

Consult /var/lib/dkms/virtualbox/6.1.38/build/make.log for more information.

dpkg: Fehler beim Bearbeiten des Paketes virtualbox-dkms (--configure):

installiertes virtualbox-dkms-Skript des Paketes post-installation-Unterprozess gab den Fehlerwert 10 zurck

dpkg: Abhngigkeitsprobleme verhindern Konfiguration von virtualbox:

virtualbox hngt ab von virtualbox-dkms (>= 6.1.38-dfsg-3~ubuntu1.22.04.1) | virtualbox-source (>= 6.1.38-dfsg-3~ubuntu1.22.04.1) | virtualbox-modules; aber:

Paket virtualbox-dkms ist noch nicht konfiguriert.

Paket virtualbox-source ist nicht installiert.

Paket virtualbox-modules ist nicht installiert.

Paket virtualbox-dkms, das virtualbox-modules bereitstellt, ist noch nicht konfiguriert.



dpkg: Fehler beim Bearbeiten des Paketes virtualbox (--configure):

Abhngigkeitsprobleme - verbleibt unkonfiguriert

Fehler traten auf beim Bearbeiten von:

virtualbox-dkms
Verstehe ich das richtig, der Fehler liegt in der Zeile „Error! Bad return status for module build on kernel….?

Hier ist die make.log
DKMS make.log for virtualbox-6.1.38 for kernel 6.5.0-14-generic (x86_64)

So 14. Jan 21:44:18 CET 2024

make: Verzeichnis „/usr/src/linux-headers-6.5.0-14-generic“ wird betreten

warning: the compiler differs from the one used to build the kernel

The kernel was built by: x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0

You are using: gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/linux/SUPDrv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPDrv.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPDrvGip.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPDrvSem.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPDrvTracer.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPLibAll.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/alloc-r0drv.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/initterm-r0drv.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/memobj-r0drv.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/mpnotification-r0drv.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/powernotification-r0drv.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/assert-r0drv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/alloc-r0drv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/initterm-r0drv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/mp-r0drv-linux.o

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/mpnotification-r0drv-linux.o

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: VBoxHost_RTR0MemKernelCopyTo+0x13: redundant CLD

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: VBoxHost_RTR0MemKernelCopyFrom+0x13: redundant CLD

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/process-r0drv-linux.o

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeLockUser’:

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1228:18: error: too many arguments to function ‘get_user_pages’

1228 | rc = get_user_pages(R3Ptr, /* Where from. */

| ^~~~~~~~~~~~~~

In file included from /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/the-linux-kernel.h:102,

from /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:31:

./include/linux/mm.h:2430:6: note: declared here

2430 | long get_user_pages(unsigned long start, unsigned long nr_pages,

| ^~~~~~~~~~~~~~

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1261:33: error: passing argument 6 of ‘get_user_pages_remote’ from incompatible pointer type [-Werror=incompatible-pointer-types]

1261 | papVMAs /* vmas */

| ^~~~~~~

| |

| struct vm_area_struct **

./include/linux/mm.h:2400:33: note: expected ‘int ’ but argument is of type ‘struct vm_area_struct *

2400 | int *locked);

|
Code:
~~^~~~~~

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1245:18: error: too many arguments to function ‘get_user_pages_remote’

1245 | rc = get_user_pages_remote(

| ^~~~~~~~~~~~~~~~~~

./include/linux/mm.h:2397:6: note: declared here

2397 | long get_user_pages_remote(struct mm_struct *mm,

| ^~~~~~~~~~~~~~~~~~~~~

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1304:39: error: assignment of read-only member ‘vm_flags’

1304 | papVMAs[rc]->vm_flags |= VM_DONTCOPY | VM_LOCKED;

| ^~

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeMapUser’:

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:1774:35: error: assignment of read-only member ‘vm_flags’

1774 | vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;

| ^~

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/rtStrFormatKernelAddress-r0drv-linux.o

cc1: some warnings being treated as errors

CC [M] /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/semevent-r0drv-linux.o

make[3]: *** [scripts/Makefile.build:251: /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.o] Fehler 1

make[3]: *** Auf noch nicht beendete Prozesse wird gewartet …

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPDrvTracer.o: warning: objtool: SUPR0TracerFireProbe+0x7: indirect jump found in RETPOLINE build

/var/lib/dkms/virtualbox/6.1.38/build/vboxdrv/SUPDrvTracer.o: warning: objtool: supdrvTracerProbeFireStub+0x0: 'naked' return found in RETHUNK build

make[2]: *** [scripts/Makefile.build:488: /var/lib/dkms/virtualbox/6.1.38/build/vboxdrv] Fehler 2

make[1]: *** [/usr/src/linux-headers-6.5.0-14-generic/Makefile:2037: /var/lib/dkms/virtualbox/6.1.38/build] Fehler 2

make: *** [Makefile:234: __sub-make] Fehler 2

make: Verzeichnis „/usr/src/linux-headers-6.5.0-14-generic“ wird verlassen

Ist da evtl mit dem Skript nicht in Ordnung, der die Kopilation regelt? Wie kann ich das Problem lösen?

Ich habe versucht das System mit einem älteren Kernel zu booten aber es bringt nichts.
 
Ich glaube mal (habe keine Zeit für dich zu googeln), dass es genau daran liegt (siehe 1. Post von dir):

If your system has EFI Secure Boot enabled you may also need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them. Please see your Linux system's documentation for more information.
Ergänzung ()

BTW: Nutze entweder einen anderen Service für Virtualization (zB kvm+qemu = libvirt), denn virtualbox ist sowieso ziemlich grindig, und auch gleich ein vernünftiges Linux-Betriebssystem für solche Dinge wie zB Fedora, Ubuntu oder auch CentOs Stream aber auch Debian...

Ich will Linux-Mint ja nicht schlecht machen, aber diese Distribution ist halt eher auf Noobs fokussiert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: madmax2010
@klausk1978 wenn es an der Signatur läge, dann würde die Fehlermeldung ausschließlich beim Laden des Kernelmoduls kommen, nicht beim Bauen.

Klingt eher als ob die Kernelmodule die da für VirtualBox ausgeliefert werden nicht zum aktuell genutzten Kernel passen.

Muss es den VirtualBox sein? Und nicht etwas kas In-Tree ist und keine selbstgebauten Kernelmodule braucht?
 
@Ray519 libvirt in Kombination mit der virtmanager-gui wäre zB eine Lösung für einen noob.

Es gäbe natürlich auch noch cloud-init ;-)
 
@klausk1978 Ich bin ja auch Noob 😁. Mint gefällt mir, weil eben alles normalerweise mitgeliefert ist und auf Anhieb funktioniert. Wie ich geschrieben habe, habe ich Virtualbox lange ohne Probleme benutzt und es gab kein Problem mit dem Secureboot. Das kam ziemlich plötzlich vor ein Paar Wochen. Evtl nach einem Update? Habe das nicht beobachtet
Mal schauen, vielleicht muss ich ja wirklich die VM wechseln wenn ich das Problem nicht bald löse.

über kvm+qemu werde ich gleich was lesen. Höre zum ersten mal davon
 
Kein Plan schrieb:
Ist da evtl mit dem Skript nicht in Ordnung, der die Kopilation regelt? Wie kann ich das Problem lösen?
Yep... Das dürfte der Bug hier sein:

https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/2044598

Der Weg, der dort veschrieben wird, ist auf VirtualBox 7 direkt von Oracle zu upgraden.

https://askubuntu.com/a/1498308

Ich würde aber auch lieber auf Virt-Manager oder Gnome Boxes (super easy zu bedienen) umsteigen - einfach besser als VirtualBox.
 
  • Gefällt mir
Reaktionen: Kein Plan
=rand(42) schrieb:
Der Weg, der dort veschrieben wird, ist auf VirtualBox 7 direkt von Oracle zu upgraden.
danke. Habe mehrmals und lange gegoogelt, das hier leider nicht gefunden.
D.h. Ich kann meine virtuellen Festplatten mit den Systemen auch in den vorgeschlagenen Gnome Boxen/VirtManager benutzen?
 
Ooh, das ist ein Argument. Theoretisch ja (d.h. nicht von mir getestet), wenn man die virtuellen Festplatten konvertiert (die ursprüngliche Platte bleibt natürlich erst mal bestehen, also zunächst kein risiko)

VBoxManage clonehd PFAD_VBOX.vdi image_tmp.img --format raw
qemu-img convert -f raw -O qcow2 image_tmp.img image_kvm.qcow2

https://docs.openstack.org/image-guide/convert-images.html

So sollte sich das image_kvm.qcow2 dann einfach in kvm einhängen passen.

----------

Ja, Sorry - eine so wirklich zufriedenstellende Antwort hab ich nicht.
Das mit den externen Kernel-Modulen (wie VirtualBox; anders als KVM, das direkt in Linux integriert ist) auf Linux ist Mist, wars schon immer und wirds auch immer sein.

Also mit VirtualBox entweder warten bis die von Ubuntu den Mist wieder in Griff bekommen haben. Oder nimm Oracle - damit funktioniert VirtualBox sicher jetzt - auch wenn ich Probleme bei zukünfitgen Updates nicht ausschließen würde.

Oder wenn dugerade Experimentierfreudig bist, probier virt-manager / boxes aus(letzteres ist übrigens der Versuch einer maxinal einfachen Oberfläche).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Kein Plan
Danke für die Hilfe. Ich habe durch den Tip von =rand das Problem vorübergehend gelöst, indem ich einfach den 6.5 Kernel entfernt habe. Mit dem 6.2.x.x lässt sich alles installieren und starten. Das ist natürlich keine dauerhafte Lösung. Bin jetzt nicht sicher, sind sicherheitsrelevante Updates im 6.2er enthalten oder sollte man unbedingt den 6.5er benutzen wenn er schon da ist? Werde mich in Zukunft auf jeden Fall nach anderen VMs umsehen.
 
Würde generell den Umstieg auf kvm+qemu mit virt-manager als GUI/Frontend empfehlen. Ist auch sehr einfach zu benutzen.
 
Ich halte es für problematisch, bei auftauchenden Ungereimtheiten eines bestimmten Programms gleich mit der Empfehlung zu kommen, dann eben ein anders Programm zu nehmen. VirtualBox ist immerhin so etwas wie der Standard-Virtualisierer in der Linux-Welt. Ich sehe daher VirtualBox und Linux in der Pflicht, eine für Jedermann gangbare Lösung ohne Frickelei zu entwickeln.

Auch bedeutet der Umstand, dass die meisten Linuxe nun auch bei eingeschalteten Secure Boot laufen, nicht automatisch, dass es nicht doch im Betrieb zu Problemen kommen kann. Der Teufel steckt bekanntlich im Detail.

Vor einiger Zeit gab es ein ähnliches Problem wie beim TE, bloß unter dem VMware Player (die andere Virtualisierer-Alternative). Da lief der Player auf einmal auch nicht mehr (unabhängig von Secure Boot). Aber ab VMware Player Version 17 funktionierte es dann wieder.

Qemu/KVM ist zwar die universellste Virtualisierungslösung. Aber selbst mit der grafischen Bedienoberfläche des 'VirtManagers' ist das nicht gerade die Empfehlung für 'Noobs'. Der VirtManager kann zwar insgesamt mehr, aber intuitiver und bequemer sind nunmal VirtualBox und VMware handzuhaben.

Es kommt auch darauf an, was für VMs betrieben werden sollen. Unter dem VirtManager und optimaler Konfiguration laufen Linux-VMs von der Performance her mindestens so gut wie unter den beiden anderen Virtualisierern. Die Performance von Windows-VMs ist dagegen meinen Erfahrungen zufolge unter dem VirtManager schlecht. Man kann es beispielsweise auch daran erkennen, dass man dort in einer VM mit Windows 7 die Aero-Funktion nicht zu aktivieren vermag.
 
  • Gefällt mir
Reaktionen: andy_m4
7vor10 schrieb:
Ich halte es für problematisch, bei auftauchenden Ungereimtheiten eines bestimmten Programms gleich mit der Empfehlung zu kommen, dann eben ein anders Programm zu nehmen.


Wann immer man unter Linux out-of-tree Treiber lokal kompilieren muss sind Probleme so viel wahrscheinlicher. Ob sie Out-of-tree sind weil proprietär oder Lizenzinkomptaibilitäten.
Dann sollte man sich immer die Frage stellen ob es eine In-Tree Alternative gibt. Kann immer noch sein, das die Out-of-Tree Lösung besser für deinen Fall ist, aber das sollte man einfach im Auge behalten. Und gerade bei Leuten die mit Linux nicht so vertraut sind um diese Probleme zu erkennen wenn sie auftreten und korrekt zuzuordnen und die Nachteile vorab korrekt zu bewerten, ist meine Antwort eher: dann geht was du willst halt nicht, als 3rd party Paketquellen oder Out-Of-Tree Module zu nehmen. Gerade wenn die Linux Kernel Entwickler sowas offen bekämpfen / Out-of-Tree Module nicht einfacher und stabiler machen wollen.

Höchstens wenn es das direkt von den Distromaintainern gibt mit Garantieen das es geht. Aber ansonsten kann man sich nicht darauf verlassen.

Für unbedarfte Linux Nutzer musst du entweder die Administration / Management von Versionen etc. übernehmen, sie müssen es lernen wollen und auch verstehen oder man sollte die Finger von solchen Sachen lassen.
 
  • Gefällt mir
Reaktionen: andy_m4
Frage, muss Secure Boot unbedingt eingeschaltet sein und laufen?
Ich sehe, besonders im privaten Umfeld, keinen Mehrwert dafür.
Es wird von Windows zwingend (korrigiert mich wenn ich irre) vorgeschrieben, aber der Nutzen?
Die meiste Schadsoftware, besonders unter Windows, verhindert Secure Boot ohnehin nicht. Die kommt auf anderen Weg, und es gibt mittlerweile gut dokumentierte Fälle, wo kompromittierte Windows Treiber signiert wurden und Secure Boot damit ebenfalls umgingen.

https://www.heise.de/news/Windows-1...I-Bootkit-BlackLotus-Secure-Boot-7533078.html

Im Firmenumfeld, besonders bei Laptops mit sensiblen Daten sehe ich wesentlich mehr Sinn für so etwas, wobei da gäbe es bessere und sicheres als Secure Boot, welches ausgerechnet von MS forciert wurde.

Also warum nicht einfach ausschalten, wenns geht?

Abseits von Secure Boot, das ganze dürfte den neuen Kernel 6.5.x betreffen, welcher vor kurzen unter Ubuntu/Mint ausgeliefert wurde. Scheinbar gibt es noch keine aktuellen Treiber für Virtualbox.
Könnte mir vorstellen, dass VirtualBox mit gebooteten Kernel 6.2 wieder funktioniert. Müsste man probieren.
 
Zuletzt bearbeitet:
7vor10 schrieb:
Ich halte es für problematisch, bei auftauchenden Ungereimtheiten eines bestimmten Programms gleich mit der Empfehlung zu kommen, dann eben ein anders Programm zu nehmen.
Ja. Da gehe ich mit mit Dir.

7vor10 schrieb:
VirtualBox ist immerhin so etwas wie der Standard-Virtualisierer in der Linux-Welt.
Das kann man so nicht sagen. Die Standardlösung unter Linux ist KVM/QEMU und das wird auch durch zahlreiche Tools unterstützt, damit es benutzerfreundlich ist.
VirtualBox' Stärke ist tatsächlich die Benutzerfreundlichkeit (und die Tatsache, das es auf mehreren Systemen zur Verfügung steht). Allerdings hat man auch ab und an mal "trouble".
Die Gefahr dafür kann man natürlich minimieren, in dem man sich rein aufs Distributions-Repository beschränkt.

7vor10 schrieb:
Ich sehe daher VirtualBox und Linux in der Pflicht, eine für Jedermann gangbare Lösung ohne Frickelei zu entwickeln.
Naja. Bezüglich VirtualBox kann nur VirtualBox/Oracle eine Verantwortung tragen.
Ich muss generell sagen, das die Qualität von VirtualBox nachgelassen hat. Das man den (so wie früher) uneingeschränkt als Desktop-Virtualisierer für Laien empfehlen kann, das scheint irgendwie vorbei.
Ergänzung ()

mike78sbg schrieb:
Die meiste Schadsoftware, besonders unter Windows, verhindert Secure Boot ohnehin nicht. Die kommt auf anderen Weg, und es gibt mittlerweile gut dokumentierte Fälle, wo kompromittierte Windows Treiber signiert wurden und Secure Boot damit ebenfalls umgingen.
Ja. Secure-Boot schützt nur vor recht speziellen Szenarien und hat dafür für Viele kaum einen Mehrwert.
 
Grundsätzlich sehe ich das auch so, dass man nicht bei kleinen Problemen auf andere Tools verweisen sollte.
Aber in dem Fall sehe ich halt nicht wirklich einen validen Grund, weiterhin VirtualBox zu verwenden. Das Teil mieft schon allein deshalb etwas, weil es von Oracle ist oder von denen übernommen wurde. Selbst wenn es Open Source sein sollte. (Bin grad nicht sicher. Wenn's proprietär ist, wäre das ein weiterer Grund, darauf zu verzichten)
KVM+QEMU ist der Standard unter Linux (KVM ist direkt vom Kernel supported), daher empfehle ich das auch. Ich weiß, dass VirtualBox populär ist, aber ich denke vor allem im Windows-Bereich. Und populär heißt halt nicht automatisch immer gut oder sinnvoll für jeden Einsatzzweck.
Einfach mal ausprobieren - diese Kombi mit Virt-Manager als GUI-Frontend ist wirklich nicht schwer zu benutzen.
 
jenzen schrieb:
dass VirtualBox populär ist, aber ich denke vor allem im Windows-Bereich.
Das ist auch im Windows Bereich keine Empfehlung mehr. Vllt haben sie es mittlerweile wieder geändert, aber die hatten ihren eigenen Hypervisor der entsprechend jeglichen anderen Hypervisor verhindert. So dass wenn Virtualbox mit Hypervisor installiert ist lauter Sicherheitstechniken von Windows und diverse andere Programme (WSL, Sandbox, Emulatoren) nicht mehr gehen. Dadurch das Virtualisierung überall eingezogen ist, sollte es mit Windows etwas sein, dass auf die Hyper-V-Platform setzt, damit es nicht exklusiv Virtualisierungsfeatures nutzten muss.
 
  • Gefällt mir
Reaktionen: jenzen
7vor10 schrieb:
VirtualBox ist immerhin so etwas wie der Standard-Virtualisierer in der Linux-Welt.
Wer behauptet denn das?

VirtualBox ist doch nur das, was der Normalnutzer von Windows her kennt und dann - völlig verständlich - nach einem Linux-Umstieg weiter nutzt, weil es das ist, was er bereits kennt.

7vor10 schrieb:
Ich sehe daher VirtualBox und Linux in der Pflicht, eine für Jedermann gangbare Lösung ohne Frickelei zu entwickeln.
Aha. In der Pflicht. Auf welcher Grundlage?

Ist ja nicht so, als würdest du für Linux Geld zahlen, oder? Und selbst wenn du tatsächlich z.B. Ubuntu Pro Desktop hättest - Ubuntu unterstützt nicht einmal VirtualBox offiziell. Das Zeug lebt in Multiverse - also Software mit problematischer Lizenzlage maintained ausschließlich von Freiwilligen.

7vor10 schrieb:
Die Performance von Windows-VMs ist dagegen meinen Erfahrungen zufolge unter dem VirtManager schlecht.
Das wiederum ist ein guter Hinweis.

Man muss wie bei VirtualBox das Win Guest tool für optimale Performance nachinstallieren. Zugegeben bisschen komisch zu finden, aber hier ist der Link:

https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.240-1/
 
=rand(42) schrieb:
Aha. In der Pflicht. Auf welcher Grundlage?
Wir reden hier nicht von juristisch einklagbaren Forderungen, sondern von 'moralischen' Pflichten, denen sich Menschen bisweilen verpflichtet fühlen, sei es aus Ehre oder Ehrgeiz und was sonst noch.

Linux ist gratis; das ist bekannt. Fast so bekannt, wie der Umstand das 'gratis für den Nutzer' nicht zwingend bedeutet, dass die Linux-Maintainer deswegen grundsätzlich kein Geld akquirieren könnten. Linus Torvalds z.B. ist seit Jahren schon Multimillionär und auch andere Linux-Häuptlinge haben durchaus ein Auskommen unter Linux gefunden. Wenn die grundsätzlich immer die Einstellung hätten, ihr da unten, ihr kleinen Linux-Wichtel, Eure Meinung und Eure Wünsche interessieren uns nicht die Bohne, wäre die gesamte Linux-Welt ganz schnell wieder am Ende.

So denken die aber nicht! Die haben schon den Ehrgeiz, Linux besser zu machen und immer mal wieder auftauchende Probleme zu lösen.

Und denen ist es auch nicht egal, wenn beispielsweise ein so essentielles Programm wie VirtualBox dauerhaft nicht funktionieren würde.

Bill Reynolds (Maintainer von PCLinuxOS) wurde einmal gefragt, warum er ausgerechnet den VirtManager nicht im ansonsten sehr reichhaltigen PCLinuxOS-Repositorium bereithält. Seine Antwort war (sinngemäß), warum die Dinge komplizierter machen als nötig - wenn es doch mit VirtualBox und VMware zwei einfacher zu nutzende Standard-Virtualisierer gibt.

Qemu/KVM mit VirtManager kann wie schon gesagt unterm Strich mehr als die beiden vorgenannten (jeweils am Umfang der Freeware-Version gemessen), aber der sogenannte 'Noob' wird auch unter Linux eine einfachere Lösung einer komplexeren vorziehen. Zumindest so lange wie er auf die komplexeren Features nicht angewiesen ist.

Wir sollten nicht vergessen, dass Menschen, die sich wirklich für Computer als solche interessieren, eine kleine Minderheit darstellen (ich beziehe das Windows-Lager da ausdrücklich mit ein). Nicht umsonst haben in den letzten Jahren viele der Desinteressierten die (private) Beschäftigung mit Computern aufgegeben. Weil sie es nicht mehr müssen! Das bißchen, was sie noch brauchen, finden sie am Smartphone. Auch aber die, welche wie ich, richtige Computer für unverzichtbar halten, bevorzugen meist einfachere Lösungen gegenüber komplizierteren. Das ist auf allen Gebieten so; quasi ein Naturgesetz des Lebens in jeglicher Form.

Übrigens, was den Link zu den Virtio-Treibern betrifft, so schaue ich in größeren Abständen nach, was an eventellen Fortschritten zu vermelden ist. Mein letzter Stand aber ist, dass in Sachen Grafik-Performance für Windows-VMs noch kein Durchbruch erzielt ist. Simpel gesagt, es gibt noch kein VirGL für Windows in der gleichen Qualität wie VirGL für Linux.
 
7vor10 schrieb:
Und denen ist es auch nicht egal, wenn beispielsweise ein so essentielles Programm wie VirtualBox dauerhaft nicht funktionieren würde.
Der Punkt von Copyleft-Opensource ist, dass der Code so wie er ist zur Verfügung gestellt wird. Und wenn du daran was geändert haben möchtest musst du entweder jemanden finden der das für Geld oder aus Spaß macht oder selbst Hand an legen, sonst ändert sich nichts.

Und ganz im Gegenteil, die Kernel-Entwickler sagen explizit, dass Kernel-Module / Code der Out-of-Tree lebt für sie nicht existiert und keinerlei Zugeständnisse für eine stabile API für Out-of-Tree Dinge gemacht werden. Genau das was dazu geführt hat, dass eine Version der VirtualBox Kernel-Module nicht mehr zu einem leicht neueren Kernel passt.
Die Kernel-Entwickler gehen damit sogar noch viel weiter und versuchen absichtlich Out-of-Tree Code, der nicht GPL ist (proprietär/nicht opensource oder opensource aber nicht mit der GPL vereinbar, siehe Nvidia Treiber, ZFS) Steine in den Weg zu legen, weil sie rein aus Überzeugung gegen solche Dinge sind. Die wollen das non-GPL Kernel-Module aufhören zu existieren. Solange VirtualBox also nicht in den Kernel wandert / den schon existierenden Support im Kernel nutzt, wird das nur weniger kompatibel werden.

Edit: VirtualBox ist scheinbar schon länger unter GPL. Keine Ahnung wie vollständig und woran genau es liegt, dass dessen Kernelmodule nicht schon länger In-Tree sind. Vllt weil sie sich beißen mit KVM und der Rest in der Linux-Welt KVM nutzt, insbesondere die Cloud-Anbieter etc. die viel Entwicklung finanzieren und VirtualBox weder brauchen noch mit dem Oracle-Lizenzkram wollen? Vllt weil Oracle die Kernel-Module unter ihrer Kontrolle haben will, so dass die sich nicht "von alleine" ändern?
 
Zuletzt bearbeitet:
7vor10 schrieb:
Wir reden hier nicht von juristisch einklagbaren Forderungen, sondern von 'moralischen' Pflichten, denen sich Menschen bisweilen verpflichtet fühlen, sei es aus Ehre oder Ehrgeiz und was sonst noch.
Aha, eine "moralische" Pflicht.

Also der Bug hier ist laut Bugtracker gefixed, aber was du schreibst finde ich trotzdem gut. Dann bewirbst du dich also demnächst als Ubuntu VirtualBox Maintainer und sorgst dafür, dass solche Probleme nicht mehr auftreten?

Oder was ist die Logik? Andere sind in der "moralischen" Pflicht für dich die Arbeit zu machen - du aber nicht, weil du bist ja du nicht nicht irgendein Ramdon Freiwilliger? Sorry, das klingt blöd, muss ich aber mal so schreiben...

7vor10 schrieb:
Linus Torvalds z.B. ist seit Jahren schon Multimillionär
Alternativ darfst du selbstverständlich auch Maintainer sponsorn.
Linus wird aber wohl nicht von privat, sondern von Firmen (Rad Hat, viele andere Firmen indirekt über Linux Foundation, ...) gesponsort.

7vor10 schrieb:
Bill Reynolds (Maintainer von PCLinuxOS) wurde einmal gefragt, warum er ausgerechnet den VirtManager nicht im ansonsten sehr reichhaltigen PCLinuxOS-Repositorium bereithält. Seine Antwort war (sinngemäß), warum die Dinge komplizierter machen als nötig - wenn es doch mit VirtualBox und VMware zwei einfacher zu nutzende Standard-Virtualisierer gibt.
Keine Ahnung. Glaub einfach mal dein Wort - ohne Quelle. "Einmal" ist halt auch gut gesagt, PCLinuxOS ist initial erschienen bevor KVM im Mainline-Kernel angekommen war. Damals war die Situation offensichtlich eine andere, was die Aussage "komplizierter machen" sehr gut erklären würde...
Ansonsten darf natürlich jeder seiner Meinung sein und Linux-Distributionen bauen, wie er Bock hat. Das ist der Witz an Open Source.

Der Punkt war, ist ein bisschen lachhaft von nicht bezahlten Freiwilligen irgendetwas zu fordern.

7vor10 schrieb:
Simpel gesagt, es gibt noch kein VirGL für Windows in der gleichen Qualität wie VirGL für Linux.
Das ist richtig, aber eine langweilige Aussage.

Die wesentlichen Fragen sind wohl:
  • Wie gut ist 3D Hardwareacceleration im Vergleich zu Virtualbox
  • Reicht dass, dass der Endnutzer vernünftig seinen Desktop mit Office-Software darstellen kann
Letzteres sage ich aus meiner Erfahrung einfach mal ja.
Ersteres könnte man mal testen. Ist ja nicht so, als wäre der VirtualBox Treiber gut - also insbesondere im Vergleich zu VMware.
 
Zurück
Oben