Linux Unter Linux: Festplatte auf kleinere SSD klonen / kopieren

[L512USER]

In den nächsten Tagen wollte ich die Festplatte in meinem T61 gegen eine SSD austauschen. Jedoch ist die SSD kleiner als die Festplatte (256 GB SSD und 320 GB SSD Festplatte).

Wie bekomme ich diese unter Linux bzw. mit Clonezilla am Besten geklont / kopiert? Beziehungsweise was wäre da zu beachten?
Das Klonen der ursprünglichen 160 GB Festplatte auf die größere Festplatte hat problemlos geklappt. Allerdings bin ich Ostern an einem klonen / kopieren einer größeren Festplatte auf eine kleinere SSD mittels Clonezilla „gescheitert“ (Notebook konnte mit der SSD nicht starten). Entsprechend müsste ich irgendwas falsch gemacht haben.

Zur Not hätte ich auch noch Adapter und Geräte mit Windows da, wo ich die Festplatte aus dem T61 und die SSD anschließen könnte und mit einer kostenlosen Software unter Windows die Laufwerke klonen könnte (so die Überlegung). Allerdings würde ich das Kopieren / Klonen über Linux bzw. mit Clonezilla vornehmen, um einen entsprechend Lerneffekt zu haben.

 

[zwieblum]

was sagt /etc/fstab?

 

[L512USER]

Jupp, musste für die verschobene SWAP-Partition eine neue UUID in /etc/fstab einfügen (oder ich habe da vorher irgendwas falsch gemacht). Jetzt scheint es wieder zu gehen, worüber ich sehr froh bin, da ich zum ersten mal über "blkid" diese ausgelesen und dann mittels "mc & nano" editiert habe. Aber die YouTube-Universität und das Wiki im Debian zum Thema SWAP hat mir da weitergeholfen.

@zwieblum: dir vielen Dank für die schnelle Rückmeldung diesbezüglich.

Beitrag automatisch zusammengeführt: 31 Mai 2023

Hat wohl geklappt: in htop sowie über swapon wird mir die /dev/sda3 als SWAP (-Partition) angezeigt.

 

[zwieblum]

 

[L512USER]

Über smartctl -a /dev/sdb werden mir über die Ziel-SSD folgende Information angezeigt:

=== START OF INFORMATION SECTION ===
Model Family: Crucial/Micron RealSSD m4/C400/P400
Device Model: MTFDDAK256MAM-1K1
Serial Number: XXX
LU WWN Device Id: 5 00a075 1095535f0
Firmware Version: 070H
User Capacity: 256.060.514.304 bytes [256 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
TRIM Command: Available, deterministic, zeroed
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 6
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Wed May 31 01:43:44 2023 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Sollte bzw. kann man trotz Sector Size von 512 bytes bei der SSD bei dd den bs-Wert auf 1M setzen? Dies wird zumindest in folgender Anleitung gemacht (→ https://www.tutonaut.de/festplatten-unter-linux-klonen-auch-ueber-das-heimnetz/) und auch seitens normsen hier im Thread erwähnt.

Der Befehlt wäre in meinem Fall dann: sudo dd if=/dev/sda of=/dev/sdb status=progress bs=1M

 

[cuco]

Die Blockgröße von dd sollte genau so groß wie oder ein vielfaches der Größe eines Blocks im Flash der SSD sein. 1 MiB wäre ein vielfaches von 512 Bytes, die Bedingung wäre also erfüllt. Und die Blockgröße/Sektorgröße der SSD ist hier eh unter Garantie gelogen. Mit 512 Bytes Blockgröße existiert garantiert keine aktuelle SSD, falls es überhaupt je eine gab. Das wird nur aus Kompatibilitätsgründen gelogen. Der Controller wird intern mindestens mit 4KiB großen Blöcken arbeiten (also 8x die gelogene Sektorengröße) und die wahre Größe einer Flash-Speicherseite dürfte eher im Bereich 16KiB oder mehr liegen.
1M als Angabe bei dd ist daher - außer in besonderen Fällen - eigentlich immer ein guter Wert. Wenn du jetzt nicht jeden Tag 10x die SSD klonst, wäre es ohne die Angabe (=> Standardwert von 512 Bytes wird genutzt) aber auch kein Beinbruch, würde nur etwas langsamer gehen.

 

[zwieblum]

Es gibt keine SSD mit 512 Byte Blockgröße Der Wert steht drinne, weil es "alle" erwarten. "Echt" ist 4k/8k/16k, das musst du aber vom Hersteller erfragen oder ein geeignetes Testprogramm nehmen.

 

[L512USER]

Der Kopiervorgang läuft, mal schauen wie es in ein paar Stunden aussieht (SSD hängt über einen Adapter an einem USB 2.0 Anschluss).

Beitrag automatisch zusammengeführt: 31 Mai 2023

Der Kopiervorgang wurde abgeschlossen. Leider hat aber wohl etwas nicht geklappt. Jedenfalls startet LMDE 5 nicht, sondern bleibt hängen (Bilder folgen). KDE NEON auf der (sda2-Partition) kann ich problemlos booten. Über den KDE Partitionsmanager wird mir die erste Partition (sda1) auf der LMDE 5 als "unbekannt" (oder so ähnlich) angezeigt.

 

[zwieblum]

Wenn du von der 2. Partition bootest, kannst du auf die erste zugreifen?

 

[L512USER]

Nein, via KDE Neon habe ich kein Zugriff auf die erste Partition. GRUB wird jedoch beim Start angezeigt und wenn man LMDE 5 auswählt, dann startet es auch - man sieht das Logo - aber irgendwann geht es nicht mehr weiter.
Wenn man LMDE 5 über GRUB im Recovery Mode starten möchte, dann kommt am Ende folgende Meldung: "ALERT! UUID= (...) does not exist. Dropping to a shell! (s. zweites Foto).

Ich meine, dass mir über das LMDE 5 Live-System (DVD) die erste Partition als ext4 angezeigt wird. Ich schaue morgen noch mal nach mit Parted Magic was mir dort angezeigt wird.

Für mich denkbare Fehlerquellen:
1. Ich habe die Ziel-SSD nicht formatiert / gelöscht. Vor dem Kopiervorgang war noch Btrfs-Partition vorhanden.
2. Die Ziel-SSD hing an einem USB-Adapter und war damit nicht eingebaut.

Nachtrag:
Scheint wohl dieses Problem zu sein: https://forums.linuxmint.com/viewtopic.php?t=243027
Da setzte ich mich aber erst morgen dran.

 

[zwieblum]

Das ist der Grund, warum ich überall die UUID durch /dev/sd... ersetze

 

[martina]

...oder (eindeutige) Labels vergeben.

 

[normsen]

Das ist der Grund, warum ich überall die UUID durch /dev/sd... ersetze

Geht 1a, bis Du von SATA auf NVMe umziehst ...

 

[L512USER]

Eine kurze Rückmeldung meinerseits: KDE NEON (auf sda2) hat die erste Partition (sda1) mit LMDE 5 nicht erkannt und eine UUID wurde mir auch nicht mit blkid angezeigt. Gleiches Ergebnis bei booten über die LMDE 5 DVD als Live System. Dort wurde mir die erste Partition als Btrfs angezeigt.

Ich habe mich entschieden alle Partitionen auf der SSD zu löschen und über Rescuezilla und einen anderen Adapter - den mir ein Foren-Mitglied geschenkt hat - die Festplatte zu kopieren. Diesmal habe ich die Festplatte in den Adapter gesteckt. Der Vorgang ging auch deutlich schneller als über dd und es scheint diesmal alles geklappt zu haben.

Beitrag automatisch zusammengeführt: 1 Juni 2023

An dieser Stelle noch mal vielen Dank für alle Rückmeldungen und Hilfestellungen.

 

[zwieblum]

Geht 1a, bis Du von SATA auf NVMe umziehst ...

Hm, hatte da aber kein Problem, heißt halt dann /dev/nvme...

 

[linrunner]

Eine kurze Rückmeldung meinerseits: KDE NEON (auf sda2) hat die erste Partition (sda1) mit LMDE 5 nicht erkannt und eine UUID wurde mir auch nicht mit blkid angezeigt. Gleiches Ergebnis bei booten über die LMDE 5 DVD als Live System.

Beim Kopieren per dd bleiben die UUIDs erhalten und die Ziel-SSD funktioniert wie gehabt, kein Grund für irgendwelche fstab Anpassungen; nur UEFI Booteinträge müssen ggf. per chroot/grub install von einem Livesystem aus neu gemacht werden. Umkopieren SATA -> NVMe spielt keine Rolle (hab ich schon gemacht).

Dort wurde mir die erste Partition als Btrfs angezeigt.

Wo auch immer die herkam, dd ändert nichts an der Formatierung.

Bei dir muss also etwas anderes schiefgegangen sein, z.B.

1. Problem aufgrund Partitionsverschiebung, sprich die Quell-SSD hätte in Wirklichkeit sda1 schon gar nicht mehr gebootet
2. Beim dd nicht oflag=direct angegeben (um den Cache zu umgehen) bzw. nach der Ausführung nicht gewartet bis der Kernel im Hintergrund den Cache auf das Medium geschrieben hat
3. Hardwareproblem mit dem USB Adapter/Kabel
4. Ziel-SSD nicht im ThinkPad eingebaut (falls die Überlieferung hier im Forum in deinem Fall zutrifft)

Rescuezilla

Ist mit wenig Erfahrung wohl besser geeignet und fängt im Gegensatz zu dd viele Fehlbedienungsmöglichkeiten ab.

 

[L512USER]

Beim Kopieren per dd bleiben die UUIDs erhalten und die Ziel-SSD funktioniert wie gehabt, kein Grund für irgendwelche fstab Anpassungen; nur UEFI Booteinträge müssen ggf. per chroot/grub install von einem Livesystem aus neu gemacht werden.

Das hat mich halt auch irritiert. Ich bin davon ausgegangen bzw. gehe eigentlich immer noch davon aus, dass dd einfach stur 1:1 kopiert.

Wo auch immer die herkam, (...)

Die war noch auf der (gebrauchten) SSD vorhanden. Ich bin davon ausgegangen, dass wenn ich über dd den Inhalt der Festplatte vollständig auf die SSD kopiere, diese vollständig gelöscht wird. Somit auch die vorhandene Btrfs-Partition. Das war / ist vielleicht ein Irrtum meinerseits gewesen.

4. Ziel-SSD nicht im ThinkPad eingebaut (falls die Überlieferung hier im Forum in deinem Fall zutrifft)

Die Ziel-SSD war in der Tat nicht im Thinkpad T61 eingebaut, sondern über einen Adapter an einen USB-Port angeschlossen.

Fazit:
Das Kopieren / Klonen hat dank Rescuezilla geklappt, aber leider nicht "manuell" mit dd. Meine Empfehlung wäre - gerade als Linux-Einsteiger / -Neuling - gleich Rescuezilla zu nehmen, nachdem man die Partition verkleinert und verschoben hat. Auf der anderen Seite weiß ich jetzt, wie man eine Partition als SWAP einbindet. Also auch wieder was gelernt.

 

[zwieblum]

... oder sich vergewissern, dass die Partitionen nicht gemountet sind, weder auf den Quell noch auf dem Zielmedium

 

[cuco]

Sollte egal sein. Wenn man mit dd nicht irgendwelche Verrenkungen macht, dann verhält es sich komplett doof und überschreibt das Zielmedium ohne Rückfragen. Eventuell dabei noch vorhandene Daten werden einfach überschrieben. Daran lag es also nicht.

 

[elektrokid]

....moin der Herr, guck mal in die fstab, da steht i.A. eine Zeile, die Dir die swap als mount hinzufügt. Solltest das ganze per systemd passieren, sieht das etwas anders aus. Aber probier mal

[EDIT] Ach herrje, mein Eintrag galt noch der swap-Problematik viel weiter oben ... wenn man morgens mal so gar nichts hinkriegt vor dem ersten Kaffee...

 

[zwieblum]

Sollte egal sein. Wenn man mit dd nicht irgendwelche Verrenkungen macht, dann verhält es sich komplett doof und überschreibt das Zielmedium ohne Rückfragen. Eventuell dabei noch vorhandene Daten werden einfach überschrieben. Daran lag es also nicht.

Bedingt. Wenn die Quellpartition gemountet ist, kannst du Glück haben und es passieren keine Schreibvorgänge wärend dd liest - oder nur Schreibvorgänge in dem bereits kopierten Teil --> alles ist ok. Wenn die Zielpartition gemountet ist und dd bügelt drüber, dann sind teile des Dateisystems noch immer im Cache ud werden später geschrieben --> du hast gute Chancen auf ein defektes Dateisystem. Journaling macht das Problem noch schlimmer, dann hast du ziemlich sicher ein defektes Dateisystem. Nota bene: auch readonly gemountete Dateisysteme mit Journaling werden beschrieben.