• 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] HDD mit GPT auf SSD klonen

A

Anonymous

Gast
Hi,
ich möchte mit Unix-Mitteln eine Festplatte mit GPT auf eine Solid State Disk klonen.
Wenn das Ziellaufwerk kleiner ist als das Qelllaufwerk wüsste ich eine Lösung:
Code:
dd if=/dev/sdX of=/dev/sdY bs=1M
sgdisk --move-second-header /dev/sdY
Die SSD ist aber kleiner als die Festplatte.
Ich kann natürlich die Größe aller Partitionen der HDD auf den Wert (SSD_Größe-2)MiB verkleinern und mit DiskDump kopieren:
Code:
dd if=/dev/sdX of=/dev/sdY bs=1M count=(SSD_Größe-1)M
Nur wie bekomme ich noch die sekundäre GUID-Partitionstabelle ganz am Ende der HDD auf die SSD?
 

josef-wien

Ultimate Guru
Wenn die Quelle kleiner als das Ziel ist, wird das Ziel genau so klein wie die Quelle, und der Rest kann mit regulären Mitteln nicht verwendet werden (mit irregulären befasse ich mich nicht). Wenn die Quelle größer als das Ziel ist und daher nur der vordere Teil kopiert wird, stehen in der Partitionentabelle und im Dateisystem trotzdem die ursprünglichen Größen, und Du schreibst günstigstenfalls in den Wald. Wenn Du unbedingt mit Behältern (und nicht mit dem Inhalt) arbeiten willst, dann nimm CloneZilla, das kann beim Duplizieren die Größen von Partitionen und Dateisystemen anpassen.
 
OP
A

Anonymous

Gast
josef-wien schrieb:
Wenn die Quelle größer als das Ziel ist und daher nur der vordere Teil kopiert wird, stehen in der Partitionentabelle und im Dateisystem trotzdem die ursprünglichen Größen,
Die Partitionen werden doch vorher verkleinert. Mit eine Festplatte mit msdos-Partitionstabelle habe ich das Klonen auf eine kleinere SSD mit DiskDump schon mal gemacht. Aber vor gpt habe ich noch Respekt.
Kann CloneZilla eine gegebene Disk auf eine kleinere Disk klonen? Die Partitionen müsste ich im Qelllaufwerk trotzdem vorher anpassen.
CloneZilla schrieb:
Limitations:
    The destination partition must be equal or larger than the source one.
Ich möchte mir eigentlich den Umweg über eine Image-Datei sparen, deswegen mein Gedanke mit DiskDump.
Aber wenn das bei gpt partitionierten Disks hinterher "im Wald landet", dann besser nicht.

Es gibt mit sgdisk noch die Möglichkeit die gesamte GUID-Partitionstabelle zu kopieren. Nur bei der Syntax bin ich mir nicht sicher ob die so stimmt.
Code:
sgdisk --replicate=/dev/sdY /dev/sdX
mit Quelle=/dev/sdX, Ziel=/dev/sdY
Danach dd wie oben. Theoretisch müsste das doch gehen, oder?
 

josef-wien

Ultimate Guru
LUH 3417 schrieb:
Die Partitionen werden doch vorher verkleinert.
Daß Du eine oder mehrere Partitionen auf der Quelle verkleinern willst, habe ich bisher nicht herausgelesen. Wenn Du eine Partition verkleinerst, wird zuerst das Dateisystem verkleinert, und das bedingt ziemlich viele Datenbewegungen. Wenn Quell- und Zielpartition dann genau gleich groß sind, kannst Du die jeweilige Partition (Anmerkung für künftige Leser: das gilt nicht für eine logische Partition einer msdos-Partitionentabelle) mit dd kopieren, wobei ich nicht sagen kann, ob unterschiedliche physikalische Sektorgrößen ein Problem darstellen können. Vergiß den Gedanken, die gesamte Platte mit dd zu kopieren, den Erfolg von
LUH 3417 schrieb:
Mit eine Festplatte mit msdos-Partitionstabelle habe ich das Klonen auf eine kleinere SSD mit DiskDump schon mal gemacht.
muß ich bezweifeln.

LUH 3417 schrieb:
Dazu kann ich nichts sagen. Aber Du träumst immer noch. Platte A hat eine Größe von X, Platte B hat eine Größe von X minus Y. Wenn Du die Partitionentabelle von Platte A auf Platte B kopierst, hat Platte B formal auch eine Größe von X, und das entspricht selbst dann nicht der Realität, wenn Du vorher dafür gesorgt hast, daß auf der Platte A der Bereich von Ende minus Y bis Ende nicht partitioniert ist.

Der mit Abstand schnellste Weg ist immer noch, die neue Platte nach Wunsch zu partitionieren und zu formatieren und dann die Daten jeder Partition mit
Code:
rsync -AHPSXavx /einhängepunkt_quelle /einhängepunkt_ziel
zu kopieren. Falls die Platte bootfähig sein soll, wirst Du das Neueinrichten von GRUB2 wohl zusammenbringen.
 
OP
A

Anonymous

Gast
josef-wien schrieb:
den Erfolg von
LUH 3417 schrieb:
Mit eine Festplatte mit msdos-Partitionstabelle habe ich das Klonen auf eine kleinere SSD mit DiskDump schon mal gemacht.
muß ich bezweifeln.
Den Beweis kann ich dir schlecht auf den Tisch legen. Aber was ich weiß, hat eine msdos-Partitionstabelle gar keinen Eintrag für die Maximalgröße der Festplatte (HDD/SSD). dd war nach 45 Min. fertig und Microsoft hat den Klon nach kurzer Datenträgerüberprüfung kommentarlos angenommen, Grub2 und openSUSE auch.
Das war sogar schon letztes Jahr: http://linux-club.de/forum/viewtopic.php?f=92&t=120691
Bei der GUID-Partitionstabelle könnte auch die Maximalgröße der Festplatte festgeschrieben sein. Dann kann ich dd tatsächlich vergessen.

josef-wien schrieb:
Der mit Abstand schnellste Weg ist immer noch, die neue Platte nach Wunsch zu partitionieren und zu formatieren und dann die Daten jeder Partition mit
Code:
rsync -AHPSXavx /einhängepunkt_quelle /einhängepunkt_ziel
zu kopieren. Falls die Platte bootfähig sein soll, wirst Du das Neueinrichten von GRUB2 wohl zusammenbringen.
2. Als root aus dem laufenden System heraus:
Code:
grub2-install /dev/sda
Gestartet bekomme ich Linux mit SuperGrubDisk2 von CD oder Memorystick.
1. Auf diesem PC läuft Microsoft-only. Diese Freundin weiß auch, dass ich ein Linux-Fan geworden bin. Aber solange sie mich nicht danach fragt, werde ich nicht "Zeugin Jehovas" spielen. Du verstehst…
 

josef-wien

Ultimate Guru
LUH 3417 schrieb:
Aber was ich weiß, hat eine msdos-Partitionstabelle gar keinen Eintrag für die Maximalgröße der Festplatte (HDD/SSD).
Ich ziehe meine Zweifel zurück, wenn der "überschüssige" Platz am Quellmedium unpartitioniert blieb (was offenbar der Fall war).

LUH 3417 schrieb:
Bei der GUID-Partitionstabelle könnte auch die Maximalgröße der Festplatte festgeschrieben sein.
Du darfst definitiv "könnte ... sein" durch "ist" ersetzen. Beide GPT enthalten unter anderem sowohl die Adresse des ersten (üblicherweise 34, also nach der ersten GPT) als auch des letzten für eine Partition benutzbaren Sektors (üblicherweise Datenträgergröße minus 34, also vor der zweiten GPT).

LUH 3417 schrieb:
War bei der SSD keine "Klon"-Software für Windows dabei?
 
OP
A

Anonymous

Gast
Der CHS-Wert in der msdos-Partitionstabelle wird nur noch für den Startsektor und nur für die erste Partition benutzt. Alle anderen CHS-Werte sind durch 0xFEFFFF bedeutungslos geworden. Bei LBA spielt die reale Plattengeometrie keine Rolle.
josef-wien schrieb:
Beide GPT enthalten unter anderem sowohl die Adresse des ersten (üblicherweise 34, also nach der ersten GPT) als auch des letzten für eine Partition benutzbaren Sektors (üblicherweise Datenträgergröße minus 34, also vor der zweiten GPT).
Genau das ist das Problem. Von einer kleineren Disk auf eine Größere kann ich dd benutzen und anschließend sgdisk --move-second-header /dev/sdY. Siehst du das auch so?
Aber von einer größeren Disk auf eine Kleinere funktioniert sgdisk --replicate=/dev/sdY /dev/sdX somit nicht.
Ich könnte es höchstens nach dd noch mit "Gewalt" versuchen:
man sgdisk schrieb:
-v, --verify
Verify disk. This option checks for a variety of problems, such as incorrect CRCs and mismatched main and backup data. This option does not automatically correct most problems, though; for that, you must use options on the recovery & transformation menu. If no problems are found, this command displays a summary of unallocated disk space. This option will work even if the disk's original partition table is bad; however, most other options on the same command line will be ignored.
josef-wien schrieb:
War bei der SSD keine "Klon"-Software für Windows dabei?
Natürlich. Das da: dl2.acronis.com/u/pdf/ATI2015HD_userguide_en-US.pdf
Das Rettungssystem von ATI2015HD nutzt Linux Kernel 3.15 als Unterbau. Das Klonen von einer größeren Disk auf eine Kleinere geht nur über den Umweg "Image" und gibt es zwei große Fallstricke in der "Prozedur". Das ist so oder so nichts für eine Hausfrau.

Ich möchte mich aber von kommerziellen Produkten nicht abhängig machen und deswegen mit Unix-Mitteln bzw. GPL-Software klonen.

Kann CloneZilla eine GPT-Disk auf eine kleinere Disk klonen? Die Partitionen müsste ich im Qelllaufwerk trotzdem vorher anpassen, was aber einfach wäre.
CloneZilla schrieb:
Limitations:
The destination partition must be equal or larger than the source one.
Ich sollte das schon sehr genau vorher wissen, denn ich will mich bei meiner Freundin nicht mit Linux und einer Doktorarbeit blamieren.
 

josef-wien

Ultimate Guru
LUH 3417 schrieb:
Siehst du das auch so?
Es könnte möglich sein, wenn die Funktion gescheit genug ist und erkennt, daß der eingetragene letzte für eine Partition benutzbare Sektor falsch ist und daher in beiden GPT korrigiert werden muß. Aber ich habe keine Erfahrung mit solchen "Defekten".

LUH 3417 schrieb:
Ich könnte es höchstens nach dd noch mit "Gewalt" versuchen
Auch hier hängt der Erfolg von der Intelligenz der Reparatur-Funktion ab.

LUH 3417 schrieb:
CloneZilla Limitations: The destination partition must be equal or larger than the source one.
Ich habe das Ding noch nie verwendet, aber es klingt logisch. Theoretisch muß das "Duplizieren" auf eine kleinere Platte zwar möglich sein, aber der dafür notwendige Aufwand wäre sicher gigantisch (und für jedes Dateisystem anders).

LUH 3417 schrieb:
Die Partitionen müsste ich im Qelllaufwerk trotzdem vorher anpassen, was aber einfach wäre.
Trotzdem wäre auch hier der eingetragene letzte für eine Partition benutzbare Sektor falsch.

Ich würde auf beiden Platten für genau gleich große Partitionen sorgen und dann jede Partition einzeln mit dd kopieren, wobei ich (wie schon einmal erwähnt) nicht sagen kann, ob unterschiedliche physikalische Sektorgrößen ein Problem darstellen können. Sind sie unterschiedlich?
 
OP
A

Anonymous

Gast
Die Idee ist gut.
Mit sgdisk alle Partitionen von Hand auf der SSD erstellen und dann mit dd und den Optionen bs=1M skip=1 seek=1 count=XXX alle Partitionen in einem Rutsch von der HDD umkopieren. Warum denn auch einzeln?
Was ich so noch nicht erfasse ist der Freiraum zwischen primärer GPT und erster Partition.   Abwarten und Kaffee trinken.
Die Partitionsgrenzen sind normalerweise an ganze MiB ausgerichtet. Aber das kann ich vorher noch korrigieren, falls das nicht so sein sollte. So ist die physikalische Sektorengröße egal. Die ist viel kleiner und ihr Vielfaches auf 1MiB immer ganzzahlig. Habe ich so in der LinuxWelt gelesen.
 

josef-wien

Ultimate Guru
LUH 3417 schrieb:
Warum denn auch einzeln?
Ich sehe weniger Chancen, etwas falsch zu machen.

LUH 3417 schrieb:
Was ich so noch nicht erfasse ist der Freiraum zwischen primärer GPT und erster Partition.
Ist die Antwort nicht der übernächste Satz:
LUH 3417 schrieb:
Die Partitionsgrenzen sind normalerweise an ganze MiB ausgerichtet.
Oder meinst Du etwas anderes?

P. S. Im übrigen traue ich Windows durchaus zu, die GUID der Partitionentabelle und/oder der Partitionen in der registry zu speichern.
 
OP
A

Anonymous

Gast
josef-wien schrieb:
LUH 3417 schrieb:
Warum denn auch einzeln?
Ich sehe weniger Chancen, etwas falsch zu machen.
Verständnisfrage zu dd: Wird per bs=1M bei skip/seek auch die Blockgröße auf 1MiB umgestellt? Also zum Überspringen der primären GPT: bs=1M skip=1 seek=1
Oder muss ich das doch getrennt angeben: bs=1M skip=1M seek=1M. Ich denke das Erste ist schon richtig.

LUH 3417 schrieb:
Was ich so noch nicht erfasse ist der Freiraum zwischen primärer GPT und erster Partition.
Unter Linux wird nach dem MBR der Dateisystemtreiber abgespeichert (GRUB stage1_5). Wer weiß was Microsoft bei GPT-Disks dort anstellt.

josef-wien schrieb:
P. S. Im übrigen traue ich Windows durchaus zu, die GUID der Partitionentabelle und/oder der Partitionen in der registry zu speichern.
Edit: Die GUID der einzelnen Partitionen kann ich mit sgdisk -u, --partition-guid=partnum:guid anlegen,
        und mit sgdisk -U, --disk-guid=guid die GUID des Laufwerks anpassen, so dass ich einen echten Klon habe.

P.S. Ich muss mich schon etwas wundern. Bin ich hier denn die Erste die beim Klonen einer HDD auf eine kleinere SSD auf die "Klon-Software für Windows" verzichten will? Übrigens habe ich die Ferien genutzt um mein Windows 10 von der SSD zu löschen. Win7 in einer VM unter QEMU reicht mir. Wenn ich openSUSE 13.2 wegen End of Support ersetzen muss, wird die SSD komplett neu partitioniert.
Ich hoffe, dass ich mit dem Kommentar hier Keiner/Keinem auf den Schlips trete.
(Motto: "Die kriegt keine Hilfe mehr von mir." Da habe ich echt schon Typen erlebt! Und die ganz bescheuerten kommen am Ende mit dummen Anmachsprüchen.)
 

josef-wien

Ultimate Guru
Bei count, skip und seek gibst Du jeweils die Anzahl der Blöcke an. Wie groß ein Block ist, legst Du mit ibs und obs (bs weist beiden denselben Wert zu) fest (siehe auch http://linux-club.de/wiki/opensuse/Dd).

Bei einer GPT kommt unmittelbar nach dem MBR (Sektor 0) die erste Partitionentabelle (Sektoren 1 bis mindestens 33), und das gilt auch für Windows. GRUB Legacy und GRUB2 können nur bei einer msdos-Partitionentabelle ein Duplikat ihrer eigenen Daten ab dem Sektor 1 speichern, bei einer GPT verweist der Boot-Code im MBR daher auf jenen Sektor, ab dem die Originale dieser Daten gespeichert sind (es ist der spezifikationwidrige Windows-Eigensinn, eine EFI-Systempartition nur mit einer GPT und einen Boot-Code im MBR nur mit einer msdos-Partitionentabelle zu akzeptieren).
 
OP
A

Anonymous

Gast
Danke. So genau geht der Kofler 2016 gar nicht darauf ein. Dann spricht er plötzlich im Buch von Datenträgern mit MBR-Partitionierung. Und ständig verwendet er MByte/GByte statt Megabyte/Gigabyte bzw. Mebibyte/Gibibyte. Auf fdisk will er nicht mehr eingehen. Beim Beispiel mit gparted passiert ihm ein Fehler beim Anlegen der 1. Partition, den er mit einer unpartitionierten Lücke von 1023KiB zur 2. Partition ausbessert. gdisk und sgdisk fehlen im Buch komplett.   Seltsam.
Code:
(parted) mklabel msdos                                                    
Warning: The existing disk label on /dev/sdg will be destroyed and all data on this disk will be lost.
Do you want to continue?
Yes/No? y                                                                 
(parted) print                                                            
Model: Intenso Rainbow Line (scsi)
Disk /dev/sdg: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start  End  Size  Type  File system  Flags

(parted) mkpart primary 1MiB 10GiB                                        
(parted) mkpart primary 10GiB 14GiB
(parted) print                                                            
Model: Intenso Rainbow Line (scsi)
Disk /dev/sdg: 16.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  10.7GB  10.7GB  primary               lba, type=83
 2      10.7GB  15.0GB  4295MB  primary               lba, type=83

(parted) unit MiB                                                         
(parted) print                                                            
Model: Intenso Rainbow Line (scsi)
Disk /dev/sdg: 15300MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start     End       Size      Type     File system  Flags
 1      1.00MiB   10240MiB  10239MiB  primary               lba, type=83
 2      10240MiB  14336MiB  4096MiB   primary               lba, type=83

(parted) unit s                                                           
(parted) print                                                            
Model: Intenso Rainbow Line (scsi)
Disk /dev/sdg: 31334400s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start      End        Size       Type     File system  Flags
 1      2048s      20971519s  20969472s  primary               lba, type=83
 2      20971520s  29360127s  8388608s   primary               lba, type=83

(parted)
Bei mir gibt es diesen "Fehler" überhaupt nicht. Wahrscheinlich war die parted-Version bei Michael Kofler fehlerhaft.
 

josef-wien

Ultimate Guru
LUH 3417 schrieb:
Auf fdisk will er nicht mehr eingehen. ... gdisk und sgdisk fehlen im Buch komplett.
Er weiß eben doch nicht immer, was gut ist. (s)gdisk wurde am Anfang von Distributionen und Live-Systemen ziemlich ignoriert, sodaß standardmäßig nur parted zur Verwaltung einer GPT zur Verfügung stand. Für mich ist fdisk auch bei einer GPT erste Wahl (selbst die erste "experimentelle" Version mit eingeschränktem Funktionsumfang hat schon alles richtig gemacht), (s)gdisk verwende ich vielleicht bei speziellen Änderungen (partitioniert habe ich damit noch nie), auch ist z. B.
Code:
fdisk -l -o +UUID /dev/sda
mit sgdisk nur einzeln pro Partition abfragbar, parted (das vermutlich immer noch von YaST verwendet wird) dient mir bestenfalls zum Informationsvergleich. Aber wir sind hier bei Linux, und da darf das aus persönlicher Sicht geeignetste Werkzeug verwendet werden.
 
OP
A

Anonymous

Gast
fdisk kann mit GPT umgehen. Das wusste ich gar nicht. Ich verwende ganz gerne sfdisk. Damit kann ich die Partitiongrenzen auch z.B. an 64kiB ausrichten. Reine Spielerei, aber ich habe sonst kein einziges Spiel installiert.
man fdisk schrieb:
fdisk is a dialog-driven program for creation and manipulation of partition tables. It understands GPT, MBR, Sun, SGI and BSD partition tables.
man sfdisk schrieb:
sfdisk doesn't understand the GUID Partition Table (GPT) format and it is not designed for large partitions.
Michael Kofler schreibt:
Kofler 2016 schrieb:
fdisk — Ein Relikt aus der Vergangenheit
Als Alternative zu parted ist bis heute auch fdisk beliebt. Da sich fdisk aber nur für Datenträger mit MBR-Partitionen eignet, gehe ich in diesem Buch auf fdisk nicht mehr ein.
Er hätte besser geschrieben: Die msdos-Partitionstabelle — Ein Relikt aus der Vergangenheit.
 

josef-wien

Ultimate Guru
[i schrieb:
man sfdisk[/i] aus util-linux 2.27.1"]Since version 2.26 sfdisk supports MBR (DOS), GPT, SUN and SGI disk labels, but no longer provides any functionality for CHS (Cylinder-Head-Sector) addressing.
P. S. Lebt Kofler mittlerweile auf dem Mond? fdisk aus util-linux 2.23 vom April 2013 unterstützt GPT "experimentell" (aber funktionierend) und aus util-linux 2.24 vom Oktober 2013 offiziell.
 
OP
A

Anonymous

Gast
Hi josef-wien,
ich kann doch alles mit sgdisk erledigen. Oben in Antwort 10 habe ich noch was zu den GUIDs ergänzt.
Ich wüsste nicht, was jetzt noch schiefgehen könnte. ;)
Oder fällt dir noch etwas ein?
Der Aufwand per Kommandozeile ist recht überschaubar und, ich finde, weniger kompliziert als dieses kommerzielle ATI2015HD-Dings. Einfach gewusst wie und der Lerneffekt steht sowieso im Vordergrund. Übernächstes WE weiß ich es und freue mich schon darauf!

P.S. Der "Kofler" ist also doch keine "Linuxbibel". Ich trotzdem froh darüber. Den 2016er habe ich für 15 Min. Arbeit und etwas Glück gewonnen.
 

josef-wien

Ultimate Guru
Falls es Dich einmal bei einem Linux-System gelüstet, solche Dinge zu tun und danach beide Platten im selben System zu verwenden, solltest Du sicherstellen, daß nirgends mit den Begriffen
Code:
LABEL=aaa
UUID=bbb
PARTLABEL=ccc
PARTUUID=ddd
/dev/disk/by-label/aaa
/dev/disk/by-uuid/bbb
/dev/disk/by-partlabel/ccc
/dev/disk/by-partuuid/ddd
(LABEL und UUID sind Attribute des Dateisystems, PARTLABEL und PARTUUID sind Attribute der Partition einer GPT, die Attribute sind voneinander völlig unabhängig) gearbeitet wird, denn die sind dann nicht mehr eindeutig. Zu Windows kann ich diesbezüglich nichts sagen.
 
OP
A

Anonymous

Gast
Die GUID der Disk (sgdisk -U), der Partitionen (sgdisk -u), Partitions Name (sgdisk -c) und Partitions Typ-Code (sgdisk -t) sind somit "erledigt".
Die Microsoft-Partitions-Attribute fehlen noch:
Code:
sgdisk -A list

0: system partition
1: hide from EFI
2: legacy BIOS bootable
60: read-only
62: hidden
63: do not automount
Siehst du in der GPT sonst noch etwas, was für Windows nach dem Klonen mit dd wichtig sein könnte?
 

josef-wien

Ultimate Guru
Mein letztes Windows war NT 4.0, seitdem schnappe ich nur ab und zu im Forum etwas auf, und zu Deiner Arbeit ist mir da nichts in Erinnerung.
 
Oben