DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [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