VirtualBox Ubuntu bootet nicht auf neuem PC

[King Julian (Gast)]

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?

[Andreas R. (daybyter)]

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.

[Rolf M. (rmagnus)]

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.

[Da D. (dieter)]

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?

[King Julian (Gast)]

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.

[ui (Gast)]

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

[Dr. No (Gast)]

ui schrieb:
> vorhanden sind crasht dein Kernel


Nö, der Kernel crasht nicht.

[King Julian (Gast)]

Es kann doch nicht sein, dass das System nicht booten kann weil das 
Mounten eines Netzlaufwerks fehlschlägt, dass kann ja jederzeit 
passieren

[Da D. (dieter)]

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.

[Rolf M. (rmagnus)]

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?

[Arno (Gast)]

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

[King Julian (Gast)]

Ihr hatted mal wieder recht, hab das mounting für das Laufwerk entfernt 
und nun booted er wieder. Vielen Dank!