On Wed, Sep 15, 2010 at 01:02:25AM +0200, Ma Begaj wrote: > >> > 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. > > ;-)). you are the man :). > > Working like a charm. Deleted partition, created new starting at 63, > unplug/plug and luks partition is there. Thanks. > > I owe you at least a drink. You are welcome. Made my now day too ;-) > >> 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. > > Wow great assumption. I did exactly that. I was doing this remotely > (I was not able to unplug) and I forgot first time to set 4kB sector size. > I deleted partition (which already was luksFormated too) and recreated > it again but this time in 4kB format. Its easy to have the idea when you already messed that up yourself once ;-) > Thanks a lot. > > > One more question because this is going pretty well now :) : > > Do you have an idea how could I recreate 4kB aligned partition > without deleting data from the disk? This is more facultative question, > because I know have my data. Difficult. You would need to shift the wole partitoon by one sector. > I thought about shrinking this partition, creating a second parition > with 500gb to copy all data on this new partition, creating first paritition > in 4kB aligned format, copying all data back to this partition etc. That would work if you can shrink. At least my standard tool (Gnu parted) cannot do much with XFS. Best option would be if you could temporary store all the date somewhere else on the machine and repartition. The other option is to live with it, USB2 is very slow anyways, sector alignment may not even matter that much. > That could maybe even work if XFS would support shrinking. But it > does not as I can remember ;-). Could partition start be moved from > sector 63 to sector 64 and keep working filesystem (of couse at the same > time risking to destroy some of the data)? Or is this (if possible) would > destroy filesystem totally? Well, you could either use dd_rescue or write a program in C that moves the raw partition. From your fdisk -ul output, I conclude that there is no space left at the end of the disk, so you would have to move the start from sector 63 to sector 60. That should still work. Another option is to do away with partitioning and move the start from sector 63 to 0. Your filesystem is then on /dev/sdm. A possible commandline for dd_rescue would be something like this (moving the partition to the start of the disk) dd_rescue -s 63 -S 0 -b /dev/sdm /dev/sdm Looks good, but better assume a 99% probability of complete data loss. Connection problems, read errors, all can kill the data. And this will take something like > 10 days for 2TB on USB2. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
