[dm-crypt] Unable to open LUKS after altering partition table

Jim jim at 8svn.com
Tue Apr 2 09:15:16 CEST 2013

I made a silly mistake and realize that I probably will not recover 
this data. My goal is an exercise to better understand dm-crypt, LUKS, 
and the rest of the stack.

I have, or had, a computer running Ubuntu 12.10 on an SSD with full 
disk encryption as configured by the standard installer. The drive 
contains an unencrypted /boot partition (sda1) and a LUKS/dm-crypt 
encrypted partition (sda5) that was a physical volume for a single 
volume group. That vg holds the lvs for an ext4 root file system and 
swap space.

The problem started when I attempted to use gparted to repartition a 
usb flash drive without changing the selected device from /dev/sda 
(internal hdd) to /dev/sdb (usb flash drive)! I deleted the existing 
partitions and told gparted to apply my changes. Of course, I chose to 
ignore all warning prompts and continue. Instant regret. I left gparted 
open for a while hoping to find some way to undo my change and rewrite 
the old partition table. No luck.

It would seem that gparted was somewhat successful in asking the kernel 
to reload the partition table as /sys/block/sda/ contained evidence of 
the sda5 partition but none of the primary partitions. I was able to 
grab the starting position and size from:
$ cat /sys/block/sda/sda5/start
$ cat /sys/block/sda/sda5/size
$ cat /sys/block/sda/sda5/alignment_offset

Apt-get installed TestDisk 6.13 from and it found the /boot partition 
which I wrote to disk as the new partition table. I then used fdisk and 
added the sda5 partition. Fdisk's default starting position matched the 
above which I took to be a positive sign.

A little more info from after the mistake but before rebooting:
$ cryptsetup status /dev/sda5
/dev/mapper/sda5_crypt is active and is in use.
   type: LUKS1
   cipher: aes-xts-plain64
   keysize: 512 bits
   device: /dev/sda5
   offset: 4096 sectors
   size: 233934848 sectors
   mode: read/write

$ cryptsetup status cryptswap1
/dev/mapper/cryptswap1 is active and is in use.
   type: PLAIN
   cipher: aes-cbc-essiv:sha256
   keysize: 256 bits
   device: /dev/mapper/cryptswap1
   offset: 0 sectors
   size: 16572416 sectors
   mode: read/write

$ vgdisplay
   --- Volume group ---
   VG Name ubuntu
   System ID
   Format lvm2
   Metadata Areas 1
   Metadata Sequence No 3
   VG Access read/write
   VG Status resizable
   Max LV 0
   Cur LV 2
   Open LV 2
   Max PV 0
   Cur PV 1
   Act PV 1
   VG Size 111.55 GiB
   PE Size 4.00 MiB
   Total PE 28556
   Alloc PE / Size 28556 / 111.55 GiB
   Free PE / Size 0 / 0
   VG UUID bfEpfv-*omitted*

$ lvdisplay
   --- Logical volume ---
   LV Path /dev/ubuntu/root
   LV Name root
   VG Name ubuntu
   LV UUID TYhvhI-*omitted*
   LV Write Access read/write
   LV Creation host, time ubuntu, 2013-01-09...
   LV Status available
   # open 1
   LV Size 103.64 GiB
   Current LE 26533
   Segments 1
   Allocation inherit
   Read ahead sectors auto
   - currently set to 256
   Block device 252:1

--- Logical volume ---
   LV Path /dev/ubuntu/swap_1
   LV Name swap_1
   VG Name ubuntu
   LV UUID S0pUq6-*omitted*
   LV Write Access read/write
   LV Creation host, time ubuntu, 2013-01-09...
   LV Status available
   # open 1
   LV Size 7.90 GiB
   Current LE 2023
   Segments 1
   Allocation inherit
   Read ahead sectors auto
   - currently set to 256
   Block device 252:1

$ fdisk -l /dev/sda

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 23441648 sectors
Unites = sectors of 1 * 512 = 512 bytes
Sectors size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier:

    Device  Boot   Start        End              Blocks   ID  System
/dev/sda1 *         2048        499711        248832   83  Linux
/dev/sda2        499712    23440703   116970496    5   Extended
/dev/sda5        501760    23440703   116969472   83  Linux

I was able to mount /boot which led me to believe I was on track. It 
seemed that sda5 was positioned correctly in this recreated partition 
table so I went ahead and rebooted.

The grub2 menu loaded as usual and then I was prompted for the 
cryptsetup password. Everything seemed normal but it would not accept my 
password! I tried dozens of times while being careful with caps,num,fn 
lock keys. As a sanity check, I loaded the computer with a backup disk 
that is an out of date dd replicatoin of this SSD and my password was 
accepted there.

Running the computer from a live cd I have examined the disk further.

$ blkid -p /dev/sda5
/dev/sda5: UUID="9c9e0774-*omitted*" VERSION="1" TYPE="crypto_LUKS" 

$ cryptsetup -v isLuks /dev/sda5
Command successful.

That seems good as the starting position and size exactly match the 
value from the open volume before rebooting. I don't see why deleting 
and restoring the partition table would affect the volume. Why does 
luksOpen no longer like my password?

After repeated failure to unlock the volume at boot time I was dropped 
to an initramfs prompt where I performed a luksDump. If I messed up on 
repartitioning I would expect luksDump to complain.

(initramfs) cryptsetup -v luksDump /dev/sda5
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha1
Payload offset: 4096
MK bits: 512
MK digest: *omitted*
MK salt: *omitted*
MK iterations: *omitted*
UUID: 9c9e0774-*omitted*

Key Slot 0: ENABLED
           Iterations: *omitted*
           Salt: *omitted*
           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
Command successful.

I may have missed something obvious but reading through the FAQ, 
searching the list and the web hasn't yielded the answer so I hope one 
of you can help or offer closure :)


More information about the dm-crypt mailing list