[gelöst] Virtualbox Kernel driver not installed

[itssme]

Hi, ich habe ein problem mit Virtualbox. Immer wenn ich eine Virtuelle Maschiene starten möchte, bekomme ich den error "Kernel diver not installed (rc=-1908)"
Hier gibt Virtualbox auch einen tollen Vorschlag -> '/etc/init.d/vboxdrv setup' und das als root ausführen. Das würde ich auch gerne machen, aber diese datei ist gar nicht vorhanden.
Ich hab mir auch schon den thread durchgelesen -> viewtopic.php?f=29&t=162053&hilit=virtu ... +installed
Dort wurde gesagt, dass es diese datei in den neueren versionen nicht mehr gibt bzw. in der version von debian.
Die lösung von dem problem in dem thread war aber ziemlich einfach, denn in /etc/default/virtualbox war LOAD_VBOXDRV_MODULE=0 sollte aber natürlich auf 1 sein (ist bei mir auf 1)
Virtualization ist im bios aktiviert.

Ich benutze übrigens den backports kernel 4.7

Code: Alles auswählen

root@debian:/# uname -a
Linux debian 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19) x86_64 GNU/Linux

dkms ist installiert

Code: Alles auswählen

root@debian:/# dkms -V
dkms: 2.2.0.3

Code: Alles auswählen

root@debian:/# systemctl status virtualbox.service
● virtualbox.service - LSB: VirtualBox Linux kernel module
   Loaded: loaded (/etc/init.d/virtualbox)
   Active: failed (Result: exit-code) since Mon 2016-11-28 10:37:52 CET; 23min ago
  Process: 753 ExecStart=/etc/init.d/virtualbox start (code=exited, status=1/FAILURE)

Nov 28 10:37:52 debian virtualbox[753]: Starting VirtualBox kernel modulesNo suitable module for running kernel found ... failed!
Nov 28 10:37:52 debian virtualbox[753]: failed!
Nov 28 10:37:52 debian systemd[1]: virtualbox.service: control process exited, code=exited status=1
Nov 28 10:37:52 debian systemd[1]: Failed to start LSB: VirtualBox Linux kernel module.
Nov 28 10:37:52 debian systemd[1]: Unit virtualbox.service entered failed state.

Code: Alles auswählen

root@debian:/# dpkg -l *virtualbox* |grep ii
ii  virtualbox                     4.3.36-dfsg-1+deb8u1       amd64        x86 virtualization solution - base binaries
ii  virtualbox-dkms                4.3.36-dfsg-1+deb8u1       all          x86 virtualization solution - kernel module sources for dkms
ii  virtualbox-qt                  4.3.36-dfsg-1+deb8u1       amd64        x86 virtualization solution - Qt based user interface

Würde mich wirklich über ein bisschen hilfe freuen!

[segmentationfault]

Hallo Itssme,

sind die Kernel-Header auch installiert?

Des weiteren ist mir bei den Eigenbaukerneln folgendes aufgefallen. Ich verwende ebenfalls Virtualbox um eine Window7-Installation zu verwenden wegen diversen Firmwareupgrades die unter Debian leider nicht möglich sind (einziger Grund für Windows7 bei mir aber nur in der Box).

Bei den selbstgebauten Kerneln mit einem Kernel_image und einem Kernel_header ist es offenbar wichtig, daß ich die Kernel-Source nicht entferne, die dort liegen wo ich den von http://www.kernel.org runtergeladenen Kernel entpackt habe und dort das Kompilieren durchgeführt habe. Ansonsten kommt der gleiche Fehler auch bei mir hoch. Diese Kernel-Sourcen müssen dort bleiben wo der Kernel erstellt wurde.

es kann also sein, daß die Kernel_header alleine nicht weiterhelfen sondern auch die Sourcen bereitgestellt sein müssen. Besser kann ich es leider nicht erklären aber vielleicht antwortet noch jemand mit mehr Ahnung in der Sache.

Gruß
Segmentationfault

[towo]

1. 4.7.0-0.bpo.1-amd64 ist kein Eigenbau-Kernel.
2. Ja, es ist notwendig, dass die passenden Headers zum Kernel installiert sind, sonst ist es Essig mit 3rd Party Modulen
3. Wenn man Kernel so baut, dass da Debs hinten bei rausfallen (make deb-pkg), dann braucht man auch die Sourcen nicht aufheben.

[ThorstenS]

Dein virtualbox sollte ebenso von bpo kommen, wie dein kernel.

Code: Alles auswählen

 apt-get -t jessie-backports install virtualbox-qt virtualbox virtualbox-dkms 

Und ein Tipp: Falls du vagrant benutzt, hol dir das deb direkt von https://www.vagrantup.com/downloads.html
Die Version aus testing erfordert auch ruby-Backports - tu dir den Ärger nicht an.

[segmentationfault]

Hallo towo,

ja, zu 1) hatte ich auch nicht Bezug genommen auf den vom Themenersteller genannten 4.7.0-0.bpo.1-amd64 sondern nur auf meine Beobachtung wenn ich von kernel.org die Sourcen runterlade und dann einen Eigenbau erstelle. 4.7.0-0.bpo.1-amd64 ist natürlich kein Eigenbau.

zu 3) Auch bei den Eigenabukernel erstelle ich debs und zwar z.B. ein linux-image-4.8.11_4.8.11_amd64.deb sowie ein linux-headers-4.8.11_4.8.11_amd64.deb allerdings nicht mit make deb-pkg sondern (Entschuldigung) make-kpkg. Dann ist mir eben aufgefallen dass die Sourcen dabei bleiben müssen wenn Virtualbox laufen soll. Aber mit make deb-pkg ist es dann wohl anders.

Gruß
segmentationfault

[itssme]

Ah danke!
Hatte vergessen das alles aus den backports zu installieren
Hab mir auch gleich die guest addons installiert

[towo]

sondern (Entschuldigung) make-kpkg. Dann ist mir eben aufgefallen dass die Sourcen dabei bleiben müssen wenn Virtualbox laufen soll.

Und das ist auch der Grund, dass Debian kernel-package nicht mehr empfielt. kernel-package erzeugt nämlich die notwendigen Symlinks in /lib/modules/$(uname-r) nicht.
Für 3rd Party Kernel-Module wird nie die Kernel-Source benötigt, wenn die Headers installiert sind.

[segmentationfault]

Hallo towo,

besten Dank für die Erläuterung!

Jetzt sehe ich ein von make-kpkg Abschied zu nehmen!
Das ist ein einleuchtendes Argument.

Gruß
segmentationfault

[segmentationfault]

So, gerade habe ich mal am 4.9rc7 mit make deb-pkg probiert.

Das funktioniert einwandfrei und die Sourcen sind für Virtualbox überflüssig.
Genauso überflüssig ist nun das Paket kernel-package.


Gruß
Segmentationfault

[KP97]

Ich wollte schon etwas eher schreiben, habe aber doch noch gewartet.
Ich bin nun auch auf deb-pkg umgestiegen, weil ich festgestellt habe, daß das Kompilieren schneller geht, als wenn ich mit make-kpkg nur ein Image baue.
Wenn man jetzt noch gcc-5 benutzt, braucht man auch kein makefile zu ändern, dann geht das ruckzuck.
Ich hatte übrigens auch noch nie die Sourcen benötigt, wenn ich die Headers hatte.

Aber was anderes ist mir aufgefallen.
Ich wollte mal spaßeshalber für meinen 27" Monitor die Nvidia Treiber installieren, nur um zu sehen, ob die besser als der Nouveau Treiber sind.
Dabei bekam ich eine Fehlermeldung, daß die Versionsbezeichnung im 4.9.0-rc7 ein ungültiges Zeichen enthält. Da ich an der Bezeichnung nichts geändert habe, vermute ich einen Fehler im Kernel. Sei also gewappnet, falls irgendwas nicht ganz sauber läuft.

[towo]

Code: Alles auswählen

~
towo:Defiant> cat /proc/version && dkms status
Linux version 4.9.0-rc7-siduction-amd64 (towo@siduction.org) (gcc version 6.2.1 20161124 (Debian 6.2.1-5) ) #1 SMP PREEMPT siduction 4.9~rc7-1~exp1 (2016-11-28)
nvidia, 375.20, 4.9.0-rc7-siduction-amd64, x86_64: installed

Nur mal so als Info.

[KP97]

Ich sehe, Du hast den 375.20 im Einsatz. Den gibt es in experimental.
Ich schaue mir das nochmal an und berichte dann.