Broken header of a luks-partition - more than once
Hello there,
Some weeks ago, my luks-partition (/dev/sdb2) broke - it was supposed to be /dev/mapper/home and then /home. Cryptsetup didn't recognize it as a luks-partition. So i tried to get my data back and failed. Then I set up the whole thing again - which worked for several days (and reboots), but finally the same thing happened again - I didn't really know what to do, so I tried to check my harddisk with a Samsung tool (it's a spinpoint f1), but that didn't work either. So I replaced the harddisk. That made it work again for another couple of days until it broke again. Something must have overwritten the header (posted it at the bottom) - and I have no clue what.
That's exactly my question now: might it be a bug in cryptsetup or can i rule that out?
I also saved my /etc/fstab and /etc/crypttab, because they were fine - however, I'll show you all of it:
fstab:
martin@Computername:~$ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'vol_id --uuid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # / was on /dev/sdb1 during installation UUID=26aaffd8-b550-4cd7-a85d-3d906f31f396 / ext3 relatime,errors=remount-ro 0 1 # swap was on /dev/sda5 during installation # UUID=ec514d0c-11e7-4c6d-ae99-99150ca52f86 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 #cryptsetup-zeugs /dev/mapper/home /home ext3 defaults 0 2 /dev/mapper/ctmp /tmp ext2 defaults 0 0 /dev/mapper/cswap swap swap swap 0 0
crypttab:
martin@Computername:~$ cat /etc/crypttab # <target name> <source device> <key file> <options> home /dev/sdb2 none luks ctmp /dev/sda2 /dev/urandom tmp,cipher=aes-cbc-essiv:sha256 cswap /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
headers:
martin@Computername:~$ sudo xxd /dev/sdb2 | head [sudo] password for martin: 0000000: 4c55 4b53 babe 0001 6165 7300 0000 0000 LUKS....aes..... 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 7874 732d 706c 6169 ........xts-plai 0000030: 6e00 0000 0000 0000 0000 0000 0000 0000 n............... 0000040: 0000 0000 0000 0000 7368 6131 0000 0000 ........sha1.... 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0fc8 0000 0040 ...............@ 0000070: 3937 0359 0b40 0608 497a 9995 6734 da4d [email protected] 0000080: 6813 8d2e f151 f2df 4f43 9454 5fa8 2d23 h....Q..OC.T_.-# 0000090: 50b5 37f1 46dd 5bc4 aecd 88ea f967 5a51 P.7.F.[......gZQ
A comment about the above one: I think that already is not what it's supposed to be - but I'm not sure. However at the moment it works - because i set it up again. When it was broke, you couldn't read anything, but data-trash - so there was no LUKS, aes or xts-plain to be read in plain text. It looked more like the last 3 lines.
martin@Computername:~$ sudo xxd /dev/sdb1 | head 0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000000: eb48 9010 8ed0 bc00 b0b8 0000 8ed8 8ec0 .H.............. 0000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600 ...|.........!.. 0000020: 00be be07 3804 750b 83c6 1081 fefe 0775 ....8.u........u 0000030: f3eb 16b4 02b0 01bb 007c b280 8a74 0302 .........|...t.. 0000040: ff00 0020 0100 0000 0002 fa90 90f6 c280 ... ............ 0000050: 7502 b280 ea59 7c00 0031 c08e d88e d0bc u....Y|..1...... 0000060: 0020 fba0 407c 3cff 7402 88c2 52be 7f7d . ..@|<.t...R..} 0000070: e834 01f6 c280 7454 b441 bbaa 55cd 135a .4....tT.A..U..Z 0000080: 5272 4981 fb55 aa75 43a0 417c 84c0 7505 RrI..U.uC.A|..u. 0000090: 83e1 0174 3766 8b4c 10be 057c c644 ff01 ...t7f.L...|.D..
no clue if that's okay..
Thanks in advance
Martin :)
Quoted 4 lines · [email protected] wrote:
Something must have overwritten the header (posted it at the bottom) - and I have no clue what.
That's exactly my question now: might it be a bug in cryptsetup or can i rule that out?
Cryptsetup never write empty first sectors except explicit LUKS format. (Of course this can very rarely happen if hw/driver problem appears...)
But see crypttab here - you have tmp device created as regular encrypted device with random key - are you sure that kernel _cannot_ swap sda & sdb and your system just formats temp device here?
Quoted 6 lines
# <target name> <source device> <key file> <options> home /dev/sdb2 none luks ctmp /dev/sda2 /dev/urandomtmp,cipher=aes-cbc-essiv:sha256
cswap/dev/sda5/dev/urandom
swap,cipher=aes-cbc-essiv:sha256
Milan
--
[email protected]
Quoted 5 lines
Quoted 4 lines · [email protected] wrote:
Something must have overwritten the header (posted it at the bottom) - and I have no clue what.
That's exactly my question now: might it be a bug in cryptsetup or can i rule that out?
I have been using LUKS for several years on three different devices and I have had many users using it for their (note|net)books. I have yet to hear any report of breakage from my users or experience it myself.
Quoted 10 lines · Milan Broz
But see crypttab here - you have tmp device created as regular encrypted device with random key - are you sure that kernel _cannot_ swap sda & sdb and your system just formats temp device here?
Quoted 6 lines
# <target name> <source device> <key file> <options> home /dev/sdb2 none luks ctmp /dev/sda2 /dev/urandomtmp,cipher=aes-cbc-essiv:sha256
cswap/dev/sda5/dev/urandom
swap,cipher=aes-cbc-essiv:sha256
Milan is probably right here, device names on modern distributions are not deterministic! However, the underlying script should be careful not to the device under the random key mapping if it contains a valid filesystem.
crypttab functionality is not part of cryptsetup, but part of your distribution. You should report this problem there.
Quoted 13 lines · On Tue, 25 Aug 2009 00:50:23 +0200 Thomas Bächler <[email protected]> wrote:
Quoted 11 lines · Milan Broz
But see crypttab here - you have tmp device created as regular encrypted device with random key - are you sure that kernel _cannot_ swap sda & sdb and your system just formats temp device here?
Quoted 6 lines
# <target name> <source device> <key file> <options> home /dev/sdb2 none luks ctmp /dev/sda2 /dev/urandomtmp,cipher=aes-cbc-essiv:sha256
cswap/dev/sda5/dev/urandom
swap,cipher=aes-cbc-essiv:sha256
Quoted 8 lines
Milan is probably right here, device names on modern distributions are not deterministic! However, the underlying script should be careful not to the device under the random key mapping if it contains a valid filesystem.
crypttab functionality is not part of cryptsetup, but part of your distribution. You should report this problem there.
Okay, I assume that is a quite good point - i didn't know this fact.. I thought crypttab is part of cryptsetup and has - more or less - nothing to do with anything else in first place.
Since the failure takes some time to happen, I will probably report back in a couple of days or weeks. Thanks a lot for your time :) Would really not have thought of that!
Martin
A message that is not in the archive (sent off-list or not yet received): [email protected]
I was too hasty, this should have gone to the list...
Quoted 51 lines · Arno Wagner
Quoted 6 lines · Milan Broz
Quoted 4 lines · [email protected] wrote:
Something must have overwritten the header (posted it at the bottom) - and I have no clue what.
That's exactly my question now: might it be a bug in cryptsetup or can i rule that out?Quoted 7 lines
Cryptsetup never write empty first sectors except explicit LUKS format. (Of course this can very rarely happen if hw/driver problem appears...)
But see crypttab here - you have tmp device created as regular encrypted device
with random key - are you sure that kernel _cannot_ swap sda & sdb and your system just formats temp device here?I had that happen to me. Nasty. The BIOS seemd to modify disk order when booting from a different drive via the bootup boot device selection.
One simple way to get around this is to create one-drive RAID1 devices and then use them. No moving by the kernel on these.
Arno
Quoted 16 lines
Quoted 6 lines
# <target name> <source device> <key file> <options> home /dev/sdb2 none luks ctmp /dev/sda2 /dev/urandomtmp,cipher=aes-cbc-essiv:sha256
cswap/dev/sda5/dev/urandom
swap,cipher=aes-cbc-essiv:sha256Milan
--
[email protected]_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-cryptSignature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Or, to prevent any chance of the BIOS swapping the disk order, you could refer to your device by id instead. I know my friends motherboard does that, it randomly sometimes swaps the disk order for no reason when booting, just some bug in the bios.
So, to refer to disks in a way that are guaranteed to always point the the exact physical disk you want, regardless of what order they are, check in the /dev/disk/by-id directory. In here the kernel creates files that point to your disks just like /dev/sda, /dev/sdb, etc, do, except that instead of some arbetrary name like /dev/sda, the name is based upon the interface, the make of the drive, and its serial number.
Regards,
Sam
Quoted 43 lines
I was too hasty, this should have gone to the list...
Quoted 39 lines · Arno Wagner
Quoted 6 lines · Milan Broz
Quoted 4 lines · [email protected] wrote:
Something must have overwritten the header (posted it at the bottom)
- and I have no clue what.
That's exactly my question now: might it be a bug in cryptsetup or can i rule that out?Quoted 7 lines
Cryptsetup never write empty first sectors except explicit LUKS format. (Of course this can very rarely happen if hw/driver problem appears...)
But see crypttab here - you have tmp device created as regular encrypted device
with random key - are you sure that kernel _cannot_ swap sda & sdb and your system just formats temp device here?I had that happen to me. Nasty. The BIOS seemd to modify disk order when booting from a different drive via the bootup boot device selection.
One simple way to get around this is to create one-drive RAID1 devices and then use them. No moving by the kernel on these.
Arno
Quoted 15 lines
Quoted 6 lines
# <target name> <source device> <key file> <options> home /dev/sdb2 none luks ctmp /dev/sda2 /dev/urandomtmp,cipher=aes-cbc-essiv:sha256
cswap/dev/sda5/dev/urandom
swap,cipher=aes-cbc-essiv:sha256Milan
--
[email protected]_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 7 lines · [email protected] wrote:
...
/dev/mapper/homeand then /home. Cryptsetup didn't recognize it as a luks-partition.
... same thing happened again
...martin@Computername:~$ cat /etc/fstab ... /dev/mapper/home /home ext3 defaults 0 2
I'm fairly new to LUKS, but are your sure about ext3? I use ext2 throughout and so far, so good.
Using one identifier "home" in multiple contexts would confuse me, and could be confusing some piece of software. I try to use unique and meaningful identifiers everywhere to keep things straight (especially with multiple drives, LUKS, and LVM).
Here is an external drive that holds backup and archive images. Note the ext2 partition and ext2 file system, and related names /dev/sda1, /dev/mapper/sda1_crypt, and /mnt/sda1_crypt:
2009-08-24 11:38:58 root@p3600 ~/p3600
# parted /dev/sda print
Model: Seagate FreeAgent XTreme (scsi)
Disk /dev/sda: 1500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos Number Start End Size Type File system Flags
1 512B 1500GB 1500GB primary ext2 2009-08-24 11:40:35 root@p3600 ~/p3600
# fdisk -l /dev/sda Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb2dd7b60
Device Boot Start End Blocks Id System
/dev/sda1 1 182402 1465138583+ 83 Linux
2009-08-24 11:42:53 root@p3600 ~/p3600
# grep sda /etc/crypttab
sda1_crypt /dev/sda1 /root/.luks/keyfile luks
2009-08-24 11:44:07 root@p3600 ~/p3600
# grep sda /etc/fstab
/dev/mapper/sda1_crypt /mnt/sda1_crypt ext2 errors=remount-ro 0 2
2009-08-24 11:45:53 root@p3600 ~/p3600
# df /mnt/sda1_crypt/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/sda1_crypt
1442147276 617075544 751814832 46% /mnt/sda1_crypt
2009-08-24 11:45:58 root@p3600 ~/p3600
# ll /mnt/sda1_crypt/
total 28
drwxr-xr-x 4 root root 4096 Jul 18 21:40 ./
drwxr-xr-x 4 root root 4096 Jul 18 21:21 ../
drwx------ 2 root root 16384 Jul 18 21:15 lost+found/
drwxrwxrwx 9 root root 4096 Aug 9 13:27 q/HTH,
David
Quoted 5 lines · David Christensen
I'm fairly new to LUKS, but are your sure about ext3? I use ext2 throughout and so far, so good.
Using one identifier "home" in multiple contexts would confuse me, and could be confusing some piece of software.
Both are not related to the problem at all, and work flawlessly with any setup of LUKS/dmcrypt. Software which gets confused by "home" as identifier for the device-mapper and the "/home" partition is broken by design.