Migration eines Ubuntu Gast-Systems auf eine reale Hardware

[CoderGrizzly]

Hallo zusammen,

ich hoffe, dass mein Thread in diesem Unterforum richtig ist - auch wenn es mit einem Converter eher am Rande zu tun hat. Dafür aber mit dem Konvertieren einer Maschine. Ansonsten würde ich einen der Mods bitten, den Thread entsprechend zu verschieben.

Zum meinem eigentlich Problem: Ich versuche ein Ubuntu 14 System, welches in einer VM läuft, auf eine reale Hardware zu übertragen. Und zwar ziehe ich mit dem Linux Tools fsarchiver eine Linux Partition als Image ab und versuche diese dann auf einer Hardware Appliance wieder einzuspielen.

Dabei treten jedoch verschiedene Probleme auf: U.a. behandelt der Kernel das System weiterhin als VMware Umgebung. Das kann man aber durch "update-initramfs" beheben.

Jedoch hängt sich der Kernel trotzdem noch beim Booten auf. Ich habe schon probiert im Zielsystem den Kernel neu zu installieren - auch in verschiedenen Versionen. Hat aber alles nichts gebracht.

Die Details kann man hier nachlesen: https://forum.ubuntuusers.de/post/8286678/

Habt Ihr mir irgendwelche Tipps und Tricks? Hattet Ihr schon mal ähnliche Probleme?

[~thc]

Moin.

Ich habe mich mal durch deinen verlinkten Artikel gelesen und bin etwas erstaunt.

Der Ansatz, eine Installation auf einer VM zu erstellen und zu pflegen und diese dann per V2P einer Hardware-Appliance als "Update" zu verkaufen... Da muss man erst mal drauf kommen.

Ihr scheint mit Euren Versuchen zudem belegt zu haben, dass es so nicht geht. Obwohl der modulare Linux-Kernel mit dem udev-Subsystem technisch die Voraussetzungen mitbringt, zwischen verschiedenen Hardware-Plattformen hin- und her zu springen, scheint es bei Ubuntu nicht zu gehen.

Es starkes Indiz dafür ist, dass er nach dem Einspielen des Images noch immer hartnäckig meint, auf der alten VMWare Plattform zu laufen - mit BIOS, PCI und allen Treibern.

[CoderGrizzly]

Es starkes Indiz dafür ist, dass er nach dem Einspielen des Images noch immer hartnäckig meint, auf der alten VMWare Plattform zu laufen - mit BIOS, PCI und allen Treibern.

Wie gesagt: Das bekommt man noch in den Griff. Das es danach immer noch Probleme gibt...

In einer Virtualisierung kann man halt schön alles Skripten, im Falle eines Abbruchs beim nächsten Mal einfach alles zurücksetzen (bzw. löschen). Bei einer nativen Hardware wird das etwas schwierig.

[continuum]

Du hast die VM an sich aber auch nicht besonders schlau aufgesetzt.
Statt einer vmxnet3 Nic solltest du zB eine e1000 nehmen.
Ein vmci-device sollte ebenfalls in deiner VM nicht eingebaut sein.
Poste doch mal deine vmx - ich schätze da ist noch mehr drin was da besser nichts verloren hätte.

[CoderGrizzly]

Du hast die VM an sich aber auch nicht besonders schlau aufgesetzt.
Statt einer vmxnet3 Nic solltest du zB eine e1000 nehmen.
Ein vmci-device sollte ebenfalls in deiner VM nicht eingebaut sein.
Poste doch mal deine vmx - ich schätze da ist noch mehr drin was da besser nichts verloren hätte.

Ich bin gerade dabei, einen anderen Weg zu probieren, welcher bis jetzt erfolgversprechend aussieht. Und zwar habe ich per Clonezilla ein funktionierendes System von der native Hardware abgezogen, welche ich in eine VM eingespielt habe. Diese habe ich dann gestartet und anschließend wieder mit fsarchiver ein Image abgezogen, welches ich auf die native Hardware wieder eingespielt habe. Und siehe da, das hat dann funktioniert. Im kern.log war die vmxnet3 drin - aber nur bei dem Start, der innerhalb der VM stattgefunden hat. Sprich das scheint soweit zu funktionieren.

Alllerdings ist das jetzt nur ein Proof-of-Concept und ich muss das ganze noch in unseren Build Prozess einbauen.

[rprengel]

Alllerdings ist das jetzt nur ein Proof-of-Concept und ich muss das ganze noch in unseren Build Prozess einbauen.

Hallo,

warum geht ihr diesen Weg?
Debian Systeme kann man doch einfach Mittels einer Steuerdatei (preseed) sauber installieren. Ubuntu hat da doch auch Möglichkeiten
http://www.gtkdb.de/index_34_1256.html
Dann hat man auch keiner Äger mit irgendwelchen IDs die ggf. im Clone stecken.

Gruss

[CoderGrizzly]

Alllerdings ist das jetzt nur ein Proof-of-Concept und ich muss das ganze noch in unseren Build Prozess einbauen.

Hallo,

warum geht ihr diesen Weg?
Debian Systeme kann man doch einfach Mittels einer Steuerdatei (preseed) sauber installieren. Ubuntu hat da doch auch Möglichkeiten
http://www.gtkdb.de/index_34_1256.html
Dann hat man auch keiner Äger mit irgendwelchen IDs die ggf. im Clone stecken.

Gruss

Ich habe hier eine Hardware Appliance, welche vorinstalliert ausgeliefert wird. Aber bis zu dem Punkt ist es auch noch kein Problem.

Die Updates werden über ein fertig eingerichtetes Image verteilt. Die Hardware Appliance unterstützt dazu ein Dual Boot. Sprich es gibt zwei Systeme auf der Kiste und das eine System aktualisiert das andere, inaktive System indem es dieses Image einspielt. Und das ist der Knackpunkt.

[rprengel]

Die Updates werden über ein fertig eingerichtetes Image verteilt. Die Hardware Appliance unterstützt dazu ein Dual Boot. Sprich es gibt zwei Systeme auf der Kiste und das eine System aktualisiert das andere, inaktive System indem es dieses Image einspielt. Und das ist der Knackpunkt.

Ok,

verstanden.
Könnte man das nicht auch mit einem chroot Mechanismus lösen und das zweite System so mounten und updaten?

Gruss

[CoderGrizzly]

Die Updates werden über ein fertig eingerichtetes Image verteilt. Die Hardware Appliance unterstützt dazu ein Dual Boot. Sprich es gibt zwei Systeme auf der Kiste und das eine System aktualisiert das andere, inaktive System indem es dieses Image einspielt. Und das ist der Knackpunkt.

Ok,

verstanden.
Könnte man das nicht auch mit einem chroot Mechanismus lösen und das zweite System so mounten und updaten?

Gruss

Prinzipiell wahrscheinlich schon. Man hat sich aber für diesen Weg entschieden. Zumindest muss man sich so nicht mit den Paketabhängigkeiten herumschlagen, kann mit einem Repository arbeiten und liefert auch immer nur das aus, was man für das System braucht (Stichwort Voll-Update / inkrementelles Update, usw.).