System auf anderen Rechner kopieren

  • Ich habe einen PC ("PC1") mit openSUSE Leap 15.3, dessen System ich auf einen anderen PC ("PC2") (mit fast identischer Hardware) kopieren möchte. Auf dem anderen Rechner läuft openSUSE Leap 15.0.

    PC1 hat das System in /dev/sda1, PC2 in /dev/sda2. /dev/sda3 ist auf beiden PCs als /boot/efi gemountet.

    Auf PC2 ist /dev/sda1 als /sys1 gemountet.

    Wenn ich auf PC1 folgendes mache


    rsync -aHSx --numeric-ids --delete --force / PC2:/sys1

    ssh PC2 update-bootloader


    und dann PC2 boote, dann kann ich im Boot-Menü zwar das System in /dev/sda1 auswählen und es startet auch, kommt aber nicht weit. Irgendwann, nach längerem Timeout, kommt dann ein Prompt, das root-Passwort einzugeben und ich lande in einer Not-Shell.

    Kann es sein, dass ich ausser update-bootloader noch etwas machen muss? Ramdisk neu generieren oder so? Die Devices haben natürlich andere UUIDs, kann es vielleicht daran liegen?

    Ich möchte das Ganze per Script machen, um es im Falle eines Falles automatisch ablaufen lassen zu können.

  • Die Devices haben natürlich andere UUIDs, kann es vielleicht daran liegen?

    Die müssen in der fstab entsprechend geändert werden.

  • Dann nutze die UUIDs doch einfach nicht..

  • Boot-Manager benutzen gerne UUIDs


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • A propos Boot-Manager..

    Grub und Grub2 müssen immer neu installiert werden. Aber das ist hier nicht dein Problem, grub funzt ja.



    Bei deiner Konstellation wäre es relativ einfach, den gleichen Kernel auf beiden Systemen nutzen und in /boot/efi abzulegen.

    Danach sollte ein rsync für das System selbst reichen, ohne den bootloader zu touchen, sobald die Partitionen gleiche Namen haben..

  • Ich mounte die Devices immer über Namen (/dev/sda1 etc.), nie über UUIDs. Von daher sollte es also schon passen.

    Aber wer weiß, wo sonst noch UUIDs verwendet werden?

    Die UUIDs müssten noch in der grub.cfg stehen und werden von mkinitrd angepast. Ich würde folgendes probieren (habe letztes Jahr damit die Systempartition von Suse 15.x kopiert):

    • von einem USB-Stick (oder andere Suse-Partition) booten
    • mount destination partition, e.g. to /mnt
    • mount -B /sys /mnt/sys
    • mount -B /dev /mnt/dev
    • mount -B /run /mnt/run
    • mount -B /proc /mnt/proc
    • chroot /mnt
    • mkinitrd (creates also changed grub.cfg with new UUID)
    • exit
  • ziemlich ähnlich zu einem LFS chroot. :)


    Aber ich glaube ein

    Code
    1. mkdir -pv /mnt/{dev,proc,sys,run}

    würde ich noch vorher im script einbauen.

  • Ich habe vor ein paar Monaten auf einem Suse 15.3 System die Root Partition von einer HD auf ein NVME SSD per Rettungsmedium migriert und hatte dann auch den root Prompt nach langem Timeout. Bei mir war der Fehler das ich das nvme Modul nicht in der Initial Ramdisk drin hatte und deshalb die Root Partition nicht gefunden wurde.

    Ich habe meine Fstab auf UUIDs umgestellt, bei mir steht auch die UUID in der grub.cfg. Bei einer Fstab mit /dev/sd* Namen stehen diese vermutlich stattdessen drin, kann ich nicht mehr überprüfen. Ich habe dann von der alten Partition gebooted, in /etc/sysconfig/kernel INITRD_MODULES angepasst, mkinitrd ausgeführt, die Partition noch einmal kopiert und dann lief es.


    Nächster Stolperstein ist dann vermutlich die Datei /etc/udev/rules.d/70-persistent-net.rules wo der Netzwerkadapter per MAC Adresse gemappt wird, zumindest wenn mann die alte Nomenklatur eth* benutzt.

  • Ja, das wäre eine Erklärung, wenn ein Kernelmodul für den Zugriff auf das root Dateisystem nicht im kernel, sondern nur als Modul existiert.


    Die Netzwerkadresse lässt sich lösen, wenn man einfach zwei rules dafür hinterlegt.

  • Die UUIDs müssten noch in der grub.cfg stehen und werden von mkinitrd angepast. Ich würde folgendes probieren...

    Das hab ich jetzt gemacht und damit stehen die richtigen UUIDs in der /mnt/boot/grub2/grub.cfg.

    Allerdings stehen in dieser Datei keine 'menuentry' Zeilen für Leap 15.3, sondern nur die für 15.0.

    Beim Reboot wird mir aber 15.0 und 15.3 angeboten. Wähle ich dann 15.3, verhält es sich immer noch so wie oben beschrieben (Timeout und Not-Shell). Wie bekomme ich denn die menuentrys-Zeilen für 15.3 in die grub.cfg?

    Nächster Stolperstein ist dann vermutlich die Datei /etc/udev/rules.d/70-persistent-net.rules wo der Netzwerkadapter per MAC Adresse gemappt wird

    Da kann ich ja einfach diese Datei kopieren.

  • Zum Abschluss noch die Erklärung, wozu ich das brauche.

    Ich möchte meinen Haupt-Rechner dahingegend absichern, dass ich im Falle eines Hardwaredefekts so schnell wie möglich auf einen Backup-Rechner umsteigen kann. Das beiliegende Skript erledigt diese Aufgabe vollständig und automatisch, so dass im Fall der Fälle nichts übersehen werden kann. Ich lasse das jede Nacht laufen und kann so maximal einen Tag zurückfallen. Konkret muss ich momentan den Hauptrechner einem längeren Speichertest unterziehen, da er sich schon mehrmals urplötzlich aufgehängt hat, was vermutlich an einem defekten RAM liegt. Mit dem Skript kann ich alles schnell auf einen zweiten Rechner "umziehen", den ersten runter- und den zweiten mit dem kopierten System hochfahren und fertig.


    Ich poste es nur der Vollständigkeit halber und für den Fall, dass sich jemand auch für sowas interessiert. Ich habe versucht, es so allgemein wie möglich zu gestalten, die Kommandos unter "Stop processes on HOST1" sind evtl. den lokalen Gegebenheiten entsprechend anzupassen.


    Falls jemand einen Fehler entdeckt oder ich irgend etwas übersehen habe, bin ich natürlich für Rückmeldungen dankbar.

    (Die ".txt" Extension ist nur wegen der Portal-Software)


    Benutzung natürlich auf eigene Gefahr! ;-)


    <edit>

    Achtung: Neue Version im nächsten Post!

    </edit>

  • Das "Hin" hat mit der gestrigen Version des Skripts schon gut geklappt, aber des "Her" (--back) noch nicht. Ich musste noch auf dem lokalen Rechner "mkinitrd" und "update-bootloader" aufrufen, damit das root-Volume erkannt wurde.

    Hier eine neue Version, mit einigen weiteren Verbesserungen/Fixes.

    Das --back dient dazu, die beiden Rechner "auszutauschen", d.h. jeder übernimmt die Rolle des anderen.


    Was bei --back noch nicht funktioniert ist der Netzwerk-Adapter. Für "Hin" reichte ein


    cp /etc/udev/rules.d/70-persistent-net.rules /mnt/etc/udev/rules.d


    für das "Her" leider nicht. Da bin ich noch am Debuggen...

  • Vielleicht wäre ein guter Weg, mal den Kernel anzuschauen und dafür zu sorgen, dass alle Module in den Kernel (nicht als Modul) compiliert sind, welche dafür notwendig sind das root Dateisystem '/' zu mounten.


    Sowas wie das modul für ext3/ext4 oder xfs; und das für die Art der HDD - sata via scsi oder usb.


    Dazu noch, falls usb (aber nur dann), ~10sec Wartezeit in der cmdline.

  • wirbel : Ich habe das Problem dadurch gelöst, dass ich auf dem PC2 auch Leap 15.3 installiert habe. Damit klappt es jetzt in beide Richtungen, und beide Rechner kommen ans Netzwerk.


    Jetzt habe ich nur noch das Problem, den sendmail zu stoppen bevor ich das System von PC1 auf PC2 "umziehe". Es sollen ja während des rsync keine Emails auf PC1 mehr angenommen werden, da diese ja u.U. nicht mehr auf PC2 kopiert würden.

    Wie man sieht wird sendmail immer wieder sofort neu gestartet, obwohl ich dem systemctl explizit sage, dass er stoppen soll.

    Was mache ich falsch?

  • Warning: Stopping sendmail-client.service, but it can still be activated by:
    sendmail-client.path

    Systemd kann u.a. auch Service-Units durch Zugriff auf einen Pfad aktivieren: https://www.freedesktop.org/so…emd/man/systemd.path.html

    Wie man sieht wird sendmail immer wieder sofort neu gestartet, obwohl ich dem systemctl explizit sage, dass er stoppen soll.

    Was mache ich falsch?

    Du musst die Unit sendmail-client.path ebenfalls stoppen (also z.B. systemctl stop sendmail-client.path oder sicherer - damit niemand aus Versehen die Unit bis zum nächsten Reboot bzw. einem gegenteiligen Befehl starten kann: systemctl mask --runtime --now sendmail-client.{path,service}).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • kls : Schau' dir ggf. auch einmal Relax-and-Recover an (oder unter: GitHub - ReaR). Das ist ein Bash Skript basiertes Framework, dass z.B. ein bootbares ISO eines Systems im laufenden Betrieb inkl. Backup anlegen kann und das entstandene Image dann auch migrierbar ist (P2P, P2V, V2V, V2P). Bei Fragen einfach bei mir melden.