On Thu, Aug 21, 2014 at 16:00:21 CEST, John Wells wrote: > I will try what you say. To add to the weirdness, I came into work this > morning with a unresponsive machine. I hard reset, booted Ubuntu, but at > that point *Ubuntu wouldn't recognize either partition, and both had the > same "GNU Parted Loopback 0" in the output of "head -c 1024 /volume | hd". Urgh. Pretty bad. > Neither partition was recognized by luksDump. I panicked. Naturally, cryptsetup needs to see the header. > Rebooted, and guess what? /dev/MORE_VG/MORE_LV was back to normal and I > could mount it. /dev/FINALFRONTIER_VG/HOME_LV was still corrupted with the > "GNU Parted Loopback 0" output. O.k., but that tells us that the LUKS header does _not_ get overwritten by this, but rather that there is some "probabilistic" (i.e. completely messed up) partition detection and remapping going on. All these things with LVM, user-space RAID assembly, udev, systemd, etc. have not been good for stability at all. It used to be that Linux was rock-solid, but it seems that those days are past for mainstream Linux. All this "magic" does more harm than good, and not least because of mismatch between developper egos and skill. > This makes no sense to me. How could the leading bits be different each > time I booted up? Could datamapper be assigning the wrong device to the > logical volume in some way? It just makes no sense. It does only make sense of some developer(s) completely borked some central boot-up functionality. Unfortunately, several teams have been hard at work to make that a reality, see above. One consequence is that, as you found, a disk- layout done with Fedora can cause random, hard to debug and non-intuitive failures with Ubuntu. Some people have lost context and sight of the goal completely here. This is really a disgrace. KISS is what distinguishes engineers and amateurs. Just do the test, and if that works we may find a way to recover from this mess. It goes without saying that you should probably avoid Ubuntu in the future or only use native Ubuntu installatons. Arno P.S.: Sorry for the rant, but the more amateurs mess with it, the more Linux gets to be like Windows. I find that comletely unacceptable. > > On Wed, Aug 20, 2014 at 5:15 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > > > Hi John, > > > > while I have no idea how HOME_LV got in this state, the > > hexdump shows what is wrong. I suspect some LVM or Parted > > "Magic" on installation caused this. > > As the salts in the header are critical for decryption, unless > > the LUKS header is somewhere else and the offsets are > > wrong (i.e. you are not looking at the place you are think > > you are looking at, e.g. due to some LVM problem) the data is > > gone. > > > > As to MORE_LV, this should work. I suspect you did the dump > > below on Ubuntu, correct? I think Ubuntu may have screwed > > up the partitioning so that Fedora 20 does not find MORE_LV > > anymore, but Ubuntu finds it. > > > > One more test would show this: > > > > Copy the first 10MB of MORE_LV on *Ubuntu* > > > > head -c 10M /dev/MORE_VG/MORE_LV >> header.dump > > > > do a loopback mount of it it on *Fedora 20* > > > > losetup /dev/loop0 header.dump > > > > and then try to luksOpen /dev/loop0. If that works > > on Fedora 20 but MORE_LV does not work on FEDORA 20, > > then this is a problem with Fedora 20 having dome issue > > accessing the raw MORE_LV partition. > > > > Note that header.dump will contain the key-slots, > > so make sure you can secure-erase the header.dump-file again! > > (You are still secure, but your passphrase is in there and > > if that becomes compromised, changing it will not be enough.) > > > > Arno > > > > > > > > On Wed, Aug 20, 2014 at 18:18:33 CEST, John Wells wrote: > > > Thanks Arno. > > > > > > Something definitely looks amiss: > > > $ sudo head -c 1024 /dev/FINALFRONTIER_VG/HOME_LV | hd > > > 00000000 47 4e 55 20 50 61 72 74 65 64 20 4c 6f 6f 70 62 |GNU Parted > > > Loopb| > > > 00000010 61 63 6b 20 30 00 00 00 00 00 00 00 00 00 00 00 |ack > > > 0...........| > > > 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > * > > > 00000400 > > > > > > $ sudo head -c 1024 /dev/MORE_VG/MORE_LV | hd > > > > > ��ޭ > > > 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 > > > |LUKS....aes.....| > > > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 > > > |........xts-plai| > > > 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |n64.............| > > > 00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 > > > |........sha1....| > > > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 > > > |...............@| > > > 00000070 4e 94 98 c0 51 a9 25 bb 74 73 88 a4 a7 6e c7 d3 > > > |N...Q.%.ts...n..| > > > 00000080 6f 18 71 fa 94 9a f4 5e d1 e8 5b 1a 34 3a 9f 9f > > > |o.q....^..[.4:..| > > > 00000090 1d 79 1f 61 f5 dd 98 09 e1 d6 2e ed c4 29 af 1a > > > |.y.a.........)..| > > > 000000a0 23 c9 59 da 00 00 77 a1 36 63 63 31 38 38 64 62 > > > |#.Y...w.6cc188db| > > > 000000b0 2d 63 63 64 62 2d 34 63 38 66 2d 39 37 62 32 2d > > > |-ccdb-4c8f-97b2-| > > > 000000c0 65 34 31 31 39 38 65 63 36 65 34 34 00 00 00 00 > > > |e41198ec6e44....| > > > 000000d0 00 ac 71 f3 00 01 df d7 79 85 dd f0 29 59 98 63 > > > |..q.....y...)Y.c| > > > 000000e0 0b 69 80 fe 48 61 8c 40 5b 3b 57 0f 82 9c ae 90 |.i..Ha.@ > > > [;W.....| > > > 000000f0 36 57 45 e2 03 82 26 c5 00 00 00 08 00 00 0f a0 > > > |6WE...&.........| > > > 00000100 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000120 00 00 00 00 00 00 00 00 00 00 02 00 00 00 0f a0 > > > |................| > > > 00000130 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000150 00 00 00 00 00 00 00 00 00 00 03 f8 00 00 0f a0 > > > |................| > > > 00000160 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000180 00 00 00 00 00 00 00 00 00 00 05 f0 00 00 0f a0 > > > |................| > > > 00000190 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 000001b0 00 00 00 00 00 00 00 00 00 00 07 e8 00 00 0f a0 > > > |................| > > > 000001c0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 000001e0 00 00 00 00 00 00 00 00 00 00 09 e0 00 00 0f a0 > > > |................| > > > 000001f0 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000210 00 00 00 00 00 00 00 00 00 00 0b d8 00 00 0f a0 > > > |................| > > > 00000220 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > 00000240 00 00 00 00 00 00 00 00 00 00 0d d0 00 00 0f a0 > > > |................| > > > 00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > |................| > > > > > > Yes, even though Fedora 20 will mount neither volume, Ubuntu 14.04 will > > > mount the /dev/MORE_VG/MORE_LV partition. > > > > > > Thanks, > > > John > > > > > > > > > On Wed, Aug 20, 2014 at 5:09 AM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > > > > > > > On Wed, Aug 20, 2014 at 00:22:29 CEST, John Wells wrote: > > > > > Thanks for your response. This is the result of luksDump on the > > > > container: > > > > > > > > > > # cryptsetup luksDump /dev/FINALFRONTIER_VG/HOME_LV > > > > > Device /dev/FINALFRONTIER_VG/HOME_LV is not a valid LUKS device. > > > > > > > > Ah, sorry. Did not see that access completely failed. > > > > That means the header was at least partially overwritten. > > > > > > > > Can you post or send me a hex-dump of the first 1024 bytes > > > > of this device and the other one? > > > > > > > > Command to do so is, e.g. > > > > > > > > head -c 1024 /dev/FINALFRONTIER_VG/HOME_LV | hd > > > > > > > > This will not compromise your security. > > > > > > > > > I will try to find the time to recreate the entire scenario. Do you > > think > > > > > the current container I'm able to open is at risk of corruption as > > well? > > > > > > > > Yes. Something seems to be running amok. > > > > > > > > Another queston: After Fedora 20 told you both were not > > > > valid LUKS devices, could you still open the one in Ubuntu > > > > that you could open before? > > > > > > > > Arno > > > > > > > > -- > > > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: > > arno@xxxxxxxxxxx > > > > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D > > 9718 > > > > ---- > > > > A good decision is based on knowledge and not on numbers. - Plato > > > > _______________________________________________ > > > > dm-crypt mailing list > > > > dm-crypt@xxxxxxxx > > > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > > > > > _______________________________________________ > > > dm-crypt mailing list > > > dm-crypt@xxxxxxxx > > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > > -- > > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > > GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 > > ---- > > A good decision is based on knowledge and not on numbers. - Plato > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. - Plato _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
