[gelöst] System auf neue Festplatte umziehen mittels dd

[chr.gogolin]

Ich möchte die in die Jahre gekommene SSD meines Notebooks austauschen und dazu mein komplettes System (dualboot mit Debian in einem LVM) auf die neue Platte umziehen.

Ich habe also (wie ich das sowieso immer mal wieder zum Sichern mache) von einer Live CD (sysrescCD) ein image der gesamten Platte (120GB) mit dd gemacht und die Korrektheit des Abbildes mit md5sum kontrolliert.

Dann die neue Platte eingebaut (500GB) und das Image wieder mit der live CD drauf geschrieben. Mir ist klar dass mir so noch nicht der volle Platz zur Verfügung steht aber darum wollte ich mich dann im nächsten Schritt kümmern. Zunächst habe ich jetzt aber folgendes Problem:

Beim ersten booten von der neuen Platte startet zwar Grub und auch Windows lässt sich booten, aber Debian bleibt mit einer Kernel Panik (korrupted filesystem, not syncing) hängen.

Habe dann noch mal die alte Platte eingebaut nochmal mittels fsck die Partitionen kontrolliert (keine Fehler), eine neues Image auf eine andere externe Platte gemacht, wieder per md5sum gecheckt und auf die neue Platte übertragen.

Noch aus dem Live System (also ohne boot von der neuen Platte) versucht mit md5sum die neue Platte zu checken. Leider ist das nicht so ganz trivial weil die neue Platte ja größer ist...

Mein versuch war also die Größe des images in Bytes per ls -l ermitteln dann durch 1024 teilen (ergibt 125034840) und dann dd if=/dev/sda bs=1024 count=125034840 | md5sum.

Ist das so richtig? Gibt auf jeden Fall den selben Wert wie die md5sum des Abbildes wenn ich diese mittels dd if=/.../img.dd bs=1024 count=125034840 | md5sum ermittle.

Man müsste nun also meine das beide Platten funktionieren und in den ersten ~120GB den selben Inhalt haben.

Schlussendlich habe ich (immer noch unter der Live CD) das LVM auf der neuen Platte angeworfen und die darin enthaltenen Partition mit fsck gecheckt. Ergebnis: jede Menge Fehler (inodes...)

Bin verwirrt. Wie kann es sein dass die alte und neue Platte exakt gleich sind, die eine jedoch zu Fehlern führt und sich das Debian darauf nicht booten lässt, aber gleichzeitig das Windows schon?

Muss ich bei einem LVM etwas besonderes beachten wenn ich ein image der ganzen Platte mit dd ziehe?

Habe ich irgendetwas offensichtliches übersehen?

Vielen Dank für die Hilfe!

[schwedenmann]

Hallo

Bin verwirrt. Wie kann es sein dass die alte und neue Platte exakt gleich sind, die eine jedoch zu Fehlern führt und sich das Debian darauf nicht booten lässt, aber gleichzeitig das Windows schon?

Laß mich raten, die Quellplatte, also die SSD war gemountet, als du dd ausgeführt hast ?

mfg
schwedenmann

[chr.gogolin]

Nein, war sie nicht. Habe ich sogar durch ausführen von mount unter dem Live System überprüft. In der Liste tauchen keine Platten mit /dev/... auf, außer natürlich die externe Platte auf die das Image geschrieben werden soll.

[charno]

Hallo,

Hast du auch versucht das Image zu mounten / LVM zu aktivieren?

Ich kenne mich nicht wirklich gut mit Festplatten / SSDs aus, aber könnte das Wear Level Management (Oder so ähnlich) der alten SSD zu Fehlern führen?

Ein anderer Schuss ins Blaue: Sind die Blockgrössen von LVM oder dem Dateisystem (was für eins eigentlich?) von der Festplatte abhängig? Oder stimmt irgend was mit dem Alignment nicht?

[habakug]

Hallo!

Beim ersten booten von der neuen Platte startet zwar Grub und auch Windows lässt sich booten, aber Debian bleibt mit einer Kernel Panik (korrupted filesystem, not syncing) hängen.

Die genaue Meldung wäre schon interessant, so gibt es das nicht. Vielleicht ist in der "grub.cfg" noch die alte ID der Platte eingetragen und verhindert das Finden der richtigen Partition. Mal die Ausgabe von blkid mit dem Inhalt der "grub.cfg" vergleichen.

Gruss, habakug

[Cae]

Wenn da stur ddt wurde, kann's eigentlich nicht an IDs vom MBR oder den Dateisystemen liegen (oder es war schon vorher kaputt).

Ist denn gesichert, dass die neue Platte okay ist? smartctl -t short sollte drin sein.

Gruss Cae

[habakug]

Hallo!

Ich meinte das:

Code: Alles auswählen

# uname -a
Linux Testrechner2 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux
# blkid
/dev/sda1: UUID="4d5da54c-33f5-47d0-b5f4-814279f277aa" TYPE="ext3" 
/dev/sda2: UUID="7ac228ec-d560-4cdb-81ec-62fae499d16c" TYPE="ext4" 
# cat /boot/grub/grub.cfg | grep 7ac22
[...]
linux	/vmlinuz-3.13-1-amd64 root=UUID=7ac228ec-d560-4cdb-81ec-62fae499d16c ro  quiet
[...]

Ebenso wie es hier [1] z.B. geschildert wird.

Gruss, habakug

[1] http://askubuntu.com/questions/171446/h ... er-machine

[r4pt0r]

Einfachere Variante bei vorhandenem LVM ganz ohne downtime:

- Im laufenden System die neue Platte partitionieren (MBR oder GPT) und ein PV für LVM in gewünschter Partition/Größe erstellen (pvcreate)
- PV in die VG des bestehenden Setups aufnehmen (vgextend)
- inhalt des PVs auf der alten platte in das PV der neuen verschieben (pvmove). Am besten zuerst mit pvmove --test laufen lassen - wenn es keine fehler gibt "richtig" verschieben.
- altes PV aus VG entfernen (vgreduce, pvremove)

Die boot-partition kann einfach mittles cp kopiert werden, dazu einfach /boot aushängen und z.b. in /temp einhängen und neue /boot mounten (fstab nicht vergessen!). Danach noch update-initramfs & grub-install & update-grub drüberjagen (dabei grub gleich in den MBR der neuen platte installieren).

Die alte Platte kann dann je nach Controller auch im Betrieb direkt entfernt werden nachdem _alle_ darauf befindlichen Dateisysteme ausgehängt sind (mount und evtl lsof). Vorher zur Sicherheit die platte auch Softwareseitig "ausschalten" z.b. mit "echo 1 > /sys/block/sda/device/delete"

dd würde ich bei vorhandenem LVM nur für die windows-partition(en) verwenden - boot und mbr neu anlegen war bisher immer die variante die sofort funktionierte...

UUIDS in der fstab sollte man sicherheitshalber immer prüfen (/boot wird sich ändern!) bzw grub bekommt ja alle neuen IDs mit auf den weg wenn man per grub-install und update-grub alles neu erzeugt...


Habe mit dieser Variante bereits bei 2 Systemen die kompletten Systemplatten im Betrieb ersetzt/erweitert - ohne downtime und mit einwandfreiem Neustart beim nächsten Kernelupdate...

[Cae]

Am besten zuerst mit pvmove --test laufen lassen - wenn es keine fehler gibt "richtig" verschieben.

Bist du sicher, dass es --test gibt? Die Wheezy-Manpage sagt etwas anderes.

Ansonsten ist das beschriebene Verfahren sehr geeignet, ich habe nach demselben Prinzip schon mehrere Systeme erfolgreich umgezogen.

Gruss Cae

[dufty2]

Bist du sicher, dass es --test gibt? Die Wheezy-Manpage sagt etwas anderes.

man-pages müssen nicht immer up2date sein:

Code: Alles auswählen

# pvmove --help
  pvmove: Move extents from one physical volume to another

pvmove 
        [--abort]
        [-A|--autobackup {y|n}]
        [--alloc AllocationPolicy]
        [-b|--background]
        [-d|--debug]
        [-h|-?|--help]
        [-i|--interval seconds]
        [--noudevsync]
        [-t|--test]
        [-v|--verbose]
        [--version]
        [{-n|--name} LogicalVolume]
        SourcePhysicalVolume[:PhysicalExtent[-PhysicalExtent]...]}
        [DestinationPhysicalVolume[:PhysicalExtent[-PhysicalExtent]...]...]

[r4pt0r]

Code: Alles auswählen

# pvmove --test --verbose /dev/sda2 /dev/md/lvm
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
    Finding volume group "pve"
    Test mode: Skipping archiving of volume group.
    Creating logical volume pvmove0
    Moving 24576 extents of logical volume pve/root
    Moving 444744 extents of logical volume pve/data
    Found volume group "pve"
    activation/volume_list configuration setting not defined: Checking only host tags for pve/root
    Found volume group "pve"
    activation/volume_list configuration setting not defined: Checking only host tags for pve/data
    Updating volume group metadata
    Found volume group "pve"
    Found volume group "pve"
    Found volume group "pve"
    Found volume group "pve"
    Found volume group "pve"
    Found volume group "pve"
    Found volume group "pve"
    Test mode: Skipping backup of volume group.
    Test mode: Wiping internal cache
    Wiping internal VG cache

edit:
ah, da war dufty schneller...

In den Manpages steht aber tatsächlich nichts zum testmodus.

[Cae]

Aha, danke. Also nur ein Doku-Bug, gut zu wissen.

Gruss Cae

[chr.gogolin]

Danke für die zahlreichen Zuschriften!

Das Problem hat sich von selbst gelöst. Leider verstehe ich immer noch nicht was eigentlich genau schief gelaufen war.

Ich habe einfach alles noch ein drittes mal vom selben Image kopiert, aber diesmal von der live CD aus nichts mit den per LVM erkannten Partitionen auf der neune Platte gemacht sondern erst neu gestartet (wieder in das Live System) und dann erst fsck angeworfen. Dabei gab es dann keine Fehler und beim anschließenden boot von der neuen Platte lief alles Fehlerfrei. Seitdem geht alles.

Ich vermute dass das LVM nicht mit dem dd klar gekommen war oder vielleicht wärend des kopierens schon versucht hat die Partitionen in dem LVM zu finde?!

Der Vollständigkeit halber hier noch die Antworten auf einige der gestellten Fragen:

Hast du auch versucht das Image zu mounten / LVM zu aktivieren?

Ja, das ging.

Ich kenne mich nicht wirklich gut mit Festplatten / SSDs aus, aber könnte das Wear Level Management (Oder so ähnlich) der alten SSD zu Fehlern führen?

Solange es noch funktionier nicht denke ich. Das passiert ja alles intern. Davon bekommt das System, das nur ein block device sieht nichts mit.

Ein anderer Schuss ins Blaue: Sind die Blockgrössen von LVM oder dem Dateisystem (was für eins eigentlich?) von der Festplatte abhängig? Oder stimmt irgend was mit dem Alignment nicht?

Das alignemnt stimmt fast sicher nicht, aber das dürfte nur die Performance beeinträchtigen.

Ist denn gesichert, dass die neue Platte okay ist? smartctl -t short sollte drin sein.

Ich hatte, wie geschrieben, sogar einen long test gemacht und der hat keine Fehler ergeben.

Die genaue Meldung wäre schon interessant, so gibt es das nicht. Vielleicht ist in der "grub.cfg" noch die alte ID der Platte eingetragen und verhindert das Finden der richtigen Partition. Mal die Ausgabe von blkid mit dem Inhalt der "grub.cfg" vergleichen.

Die Kernel Panik konnte ich (glücklicherweise) nicht mehr reproduzieren nach dem dritten mal Image aufspielen. Die grub.cfg enthält für die Debian installation nur Einträge die auf Partitionen im LVM verweisen und die passen nach wie vor. Außerdem startet der Kernel ja, konnte also gefunden werden.

Einfachere Variante bei vorhandenem LVM ganz ohne downtime: [...]

Das ist in der Tat eine coole Methode an die ich noch nicht gedacht hatte. Wieder was gelernt, danke! Da es sich bei dem System aber um ein Notebook handelt hätte ich nicht beide Platten geleichzeitig einbauen können.