From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tansi.org (ns.km10532-04.keymachine.de [87.118.102.195]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 15 Sep 2010 00:13:04 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-239.dclient.hispeed.ch [84.74.164.239]) by tansi.org (Postfix) with ESMTPA id 8B806212804A for ; Wed, 15 Sep 2010 00:13:04 +0200 (CEST) Date: Wed, 15 Sep 2010 00:13:03 +0200 From: Arno Wagner Message-ID: <20100914221303.GA6023@tansi.org> References: <20100914173332.GB32723@tansi.org> <20100914203233.GA4559@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] WD20EARS (4KB sector size) lost Luks header after reboot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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