Linux Unter Linux: Festplatte auf kleinere SSD klonen / kopieren
- Ersteller L512USER
- Erstellt am
Linux Betriebssystem
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.
Hat wohl geklappt: in htop sowie über swapon wird mir die /dev/sda3 als SWAP (-Partition) angezeigt.
@zwieblum: dir vielen Dank für die schnelle Rückmeldung diesbezüglich.
Beitrag automatisch zusammengeführt:
Hat wohl geklappt: in htop sowie über swapon wird mir die /dev/sda3 als SWAP (-Partition) angezeigt.
Zuletzt bearbeitet:
Ü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
=== 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
Anhänge
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.
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.
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).
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.
Beitrag automatisch zusammengeführt:
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.
Zuletzt bearbeitet:
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.
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.
Anhänge
Zuletzt bearbeitet:
normsen
Active member
- Registriert
- 14 März 2017
- Beiträge
- 519
Geht 1a, bis Du von SATA auf NVMe umziehst ...Das ist der Grund, warum ich überall die UUID durch /dev/sd... ersetze
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.
An dieser Stelle noch mal vielen Dank für alle Rückmeldungen und Hilfestellungen.
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:
An dieser Stelle noch mal vielen Dank für alle Rückmeldungen und Hilfestellungen.
Zuletzt bearbeitet:
zwieblum
Well-known member
- Registriert
- 3 Mai 2009
- Beiträge
- 1.428
Hm, hatte da aber kein Problem, heißt halt dann /dev/nvme...
linrunner
Ubuntuversteher
- Registriert
- 22 Juni 2007
- Beiträge
- 13.079
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).
Wo auch immer die herkam, dd ändert nichts an der Formatierung.
Bei dir muss also etwas anderes schiefgegangen sein, z.B.
- Problem aufgrund Partitionsverschiebung, sprich die Quell-SSD hätte in Wirklichkeit sda1 schon gar nicht mehr gebootet
- 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
- Hardwareproblem mit dem USB Adapter/Kabel
- Ziel-SSD nicht im ThinkPad eingebaut (falls die Überlieferung hier im Forum in deinem Fall zutrifft)
Ist mit wenig Erfahrung wohl besser geeignet und fängt im Gegensatz zu dd viele Fehlbedienungsmöglichkeiten ab.
Zuletzt bearbeitet:
Das hat mich halt auch irritiert. Ich bin davon ausgegangen bzw. gehe eigentlich immer noch davon aus, dass dd einfach stur 1:1 kopiert.
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.
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.
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
Active member
- Registriert
- 28 Feb. 2011
- Beiträge
- 910
....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...
[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
Well-known member
- Registriert
- 3 Mai 2009
- Beiträge
- 1.428
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.
