Re: Umzug von Daten
Hallo zusammen,
Am 04.02.2017 um 03:22 schrieb Siegfrid Brandstätter:
> 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[1]
> mke2fs 1.42.12 (29-Aug-2014)
> The file dev/mapper/luks-b50d4cb0-7c32-4c3d-9f59-d5ddd902df23 does not exist and
^
/ davor wieder vergessen; Fehler halten sich hartnäckig ;-)
> no size was specified.
Zum prüfen und ggf. reparieren fsck.ext4 (bzw. e2fsck) verwenden.
Gruß, Tom
Reply to: