On Mon, Feb 16, 2009 at 09:59:19AM +0100, orinoco wrote: > On Mon, 16 Feb 2009 08:34:42 +0100 > Milan Broz <mbroz@xxxxxxxxxx> wrote: > > orinoco wrote: > > > after an auto-software upgrade with siduxcc on an amd64 system on > > > friday I cannot mount one of four luks partitions any more. > > > It used to work before the upgrade without any problems: > > > $ crypsetup luksOpen <device> <mapper> > > > permanently results in "Command failed: Can not access device". > > > Sometimes altered with "No key available with this passphrase" > > > > This basically means that cryptsetup cannot open the device before > > any key operation. > > It can be hw problem (is anything in syslog?) but also some > > other subsystem can use the device. > > > > Try to check "dmsetup table" and "cat /proc/mdstat" if there > > is not other mapping of the same device - check for major:minor of > > device (ls -l /dev/<device>). > > > > Maybe some clever tools tries to open the device too? > > OMG! > I found the error and I fear an irrevocable data loss: > > With the update the kernel switched the internal /dev/sdXX order of the > hard disks - again. Unfortunately the former /dev/sdb5 was mounted in > crypttab as encrypted swap with /dev/random as key before all other > devices. And then I did reboot with the new kernel ... :-((((((( > I did address the swap partitions with the /dev/sdXX name because there > was not uuid in ls -la /dev/disk/by-uuid/ for them .... :-((((( > That explains everything ... but I fear ... > > If anyone has any idea how to restore this partition > I guess he would be a candiate for nobel price ... No nobel price, but the real question is how much of the swap was written to and were the data was written. I have absolutely no idea how swap space is used with regard to where stuff gets swapped to, but if you swap usage is low, most of the LUKS header may still be intact. There is also the swap signature to be considerd. I do not know exactly what it looks like, but an experiment with a file of zeros it looks to me like only the first 4096 bytes hold management info and that of these very little is written except onactual swap usage. >From an other such discussion here, what you need is at least one key and all its salts, as well as the salt of the master key. The rest of the header is, I think, less-critical and may be reconstructable. So have a look at the LUKS header spec and see what is still there on your partition. Unfortunately it looks like the LUKS homepage at http://luks.endorphin.org/ is down at the moment. However it seems the PDF with the on-disk specification is also available here: http://code.google.com/p/cryptsetup/wiki/Specification Rough overview is the figure directly under 1. Overview. The actual on-disk header in detail is in Figure 1, and the keyslod description is in Figure 2. I think you absolutely need the fields at offsets 112 and 132, in addition to a keyslot with intact salt data and the actual key-block intact. There may be other fields you absolutely need, but 32-64 bits or so can be brute-forced today without too much hassle, depending on what actually need to be done for a try. This still costs significant effort and may cause significant cost. The other thing is to think about how much your data is worth. It may be cheaptest to regard this as a lost cause from the beginning. Although I would recomment at least one in-detail look at the header. It may basically still be there. 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 - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
