• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]Ein bestehendes System umziehen

goeba

Hacker
Hallo,

bevor ich mich an die Arbeit mache, wollte ich mal fragen, ob das eine ganz dumme Idee ist.

Ich habe einen neuen Rechner, auf diesem auch ein neues System installiert. Ich habe aber aktuell nicht die Zeit, alle Programme, Einstellungen usw. neu zu machen.

Daher die Idee, das alte System einfach umzuziehen. Dies wäre auch eigentlich kein Problem (habe ich schon oft gemacht), aber: Ich möchte das neue System auch behalten.

Ich müsste also das alte System von einer Single-Boot Installation in eine Multiboot-Installation übertragen.

Mein grundsätzlicher Plan:
- die alten Partitionen mit dd auf ein externes Laufwerk sichern
- auf dem neuen Gerät Partitionen in passender Größe anlegen
- die Partitionen mit dd dorthin übertragen
- Grub + den Bootvorgang so anpassen, dass es funktioniert

Der letzte Punkt ist natürlich der einzig schwierige. Aber dafür gibt es ja tools, z.B. dieses hier:

https://www.supergrubdisk.org/wizard-restore-grub-with-super-grub2-disk/

Die dort gegebenen Anleitungen sind aber eher dafür gedacht, dass Windows den MBR zerschossen hat oder ähnliches. Ich habe ja kein Windows auf der Platte.

Würde das für dieses Szenario auch funktionieren?

Per Hand müsste man aus der Grub Kommandozeile heraus das System booten und Grub neu aufsetzen. Sowas habe ich auch schon gemacht, aber ich habe keine gute Erinnerung daran.

Also: Ich hätte gerne Eure Einschätzung zur Schwierigkeit, ein System aus einer Single-Boot Umgebung in eine Multi-Boot Umgebung umzupflanzen. Dass es irgendwie möglich ist, bezweifle ich ehrlich gesagt nicht, aber es sollte ja weniger Arbeit sein als alles neu zu installieren + konfigurieren.

Dank + Gruß,

Andreas
 

marce

Guru
den Weg über dd würde ich mir sparen sondern einfach auf dem neuen System die Part. nach Wunsch anlegen und dann die Daten direkt per rsync übertragen.

... dann musst du nur noch die Boot-Konfig anpassen, aber auf dem bereits dort laufenden System sollte das mit einem OS-Detect von Grub problemlos automatisch passieren.
 

josef-wien

Ultimate Guru
Von dd würde ich hier die Finger lassen. Kopiere die Daten der Systempartition des laufenden Systems mit:
Code:
rsync -AHPSXavx --delete / /einhängepunkt_neue_systempartition/
Wenn das neue System Dein Hauptsystem sein soll, dann starte es mit der Super Grub2 Disk, und installiere danach den Boot-Manager. Wenn ein anderes System Dein Hauptsystem bleiben soll, dann gehe wie von marce beschrieben vor.

Wenn Du den Zwischenschritt über ein externes Medium vorziehst, dann befülle die neue Systempartition über ein anderes System:
Code:
rsync -AHPSXavx --delete /einhängepunkt_partition_externes_medium/ /einhängepunkt_neue_systempartition/


Solltest Du Deine Partition(en) anders als mit LABEL oder UUID (beide sind Attribute des Dateisystems) ansprechen, mußt Du bei der "Kopie" die entsprechenden Dateien natürlich anpassen.
 
OP
G

goeba

Hacker
Hallo,

vielen Dank. Mit rsync bin ich (noch) nicht so vertraut, daher bin ich auf die Idee gar nicht gekommen.

Nun ist es aber so, dass das zu kopierende System auf drei Partitionen verteilt ist ( diese sind auf / , /home und auf /data gemountet).

Wir wirkt sich das auf den rsync-Befehl aus? Da die Partitionen ja gemountet sind, sind sie unterhalb von / eingehängt, werden dann die Sachen alle mitkopiert und landen am Ende dann in einer Partition?

Den Zwischenschritt über ein externes Medium muss ich, denke ich, gehen, weil es sich bei beiden Systemen um Notebooks handelt, wo ich ungern erst die Festplatte ausbauen möchte.

Dank + Gruß,

Andreas
 

josef-wien

Ultimate Guru
Du mußt die Daten jeder Partition separat kopieren. Der Parameter -x sorgt dafür, daß eingehängte andere Dateisysteme nicht berücksichtigt werden.

Auch zwei Notebooks können schon ein Netzwerk bilden.
 

MH1962

Member
Ich würde im Zweifelsfalle tatsächlich dd benutzen, denn nur so entsteht eine sicher funktional identische Kopie. Jedenfalls hätte ich bei rsync Angst, mal wieder nicht die richtigen Switches zu erwischen und dann irgendwelche versteckten Verzeichnisse, Softlinks, Device Nodes etc. zu vermissen. Mit dd kann man sogar auf eine größere Partition umziehen, wenn man hinterher das Filesystem anpasst.

Nachteil: Man muss schon sehr genau wissen, was man da macht...
 
OP
G

goeba

Hacker
Moin,

das hat soweit funktioniert, vielen Dank.

Zwei Probleme sind aufgetreten:

- da ich die Partitionen auf dem neuen Rechner neu angelegt hatte, hatten diese auch andere UUIDs . Ich hatte @Josef-Wien dabei offenbar missverstanden, ich dachte, Du wolltest mir sagen,dass die UUID bei diesem rsync-Befehl irgenwie mit übertragen wird. Ich musste also in der fstab die uuids anpassen
- in der Kernel-Zeile von Grub waren aber trotz Grub-Update noch die alten UUIDs drin.

Ein Problem, das auf meine mangelhaften rsync-Kenntnisse zurückgeht: Für das root Verzeichnis stimmt alles perfekt. Für /home und /daten allerdings sind die Dateien in einem Ordner gelandet, auf dem neuen System ist das jetzt einfach /home/home und /daten/daten .

Wie repariere ich das am einfachsten? einfach mit mv? Getestet habe ich das System aber schon, ich habe für meinen Hauptuser einfach einen symbolischen Link angelegt.

Schon toll, was man mit Linux so machen kann ...

Dank + Gruß,

Andreas
 

josef-wien

Ultimate Guru
Beim Satz mit LABEL und UUID waren meine Gedanken leider wieder bei dd. Realistisch hätte dort stehen müssen, daß beim Formatieren die gewünschten Werte anzugeben oder danach anzupassen sind.

Hinsichtlich /home/home und /daten/daten haben bei Dir wohl die Schrägstriche am Ende der Pfad-Angaben gefehlt. Als root ohne grafischem System:
Code:
mv /home /homealt
mv /homealt/home /home
rm -d /homealt
Für /daten dann analog (und das geht auch bei aktivem grafischen System).
 
OP
G

goeba

Hacker
Hallo,

wenn im Ordner /home eine eigene Partition gemountet ist, dann bewirkt mv /home /homealt aber das Verschieben auf eine andere Partition, es wird also eine physische Kopie + Löschen dieser Daten durchgeführt, richtig?

Ich glaube, da verwende ich lieber mv /home/home/user /home/user und mache das für alle User, oder? Ich glaube mich erinnern zu können, dass ich ja nicht einfach mv /home/home/* /home machen kann.
 

josef-wien

Ultimate Guru
Irgendwie übst Du einen negativen Einfluß auf mich aus, ich stehe dauernd auf der Leitung. Mein erster Befehl scheitert, da man damit den Namen eines Einhängepunkts nicht ändern kann, wenn etwas eingehängt ist.



goeba schrieb:
mv /home/home/* /home
Bei mir funktioniert ein solches Konstrukt einwandfrei, ohne daß etwas kopiert wird:
Code:
ls -i
liefert jeweils dieselben Inode-Werte. /home/home ist danach leer und kann entsorgt werden.
 
OP
G

goeba

Hacker
Lieber Josef,
das tut mir natürlich sehr leid, dass ich einen schlechten Einfluss auf Dich habe ;)

Vielen Dank, dass Du trotzdem weieter antwortest.

Ich habe das jetzt entsprechend gemacht. Das Problem, das ich grob erinnerte (und jetzt verifiziert habe), ist, dass mv /home/home/* ggf. vorhandene versteckte Dateien nicht kopiert. Das ist in der Wurzel des Homeordners natürlich normalerweise nicht der Fall, dass da versteckte Dateien drin sind. In meinem Datenordner aber (in geringem Umfang) schon. Das Problem hätte man eben nicht, wenn man irgendwie den ganzen Ordner /home/home hätte verschieben können, ohne auf Platzhalter zurückgreifen zu müssen.

Das kann ich dann aber händisch noch machen, somit ist die Installation jetzt ziemlich komplett umgezogen.

Viele Grüße + danke nochmal,

Andreas
 

josef-wien

Ultimate Guru
Naja, wer rechnet schon mit solchen Spezialfällen? Durch den Stern fügt die Bash jedes im Verzeichnis /home/home gefundene Objekt in den mv-Befehl ein, aber Objekte mit einem Punkt am Anfang werden standardmäßig nicht berücksichtigt. In Deinem Fall hättest Du zuerst den Befehl
Code:
shopt -s dotglob
ausführen müssen, dann werden auch diese Objekte (aber nicht die Objekte . und ..) einbezogen:
man bash schrieb:
dotglob
If set, bash includes filenames beginning with a `.' in the results of pathname expansion.
 
OP
G

goeba

Hacker
Danke auch für diesen Hinweis. Ich hatte halt in Erinnerung, dass mv problematisch beim Kopieren ganzer Verzeihnisinhalte ist, und damals ging es tatsächlich um ein Homeverzeichnis.

Ich markiere das Thema dann als gelöst!
 
Oben