|
Am Samstag, 4. Februar 2017, 02:18:29 schrieb Sascha Reißner: > Am Freitag, den 03.02.2017, 21:58 +0100 schrieb Ulf Volmer: > > On Fri, Feb 03, 2017 at 09:38:44PM +0100, Peter Ludikovsky wrote: > > > OK, gerade nachgelesen, LUKS speichert sich alle Infos in den ersten > > > 4096 Bytes eines Volumes, und anscheinend ohne diese Infos an anderer > > > Stelle nochmal abzulegen. Ich muss mich noch etwas einlesen, ob man > > > nicht mit den gleichen Parametern zumindest den Header rekonstruieren > > > kann um wieder auf die Daten zugreifen zu können. > > > > Sigi hat nicht das Raw- Devices des LUKS zum PV gemacht, sondern das > > entschlüsselte. Dem LUKS geht es also soweit gut. > > Das lässt sich leicht prüfen da die magic-number von LUKS genau aus dem > Namen, nämlich 'LUKS', besteht. > Folgender Aufruf müsste als Ergebnis 'LUKS' zum Vorschein bringen (wobei > '/dev/sdX' das LUKS-Device ist): > > # dd if=/dev/sdX bs=4 count=1 2> /dev/null > LUKS > > Sollte bei Sigi nicht 'LUKS' erscheinen, ist der LUKS-Header > zerschossen. > > > Das daraufliegende ext4 hat allerdings Schaden genommen. > > Aber das kann man eventuell reparieren. In einem anderen Ast wurde der > Befehl 'mkfs.ext4 -n …' ja bereits genannt mit dem man in Erfahrung > bringt, wo die anderen Superblöcke liegen sollten. > Sehe gerade, dort wurde 'mke2fs' verwendet ohne Angabe des Filesystems. > Ich bevorzuge immer die 'mkfs.xxx'-Varianten, da man hierbei gleich das > FS-Type mit angibt. > So? # mkfs.ext4 -n dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-d5ddd902df23
-- Liebe Grüße Sigi |