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
501760
$ cat /sys/block/sda/sda5/size
233938944
$ cat /sys/block/sda/sda5/alignment_offset
0
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"
USAGE="crypto" PART_ENTRY_SCHEME="dos" PART_ENTRY_TYPE="0x83"
PART_ENTRY_NUMBER="5" PART_ENTRY_OFFSET="501760"
PART_ENTRY_SIZE="233938944" PART_ENTRY_DISK="8:0"
$ 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 :)
Thanks!
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
