* [dm-crypt] From /dev/mapper to the real device
@ 2011-01-18 9:01 Xavier Nicollet
2011-01-18 9:34 ` Milan Broz
0 siblings, 1 reply; 7+ messages in thread
From: Xavier Nicollet @ 2011-01-18 9:01 UTC (permalink / raw)
To: dm-crypt
Hi,
I have searched through the manuals without finding an answer.
I did something like that:
cryptsetup luksOpen /dev/mapper/lv_device crypto_device
I would like to find a way, given /dev/mapper/crypto_device, to find
which lv_device it was built from.
Is there a command or a way to find this information back ?
A sort of mount command for the dm-crypt.
Thank you very much,
Cheers,
--
Xavier Nicollet
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] From /dev/mapper to the real device
2011-01-18 9:01 [dm-crypt] From /dev/mapper to the real device Xavier Nicollet
@ 2011-01-18 9:34 ` Milan Broz
2011-01-18 14:25 ` Arno Wagner
2011-01-18 15:38 ` [dm-crypt] Another corrupt luks header thread Viktor Ekmark
0 siblings, 2 replies; 7+ messages in thread
From: Milan Broz @ 2011-01-18 9:34 UTC (permalink / raw)
To: nicollet; +Cc: dm-crypt
On 01/18/2011 10:01 AM, Xavier Nicollet wrote:
> I did something like that:
> cryptsetup luksOpen /dev/mapper/lv_device crypto_device
>
> I would like to find a way, given /dev/mapper/crypto_device, to find
> which lv_device it was built from.
cryptsetup status crypto_device (for active mapping)?
(But note this device name is not always the same you used, for LV you can
have several symlinks /dev/mapper/vg-lv or /dev/vg/lv or /dev/by-uuid/...
so there are hardcoded priorities)
Milan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] From /dev/mapper to the real device
2011-01-18 9:34 ` Milan Broz
@ 2011-01-18 14:25 ` Arno Wagner
2011-01-18 16:31 ` Thomas Bächler
2011-01-18 15:38 ` [dm-crypt] Another corrupt luks header thread Viktor Ekmark
1 sibling, 1 reply; 7+ messages in thread
From: Arno Wagner @ 2011-01-18 14:25 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]
On Tue, Jan 18, 2011 at 10:34:56AM +0100, Milan Broz wrote:
> On 01/18/2011 10:01 AM, Xavier Nicollet wrote:
> > I did something like that:
> > cryptsetup luksOpen /dev/mapper/lv_device crypto_device
> >
> > I would like to find a way, given /dev/mapper/crypto_device, to find
> > which lv_device it was built from.
>
> cryptsetup status crypto_device (for active mapping)?
>
> (But note this device name is not always the same you used, for LV you can
> have several symlinks /dev/mapper/vg-lv or /dev/vg/lv or /dev/by-uuid/...
> so there are hardcoded priorities)
I have a Python script, that does a traversal of /dev/
to find all devices mapped to the same object as a node
in /dev/mapper/ for each node in /dev/mapper/. This works
by comparing not names, but major and minor device number.
It does not work for symlinks though, only for duplicate
device special files. Symliks could be added easily though.
Not very elegant, but works. Copy for current cryptsetup
is attached. Sample output:
/dev/mapper/c1 is active and is in use.
type: PLAIN
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
devices: (9, 6) /dev/md6
offset: 0 sectors
size: 387462831 sectors
mode: read/write
mounted: /opt
Gruesse,
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
[-- Attachment #2: cryptstat --]
[-- Type: text/plain, Size: 6036 bytes --]
#!/usr/bin/python
# cryptstat.py
# Displays all matching devices in /dev/ for a cryptsetup target
# Calls "cryptsetup status <target>" to get the initial info,
# then determines major/minor of the reported device and does
# a traversal of /dev/ to find all matches.
# Reports an augemented result of "cryptsetup status", also
# including mount points.
# Arguments are any number of cryptsetup targets. Does a validity
# check and refuses targets not found in /dev/mapper/
# Without argument, displays info on all targets found in /dev/mapper/
# (c) Arno Wagner 2010, distributed under the modified BSD license.
# Version 0.03
# Version history
# 0.03 Adjustments for cryptsrtup 1.2.0
# 0.02 fixed error on unmounted but mapped devices
import sys, os, stat, subprocess, re
dev_path = '/dev'
mapper_path = '/dev/mapper'
cryptsetup_path = '/usr/sbin/cryptsetup'
# Utility functions
def normalize_path(path):
"""Replaces any number of occurences of '/' with a single '/'"""
# Note: INefficient, but should not matter
while path.find('//') > -1:
path = path.replace('//','/')
return(path)
def dir_walk(dir):
"""Returns a list of all filenames with full paths
(including dirs, specials, etc.) below the argument.
"." and ".." are omitted. Does not follow symblinks
to avoid loops, but there is no real loop prevention."""
names = []
dir = normalize_path(dir)
# process current directory
current = os.listdir(dir)
for d in current:
d = dir + '/' + d
# Test whether d is a directory. If so, recurse.
s = os.lstat(d)
if stat.S_ISDIR( s[stat.ST_MODE] ):
names.extend(dir_walk(d))
else:
names.append(d)
return(names)
def dir_walk_block(dir):
"""Returns the names of all block devices in the subtree at dir"""
names = dir_walk(dir)
block_dev = []
for n in names:
if stat.S_ISBLK(os.lstat(n)[stat.ST_MODE]):
block_dev.append(n)
return(block_dev)
def special_dev_major_minor(n):
"""Returns (major,minor) for a device special file name"""
s = os.lstat(n)
if not stat.S_ISBLK(s[stat.ST_MODE]) and \
not stat.S_ISCHR(s[stat.ST_MODE]) :
return None
else:
maj = os.major(s.st_rdev)
min = os.minor(s.st_rdev)
return (maj, min)
def build_block_major_minor_tables(dir):
"""Returns
1) a table of filenames that are all block special files
2) a dict mapping each name to (major,minor)
3) a dict mapping each (major,minor) pair to a table of filenames"""
names = []
name2pair = {}
pair2name = {}
names = dir_walk_block(dir)
for n in names:
maj, min = special_dev_major_minor(n)
name2pair[n] = (maj, min)
if (maj, min) not in pair2name:
pair2name[(maj, min)] = [n]
else:
pair2name[(maj, min)].append(n)
return (names, name2pair, pair2name)
# Start of main action
# determine list of targets to be processed
targets = []
# first get all in mapper_path except 'control'
mapper_targets = []
mapper_entries = os.listdir(mapper_path)
tmp = []
for e in mapper_entries:
if e != 'control':
tmp.append(e)
mapper_entries = tmp
# if argument list empty, copy mapper_entries
if len(sys.argv) == 1:
targets = mapper_entries
targets.sort()
else:
targets = sys.argv[1:]
# Make sure all targets are in mapper_entries
tbl = {}
for e in mapper_entries:
tbl[e] = None
for e in targets:
if e not in tbl:
print '\nError: Command argument "'+e+'" is not present in '+\
'mapper dir '+mapper_path+'!\nAborting\n'
sys.exit(1)
# print targets
# Create mappings (major,minor) <-> name
names, name2pair, pair2names = build_block_major_minor_tables(dev_path)
print
for t in targets:
# do call to "cryptsetup status"
cmd = cryptsetup_path + ' status ' + t
# print 'calling "' + cmd + '"'
p = subprocess.Popen(cmd, shell=True, bufsize=0,
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
stderr=subprocess.PIPE, close_fds=True)
(out, err) = p.communicate()
out_lines = out.splitlines()
if (p.returncode != 0): raise IOError(p.returncode, err)
# print('command output = [' + out + ']')
# check output line 7 for ' device: <device name>'
if not re.match('\ \ device\:\ \ \S+', out_lines[4]):
print '\nError: Line 7 of cryptsetup output has unexpected form'
print 'Expected: " device: <device name>'
print 'found: [' + out_lines[4]+ ']'
print 'complete cryptsetup output:\m'
print out
print '\nAborting!\n'
sys.exit(1)
device = out_lines[4][11:]
# print 'device found: [' + device + ']'
(maj, min) = name2pair[device]
# print '(maj, min) = ', (maj, min)
devices = pair2names[(maj, min)]
dev_str = ''
for d in devices: dev_str = dev_str + d + ' '
# print 'devices: ', dev_str
out_lines[4] = ' devices: '+str((maj, min))+' '+dev_str
for l in out_lines: print l
# determine mounts and print them
mounts = ' mounted:'
# ';echo' in next command is so that we have at least one line
# of output to avoid an error from subprocess
cmd = 'mount | grep '+mapper_path+'/'+t+'; echo'
# print 'calling "' + cmd + '"'
p = subprocess.Popen(cmd, shell=True, bufsize=0,
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
stderr=subprocess.PIPE, close_fds=True)
(out, err) = p.communicate()
out_lines = out.splitlines()
# print('command output = [' + out + ']')
if (p.returncode != 0): raise IOError(p.returncode, err)
if len(out_lines) == 1:
mounts = mounts + ' not mounted'
else:
for l in out_lines:
# print 'l = ', l
match = re.search(' on (\S+) type', l)
if match != None:
mounts = mounts + ' ' + match.group(1)
print mounts
print
^ permalink raw reply [flat|nested] 7+ messages in thread
* [dm-crypt] Another corrupt luks header thread
2011-01-18 9:34 ` Milan Broz
2011-01-18 14:25 ` Arno Wagner
@ 2011-01-18 15:38 ` Viktor Ekmark
2011-01-18 16:36 ` Thomas Bächler
2011-01-18 18:54 ` Arno Wagner
1 sibling, 2 replies; 7+ messages in thread
From: Viktor Ekmark @ 2011-01-18 15:38 UTC (permalink / raw)
To: dm-crypt
Hello everyone,
My lvm and luks header went corrupt last week because of a naive user
and a possible faulty hw-raid controller. I believe the rest of the data
is intact and I have an old luksDump from when I first created the volume.
The volume had one large LV, which was then encrypted with luks. I have
other volumes with the same layout to compare with.
Since the lvm is also corrupt, I can only inspect the volume without the
LV device. All data seems intact after 0x31000. After comparing the
corrupt volume with a intact volume, I've noticed they both begin data
at that position and the position inside the LV device is 0x1000.
I'm missing something like this inside the LV (taken from one of my
intact LV devices:
00000000 4C 55 4B 53 BA BE 00 01 61 65 73 00 00 00 00 00 00 00 00
00 LUKS....aes.........
00000014 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000028 78 74 73 2D 70 6C 61 69 6E 00 00 00 00 00 00 00 00 00 00
00 xts-plain...........
0000003C 00 00 00 00 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00
00 ............sha1....
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000064 00 00 00 00 00 00 08 08 00 00 00 20 F4 8A 16 39 E5 12 8A
BA ........... ...9....
00000078 9B FC D5 B5 C8 BB 2B 13 7B 76 BF 35 55 D5 80 2E A8 0B 1F
66 ......+.{v.5U......f
0000008C 0A 07 F3 C1 81 CA FC 46 BB D6 13 F5 FB 12 81 C5 DA 57 6F
94 .......F.........Wo.
000000A0 04 B5 B9 CA 00 00 00 0A 66 61 32 32 38 64 63 66 2D 31 34
35 ........fa228dcf-145
000000B4 65 2D 34 38 35 32 2D 38 65 37 33 2D 39 30 38 35 62 37 61
33 e-4852-8e73-9085b7a3
000000C8 39 38 33 65 00 00 00 00 00 AC 71 F3 00 03 A7 03 6E 67 02
8D 983e......q.....ng..
000000DC 96 F6 1A B2 36 31 5D 51 4B E1 3A 4C 84 23 D6 41 A5 1F EC
51 ....61]QK.:L.#.A...Q
000000F0 AB DF F5 4D B4 CD 8C E6 00 00 00 08 00 00 0F A0 00 00 DE
AD ...M................
00000104 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000118 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
08 ....................
0000012C 00 00 0F A0 00 00 DE AD 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000154 00 00 00 00 00 00 02 08 00 00 0F A0 00 00 DE AD 00 00 00
00 ....................
00000168 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
0000017C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 08 00 00 0F
A0 ....................
00000190 00 00 DE AD 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
000001A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
000001B8 00 00 04 08 00 00 0F A0 00 00 DE AD 00 00 00 00 00 00 00
00 ....................
000001CC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
000001E0 00 00 00 00 00 00 00 00 00 00 05 08 00 00 0F A0 00 00 DE
AD ....................
000001F4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06
08 ....................
0000021C 00 00 0F A0 00 00 DE AD 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 ....................
00000244 00 00 00 00 00 00 07 08 00 00 0F A0 00 00 00 00 00 00 00
00 ....................
Old luksDump from my corrupt LV:
LUKS header information for /dev/mapper/lv02a-lv02a
Version: 1
Cipher name: aes
Cipher mode: xts-plain
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: d4 38 70 47 0d 20 72 42 0e 04 97 94 e8 56 59 1f f9 6f
ec 1c
MK salt: c6 63 93 f7 67 6b b9 d9 dd a0 5e 7a 46 6f 2e b7
d2 43 63 db 88 1b c7 aa 3b c9 41 2c dd 5c be 58
MK iterations: 10
UUID: b81d8995-33b3-48a8-b1e1-1c0d0c237974
Key Slot 0: ENABLED
Iterations: 162621
Salt: 44 cc 3d 3b 6d e1 34 9b 83 e0 b5 e2 0b e1 f0 4d
a3 c6 1e 11 fa c1 6f ab a6 61 04 7d e9 17
b9 20
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
I believe the lvm can be easily restored from backups in
/etc/lvm/backup, so the remaining problem is the luks header.
Is it possible to restore the LUKS header? If so, how should I proceed?
I would appreciate any help with this.
If not, is it possible to recover any data on the volume?
Viktor
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] From /dev/mapper to the real device
2011-01-18 14:25 ` Arno Wagner
@ 2011-01-18 16:31 ` Thomas Bächler
0 siblings, 0 replies; 7+ messages in thread
From: Thomas Bächler @ 2011-01-18 16:31 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
Am 18.01.2011 15:25, schrieb Arno Wagner:
>
>
> On Tue, Jan 18, 2011 at 10:34:56AM +0100, Milan Broz wrote:
>> On 01/18/2011 10:01 AM, Xavier Nicollet wrote:
>>> I did something like that:
>>> cryptsetup luksOpen /dev/mapper/lv_device crypto_device
>>>
>>> I would like to find a way, given /dev/mapper/crypto_device, to find
>>> which lv_device it was built from.
>>
>> cryptsetup status crypto_device (for active mapping)?
>>
>> (But note this device name is not always the same you used, for LV you can
>> have several symlinks /dev/mapper/vg-lv or /dev/vg/lv or /dev/by-uuid/...
>> so there are hardcoded priorities)
>
> I have a Python script, that does a traversal of /dev/
> to find all devices mapped to the same object as a node
> in /dev/mapper/ for each node in /dev/mapper/. This works
> by comparing not names, but major and minor device number.
> It does not work for symlinks though, only for duplicate
> device special files. Symliks could be added easily though.
I don't see why this is necessary. I always have only one copy of the
device (/dev/dm-X) and a bunch of symlinks. The same is true for any
other device, not only device-mapper nodes. Any symlinks and the real
device node can be found using:
udevadm info --name=/dev/foo/bar --query=symlink
udevadm info --name=/dev/foo/bar --query=name
You can filter that output for whatever you need.
This is only screwed up if you don't let udev manage your devices and
mess with them yourself. cryptsetup doesn't do that, neither does the
device-mapper.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Another corrupt luks header thread
2011-01-18 15:38 ` [dm-crypt] Another corrupt luks header thread Viktor Ekmark
@ 2011-01-18 16:36 ` Thomas Bächler
2011-01-18 18:54 ` Arno Wagner
1 sibling, 0 replies; 7+ messages in thread
From: Thomas Bächler @ 2011-01-18 16:36 UTC (permalink / raw)
Cc: dm-crypt
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
Am 18.01.2011 16:38, schrieb Viktor Ekmark:
> Is it possible to restore the LUKS header? If so, how should I proceed?
> I would appreciate any help with this.
If the key slot has been damaged, your data is doomed. If the key slot
is intact, you can probably get the rest of the header from careful
careful reading of the LUKS standard and the data in your luksDump.
> If not, is it possible to recover any data on the volume?
This question amuses me and makes me sad at the same time. You encrypt
your data in order to protect it from unauthorized access. The you loose
your header and wish to bypass that protection - if you could do that,
your encryption would be worthless.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Another corrupt luks header thread
2011-01-18 15:38 ` [dm-crypt] Another corrupt luks header thread Viktor Ekmark
2011-01-18 16:36 ` Thomas Bächler
@ 2011-01-18 18:54 ` Arno Wagner
1 sibling, 0 replies; 7+ messages in thread
From: Arno Wagner @ 2011-01-18 18:54 UTC (permalink / raw)
To: dm-crypt
Please have a look at the FAQ. Several topics relevant to
your problem are covered there, including how to backup
and restore a LUKS header.
Arno
On Tue, Jan 18, 2011 at 04:38:24PM +0100, Viktor Ekmark wrote:
> Hello everyone,
>
> My lvm and luks header went corrupt last week because of a naive user
> and a possible faulty hw-raid controller. I believe the rest of the data
> is intact and I have an old luksDump from when I first created the
> volume.
>
> The volume had one large LV, which was then encrypted with luks. I have
> other volumes with the same layout to compare with.
>
> Since the lvm is also corrupt, I can only inspect the volume without the
> LV device. All data seems intact after 0x31000. After comparing the
> corrupt volume with a intact volume, I've noticed they both begin data
> at that position and the position inside the LV device is 0x1000.
>
> I'm missing something like this inside the LV (taken from one of my
> intact LV devices:
> 00000000 4C 55 4B 53 BA BE 00 01 61 65 73 00 00 00 00 00 00 00 00
> 00 LUKS....aes.........
> 00000014 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000028 78 74 73 2D 70 6C 61 69 6E 00 00 00 00 00 00 00 00 00 00
> 00 xts-plain...........
> 0000003C 00 00 00 00 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00
> 00 ............sha1....
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000064 00 00 00 00 00 00 08 08 00 00 00 20 F4 8A 16 39 E5 12 8A
> BA ........... ...9....
> 00000078 9B FC D5 B5 C8 BB 2B 13 7B 76 BF 35 55 D5 80 2E A8 0B 1F
> 66 ......+.{v.5U......f
> 0000008C 0A 07 F3 C1 81 CA FC 46 BB D6 13 F5 FB 12 81 C5 DA 57 6F
> 94 .......F.........Wo.
> 000000A0 04 B5 B9 CA 00 00 00 0A 66 61 32 32 38 64 63 66 2D 31 34
> 35 ........fa228dcf-145
> 000000B4 65 2D 34 38 35 32 2D 38 65 37 33 2D 39 30 38 35 62 37 61
> 33 e-4852-8e73-9085b7a3
> 000000C8 39 38 33 65 00 00 00 00 00 AC 71 F3 00 03 A7 03 6E 67 02
> 8D 983e......q.....ng..
> 000000DC 96 F6 1A B2 36 31 5D 51 4B E1 3A 4C 84 23 D6 41 A5 1F EC
> 51 ....61]QK.:L.#.A...Q
> 000000F0 AB DF F5 4D B4 CD 8C E6 00 00 00 08 00 00 0F A0 00 00 DE
> AD ...M................
> 00000104 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000118 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
> 08 ....................
> 0000012C 00 00 0F A0 00 00 DE AD 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000154 00 00 00 00 00 00 02 08 00 00 0F A0 00 00 DE AD 00 00 00
> 00 ....................
> 00000168 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 0000017C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 08 00 00 0F
> A0 ....................
> 00000190 00 00 DE AD 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 000001A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 000001B8 00 00 04 08 00 00 0F A0 00 00 DE AD 00 00 00 00 00 00 00
> 00 ....................
> 000001CC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 000001E0 00 00 00 00 00 00 00 00 00 00 05 08 00 00 0F A0 00 00 DE
> AD ....................
> 000001F4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06
> 08 ....................
> 0000021C 00 00 0F A0 00 00 DE AD 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 ....................
> 00000244 00 00 00 00 00 00 07 08 00 00 0F A0 00 00 00 00 00 00 00
> 00 ....................
>
> Old luksDump from my corrupt LV:
>
> LUKS header information for /dev/mapper/lv02a-lv02a
>
> Version: 1
> Cipher name: aes
> Cipher mode: xts-plain
> Hash spec: sha1
> Payload offset: 2056
> MK bits: 256
> MK digest: d4 38 70 47 0d 20 72 42 0e 04 97 94 e8 56 59 1f f9 6f
> ec 1c
> MK salt: c6 63 93 f7 67 6b b9 d9 dd a0 5e 7a 46 6f 2e b7
> d2 43 63 db 88 1b c7 aa 3b c9 41 2c dd 5c be 58
> MK iterations: 10
> UUID: b81d8995-33b3-48a8-b1e1-1c0d0c237974
>
> Key Slot 0: ENABLED
> Iterations: 162621
> Salt: 44 cc 3d 3b 6d e1 34 9b 83 e0 b5 e2 0b e1 f0 4d
> a3 c6 1e 11 fa c1 6f ab a6 61 04 7d e9 17
> b9 20
> Key material offset: 8
> AF stripes: 4000
> Key Slot 1: DISABLED
> Key Slot 2: DISABLED
> Key Slot 3: DISABLED
> Key Slot 4: DISABLED
> Key Slot 5: DISABLED
> Key Slot 6: DISABLED
> Key Slot 7: DISABLED
>
> I believe the lvm can be easily restored from backups in
> /etc/lvm/backup, so the remaining problem is the luks header.
>
> Is it possible to restore the LUKS header? If so, how should I proceed?
> I would appreciate any help with this.
>
> If not, is it possible to recover any data on the volume?
>
> Viktor
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-01-18 18:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-18 9:01 [dm-crypt] From /dev/mapper to the real device Xavier Nicollet
2011-01-18 9:34 ` Milan Broz
2011-01-18 14:25 ` Arno Wagner
2011-01-18 16:31 ` Thomas Bächler
2011-01-18 15:38 ` [dm-crypt] Another corrupt luks header thread Viktor Ekmark
2011-01-18 16:36 ` Thomas Bächler
2011-01-18 18:54 ` Arno Wagner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox