Problem mit dmcrypt nach dd und reboot

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
BlueTiger
Beiträge: 9
Registriert: 02.10.2005 02:26:44
Wohnort: Lünen

Problem mit dmcrypt nach dd und reboot

Beitrag von BlueTiger » 02.10.2005 04:08:03

Guten Abend,
ich bin neu hier, habe direkt ein Problem und hoffe auf Beistand ;-)

Es geht um folgendes:
Ich habe schon vor einiger Zeit meinen Server auf verschlüsselte Daten-Partitionen umgestellt und benutze dazu dm-crypt auf einem Debian Sarge System - funktioniert hervorragend.
Nun möchte ich aber auch meine /var Partition verschlüsseln, da ich aber leider keinen freien Platz auf meinen Platten habe, um einfach eine weitere (verschlüsselte) Partition anzulegen, muss ich das sozusagen on-the-fly machen. Sprich ich kann nicht einfach eine neue (verschlüsselte) Partition erstellen und dann die Daten per dd übernehmen.

Meine Vorgehensweise: (schonmal vorweg: es klappt einwandfrei bei einer frischen Installation in einer VMware, aber beim realen Server leider nicht)

- umount /var klappt nicht, da Prozesse noch im Zugriff
-----------
- Alternative 1:
- init 1
- umount /var
- Alternative 2 (klappt nicht immer!!!):
- fuser -km /var – killt alle Prozesse, die noch auf /var zugreifen
- umount /var
-----------
- cryptsetup -y -c aes -s 256 create <cryptname> /dev/<devicename> (passphrase min. 20-stellig)
- dd if=/dev/<devicename> of=/dev/mapper/<cryptname> (DAUERT!!)
- fsck /dev/mapper/<cryptname>
- mount /dev/mapper/<cryptname> /var
- Im Falle von Alternative1: init 2
- /etc/crypttab anpassen
- /etc/fstab anpassen

Soweit sogut, bisher hat auch auf dem realen Server alles geklappt.
Ich konnte die verschlüsselte Partition wieder an der alten Stelle einbinden und das System mit init 2 wieder in den normalen Betriebstatus versetzen.
Das Problem gibt es erst, wenn ich einen reboot durchführe, dann bekomme ich nach der Eingabe der Passphrase und beim Prüfen/Einbinden der nun verschlüsselten Partition den Fehler, dass der superblock fehlt (Format ist reiserfs 3.6).
Genau an dieser Stelle stehe ich auf dem Schlauch!!

Ich hoffe, jemandem fällt dazu etwas ein, wäre für jeden Hinweis dankbar!

mfg Thomas

Benutzeravatar
Incom
Beiträge: 417
Registriert: 09.11.2003 13:35:27
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Paderborn
Kontaktdaten:

Beitrag von Incom » 02.10.2005 10:09:15

Dumme Frage, aber: Bist du dir sicher das der Key richtig ist?
Die Meldung mit Superblock usw bekomme ich immer wenn ich eine nicht entschlüsselte Partition mounten will.

MfG
Incom
Du suchst eine Schritt-für-Schritt Anleitung? Dann schau im Wiki nach!

BlueTiger
Beiträge: 9
Registriert: 02.10.2005 02:26:44
Wohnort: Lünen

Beitrag von BlueTiger » 02.10.2005 13:15:17

hallo,
leider ist es nicht ein unpassender Key - leider!! ich wünschte es wäre so einfach!
Aber stimmt schon, diese Meldung kommt auch, wenn der Key falsch eingegeben wurde...

mfg Thomas

Benutzeravatar
Incom
Beiträge: 417
Registriert: 09.11.2003 13:35:27
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Paderborn
Kontaktdaten:

Beitrag von Incom » 02.10.2005 13:53:16

hast du es schonmal mit einem anderem dateisystem ausprobiert?
Du suchst eine Schritt-für-Schritt Anleitung? Dann schau im Wiki nach!

BlueTiger
Beiträge: 9
Registriert: 02.10.2005 02:26:44
Wohnort: Lünen

Beitrag von BlueTiger » 02.10.2005 14:10:18

nein, habe ich noch nicht. Was bringt dich zu der Annahme, dass es damit was zu tun hat?
Ich mein, nach dem dd konnte ich das Dateisystem erfolgreich checken und auch einbinden und damit arbeiten... und die ganze Prozedur hat auf dem vmware-testsystem vollständig geklappt, also auch mit reboot... sehr komisch das

Benutzeravatar
Incom
Beiträge: 417
Registriert: 09.11.2003 13:35:27
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Paderborn
Kontaktdaten:

Beitrag von Incom » 02.10.2005 15:15:56

Vielleicht hilft es auch das Dateisystem "normal" anzulegen und die Daten dann mit cp zu kopieren.
Bad superblock bedeutet für gewöhnlich dass das Dateisystem nicht in ordnung ist.
Du suchst eine Schritt-für-Schritt Anleitung? Dann schau im Wiki nach!

BlueTiger
Beiträge: 9
Registriert: 02.10.2005 02:26:44
Wohnort: Lünen

Beitrag von BlueTiger » 02.10.2005 15:27:15

ja stimmt, das is wohl meine letzte Alternative...
Auf n usb-gerät ne Ausweichpartition erstellen und die dann in der fstab als /var eindrehen.
Danach an den Ursprungsstelle die Partiton komplett neu verschlüsselt erstellen und per cp die daten von der usb-partition zurückholen und die fstab und die crypttab wieder eindrehen... genau das wollte ich eigentlich vermeiden... naja hab ja n gutes Backup, also versuch ichs auf diese Art...
Danke für die Anteilnahme ;-)

BlueTiger
Beiträge: 9
Registriert: 02.10.2005 02:26:44
Wohnort: Lünen

Beitrag von BlueTiger » 02.10.2005 17:35:30

Hallo nochmal,
sooo... ich hab jetzt den oben genannten workaround durch gemacht und es hat geklappt! JUHU
Aber natürlich gebe ich jetzt einfach mal nen Kurzabriss meiner Vorgehensweise, vielleicht bringt das ja mal jemandem was:

WORKAROUND:
benötigt: usb platte mit linuxpartiton
- /var auf die partiton übernehmen:
------
- mounten der usb-partition
- per cp alle Daten von /var auf usb übernehmen (cp -rp /var/* /mnt/sda1 )
-------
- init 1
- /etc/fstab anpassen und /var auf die usb-partition eindrehen
- umount /var
- mount /dev/<usb-partition> /var
- init 2
- per cryptsetup wie gehabt auf der alten Position n crypt-device erstellen
- mkfs.reiserfs /dev/mapper/<cryptname>
- mount /dev/mapper/<cryptname> /mnt/<temp>
- cp -rp /var/* /mnt/<temp>
- /etc/fstab wieder ändern – diesmal /dev/mapper/<cryptname> auf /var zeigen lassen
- /etc/crypttab anpassen!!!!!!!!!
- REBOOT - FERTIG

Soweit dazu, naja es klappt, wenns auch nich ganz mein Ursprungsansatz war.
Vielen Dank Incom, dass du dich an dieser Sache beteiligt hast!

mfg Thomas

Antworten