Clonezilla klont luks-verschlüsselte Swap nicht mit und Boot-Test vor SSD-Wechsel

[jh47]

Liebe Forumsmitglieder,
ich habe 3 konkrete Fragen an Euch (vgl. unten), für die ich aber wahrscheinlich ein wenig ausholen muss, um den Kontext zu verstehen. Vielleicht kann man es aber auch überspringen:

Auf meinem Laptop ist die Root-Partition für ein Update von Debian 11 auf Debian 12 zu klein, so dass ich auf eine größere SSD umziehen möchte.

Mittlerweile habe ich eine ca. 500-SSD in einem externen Laufwerk und mittels Conzilla auch die ursprüngliche 256GB-SSD (mit u.a. System und Home) als Ganzes geklont, wobei die Partitionen proportional vergrößert wurden. Das hat soweit reibungslos funktioniert, ebenso wie das nachträgliche Resizen der Luks-Container und des Filesystems in den jeweiligen Partionen -- auf der 500- SSD.

Bevor ich die 256GB-SSD gegen die 500-SSD auswechsle, möchte ich erst sicherstellen, dass alles funktioniert (ist mein Produktivsystem, auch vorrübergehender Ausfall ist ungünstig). Ja natürlich habe ich Backup u.a. vom Home-Verzeichnis, aber wenn ich nicht weiterarbeiten kann, ists halt schlecht, da keine alternativen linux-rechner im Haus...

Da ein Test-Booten auf (noch externer) 500-SSD im ursprünglichen Laptop problematisch ist, da die Partitionen auf Quell- und Ziel-SSD nun gleiche UUIDs haben, habe ich mal an separatem Rechner gebootet:

Prinzipiell scheint das zu gehen, aber es scheitert (scheinbar?) daran, dass der Boot-Vorgang versucht, die Swap-Partition zu mounten, die ursprünglich per Luks verschlüsselt war, beim Klonen aber nur eine unverschlüsselte Swap-Partition erstellt (vgl. unten Pfeile <=), ohne den Luks-Container darin zu übernehmen. In Kurzform sieht die Situation (auszugsweise) so aus (blkid -o list):

sda = eingebaute 256GB-SSD
sdc = extern über usb angeschlossene 500GB-SSD (der Conzilla-Klon der 256GB-SSD)

device fs_type label mount point UUID

/dev/sda1 ext2 /boot 7177686d-b2b9-4d6b-8a21-XXXXXXXXXXXX
/dev/sda2 crypto_LUKS (in Benutzung) 820ece84-9f22-418d-a52a-XXXXXXXXXXXX <=
/dev/sda3 crypto_LUKS (in Benutzung) 5fe4504f-35eb-48b4-9cac-XXXXXXXXXXXX
/dev/sda4 crypto_LUKS (in Benutzung) 81fb6339-4c25-4b02-8084-XXXXXXXXXXXX
/dev/mapper/sda3_crypt
ext4 / 8b126328-84d9-465f-8205-XXXXXXXXXXXX
/dev/mapper/sda2_crypt
swap [SWAP] 92f1b0c6-3808-4ea1-a13c-XXXXXXXXXXXX

...


/dev/mapper/sda4_crypt
ext4 /home b7427644-eb59-464e-81bb-XXXXXXXXXXXX

...

/dev/sdc1 ext2 (nicht eingehängt) 7177686d-b2b9-4d6b-8a21-XXXXXXXXXXXX
/dev/sdc2 swap (nicht eingehängt) fa256bea-d154-40a4-ae9f-XXXXXXXXXXXX <=
/dev/sdc3 crypto_LUKS (nicht eingehängt) 5fe4504f-35eb-48b4-9cac-XXXXXXXXXXXX
/dev/sdc4 crypto_LUKS (nicht eingehängt) 81fb6339-4c25-4b02-8084-XXXXXXXXXXXX

*******************************************************
Nun zu meinen 3 konkreten Fragen an Euch:
*******************************************************

0) Ist Test von externem Laufwerk vorab überhaupt möglich? Schließlich wird dann die SSD ja nie als sda angesprochen, wie es aber in crypttab und fstab ja eingestellt ist?
1) Wie kann man Conzilla dazubringen, auch die Swap-Partition eins zu eins zu klonen, also mit Luks-Container? Also wirklich 1:1-Klon, bei dem bei Austausch keine Überraschungen zu erwarten sind -- also SSD raus, neue geklonte SSD rein und läuft?
2) Wenn ich jetzt noch mal klone, haben Quell- und Ziel-SSD ja im Vorfeld schon gleiche UUIDs bei schon existierenden Partitionen. Könnte das zu Problemen führen, etwa, dass Conzilla Ziel und Quelle mitunter verwechselt oder ist das durch Wahl von sda als Quelle und sdc als Ziel quasi unverwechselbar? Ansonsten: Müsste ich die Zielfestplatte zunächst vor erneutem Klonen irgendwie "zurücksetzen" etwa Partitionen wieder löschen (auch lieber an anderem Rechner um nicht mit gleich UUIDs durcheinanderzukommen)?

Vielen Danke für Hilfe jeder Art, lg jh

[rhHeini]

Einfach mit dd abziehen wäre ein Möglichkeit.

[niemand]

0) Ist Test von externem Laufwerk vorab überhaupt möglich? Schließlich wird dann die SSD ja nie als sda angesprochen, wie es aber in crypttab und fstab ja eingestellt ist?

Sofern irgendwo die UUID verwendet wird, und du die beim neuen SSD nicht geändert hast: nein, das knallt. Wenn du nirgends die UUID verwendest: würd’ ich trotzdem nicht machen: du weißt im Vorfeld nicht, wer sda bekommt.

1) Wie kann man Conzilla dazubringen, auch die Swap-Partition eins zu eins zu klonen, also mit Luks-Container? Also wirklich 1:1-Klon, bei dem bei Austausch keine Überraschungen zu erwarten sind -- also SSD raus, neue geklonte SSD rein und läuft?

Man kann’s einfach ohne Clonezilla machen, indem man das neue SSD partitioniert, verschlüsselt, die Dateisysteme anlegt, die Daten kopiert und den Bootloader schreibt. Dann kann man es so testen, wie du’s bei 0) machen möchtest: damit haben die Dateisysteme und Partitionen verschiedene UUIDs. Tatsächlich halte ich diesen Weg jeder Clonerei gegenüber für überlegen.

OT: könntest du so Ausgaben bitte zwischen [​code] und [/code] posten, damit’s besser lesbar ist? Sähe dann in etwa so aus:

Code: Alles auswählen

/dev/sda1 ext2 /boot 7177686d-b2b9-4d6b-8a21-XXXXXXXXXXXX
/dev/sda2 crypto_LUKS (in Benutzung) 820ece84-9f22-418d-a52a-XXXXXXXXXXXX <=
/dev/sda3 crypto_LUKS (in Benutzung) 5fe4504f-35eb-48b4-9cac-XXXXXXXXXXXX
/dev/sda4 crypto_LUKS (in Benutzung) 81fb6339-4c25-4b02-8084-XXXXXXXXXXXX
/dev/mapper/sda3_crypt
ext4 / 8b126328-84d9-465f-8205-XXXXXXXXXXXX
/dev/mapper/sda2_crypt
swap [SWAP] 92f1b0c6-3808-4ea1-a13c-XXXXXXXXXXXX

[jh47]

Herzlichen Dank für Eure Tipps


@rhHeini: mit dd habe ich natürlich dann die Arbeit, Partitionsgrößen später noch an größere SSD anzupassen (geht das einfach, wenn die Partitionen "bündig" hintereinderliegen), aber wenn ichs richtig verstehe, ist das ja dann wirklich erst mal ein 1:1-Klon, bei dem ich frei bleibenden Speicher dann aber doch noch zur Verfügung habe, oder?

@niemand: OT: mit Code mache ich natürlich in Zukunft, Danke für Hinweis. Nur ein Test:

Code: Alles auswählen

hello world 

Bootloader schreiben etc. als neu basteln wollte ich ja gerade nicht, wenns sich vermeiden lässt und habe das Gefühl, ja momentan schon bei 99%- Lösung zu sein -- 1% fehlt halt, d.h. müsste halt (durch irgendeine Clonezilla-Option) nur Swap richtig geklont kriegen -- oder da die Partition im Nachhinein noch mit dd 1:1 klonen?
Dann hätte ich immer die folgenden Möglichkeit: (1) SSD-Tausch -- Läuft alles = prima -- nein, dann SSD-Rücktausch = und erst mal in Echtzeit produktiv weiterarbeiten und parallel Problem/Fehler suchen/lösen und dann im Flussdiagramm wieder zurück zu (1)

[niemand]

Bootloader schreiben etc. als neu basteln wollte ich ja gerade nicht, wenns sich vermeiden lässt und habe das Gefühl, ja momentan schon bei 99%- Lösung zu sein -- 1% fehlt halt, d.h. müsste halt (durch irgendeine Clonezilla-Option) nur Swap richtig geklont kriegen -- oder da die Partition im Nachhinein noch mit dd 1:1 klonen?

Warum basteln? Das ist im Normalfall ein Aufruf. Aber wenn du bei deinen „geclonten“ Images bleiben möchtest, dann hast du im Wesentlichen zwei sichere Möglichkeiten:

• du schraubst deine Maschine auf, tauschst die Datenträger gegeneinander aus und schaust, ob es bootet. Die Chancen stehen gut – ich würde allerdings swap erstmal komplett aus der fstab nehmen. Kann man im Nachhinein immer noch wieder im dann laufenden System einrichten – die Daten, die dort drin sind, werden mit dem Herunterfahren völlig nutzlos und werden beim nächsten Booten sowieso entsorgt, da muss man sich nicht dran festklammern.
• du änderst sämtliche UUIDs auf dem neuen Datenträger – und zwar die der Dateisysteme und der Partitionen, als auch in jeglicher Config, wo die auftauchen. Übersiehst du da was, kann’s dir gehen, wie mir vor zwei Tagen: Direkt nachdem Verfügbarwerden des Dateisystems gab’s Datensalat in der Form, dass der Rechner nur noch durch Abziehen des Datenträgers und Reboot wieder nutzbar zu bekommen war. An dem Datenträger selbst konnte ich von dem Rechner aus also gar nichts mehr tun.
  Die Ausgangslage war ziemlich ähnlich zu dem, was du da machst, btw.: ich war faul und es sollte schnell gehen, deswegen hab ich dieses Mal einfach den kompletten Inhalt des alten SSDs mit dd auf das Neue geschmissen – mit Testen hab ich mich da nicht weiter aufgehalten: entweder funktioniert, dann ist’s gut, oder funktioniert nicht – dann kann ich mich immer noch damit beschäftigen. War halt ungeschickt, als ich nun später das alte SSD nochmal durchschauen wollte, und nach allerhand geänderten UUIDs dann doch was übersehen hatte

[rhHeini]

Ein möglicher Weg mit dd geht so: Du legst auf Deiner neuen SSD die Swap-Partition so gross an wie Du sie haben willst, in jedem Fall grösser als die alte, z.B. mit gparted.

Dann sicherst Du mit dd die alte Swap-Partition entweder auf einen USB-Stick und dann von da auf die neue oder schreibst direkt auf die neue Partition. Ergebnis: auf der neuen SSD ist die Swap mit den gleichen Parametern wie Grösse, UUID usw. wie auf der alten SSD vorhanden. Dann bootest Du ein gparted-Live und vergrösserst die Swap damit auf die reservierte Grösse.

[jh47]

Danke für Eure ausführlichen Hinweise.

Das Ding mit der Swap ist halt, dass die originale Luks-verschlüsselt ist (warum erkennt Clonezilla das eigentlich trotz Luks-Container als Swap?) und daher auch schon im initram -- so nennt mans glaubich -- also auf jeden fall schon sehr früh beim booten versucht wird, zu entschlüsseln (steuerung durch crypttab) noch bevor fstab "zur Anwendung" kommt. Also einfach in fstab die swap rauswerfen, dürfte nicht reichen...

Ich denke ich versuche mal mit dd die orignale Swap-Partition nachträglich zu klonen, vielleicht reicht das ja schon und vielleicht gibt es doch eine Möglichkeit des Testens, habe gesehen, dass bei einem Rechner im Bios Festplatten aus Boot-Vorgang exkludiert werden können. Wenn man da zum Testen alle exkludiert, außer die zu Testende müsste die doch eigentlich auf sda gemappt werden (da sonst nichts vorhanden) und man könnte die Konfiguration so testen, wie es später bei Festeinbau im Laptop der Fall wäre. So die Theorie. Werde berichten und bin aber natürlich weiter offen für Ideen oder Korrekturen bei Denkfehlern.

Schönen Abend erst mal...

[jh47]

Hat geklappt: Mit dd konnte die ursprüngliche Swap-Partition (samt Luks-Container auf ihr) auf die Swap-Partition des Clonezilla-Klons -- die ja ohne LUKS-Container angelegt wurde -- nachträglich ergänzt werden, so dass nun reibungslos vom Klon gebootet werden konnte (auf separatem Rechner). Das reicht mir auch als Test, da ich vor allem sketpisch war, ob die Entschlüsselung der LUKS-Container nach Klonen noch funktioniert oder ich mich dadurch aussperre. Clonezilla kommt also mittlerweile mit LUKS tatsächlich klar wie es aussieht (wenn man von der verschlüsselten Swap mal absieht.)

Für evtl. andere Interessierte bestätige ich, worauf ihr micht schon hingewiesen habt: Booten am selben Rechner (wenn Original- und Klon beim Boot-Vorgang angschlossen sind) führt aufgrund derselben UUIDs tatsächlich zu eigenartigem Verhalten: So wird etwa unabhängig ob vom Booten des Klons oder des Originals die Boot-Partition vom Original eingehangen, aber das Root-Verzeichnis Klons eingehangen. Chaos ist da sicher vorprogrammiert.

Code: Alles auswählen

sda              8:0    0 238,5G  0 disk  
├─sda1           8:1    0   4,7G  0 part  /boot
...
sdb              8:16   0 476,9G  0 disk  
├─sdb1           8:17   0   9,3G  0 part  
├─sdb2           8:18   0   8,4G  0 part  
│ └─sda2_crypt 254:1    0   8,4G  0 crypt [SWAP]
├─sdb3           8:19   0  82,9G  0 part  
│ └─sda3_crypt 254:0    0  82,9G  0 crypt /

Bei der Größenanpassung der LUKS-Container auf dem Klon (das macht Clonezilla nämlich nicht mit), hat folgendes Vorgehen gut funktionert:

https://help.ubuntu.com/community/Resiz ... Partitions

Zusammenfassend hat bei mir das funktioniert, um einen boot-fähigen Clone zu erhalten (ohne Anpassungszwang von fstab, crypttab etc.)

1) Clonezilla mit proportionaler Vergrößerung gewählt (Partitiontsvergrößerung)
2) manuelles Resize der LUKS-Container in den Partitionen
3) mit dd nachträglich auch noch die verschlüsselte Swap-Partion auf unverschlüsselt gebliebene Klon-Swap-Partition klonen.

Herzlichen Dank noch mal für Eure Hilfen,

[ dann schaue ich jetzt mal nach der handwerklichen Seite des SSD-Tauschs, nicht dass es auf den letzten Metern daran scheitert, dass ich da was verbiege oder nicht mehr zusammenschrauben kann:) ]

[niemand]

dann schaue ich jetzt mal nach der handwerklichen Seite des SSD-Tauschs, nicht dass es auf den letzten Metern daran scheitert, dass ich da was verbiege oder nicht mehr zusammenschrauben kann:)

Wichtigste Regel: wenn du Kraft aufwenden musst, ist es verkehrt → aufhören und nochmal neu ansetzen.