Ok, VMware-eigene Werkzeuge wie v2p sind keine Lösung?
[Edit] Ich sehe grade, für Linux gibt's das nicht, sondern nur für Windows....ärgerlich...
Anmeldungsdatum: Beiträge: 1032 |
Ok, VMware-eigene Werkzeuge wie v2p sind keine Lösung? [Edit] Ich sehe grade, für Linux gibt's das nicht, sondern nur für Windows....ärgerlich... |
(Themenstarter)
Anmeldungsdatum: Beiträge: 73 |
Das Problem ist, dass wir die Datei, welche fsarchiver zur Verfügung stellt, anschließend noch weiter verwursten. Auch ist der Updater bisher auf das fsarchiver Format angewiesen, was ich auch nicht ändern kann. Also wird es wohl eher nicht gehen. Aber Danke für den Einwurf. ☺ |
(Themenstarter)
Anmeldungsdatum: Beiträge: 73 |
Also, ich habe mit "dpkg --purge" die entsprechenden Kernel Pakete entfernt. Dann habe ich aus dem Ubuntu Repository die aktuellen Kernel Pakete manuell heruntergeladen (4.2.0-36), auf die Maschine geschoben und mit "dpkg --install" installiert. Den Rest drum rum habe ich nach der Anleitung gemacht: http://askubuntu.com/a/28183 Ergebnis: Das Problem besteht weiterhin. Auch der neue Kernel bleibt hängen. ☹ Noch schlimmer: Jetzt bekommen ich ihn nicht einmal durch Drücken von irgendwelchen Knöpfen weiter... |
(Themenstarter)
Anmeldungsdatum: Beiträge: 73 |
Ich bin jetzt mal auf Kernel 3.13.0-24 zurück. Das ist der Kernel, welcher auch auf der anderen Partition läuft. [ 7.629338] Adding 3906556k swap on /dev/sda3. Priority:-1 extents:1 across:3906556k SSFS Und, die SWAP ist nicht im Eimer, da sie mit der anderen Linux Installation auf der gleichen Hardware wunderbar zusammenarbeitet. 😉 Der Lösung bin ich aber jetzt nicht viel näher gekommen... ☹ |
(Themenstarter)
Anmeldungsdatum: Beiträge: 73 |
Zwischenzeitlich habe ich das Problem lösen können: Ich habe auf der nativen Hardware zwei Ubuntu Installationen hochgezogen, dieses mit Clonezilla abgezogen, in VMware eine VM erstellt und dort mit Clonezilla wieder eingespielt. Dann beide Linux System gestartet und anschließend wieder mit Clonezilla ein Image gezogen. Dieses dann wieder auf der nativen Hardware eingespielt. Und siehe da: Es läuft wunderbar und hat auch keine Einträge der VMware Hardware mehr im kern.log. Außer natürlich zu der Zeit, in der es wirklich auf VMware lief. Das ganze funktioniert auch mit Installation der open-vm-tools (die ich während des Prozesses zur Steuerung der VM benötige): Ich habe diese bereits auf der nativen Hardware installiert und am Ende der VMware Sitzung wieder deinstalliert. |