[dm-crypt] Broken header of a luks-partition - more than once

[dm-crypt] Broken header of a luks-partition - more than once

[spamzad]

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  97.Y.@..Iz..g4.M
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 :)

Re: [dm-crypt] Broken header of a luks-partition - more than once

[Milan Broz]

spamzad@googlemail.com 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?

> # <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

Milan
--
mbroz@redhat.com

Re: [dm-crypt] Broken header of a luks-partition - more than once

[David Christensen]

spamzad@googlemail.com wrote:
> ... /dev/mapper/home and 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

Re: [dm-crypt] Broken header of a luks-partition - more than once

[Heinz Diehl]

On 24.08.2009, David Christensen wrote: 

> 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.

Re: [dm-crypt] Broken header of a luks-partition - more than once

[Thomas Bächler]

> spamzad@googlemail.com 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.

Milan Broz schrieb:
> 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?
> 
>> # <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

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.

Re: [dm-crypt] Broken header of a luks-partition - more than once

[Martin]

On Tue, 25 Aug 2009 00:50:23 +0200
Thomas Bächler <thomas@archlinux.org> wrote:


> Milan Broz schrieb:
> > 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?
> > 
> >> # <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
> 
> 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

Re: [dm-crypt] Broken header of a luks-partition - more than once

[Arno Wagner]

I was too hasty, this should have gone to the list...

On Mon, Aug 24, 2009 at 08:08:57PM +0200, Arno Wagner wrote:
> On Mon, Aug 24, 2009 at 05:55:37PM +0200, Milan Broz wrote:
> > spamzad@googlemail.com 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?
> 
> 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
> 
> 
>  
> > > # <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
> > 
> > Milan
> > --
> > mbroz@redhat.com
> > 
> > _______________________________________________
> > 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 

-- 
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 

Re: [dm-crypt] Broken header of a luks-partition - more than once

[test532]

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

> I was too hasty, this should have gone to the list...
> 
> On Mon, Aug 24, 2009 at 08:08:57PM +0200, Arno Wagner wrote:
> > On Mon, Aug 24, 2009 at 05:55:37PM +0200, Milan Broz wrote:
> > > spamzad@googlemail.com 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?
> >
> > 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
> >
> > > > # <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
> > >
> > > Milan
> > > --
> > > mbroz@redhat.com
> > >
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt
>