Red Hat Bugzilla – Bug 468062
Encrypted LV has mismatching UUID
Last modified: 2013-02-28 23:06:52 EST
I installed F10-Snap2 reusing an existing partition layout from a previous F10 install. On installer boot it ask for my encrypted partitions p-word and I gave it the p-word.
On all three LV's I selected to 'format as ext3' and for /home I selected 'encrypted'. It did NOT ask me for a new /home p-word (which I think it should have)
After install the system failed to boot and dropped into maint mode because it couldn't mount /home.
/dev/mapper/luks-b30e9682-3df8-414b-a698-1d19764f1a2b /home ext3 defaults 1 2
luks-b30e9682-3df8-414b-a698-1d19764f1a2b UUID=b30e9682-3df8-414b-a698-1d19764f1a2b none
/dev/mapper/F10686VG00-LogVol01: UUID="9c6023c5-c15e-4859-9b60-f4b3c510b8b4" TYPE="ext4"
cryptsetup luksUUID /dev/mapper/F10686VG00-LogVol01 shows:
So notice that blkid UUID for the LV in question is not the same UUID that everything else is using and the TYPE= is clearly wrong and a remnant from a long past (at least 2 installs back) point in history. In every install I do In at least the last 2 installs I selected to 'format' and to 'encrypt' this LV.
Changing /etc/crypttab to be:
luks-b30e9682-3df8-414b-a698-1d19764f1a2b UUID=9c6023c5-c15e-4859-9b60-f4b3c510b8b4 none
Caused the system to ask me for the p-word for /home and everything booted and mounted correctly.
When writing out /etc/crypttab we are using the LUKS UUID, but we should instead be using whatever blkid sees as the UUID.
Having thought about this a little bit, I don't think that anaconda is the place to fix this. What is happening is libblkid is misinterpreting the device as ext4. Is this random data that happens to match the magic, or is it residual data on the device? I'd guess the latter.
One thing (dirty trick, I guess) that I expect would solve this is to move the LUKS entry to the beginning of the types array in probe.c. Thoughts?
Eric, can you attach the first several sectors of the block device in question?
Created attachment 321457 [details]
first 40k of LV
dd if=/dev/F10686VG00/LogVol01 of=/tmp/beginning bs=4096 count=10
This LV was created BEFORE I ran anaconda.
At some point long ago it was formatted unencrypted ext4
Before this install it was formatted (from the beta anaconda) encrypted ext4 (it didn't work probably due to the same problem, but I didn't run it down)
In anaconda this I chose to format as encrypted ext3.
I don't like the fact that if anaconda queries for the p-word for a partition and you chose to format and encrypt that partition it doesn't give you the option to change the p-word...
(In reply to comment #4)
> I don't like the fact that if anaconda queries for the p-word for a partition
> and you chose to format and encrypt that partition it doesn't give you the
> option to change the p-word...
For the sake of simplicity we chose between:
1. newly formatted fs means new luks header
2. luks header only gets nuked if the user unchecks 'encrypt' and then hits 'ok'
The first option violates the principle of least surprise. Showing a dialog asking which you want just seems like yet another annoying dialog (to me).
So, to nuke your luks header, you uncheck 'encrypt', hit 'ok', then re-edit as you like. Not perfect, but not scary either.
3. add a little box to the right of the encrypt tick box, "set password"
if on new creation they don't click the box you ask them like they do now. If someone wants to change it they have to click the box. I don't think it would make it more annoying....
(In reply to comment #6)
> 3. add a little box to the right of the encrypt tick box, "set password"
> if on new creation they don't click the box you ask them like they do now. If
> someone wants to change it they have to click the box. I don't think it would
> make it more annoying....
I know. We can put it next to the widgets that allow users to choose the encryption algorithm, key size, &c. Hmm, maybe move that into an "Advanced" tab that is initially hidden. If we're going that far, maybe it's time for system-config-luks... /me starts to cry
Seriously, for now, I had to draw the line somewhere. Who knows what the future may hold...
Ok, so, yes - both signatures are there.
[root@inode ~]# hexdump -C beginning | more
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 63 62 63 2d 65 73 73 69 |........cbc-essi|
00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........|
00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 |........sha1....|
00000400 00 00 01 00 00 00 04 00 33 33 00 00 9b ce 03 00 |........33......|
00000410 f5 ff 00 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00000420 00 80 00 00 00 80 00 00 00 20 00 00 35 8d ec 48 |......... ..5..H|
00000430 83 90 ec 48 01 00 ff ff 53 ef 01 00 01 00 00 00 |...H....S.......|
(53 ef is the ext2/3/4 magic)
Based on Eric's details, the ext magic is old.
So really, mke2fs should be zeroing the first 1K up to it's superblock (maybe it is already, I need to double check) and cryptsetup (?) should probably be splatting some zeros over the first part of the device, as well.
I'll look at both ...
ok, mke2fs does already zero the first 1k.
I'm going to punt this over to cryptsetup-luks. It looks like when it is creating a new volume, it should zero out a bit of the block device past the header that it is writing; would be simplest to just splat a few kilobytes of zeros or so onto the device, *then* write the header at the beginning.
This would erase older signatures.
FWIW, mkfs.xfs gave up trying to track all the ranges that needed to be hit, and just writes 128k of 0s to the beginning and end of the device to obliterate anything that might be there.
Hm, I think cryptsetup wipes enough space to remove all previous signatures but need to check it.
There is quite large area where are the keyslots stored (with the AF shuffle, so it iw rewrited) + writing visible header in the beginning, if there is still some remaining data between these areas, it is surely cryptsetup bug.
Cryptsetup save (uncrypted) physical header, current length is 2 sectors in the start of device.
From the 0x1000 ofset is stores crypted keyslot data.
Unfortunatelly there is space between this two areas which is not wiped and old data remains there - including ext2/3/4 magic.
I checked in patch to rawhide which wipes first 8 sectors with zeroes before the real header is written (8 sector is space before the keyslot data).
This should be problably fixed in new LUKS header revision by header padding, but for the time being the patch is enough.
I'll try to fix this upstream somehow too.
Anyway, old LUKS formatted volumes possibly contains these relic data, so blkid can fail fo them...
Fixed in build cryptsetup-luks-1.0.6-6.fc10.
While I'm sure this fixes that blkid thinks the type is ext4 does it fix that fact that the UUID from blkid != UUID from cryptsetup luksUUID yet the /etc/crypttab file was created as if they were the same? If so, great, if not, we need to reopen....
In short: yes, it fixes it.
They will be the same if libblkid correctly detects the device as a LUKS device. The problem is that it incorrectly detected the device as an ext device and therefore used the ext UUID instead of the LUKS UUID. Had it correctly identified the device in the first place it would have used the correct UUID and there would not have been a problem.
It's fairly important that this fix get into F10. Milan, can you please do a build and a request to get it in?
(In reply to comment #15)
> It's fairly important that this fix get into F10. Milan, can you please do a
> build and a request to get it in?
Here is a ticket for this:
Build was already in updates and now it is tagged to F10 too.
Also I committed patch to upstream svn a few days ago.