Hi,
am Notebook gibt die Platte auf. Passend zum langen Wochenende. Kein Problem - dachte ich.
Das System ist mit LUKS und LVM aufgebaut, alles damals ganz easy per openSUSE Installationsvorgang. Dabei wurde wohl ein LUKS-verschlüsseltes LVM aufgebaut in dem alles außer dem Ordner /boot abgelegt ist.
1. neue Platte per USB2SATA Adapter angeschlossen. 2. Vom USB-Stick gebootet. 3. per dd <alte Platte> <neue Platte> kopiert. Die Platte hat drei Partitionen. Wenn ich sda nach sdb kopiere, werden die ersten beiden recht zügig übertragen, die dritte hingegen wird erst ebenso schnell dann aber immer langsamer übertragen. Nur wenn ich (mindestens) die dritte Partition als Partition sda3 -> sdb3 übertrage ist die Geschwindigkeit OK.
4. neue Platte statt der alten eingebaut und ... 5. Die Passphrase der Platte wird *nicht* abgefragt -> boot ist nicht erfolgreich.
Wenn ich lange genug warte lande ich an der 'Emergency Console'. Aber mangels Platte komme ich da nur in eine Shell (sh-4.4) die nichts kann (wahrscheinlich weil /root nicht gemountet ist).
Wie geht es richtig?
Bernd
Hi
ich weiss zwar nicht was schief ging. Ich geh' in solchen Fällen anders vor: 0) Datensicherung 1) Suse neu installieren, wenn alte und neue Platte gleichzeitig im System vorhanden sind frägt Suse ja nach, ob z.B. /etc/passwd etc. übernommen werden soll. 2) /etc mit der Datensicherung "abgleichen" (diff -r /etc /old/etc) und ggf. anpassen 3) /home dann via rsync kopieren
dann funktionieret's (i.d.R. :-)
Bye Jürgen
Am Freitag, 1. Mai 2020, 16:25:47 CEST schrieb Bernd Nachtigall:
Hi,
am Notebook gibt die Platte auf. Passend zum langen Wochenende. Kein Problem - dachte ich.
Das System ist mit LUKS und LVM aufgebaut, alles damals ganz easy per openSUSE Installationsvorgang. Dabei wurde wohl ein LUKS-verschlüsseltes LVM aufgebaut in dem alles außer dem Ordner /boot abgelegt ist.
- neue Platte per USB2SATA Adapter angeschlossen.
- Vom USB-Stick gebootet.
- per dd <alte Platte> <neue Platte> kopiert.
Die Platte hat drei Partitionen. Wenn ich sda nach sdb kopiere, werden die ersten beiden recht zügig übertragen, die dritte hingegen wird erst ebenso schnell dann aber immer langsamer übertragen. Nur wenn ich (mindestens) die dritte Partition als Partition sda3 -> sdb3 übertrage ist die Geschwindigkeit OK.
- neue Platte statt der alten eingebaut und ...
- Die Passphrase der Platte wird *nicht* abgefragt -> boot ist nicht
erfolgreich.
Wenn ich lange genug warte lande ich an der 'Emergency Console'. Aber mangels Platte komme ich da nur in eine Shell (sh-4.4) die nichts kann (wahrscheinlich weil /root nicht gemountet ist).
Wie geht es richtig?
Bernd
Am 01.05.20 um 17:13 schrieb Dr. Juergen Vollmer: (...)
- Datensicherung
Home ist nat. gesichert :-)
- Suse neu installieren, wenn alte und neue Platte gleichzeitig im
System vorhanden sind frägt Suse ja nach, ob z.B. /etc/passwd etc. übernommen werden soll.
- /etc mit der Datensicherung "abgleichen" (diff -r /etc /old/etc)
und ggf. anpassen
Weil das was wichtigerweise übernommen werden soll? (Das ist ein User-Linux, nix Server oder so.
- /home dann via rsync kopieren
oder aus der Datensicherung, klar.
dann funktionieret's (i.d.R. :-)
Joaa, das wäre ein Weg ... Aber neu installieren ist erst der letzte Ausweg.
Mich würde halt auch interessieren ob es da ein spezielles Problem wg. des LUKS gibt. Ich dachte wenn ich das per dd kopiere wären die Platten bis aufs Bit gleich, so das da keine Probleme auftreten sollten.
Bernd
Am 01.05.2020 um 18:10 schrieb Bernd Nachtigall:
Am 01.05.20 um 17:13 schrieb Dr. Juergen Vollmer: (...)
- Datensicherung
Home ist nat. gesichert :-)
- Suse neu installieren, wenn alte und neue Platte gleichzeitig im
System vorhanden sind frägt Suse ja nach, ob z.B. /etc/passwd etc. übernommen werden soll.
- /etc mit der Datensicherung "abgleichen" (diff -r /etc /old/etc)
und ggf. anpassen
Weil das was wichtigerweise übernommen werden soll? (Das ist ein User-Linux, nix Server oder so.
- /home dann via rsync kopieren
oder aus der Datensicherung, klar.
dann funktionieret's (i.d.R. :-)
Joaa, das wäre ein Weg ... Aber neu installieren ist erst der letzte Ausweg.
Mich würde halt auch interessieren ob es da ein spezielles Problem wg. des LUKS gibt. Ich dachte wenn ich das per dd kopiere wären die Platten bis aufs Bit gleich, so das da keine Probleme auftreten sollten.
Das ist so schon richtig. Was aber natürlich unterschiedlich ist sind die /dev/disk/by-id und ggf noch weitere Dinger da.
Mangels Erfahrung in diesen Dingen (LUKS/LVM) kann ich nicht sagen ob da im Inneren irgendwelche Verweise darauf existieren. Ansonsten fällt mir kein Grund ein warum eine korrekte Spiegelung mit dd nicht funktionieren sollte
Ich würde halt nach der Spiegelung erst versuchen, die gespiegelte manuell vom Rettungssystem zu mounten. Zumindest das sollte ja gehen
Manfred
Am 01.05.20 um 19:43 schrieb Manfred Kreisl:
Am 01.05.2020 um 18:10 schrieb Bernd Nachtigall:
Am 01.05.20 um 17:13 schrieb Dr. Juergen Vollmer: (...)
- Datensicherung
Home ist nat. gesichert :-)
- Suse neu installieren, wenn alte und neue Platte gleichzeitig im
System vorhanden sind frägt Suse ja nach, ob z.B. /etc/passwd etc. übernommen werden soll.
- /etc mit der Datensicherung "abgleichen" (diff -r /etc /old/etc)
und ggf. anpassen
Weil das was wichtigerweise übernommen werden soll? (Das ist ein User-Linux, nix Server oder so.
- /home dann via rsync kopieren
oder aus der Datensicherung, klar.
dann funktionieret's (i.d.R. :-)
Joaa, das wäre ein Weg ... Aber neu installieren ist erst der letzte Ausweg.
Mich würde halt auch interessieren ob es da ein spezielles Problem wg. des LUKS gibt. Ich dachte wenn ich das per dd kopiere wären die Platten bis aufs Bit gleich, so das da keine Probleme auftreten sollten.
Das ist so schon richtig. Was aber natürlich unterschiedlich ist sind die /dev/disk/by-id und ggf noch weitere Dinger da.
Mangels Erfahrung in diesen Dingen (LUKS/LVM) kann ich nicht sagen ob da im Inneren irgendwelche Verweise darauf existieren. Ansonsten fällt mir kein Grund ein warum eine korrekte Spiegelung mit dd nicht funktionieren sollte
Ich würde halt nach der Spiegelung erst versuchen, die gespiegelte manuell vom Rettungssystem zu mounten. Zumindest das sollte ja gehen
Na ja, so wie ich das sehe muss da VORHER das LUKS-Device geöffnet werden. Dann steht erst das LVM-Device zur Verfügung.
Und genau das scheitert ja, das LUKS wird zwar geöffnet, aber das LVM jammert. Damit gibt es kein /root und somit fällt der Boot auf die Nase. So ist das auch wenn ich mit angesteckter alter Platte neu installieren will. Dann erscheint zwar ein Fenster zur Eingabe des LUKS-Pwd aber das weitere klappt dann irgendwie nicht ... OK, das KANN der Platte geschuldet sein, die hat ja einen Hau, deshalb wird sie ja ersetzt ... aber komisch ist das schon ...
Ich werde wohl einen plain install machen und dann Home vom Backup holen.
Bernd
Am 01.05.20 um 20:08 schrieb Bernd Nachtigall:
Ich werde wohl einen plain install machen und dann Home vom Backup holen.
Hm, ich habe sehr gute Erfahrungen mit clonezilla gemacht. Alte und neue Platte anschließen, Clonezilla von USB-Stick booten, Platte kopieren lassen.
Hat bei mir auch den grub auf der neuen (bei mir größeren) Platte wieder zum Laufen gebracht.
Auf dem System, wo ich das gemacht habe, lief zwar nicht lvm und luks, aber hier
https://gist.github.com/andyrbell/4a339c0d8a3bc9465743a6b876671dcb
habe ich eine Anleitung gefunden, wo es auch damit funktionieren sollte.
Martin
Am 01.05.2020 um 20:08 schrieb Bernd Nachtigall:
Am 01.05.20 um 19:43 schrieb Manfred Kreisl:
Am 01.05.2020 um 18:10 schrieb Bernd Nachtigall:
Am 01.05.20 um 17:13 schrieb Dr. Juergen Vollmer: (...)
- Datensicherung
Home ist nat. gesichert :-)
- Suse neu installieren, wenn alte und neue Platte gleichzeitig im
System vorhanden sind frägt Suse ja nach, ob z.B. /etc/passwd etc. übernommen werden soll.
- /etc mit der Datensicherung "abgleichen" (diff -r /etc /old/etc)
und ggf. anpassen
Weil das was wichtigerweise übernommen werden soll? (Das ist ein User-Linux, nix Server oder so.
- /home dann via rsync kopieren
oder aus der Datensicherung, klar.
dann funktionieret's (i.d.R. :-)
Joaa, das wäre ein Weg ... Aber neu installieren ist erst der letzte Ausweg.
Mich würde halt auch interessieren ob es da ein spezielles Problem wg. des LUKS gibt. Ich dachte wenn ich das per dd kopiere wären die Platten bis aufs Bit gleich, so das da keine Probleme auftreten sollten.
Das ist so schon richtig. Was aber natürlich unterschiedlich ist sind die /dev/disk/by-id und ggf noch weitere Dinger da.
Mangels Erfahrung in diesen Dingen (LUKS/LVM) kann ich nicht sagen ob da im Inneren irgendwelche Verweise darauf existieren. Ansonsten fällt mir kein Grund ein warum eine korrekte Spiegelung mit dd nicht funktionieren sollte
Ich würde halt nach der Spiegelung erst versuchen, die gespiegelte manuell vom Rettungssystem zu mounten. Zumindest das sollte ja gehen
Na ja, so wie ich das sehe muss da VORHER das LUKS-Device geöffnet werden. Dann steht erst das LVM-Device zur Verfügung.
So ist es
Und genau das scheitert ja, das LUKS wird zwar geöffnet, aber das LVM jammert. Damit gibt es kein /root und somit fällt der Boot auf die Nase.
Mit 'jammert' kann man hier aber wahnsinnig viel anfangen.
So ist das auch wenn ich mit angesteckter alter Platte neu installieren will. Dann erscheint zwar ein Fenster zur Eingabe des LUKS-Pwd aber das weitere klappt dann irgendwie nicht ...
Neu installieren? Auf neue Platte?
OK, das KANN der Platte geschuldet sein, die hat ja einen Hau, deshalb wird sie ja ersetzt ... aber komisch ist das schon ...
Ja, allerdings. Und deine exakten Fehlerbeschreibungen helfen einem auch nicht wirklich weiter.
Ich werde wohl einen plain install machen und dann Home vom Backup holen.
Das wird wohl das Beste sein.
Manfred
Hi Bernd
Am Freitag, 1. Mai 2020, 18:10:11 CEST schrieb Bernd Nachtigall:
Joaa, das wäre ein Weg ... Aber neu installieren ist erst der letzte Ausweg.
ach das geht inzwischen so schnell....
Mich würde halt auch interessieren ob es da ein spezielles Problem wg. des LUKS gibt. Ich dachte wenn ich das per dd kopiere wären die Platten bis aufs Bit gleich, so das da keine Probleme auftreten sollten.
es gibt ein paar Stellen, wo der Name der Festplatte vorkommt:
- /etc/fstab - /etc/crypttab - wahrscheinlich noch, mehr.... grep -i -r uuid /etc
und die können sich ändern, wenn man die UUID als Kennzeichnung nimmt.
ein 'dd' ändert das nicht....
Die Folge -> 's geht halt nimmer
Bye Jürgen
Am 01.05.20 um 20:24 schrieb Dr. Jürgen Vollmer:
Hi Bernd
Am Freitag, 1. Mai 2020, 18:10:11 CEST schrieb Bernd Nachtigall:
Joaa, das wäre ein Weg ... Aber neu installieren ist erst der letzte Ausweg.
ach das geht inzwischen so schnell....
Mich würde halt auch interessieren ob es da ein spezielles Problem wg. des LUKS gibt. Ich dachte wenn ich das per dd kopiere wären die Platten bis aufs Bit gleich, so das da keine Probleme auftreten sollten.
es gibt ein paar Stellen, wo der Name der Festplatte vorkommt:
- /etc/fstab
- /etc/crypttab
- wahrscheinlich noch, mehr.... grep -i -r uuid /etc
und die können sich ändern, wenn man die UUID als Kennzeichnung nimmt.
ein 'dd' ändert das nicht....
Die Folge -> 's geht halt nimmer
Ja, genau, hier liegt der Hase im Pfeffer.
Mein System hat ein unverschlüsseltes /boot. Hab das vor längerer Zeit auseinandergedröselt und hier gepostet. Hab nur den Link nicht zur Hand, deshalb hier die vollständige Anleitung konkret:
Hallo,
vielleicht ist diese erprobte Zusammenstellung hilfreich.
Bei mir funktioniert es mit LUKS + encrypted aus dem Rettungssystem nach folgender Methode. Möglicherweise sind einige Schritte obsolet. Aber so habe ich es mehrfach durchgeführt, d.h. Systeme auf andere Festplatten umgezogen, usw.
Über Anmerkungen, Tipps u.ä. würde ich mich freuen.
Viele Grüße, Klaus
### Rücksicherung eines Systems mit LUKS-Verschlüsselung und LVM:
- Festplatte einbauen, mit dd die Partitionstabelle löschen, OpenSUSE installieren (mit LVM + Verschlüsselung, Swap erweitert für StandBy / Suspend to RAM). - ACHTUNG: ALLE Partitionen neu erstellen, oder vorher Partitionstabelle mit dd löschen. (Bereits vorhandene Partitionstabellen werden von yast receycelt und funktionieren u.U. nicht richtig) - Neues System starten und UNBEDINGT verfügbare Updates installieren. - OpenSUSE Rettungssystem starten (ACHTUNG: Sofort Sprache richtig stellen, sonst englische Tastaturbelegung!) - WENN VERSCHLÜSSELTES Backup-Medium: - Backup-Medium anschließen - <modprobe dm-crypt> - <fdisk -l> (Sicherungsmedium identifizieren) -> /dev/sdxy - <cryptsetup luksOpen /dev/sdxy backup> danach Passwort - WENN im Backup diese Dateien / Verzeichnisse bereits entfernt wurden: - /etc/fstab - /etc/lvm - /etc/crypttab - /boot - DANN: <mount -o ro /dev/mapper/backup /media> (schreibgeschützt einhängen) - SONST: - <mount /dev/mapper/backup /media> (rw einhängen) - o.a. Dateien / Verzeichnisse aus Backup entfernen - WENN NORMALES Backup-Medium: - Backup-Medium anschließen - <fdisk -l> (Sicherungsmedium identifizieren) -> /dev/sdxy - WENN im Backup diese Dateien / Verzeichnisse bereits entfernt wurden: - /etc/fstab - /etc/lvm - /etc/crypttab - /boot - DANN: <mount -o ro /dev/sdxy /media> (schreibgeschützt einhängen) - SONST: - <mount /dev/sdxy /media> (rw einhängen) - o.a. Dateien / Verzeichnisse aus Backup entfernen - Disk(s) anzeigen: <lsblk>: / dev / nvme0n1p1 / boot / dev / nvme0n1p2 LVM-encrypted - Now I enter the encrypted partition LVM: <cryptsetup luksOpen /dev/nvme0n1p2 neu> - Now active LVM partition: <vgchange -a y> - Was habe ich: <pvdisplay> <vgdisplay> --> <lvdisplay> zeigt /dev/system/root --> nach /mnt mounten: <mount /dev/system/root /mnt> - pvs zeigt Status: <pvs -v --segments /dev/mapper/neu> - ACHTUNG, UNBEDINGT für die Rücksicherung auf ein encrypted+lvm-Medium folgende Verzeichnisse / Dateien aus dem -->BACKUP-MEDIUM//DATA/ksc999/daily.0<-- entfernen, BEVOR die Rücksicherung durchgeführt wird, bzw. NICHT mitsichern: - /etc/fstab - /etc/lvm - /etc/crypttab - /boot - <cd /mnt> - verzeichnisweise: <rsync -avxHSAX /media/ksc999/daily.0/bin .> usw. <cd> <umount /mnt> - <mount /dev/system/home /mnt> <cd /mnt> <rsync -avxHSAX /media/ksc999/daily.0/home/* .> <cd> <umount /mnt> - <mount /dev/system/var /mnt> <cd /mnt> <rsync -avxHSAX /media/ksc999/daily.0/var/* .> <cd> <umount /mnt> - <sync>, alles aushängen. - reboot FERTIG ###
On Fri, May 01, Bernd Nachtigall wrote:
Wie geht es richtig?
Die beiden Platten haben unterschiedliche /dev/disk/by-id/ Werte. dracut wird die in der initrd speichern, und beim Start erwarten.
Am besten nach 'man dracut' suchen und schauen ob es ein Option für den Kernel gibt mit dem die initrd etwas anderes als das eingebaute /dev/disk/by-id nimmt.
Alternativ: eine genügend neue openSUSE Installations DVD starten, am Anfang die Passphrase eingeben damit das LVM auftaucht. Dann mit 'Strg+Alt+Shift+x' ein xterm starten, oder mit Alt+F2 zur Konsole. Dann nachschauen welche LVMs es gibt und ein chroot in das rootfs:
# lsblk -f # mount-rootfs-and-do-chroot.sh /dev/meinlvm/lv # mount -vat ext4 # mount -vat btrfs # mount -vat xfs # mkinitrd # exit 0 # sync
Jetzt müsste die initrd die neue Platte kennen und benutzen.
Viel Erfolg.
Olaf
Hallo Olaf,
Am 07.05.20 um 19:36 schrieb Olaf Hering:
On Fri, May 01, Bernd Nachtigall wrote:
Wie geht es richtig?
Die beiden Platten haben unterschiedliche /dev/disk/by-id/ Werte. dracut wird die in der initrd speichern, und beim Start erwarten.
Arrgh, ich wusste warum ich bei allen andern Rechnern die Dinger via Label mounte ...
Naja, bis zum Entschlüsseln der LUKS-Partition komme ich ja. Da das ein 'ugegradeter' Rechner war, war /boot darauf nicht verschlüsselt. dracut sollte eigentlich LUKS Partitionen suchen
Am besten nach 'man dracut' suchen und schauen ob es ein Option für den Kernel gibt mit dem die initrd etwas anderes als das eingebaute /dev/disk/by-id nimmt.
man dracut (ff.) ... Eine wahre Quelle der Information :-)
Alternativ: eine genügend neue openSUSE Installations DVD starten, am Anfang die Passphrase eingeben damit das LVM auftaucht. Dann mit 'Strg+Alt+Shift+x' ein xterm starten, oder mit Alt+F2 zur Konsole. Dann nachschauen welche LVMs es gibt und ein chroot in das rootfs:
# lsblk -f # mount-rootfs-and-do-chroot.sh /dev/meinlvm/lv # mount -vat ext4 # mount -vat btrfs # mount -vat xfs # mkinitrd # exit 0 # sync
Jetzt müsste die initrd die neue Platte kennen und benutzen.
Danke für diese ausführliche Beschreibung! Das kommt auf jeden Fall ins Archiv. (Inzwischen habe ich den Weg der Neuinstallation und des anschließenden Restore gewählt.) Aber evtl. suche ich eine andere Platte und versuche deinen Weg. Nur zum lernen ...
Bernd
Viel Erfolg.
Olaf
Am 08.05.2020 um 07:51 schrieb Bernd Nachtigall:
Hallo Olaf,
Am 07.05.20 um 19:36 schrieb Olaf Hering:
On Fri, May 01, Bernd Nachtigall wrote:
Wie geht es richtig?
Die beiden Platten haben unterschiedliche /dev/disk/by-id/ Werte. dracut wird die in der initrd speichern, und beim Start erwarten.
Arrgh, ich wusste warum ich bei allen andern Rechnern die Dinger via Label mounte ...
Naja, bis zum Entschlüsseln der LUKS-Partition komme ich ja. Da das ein 'ugegradeter' Rechner war, war /boot darauf nicht verschlüsselt. dracut sollte eigentlich LUKS Partitionen suchen
Schätze mal der sucht nicht. Der nimmt das was vorgegeben war. Ich hatte das mit dem /dev/disk/by-id ja schon erwähnt gehabt, hätte mir aber nie träumen lassen dass das irgendjemand verwendet. Wozu gibts denn uuid's.
[...]
Danke für diese ausführliche Beschreibung! Das kommt auf jeden Fall ins Archiv. (Inzwischen habe ich den Weg der Neuinstallation und des anschließenden Restore gewählt.) Aber evtl. suche ich eine andere Platte und versuche deinen Weg. Nur zum lernen ...
Viel Spaß ;)
Manfred
-
Bernd Nachtigall -
Dr. Juergen Vollmer -
Dr. Jürgen Vollmer
-
funedv＠gmx.de -
Manfred Kreisl -
Martin Burnicki -
Olaf Hering