TL; DR Dies kann durch einen Neustart schnell behoben werden . Dann funktioniert die CD-ROM und die Guest Additions können installiert werden:
sudo reboot
Die "beste" Sequenz, um den Kernel auf VirtualBox mit Additions zu aktualisieren, ist:
apt-get update
apt-get upgrade (or apt-get dist-upgrade)
reboot
(re)install VirtualBox Additions on the new kernel that is now running
apt-get autoremove
(Der neueste alte Kernel wird aus Sicherheitsgründen möglicherweise nicht automatisch entfernt, damit Sie "zurück" gehen können.)
Wie ist es passiert? (vorherige lange Antwort)
Genau diese Art von Problem tritt auf, wenn Sie:
- aktualisiere den Kernel (sprich von .66 auf .67)
- starte
apt-get autoremoveund entferne irgendwie den laufenden Kernel oder entferne manuell den "alten" Kernel, wodurch alle Module aus /lib/modules/kernel.66 entfernt werden
- Starten Sie nicht neu, um den "alten" .66-Kernel am Laufen zu halten. Die geladenen Module bleiben im Speicher und alles funktioniert, aber es können keine neuen Module geladen werden, da .66-Module gelöscht wurden.
- Versuchen Sie, alles zu tun, was das Laden eines noch nicht geladenen Moduls erfordert
Für die Installation der VirtualBox ISO ist möglicherweise genau das erforderlich - Laden des ISO9660-Unterstützungsmoduls.
Das angeforderte Modul kann jetzt nicht mehr automatisch geladen werden, da der ausgeführte Kernel (.66) in /lib/modules/kernel.66 nichts findet. Das Modul ist vorhanden , befindet sich jedoch in /lib/modules/kernel.67, von dem der aktuelle .66-Kernel nichts weiß (und es wird nicht empfohlen, ein nicht übereinstimmendes Modul zu laden).
Das erneute Installieren des unbenannten Kernels wird natürlich die laufenden Kernelmodule erneut installieren, wodurch ../.66/.../isofs.ko wieder verfügbar und ein Neustart unnötig wird. Dies ist ein Downgrade des installierten Kernels und das Update-Problem bleibt bestehen (siehe unten).
Das heißt, wenn Sie die Additions-CD ausführen, wird sie für den laufenden .66-Kernel installiert , nicht für den aktualisierten .67-Kernel (der immer noch nicht läuft).
Wenn Sie in einer solchen Situation sind , können Sie auch sicher das Problem beheben durch einen Neustart (der neue 0,67 laufenden Kernel seine Module finden), und wahrscheinlich durch Laden des Moduls auf den neuen Kernel gehör ( isofsist ziemlich stabil), die es sei denn , Sie haben Ein wichtiges Kernel-Upgrade wird weiterhin kompatibel sein ( dies wird immer noch nicht empfohlen! ):
# mount /dev/cdrom /mnt
mount: unknown filesystem type 'iso9660'
Dies ist der Root-Fehler, den Sie erhalten ("unbekannter Dateisystemtyp").
# uname -a
Linux virtual 3.13.0-66-generic ...
Wir prüfen also, welche Version der Module installiert ist. Es sollte .66 sein:
# ls /lib/modules
3.13.0-67-generic
... aber es gibt nur ein Verzeichnis und es ist .67 (das .66-Verzeichnis ist möglicherweise vorhanden, aber leer; in diesem Fall du -sh /lib/modules/*wird angegeben, wie viel Speicherplatz die verschiedenen Verzeichnisse belegen , sodass zwischen leeren und vollen Verzeichnissen unterschieden werden kann).
Das erneute Installieren des alten Kernel-Images ohne erneutes Grub wird das eigentliche Problem nicht beheben
Sie installieren den .66-Kernel mit seinen Modulen und Headern neu. Jetzt haben Sie beide Kernel, mit denen Sie grubden neueren .67 laden können.
Die ISO-CD-ROM kann gemountet werden (weil das Modul jetzt vorhanden ist) und die VBox-Module werden kompiliert (weil die Header installiert wurden).
Es werden Module für den laufenden .66-Kernel kompiliert, und sie werden ... für eine Weile funktionieren.
Beim ersten Neustart befinden Sie sich mit einem .67-Kernel ohne VirtualBox-Zusätze.
Das erneute Installieren des alten Kernel-Images mit Re-Grub und Re-Boot behebt das eigentliche Problem ebenfalls nicht
Wie oben, starten Sie neu und befinden sich mit einem herabgestuften Kernel. In Kürze wird Ubuntu versuchen, es zu aktualisieren, und Sie sind wieder da, wo Sie begonnen haben (siehe unten: "Kernel herunterstufen").
Das Patchen im ISO-Modul behebt auch nicht das eigentliche Problem
Möglicherweise können wir das ISO9660-Modul trotzdem zwangsweise laden, da zwischen den Kerneln 66 und 67 keine Arbeit geleistet wurde und die Binärdatei im Wesentlichen unverändert ist. Deshalb versuchen wir Folgendes:
# insmod /lib/modules/3.13.0-67-generic/kernel/fs/isofs/isofs.ko
Keine Fehler. Es funktionierte. Kernel .66 geladenes Modul vom Kernel .67. Versuchen wir noch einmal, die CD-ROM zu mounten:
# mount /dev/cdrom /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only
Dies hilft immer noch nicht weiter, da es sich bei der zu installierenden CD um VirtualBox Additions handelt, für die die ausgeführten Kernel-Header installiert sein müssen. Wenn die laufenden Kernelmodule nicht mehr vorhanden sind, werden wahrscheinlich auch die Kernel-Header nicht mehr angezeigt.
Außerdem müssen die neu kompilierten Virtualbox-Module nirgendwo hin, da das .66-Modulverzeichnis bereinigt wurde.
Aber sagen wir, Sie haben das alles behoben: Sie haben im Wesentlichen ein teures (und teilweises) Kernel-Downgrade durchgeführt, und die Ergänzungen gehen beim nächsten Upgrade zusammen mit dem Rest des .66-Kernels verloren, genau wie im obigen Fall.
Das Downgrade des Kernels funktioniert ... für eine Weile
Wenn wir den .67-Kernel entfernen und stattdessen den .66-Kernel mit Modulen neu installieren, wird es für eine Weile schwierig. Kein Neustart erforderlich, wie in der obigen Lösung "Force ISO-Modul".
Und ein Neustart verliert nichts, da kein Kernel installiert ist, der von Additions in Frage gestellt wird.
Auf diese Weise befindet sich der Kernel jedoch weiterhin in der Liste der zu aktualisierenden Kernel, und das gleiche Problem wird früher oder später auftreten.
Zugegeben, Sie können es jetzt in einem angemesseneren Moment Ihrer Wahl entstehen lassen, der eine ganze Menge wert sein könnte.
Einfach neustarten!
Beim Neustart wird der neuere .67-Kernel aktiviert und alle seine Module und Header sind vorhanden.
Also, nach dem Neustart werden Gasterweiterungen arbeiten, und das Upgrade „nehmen“.
