Created attachment 363314 [details]
Attached traceback automatically from anaconda.

Version of components:
rawhide-20090930
anaconda 12.32

How reproducible:
Not sure, sometimes

Steps to reproduce:

1. Start the installation of rawhide
2. Proceed to partitioning dialog, create following partitioning layout:
(on first partition I have ntfs)
/dev/sda2     /boot              ext3    200MB
/dev/sda3      LVM encrypted     LVM     the rest (19800 MB in my case)

on top of LVM create:
1.             swap   swap    1000MB
2.             /      ext4     the rest (18800 MB)

3. Click on Next button, input the password for encrypted volume.

Result: 
Traceback is displayed: luks_format failed for '/dev/mapper/VolGroup-LogVol00'

Expected result:

There should be no traceback and user should be able to install fedora rawhide.

Are you sure that the drive is OK? The log contains following:

<3>Buffer I/O error on device dm-0, logical block 105
...
<3>Buffer I/O error on device dm-0, logical block 114
<4>device-mapper: ioctl: unable to remove open device temporary-cryptsetup-333

So it is probably either the drive or devicemapper or kernel.

Well, before this installation I made another one with crypted LVM on RAID device, and it finished successfully. After that, the second installation asked for password for crypted volume as expected. So I think the drive should be OK.

(In reply to comment #3)
> <3>Buffer I/O error on device dm-0, logical block 105
> ...
> <3>Buffer I/O error on device dm-0, logical block 114
> <4>device-mapper: ioctl: unable to remove open device temporary-cryptsetup-333
> 

Cryptsetup uses temporary device to access its keyslots. This device is named temporary-cryptsetup-$PID (and in rawhide it have also DM UUID in the form CRYPT-TEMP-*). This device contains key material and no one except cryptsetup should ever open it.

Unfortunately udev (and maybe others) scans all newly appeared block devices in system for fs signature (usually blkid triggered from some udev rule). This is not only wrong but it can be also a security problem - that device contains key material.

Cryptsetup need to remove that temporary device before creating real mapping, if the removal operation fails (because someone have the device opened), it remaps it to error target and sleep for a while before retry. This can cause

Buffer I/O error on device dm-0, logical block <a block with a possible signature>

messages.

So I suggest reassigning this to udev and check that udev rule _ignores_ temporary cryptsetup device. It should contain something like this:

ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_last_rule"
ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="dm_last_rule"

(these rules are part of reverted DM change, but should be also in old udev rules).

Maybe there is another application in anaconda scanning these device - it must stop to do that.

Anyway the messages just indicate that someone scan wrong devices, there is no error on real disk.

(In reply to comment #5)
> So I suggest reassigning this to udev and check that udev rule _ignores_
> temporary cryptsetup device. It should contain something like this:
> 
> ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_last_rule"
> ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*",
> GOTO="dm_last_rule"
> 
> (these rules are part of reverted DM change, but should be also in old udev
> rules).

Well, actually the device-mapper part in 70-anaconda.rules that is responsible for creating the symlinks (and calling blkid) for these temporary devices was not removed (or such filter rules applied) -- this was supposed to be removed when we ship our packages with udev support.

But now, when we have this situation as it is, anaconda team should consider adding this filter (at least temporarily until we deliver new packages with udev support turned on again).

Because the new udev changes for DM were reverted for F12, the problem should
be fixed in old udev rules.

I mean
 - react only to "change" event and not "add" event for DM devices
 - ignore at least temporary crypsetup device for blkid scan

There are many possible problems without these changes, adding that bug to F12
blocker and reassigning to udev. (I hope it is correct component for that.)

Filter for temporary cryptsetup devices added to 70-anaconda.rules.

master: anaconda-13.1-1 (commit 0d75702af9f27e93c38)
f12-branch: anaconda-12.34-1 (commit d2a66e1114b780c8f7)

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

Milan,

Could you verify that /lib/udev/rules.d/70-anaconda.rules in current anaconda meets your requirements?

I'm asking because here's what I found in anaconda-12.38-1.fc12.x86_64:

  ACTION!="add|change", GOTO="anaconda_end"

This seems to contradict your request:
> react only to "change" event and not "add" event for DM devices

And further, though it does contain the rules to ignore temporary cryptsetup devices...:

  ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="anaconda_end"
  ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="anaconda_end"

... these rules are evaluated _after_ blkid has already been called. So it contradicts your other request:
> ignore at least temporary crypsetup device for blkid scan

Oh, it's wrong. Sure, we have to filter out "add" events for KERNEL=="dm-?*" + that filter for temporary cryptsetup must be applied before blkid call. This needs to be fixed...

this seems to have been really-fixed in 12.39:

 	* Fri Oct 23 2009 Peter Jones <pjones> - 12.39-1 - More udev fixups for device-mapper and cryptsetup temp devices. (dlehman) (#526699) 

setting to MODIFIED; can Peter confirm that it's now correct in 12.39?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

> setting to MODIFIED; can Peter confirm that it's now correct in 12.39?

Yes, it is correct now (Dave sent me the fix and we discussed it before applying). I've also checked the package directly..

excellent, let's close this then.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers