Vielleicht kann mir jemand weiterhelfen der etwas mehr von Linux/Virtualbox versteht als ich. Mein Problem, ich würde gerne meine virtuelle Linux Ubuntu Maschine von einem Rechner auf einem anderen verwenden. Also habe ich einfach den gesamten Order des images vom einen zum anderen kopiert und dort gestartet. Anfänglich hat bereits das Ausführen nicht geklappt, weil gewisse Features für die Virtualisierung nicht aktiviert waren, das hab ich dann behoben. Nun hab ich das Problem, dass die Linux Maschine beim booten in den Emergency Mode geht und ich nicht weiss wieso. Kleiner Unterschied zwischen den beiden PCs ist, dass der neuen ein Dualboot System ist. Wenn ich nun die virtuelle Maschine starte, lande ich im GRUB was auf der Ursprungssystem ohne Dualboot nicht der Fall ist. Habe noch einen Screenshot angehängt, kann es sein, dass das fehlende Netzlaufwerk Probleme macht das er nicht mounten kann?
Wieso hast Du den Ordner kopiert? Der korrekte Weg ist, die VM auf dem alten Rechner zu exportieren, dieses File zu kopieren und es auf dem neuen Rechner zu importieren.
King Julian schrieb: > Also habe ich einfach den gesamten Order des images vom einen zum anderen > kopiert und dort gestartet. Du musst es als Appliance exportieren, nicht einfach die Dateien rüberkopieren. Das wird nicht ohne manuelle Nacharbeit funktionieren.
Warum funktioniert kopieren nicht? Bzw. welche Probleme kann es dabei geben? Ich hab meine VMs bisher immer durch einfaches Kopieren auf andere Systeme umgezogen und nie Probleme gehabt. Hab ich einfach Glück gehabt?
Ich bin auch davon ausgegangen dass das funktionieren sollte, zumindest da laut Google dies die einfachste Möglichkeit ist. Leider hab ich den anderen Rechner nicht zur Verfügung um es mit einem Export zu versuchen. Niemand eine Idee wie sich das Problem beheben lässt? Das Filesystem der VM scheint intakt zu sein, zumindest kann ich darauf zugreiffen.
Steht doch da... In der orignalen VM hattest du einen shared folder, den hast du jetzt nicht mehr. Da dafür Anpassungen im Guest Kernel notwendig sind versucht er auf biegen und brechen die zu mounten. Da sie nicht vorhanden sind crasht dein Kernel
Es kann doch nicht sein, dass das System nicht booten kann weil das Mounten eines Netzlaufwerks fehlschlägt, dass kann ja jederzeit passieren
Mein Tipp zur Reparatur: Versuch es so, wie man ein richtiges Desktopsystem auch reparieren würde. Linux Live-DVD ins (virtuelle) Laufwerk hängen und Maschine starten. Dann schmeißt du das nicht mountbare Dateisystem raus, und kannst wieder ganz normal booten.
King Julian schrieb: > Es kann doch nicht sein, dass das System nicht booten kann weil das > Mounten eines Netzlaufwerks fehlschlägt, dass kann ja jederzeit > passieren Was sagt denn das System, wenn du das tust, was in den Meldungen vorgeschlagen wird?
Das System weiß ja nicht, ob auf dem Netzlaufwerk Daten (oder Programme) sind, die für die Ausführung wichtig sind. Oder nein, eigentlich ist das der falsche Ausdruck... das System glaubt, dass der Zugriff auf das Netzlaufwerk für den korrekten Betrieb nötig ist - so haben die Macher von Ubuntu offensichtlich ihren systemd konfiguriert. Das sagt mir die schöne Zeile "[DEPEND] Dependency failed for Local File Systems". (und das hat bei vielen Netzwerk-Dateisystemen auch seinen Sinn, man kann damit zum Beispiel wunderschön zentrale Home-Verzeichnisse für ein Netzwerk einrichten, oder Softwareinstallationen (/usr und /opt) zentral vorhalten statt auf jedem Client. Es gibt nun zwei Möglichkeiten: 1) Du sorgst dafür, dass der Zugriff wieder funktioniert 2) Du erklärst deinem System, dass das nicht stimmt und es auch bei nicht erreichbarem Netzlaufwerk weiter hochfahren soll. Dazu darfst du dich durch die systemd-Dokumentation wühlen, die ich persönlich als ziemlich bescheiden (unverständlich, nicht logisch aufgebaut, teilweise veraltet, fehlender Zusammenhang zwischen "das ist das Konzept" und "so wird das in der Praxis konfiguriert" - viele wichtige Informationen habe ich nur auf irgendwelchen Blogs gefunden) in Erinnerung habe - einer der Gründe, warum ich weiter auf eine Distribution setze, die keinen systemd einsetzt. MfG, Arno
Ihr hatted mal wieder recht, hab das mounting für das Laufwerk entfernt und nun booted er wieder. Vielen Dank!
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.