All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] WD20EARS (4KB sector size) lost Luks header after	reboot
Date: Wed, 15 Sep 2010 00:13:03 +0200	[thread overview]
Message-ID: <20100914221303.GA6023@tansi.org> (raw)
In-Reply-To: <AANLkTinweGfYyscC3coVreEosyGWnmKZKfrnDh7TZ-pA@mail.gmail.com>

On Tue, Sep 14, 2010 at 11:37:03PM +0200, Ma Begaj wrote:
> >> root@road:/dev/disk/by-uuid# ?grep -ob --binary-files=text LUKS /tmp/sdm
> >> 32256:LUKS
> >>
> >> or grep directly on /dev/sdm
> >>
> >> [ 32256 ] should be offset.
> >>
> >> What should I do with this?
> >
> > This confirms that you did create the LUKS container at the
> > right place, namely the LUKS header is at 64 x 512 B offset.
> 
> 64x512 =32768
> 32768  !=  32256
> 
> 512 bytes is partition table? should it be 32780?
> I am probably missing something.

No, you see what I missed. Your LUKS sector is at 63 sectors
offset, not 64. However the partition starts at 64 and therefore
the LUKS sector is not at its start. 

I don't know what went wrong here, but partitions 1-4 are special in
that you can change them without any changes to the disk except 
in the first sector (for partitions >= a chained partition sector
is writte to disk and that can kill a LUKS header and do other dmage).

This smeans you can just delete the partiton with fdisk and create
a new one, which will the start at sector 63 and should have
your LUKS container in it. It will not be 4kB alingned, though.
You should unplug and replug the disk after the partition creation.

If this goes wrong, you still have the first 100MB as backup.

> I just tested it on other LUKS disks and every disk gives 32256 which means
> that this offset is OK.

This is the standard offset when using 512 byte sectors, i.e.
the standard first sector of a partition starting at sector 63.

 
> > This seems to be some bizzarre issue with your system not detecting the
> > partitions right and LUKS is actually working as expected.
> 
> grep -ob --binary-files=text LUKS  /dev/sdm1
> 
> /dev/sdm1 does not return anything although it should return "0:LUKS".
> 
>  but grep on /dev/sdm returns "32256:LUKS"

Yes, because the poartition starts at offset 32768 and the header is
one sector before that.

> >
> > Ok, lets do some triage.
> >
> > - What Linux, what kernel version?
> 
>  2.6.29.4, vanilla
> 
> I have a few other HDDs in this machine, some of them with
> LUKS,  raid5 with LUKS etc.
> This is the only disk with LUKS on USB (others are intern/SATA)
> but that should not be the reason.

I agree.

> 
> > - Any special set-up like virtuzlization?
> > - Any special partition management system?
> 
> No to both.
> 
> 
> I think it has something to do with 4Kb sector size and some kind
> partition table incompatibilty with the kernel.
> 
> or maybe mkfs.xfs did something because I did not use "-b 4096" (block size
> in XFS is 4kB by default).
> 
> 
> LUKS header starts obviously where it should if I look at /dev/sdm.
>
> I don't know enough about partition tables and headers but it looks like
> /dev/sdm1 is starting little bit too far and LUKS header stays before the
> beginning of /dev/sdm1 (first partition).

Indeed.
 
> Only obvious reason (at lease for me)  for this could be in this 4Kb
> sector size.

I think something has gone wrong when you did the alignment.
Did you first create a not-4kB aligned partition and delete 
that again? If so the kernel would could remembered the partition
but not that it got deleted and replaced (that needs a disk unplug).
The reason is that the kernel sees partition changes only under some
circumstances.

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 

  reply	other threads:[~2010-09-14 22:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14 16:55 [dm-crypt] WD20EARS (4KB sector size) lost Luks header after reboot Ma Begaj
2010-09-14 17:33 ` Arno Wagner
2010-09-14 18:50   ` Ma Begaj
2010-09-14 20:32     ` Arno Wagner
2010-09-14 21:37       ` Ma Begaj
2010-09-14 22:13         ` Arno Wagner [this message]
2010-09-14 23:02           ` Ma Begaj
2010-09-15 10:29             ` Heinz Diehl
2010-09-15 11:21               ` Ma Begaj
2010-09-15 14:09             ` Arno Wagner
2010-09-16  7:30               ` Ma Begaj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100914221303.GA6023@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.