Re: [dm-crypt] WD20EARS (4KB sector size) lost Luks header after reboot

[Arno Wagner <arno@wagner.name>]

On Tue, Sep 14, 2010 at 08:50:19PM +0200, Ma Begaj wrote:
> > Hi,
> >
> > On Tue, Sep 14, 2010 at 06:55:36PM +0200, Ma Begaj wrote:
> >> Hi,
> >>
> >>
> >> I got a new HDD a few days ago and I put it in an external case and connected
> >> it over USB with my home server. It is a 2000GB WD disk, ?WD20EARS.
> >
> > That would be one of the 2kB sector drives...
> 
> you mean 4kb?

Yes ;-)
 
> >
> >> I already read a few articles how should I format this "special"
> >> drive, and I did it like this:
> >> http://ubuntuforums.org/showthread.php?t=1456251
> >>
> >> I set the partition to begin on sector 64 (instead of 63), run
> >> luksFormat, run luksOpen,
> >> created XFS and copied my files on this disk. I umounted it later and
> >> I rebooted
> >> the server today.
> >>
> >> First thing I noticed is that disk/paritions are not visible in
> >> /dev/disk/by-uuid/ although
> >> /dev/sdm and /dev/sdm1 are available. fdisk also does not look same
> >> as before:
> >
> > Not good.
> >
> >> fdisk output:
> >> --------------
> >> root@road:/dev/disk/by-uuid# ?fdisk /dev/sdm
> >>
> >> The number of cylinders for this disk is set to 243201.
> >> There is nothing wrong with that, but this is larger than 1024,
> >> and could in certain setups cause problems with:
> >> 1) software that runs at boot time (e.g., old versions of LILO)
> >> 2) booting and partitioning software from other OSs
> >> ? ?(e.g., DOS FDISK, OS/2 FDISK)
> >>
> >> Command (m for help): p
> >>
> >> Disk /dev/sdm: 2000.3 GB, 2000398934016 bytes
> >> 255 heads, 63 sectors/track, 243201 cylinders
> >> Units = cylinders of 16065 * 512 = 8225280 bytes
> >> Disk identifier: 0x00000000
> >>
> >> ? ?Device Boot ? ? ?Start ? ? ? ? End ? ? ?Blocks ? Id ?System
> >> /dev/sdm1 ? ? ? ? ? ? ? 1 ? ? ?243202 ?1953514552 ? 83 ?Linux
> >
> > You did create one large partition?
> 
> yes just one filling whole disk.
> 
> 
> >
> > What is the output of "fdisk -lu /dev/sdm1"?
> >
> 
> root@road:/dev/disk/by-uuid#  fdisk -lu /dev/sdm1
> 
> Disk /dev/sdm: 2000.3 GB, 2000398934016 bytes
> 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Disk identifier: 0x00000000
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdm1              64  3907029167  1953514552   83  Linux
> 
> Well, it looks good.

Indeed. Now there is the question why cryptsetup fails and
the partition is not detected.

> 
> 
> >
> >> --------------
> >>
> >> "Start" is 1 instead of 64.... pretty strange because I set it to 64
> >> when I was making this partition.
> >
> > You set it to 64 sectors. The 1 is a cylinder. You cannto see in this
> > view where exactly the partition starts. Use the -u option to fdisk.
> 
> Good to know. Thanks.
> 
> 
> 
> >
> >>
> >> luksOpen does not work and luksDump/isLuks reported that /dev/sdm1 is
> >> not luks partition.
> >
> > Interesting.
> >
> >> I have cryptsetup 1.0.5 on my server.
> >
> > Aehm, that is hiostoric. Please try with the current one,
> > which would be 1.1.3.
> 
> Right now before continuing with the rest? I have 3 other luks
> partitions on this machine. Should I expect some hiccups?
> 
> I am planning to upgrade whole system in the next week and
> if possible I will wait until than.

Hmm. Better wait. Therw was some issue that could hit you
if you have other LUKS partitions. I am honestly not sure
whether it applies.


> 
> >
> >> There are two questions for me here:
> >> 1. I have luksDump of /dev/sdm1 before this happened. Can I use
> >> luksDump ouput ?to
> >> recover/overwrite Luks partition?
> >
> > I think not, but I am not sure. Before trying that, lets figure
> > out whether this is simply an offset issue. Can you look
> > through the start of the disk and give the offset where the
> > "LUKS" string is exactly?
> >
> > Something like this should do the trick:
> >
> > hd /dev/sdm | grep LUKS
> 
> "hd"? I don't have hd command on my server.

HexDump.

> but I found the position with with dd and vi:
> 
> dd if=/dev/sdm of=/tmp/sdm bs=32256 count=1 obs=10240 skip=1
> 
> 
> this gives me LUKS on the beginning of /tmp/sdm so offset should be 32256:
> 
> LUKS??^@^Aaes^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@cbc-essiv:sha256^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@sha1^@^@^@^@^@^@^@^@^@^
>    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^D^H^@^@^@^Pq^W:<93>CE?????k?)?Ql?<8f>??0?<9b>m^Yr
> ?^E
> 
> 
> and like this:
> root@road:/dev/disk/by-uuid#  dd if=/dev/sdm of=/tmp/sdm bs=1024000 count=1
> 1+0 records in
> 1+0 records out
> 1024000 bytes (1.0 MB) copied, 0.0327064 s, 31.3 MB/s
> 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. 

This seems to be some bizzarre issue with your system not detecting the
partitions right and LUKS is actually working as expected.


Ok, lets do some triage.

- What Linux, what kernel version?

- Any special set-up like virtuzlization?

- Any special partition management system?


> >
> >> fdisk reports "start" on sector 1 instead of 64, which means that
> >> something there went wrong.
> >
> > No, see above.
> >
> >> Or not? Ideas? If I can use luksDump to recover luks-header should the
> >> partition table maybe be
> >> rewritten beginning with sector 64 before I recreate luks header.
> >>
> >>
> >> 2. How all this could happen?
> >>
> >> I would be very happy to experiment with this, to repeat all the steps
> >> to recreat the situation
> >> ?if I know that I am able to recover my partition. Any ideas before I
> >> start to play with this?
> >> How much of the partition header should I backup before starting with
> >> all of this?
> >
> > See the FAQ. If you back up the first 100MB, you are on the safe side.
> >
> 
> root@road:/dev/disk/by-uuid#  dd if=/dev/sdm of=/root/sdm.iso
> bs=1024000 count=100
> 100+0 records in
> 100+0 records out
> 102400000 bytes (102 MB) copied, 3.01704 s, 33.9 MB/s

Yes, like that.

> 
> >>
> >> p.s. I have all the data but I would like to avoid copying again
> >> because I have to copy everything
> >> (over 500gb) over SSH trough a 10mb connection
> >
> > Half a pound (500g) of 'b' though a 10 milli-bit connection?
> > Sounds like a pain (yes, capitalization can carry meaning).
> 
> ;-). believe me even 10[M]b is pretty slow if you have to copy 500[GB].

Hehe.

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