Adding Kamil due to bug #5184 where I noticed this issue.

CC: (none) => n54

This could actually be worse than I thought... it might actually corrupt things within it....

I'll have to do more tests (it's either the action of unlocking it, or because I hit the "add to lvm" button and used the same name as the lvm that should have been on it - that operation failed. Not sure which action actually caused my corruption.

Marking as release_blocker until I've done more tests.

Priority: Normal => release_blocker
Severity: normal => critical

As far as I remember, because of this I was always forced to make new partitions from scratch.

OK, so this is not as big a problem as it could be. Here are the results of my tests:

 1. Install system as described above.
 2. Run the installer and unlock the encrypted drive.
 3. Hit the "More" button and select "Reread partition table". After doing that, the LVM VG appeared and I could see all the partitions and complete a successful reinstall without recreating any partitions (I did reformat / and /boot, but I don't think there was any problem after this.

So the "fix" here is simply to make diskdrak always perform the "reread partition tables" after unlocking an encrypted drive. There was a small display error when I did it manually as outlined above, (the sda device was still shown as the selected tab the the contents of that tab were blank. I had to switch away from sda to the vg-mga that had appeared and switch back again before it redrew itself correctly.


I guess the actual corruption comes in when adding it to the LVM which is kinda fair enough. We should be able to avoid this by ensuring the reread option is always performed.


So, who can fix diskdrak? :)

Some further additions:
 1, If you only have one disk (sda) and simply hit More -> Reload... you will end up with the display error mentioned above. You cannot fix this and have to reboot!
 2. I can confirm that the corruption of data comes in from not doing the Reload and selecting the Add to LVM option on the freshly unlocked drive.


So in short, 2 bugs to fix in diskdrak:
 1. As per previous comment, unlocking encrypted drive should also run "Reread partition table" afterwards.
 2. The display error after running "Reread partition table" needs to be fixed.

Hmm I don't think we have ever supported having partitions inside encrypted partition.
I think it does not matter if it is lvm or other, it is a matter of handling the device as a disk instead of a partition after unlocking it.

in open_part, after decrypting, code calls _get_existing_one doing things like:

    my $part = { device => "mapper/$active_dmcrypt->{name}", size => $active_dmcrypt->{size},
                 options => 'noatime', dmcrypt_name => $active_dmcrypt->{name},
                 major => $p->{major}, minor => $p->{minor} };
[...]
    fs::type::set_isFormatted($part, to_bool($part->{fs_type}));

Which means, creating a Partition object for mapper/$active_dmcrypt->{name}.

?  I am maintaining one mandriva 2010.2, two mga1, and two cauldron systems with encrypted LVM containing /, /home, swap.  (and /boot outside LVM)

CC: (none) => fri

My Bug 5382 seem similar, possible duplicate, may have interesting info.

*** Bug 5382 has been marked as a duplicate of this bug. ***

@Pascal. Not sure what you mean in your comment 7. Do you have a suggested resolution to either of the bugs here (the redisplay or the corruption of encrypted partitions which contain LVM)?

It should work fine if the encrypted partition contains one PV (and whatever inside), not if it is partitioned.
I was confused by the discussion about reading partition table. Reading again the original report, this should indeed work.

I believe I understood the problem and have a patch to test at home, I will test it tonight or tomorrow.
It seems blkid no longer sets ID_FS_USAGE so type_subpart_from_magic is broken.

Might be a side effect of udev
eg: I fixed yesterday a bug where we weren't offering to upgrade RAIDs b/c we weren't activating them b/c udev already did (but failed b/c it didn't loaded the proper modules).

Doesn't blkid rely somewhat on udev db?
We may lack some rules.

CC: (none) => mageia

(In reply to comment #14)
> Doesn't blkid rely somewhat on udev db?
> We may lack some rules.

I'm not sure. I thought that blkid was used by udev to get the info for it's database... tho' these days it's built in to udev itself, but the concept is still there. i.e. in the rules you do: IMPORT{builtin}="blkid" vs IMPORT{program}="/sbin/blkid -o udev $tempnode"


Back at the problem, does:
  /sbin/blkid -o udev -p /dev/crypt_sda5
no longer print ID_FS_USAGE?

I can do more tests on my VM tomorrow.

Hmm it's strange, when I tested it it did not, but it seems to in the cauldron chroot on another machine I tried now. I will check again in my vm.

So it appears the behaviour did not change, I don't know why it had happened during my test but fixed the real problem in svn.

(Having raids on top of encrypted partition will probably not work too)

A new stage2 was uploaded

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

So just for the record, the -p argument is very important in blkid calls. Without it a cache is used and only a subset of the data is used. The cache is a broken concept and should never be used. -p is almost a mandatory argument.

Also lsblk might be a better tool. It queries udev and uses libblkid as a fallback.

For the record, -p flag was used up to the stage2 uploaded on 2013-01-05 so this is totally unrelated to this bug report.

This bug report is old, but when discussing the problem with Pascal he remembered the bug but not the follow/conditions around it. I only added my comment to aid us in the future should we ever get confused again.