I should add that this only happens with the kernels I got after the upgrade. I can still boot with the F12 kernel and associated initramfs built with an F12 dracut.

might be a problem with the new device mapper handling.

yes, probably new udev handling problem...
what's the version of device-mapper abd cryptsetup?
(there should be recent upgrade in repo)?

-bash-4.0$ rpm -qa '*mapper*' '*cryptsetup*'
device-mapper-1.02.39-3.fc13.i686
device-mapper-multipath-0.4.9-11.fc13.i686
python-cryptsetup-0.0.10-1.fc12.i686
device-mapper-event-1.02.39-3.fc13.i686
device-mapper-multipath-libs-0.4.9-11.fc13.i686
cryptsetup-luks-1.1.0-0.4.fc13.i686
device-mapper-devel-1.02.39-3.fc13.i686
cryptsetup-luks-libs-1.1.0-0.4.fc13.i686
device-mapper-event-libs-1.02.39-3.fc13.i686
device-mapper-libs-1.02.39-3.fc13.i686

I installed kernel-PAE-2.6.31.6-148.fc12.i686 and was able to boot normally from it. This suggests the problem is more closely tied to the 2.6.32 kernel than dracut or system tools.

Hmm, I've also noticed that there are symlinks created for cryptsetup devices in /dev/mapper instead of nodes. This means that udev has created those symlinks, not libdevmapper.

The thing is that cryptsetup does not use udev synchronisation interface yet. Libdevmapper should always detect this situation and set proper flags for udev rules so they are skipped and we fallback to old (libdevmapper) node creation then. This is to prevent races between udev and libdevmapper...

This detection is always done unless someone disables udev synchronisation code by calling certain libdevmapper function explicitly - but this is not what cryptsetup does today, so we should fallback to old node creation (..udev will only create /dev/dm-X nodes automatically, but that should not interfere here at all).

When I use cryptsetup directly, everything is done as described above and it works as expected. The problem is with devices activated in dracut only - I find it a little bit strange since dracut uses exactly the same udev rules and same libdevmapper as we can find in standard environment.

Once the nodes are created by udev and libdevmapper's udev synchronisation interface is not used, there is a possibility for races to occur - that could possibly explain the strange behaviour described here.

But still, I'm thinking how it is possible that the /dev/mapper content is removed *before* that lsetfilecon is called - the device is removed *after* lsetfilecon is called only (..this one is called in libdevmapper just after the node is created). Strange.

OK, I'll try to debug this somehow...

After further investigation - the nodes in /dev/mapper for cryptsetup devices are fine in dracut. Actually, it's the start_udev script that is run afterwards that changes the nodes to symlinks (because of the udevadm_trigger that is run and this causes device-mapper udev rules to be applied - they overwrite the existing nodes in /dev/mapper, so it was a little bit misleading for me at first sight when I saw the symlinks there...).

The nodes during dracut stage are not applied at all so we can rule out the possibility of udev race with respect to /dev/mapper content here for those cryptsetup devices.


Anyway, I have a problem with upgrading to current rawhide's selinux-policy - I got:

libsepol.print_missing_requirements: chrome's global requirements were not met: type/attribute etcfile (No such file or directory).
lisemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule: Failed!

(this was standard F12 installation with an immediate upgrade to rawhide)

Has anyone encountered this?

The outcome is that I can't install current rawhide's policy sucessfully, because there's is none in /etc/selinux/targeted/policy after I got these errors...

There also is some tie in for this problem with SELinux. Booting with it disabled also allows the boot to complete. Maybe the initial policy in the kernels is different between 2.6.31 and 2.6.32 in a way that affects how crypt devices are set up.

I have been seeing more policy upgrade issues in recent months. (This might be tied to having local policies that could potentially cause problems for updates.) I asked Dan to make a tool that would reset the policy to the plain vanilla policy for use when things get messed up. I think currently you can get things into a state where you can't change to an updated policy in one step and there are no valid intermediate steps you can go through to get there. When that happens I use a hammer and remove the current policy's active directory and then reinstall it. It would probably also work to switch policies, reinstall the policy of interest and switch back. But that takes two relabels, while with the first you can do one and not much (or nothing) will change.

I am working to fix the current policy.

You are looking for a script to do.

# setenforce 0
# rm -rf /etc/selinux/targeted
# yum -y reinstall selinux-policy-targeted
# restorecon -R /etc/selinux/targeted
# setenforce 1

Thanks for the tip, it worked. However, I was not able to hit these kind of errors reported here by any means...

Clearly, something either prevents the temporary-cryptsetup nodes to be created or removes it just before lsetfilecon is called. And it's not even udev related - /dev/mapper content for these cryptsetup devices is not managed by udev at all. 

I'm still thinking what else could possibly interfere here (and possibly related to kernel version used?). Do you have any custom selinux settings that could be related to this? Or any other customizations different from plain rawhide installation (..that could help us to find the source of the problem)?

I have some custom stuff in a local module, but it is less restrictive than the base policy not more. I also have a few local context label rules, that shouldn't even be applied unless one is doing a restorecon function.

Perhaps the files that are created during the boot process are created with different labels during the boot process. I am not sure why that would be, but I don't know how selinux is handled early in the boot process.

Could you please try to edit (temporarily) one line in /lib/udev/rules.d/10-dm.rules - try to change this one:

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

into this:

  ACTION!="change", GOTO="dm_end"

(just remove the "add")

...and see if the error reported still occurs. I have a suspicion that there might be a race between NAME="" rule with which we suppress node creation on ADD events (and which removes the nodes if they exist already) and cryptsetup not using udev synchronisation. Thanks.

(this will affect non-initramfs environment only, of course - but I assume that's the exactly where you see that problem, *after* dracut has finished its job)

I won't be able to try this until tonight. I assume from the last part of the comment, that I don't need to run dracut to build a new initramfs in order to do this test.

I tried it and it didn't change how things worked.
Note that I am running the same udev for boots with f12 and f13 kernels, making it less likely to be a udev config issue. There is also the datum of it booting successfully when I disabled selinux. I also used the f13 dracut for both kernels.
I noticed that one of the features for the new kernel is selinux protection for some of the sysfs stuff. Could the problem be related to that?

So we can rule out that specific situation with node suppresion on ADD udev event then (..anyway, I think we need to cover this, too :) But that's different problem now..)

Well, we use sysfs for scanning (but that's lvm2, so not applicable to this problem) and reading some values (e.g. the name/uuid/suspended values from within the udev rules). But this should not matter, I presume.

The thing that led me to think about a race here is that I did not manage to reproduce this even after a fresh update to rawhide (with applying that trick to update selinux-policy as written above). But if you can reproduce it 100% of the time, then there's probably something else...

Does this happen even when you totally reset/reinstall the policy?

I retested this after resetting my policy and I saw the same thing. I do have some local policy bits, but they grant additional access and I don't have a problem booting the f12 kernel.
Since you don't seem to be able to reproduce it, I'll mention a couple of things that might be different between my system and yours. All of my file systems are on luks over raid1 except for /boot and swap which are just using raid1. My file systems include /, /home, /var, /boot and swap.

I can reproduce this problem on f13.  I have a dual boot F12/F13 system here where only my /home directory is encrypted.  I installed the f13 kernel on top of f12 and it worked.

with the f13 kernel on f13 the password is not ask for until after udev has started.  with f13 kernel on f12 the password for /home is requested before we pivot root.

Believe I am seeing this problem with fc13 (kernel-2.6.32-0.63.rc8.git2.fc13.x86_64) when I connect a LUKS-encrypted USB hard drive after the system has booted and I've been logged in for a while:

Dec  3 07:19:45 tlondon kernel: sdc: sdc1
Dec  3 07:19:45 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write
through
Dec  3 07:19:45 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk
Dec  3 07:19:53 tlondon kernel: usb 1-5.3: reset high speed USB device using
ehci_hcd and address 7
Dec  3 07:20:30 tlondon kernel: padlock: VIA PadLock Hash Engine not detected.
Dec  3 07:20:30 tlondon modprobe: FATAL: Error inserting padlock_sha
(/lib/modules/2.6.32-0.63.rc8.git2.fc13.x86_64/kernel/drivers/crypto/padlock-sha.ko):
No such device
Dec  3 07:22:07 tlondon kernel: device-mapper: ioctl: unable to remove open
device temporary-cryptsetup-14952
Dec  3 07:24:49 tlondon kernel: device-mapper: ioctl: unable to remove open
device temporary-cryptsetup-15092

The drive is recognized, and I get a window requesting the LUKS password. 
However, the password is rejected.

I then use /usr/bin/palimpsest an try to unlock the drive.  I can enter the proper passphrase 10 times and fiddle with "setenforce" settings before the device is successfully unlocked.  I see no graphical messages, nor anything in /var/log/messages except the above message.  And I only get that message occasionally. 

Once palimpsest unlocks the drive, I can mount it and use it as normal.

I am running "stock" rawhide with unmodified SELinux policy.

This the same problem?

How to help?

(In reply to comment #15)
> ..anyway, I think we need to cover this, too :) But that's
> different problem now..

OK, for this exact situation to occur (the problem with ADD event I mentioned above), there has to be a record in udev database - udev can automatically removes the nodes/symlinks it has in its records only. So that should not be a problem then.

But when creating DM devices, we have ADD event and CHANGE event afterwards. We suppress the node/symlink creation on ADD events (so there's no udev record for /dev/mapper/ content at all) and then we suppress DM udev rules for CHANGE events with DM_UDEV_DISABLE_DM_RULES_FLAG set (that's exactly the situation with cryptsetup - this flag is set automatically by libdevmapper when the software does not use the udev synchronisation interface at all). It seems to be OK so far - we can avoid the record in udev db and therefore there shouldn't be a place for races to occur.

HOWEVER, there's a new CHANGE event generated in kernel version 2.6.32. This one is generated for block devices that change it's read-only attribute and it has DISK_RO=1 variable set. The problem is that this event does not have that DM_UDEV_DISABLE_DM_RULES_FLAG set because this event is not managed by DM.

So the problematic sequence could be CHANGE event with DISK_RO=1 (and without that DM flag!) and then regular CHANGE event (with that DM flag).

What I mean is is that the event with DISK_RO creates the node in /dev/mapper. Then we have regular change event with DM_UDEV_DISABLE_DM_RULES_FLAG set that should not create the node and skip the rules, of course. But since udev DB knows about the node from the event before and we skip the rules as directed by that disable flag, udevd automatically removes the node.

It's tricky, but this is possible and it needs fixing. I know this has nothing to do with selinux, but could you, please, first try adding this one line into /lib/udev/rules.d/10-dm.rules:

ENV{DISK_RO}=="1", GOTO="dm_disable"

(..add this just after KERNEL!="dm-[0-9]*", GOTO="dm_end" line at the beginning of the file)

This "DISK_RO event" is new and it is not yet covered by the rules we have in upstream. But first I need to know if this one is or is not the cause of the problem we're trying to find here (..if not, we'll continue searching deeper :)).

But for now, this one is the only problem I could imagine with 2.6.32 kernels.


(In reply to comment #15)
> Dec  3 07:22:07 tlondon kernel: device-mapper: ioctl: unable to remove open
device temporary-cryptsetup-14952
> This the same problem?

Well, I don't think so. This is exactly the opposite - something keeps it open and prevents it from being removed, while the thing reported in this bug is about having the node removed prematurely.

Hmm, but these kind of errors should not occur anymore since all the other (foreign) rules that try to touch inappropriate devices somehow should ignore it (and temporary-cryptsetup really is the inappropriate one :)).

For starters, could you please attach the listing of /lib/udev/rules.d and /etc/udev/rules.d directory - just the list of files, so I can see which rules are installed on your system. Do you use original rules from the packages or have you edited some of them or do you use any custom ones?

Thanks.

(In reply to comment #17)
> with the f13 kernel on f13 the password is not ask for until after udev has
> started.  with f13 kernel on f12 the password for /home is requested before we
> pivot root.  

..well, F13 has official device-mapper/lvm2 udev rules installed (and so they are propagated into initramfs for newly created initramfs). So that could change things a little...

When I looked into the dracut I saw that it calls "check_finished" in its main loop. This one should check /initqueue-finished content and return appropriate value. When running dracut, I noticed that the /initqueue-finished contains "block.sh" script that just checks for /dev/root existence [ -e /dev/root ]. This one could cause the main loop to break and cause the dracut to finish.

But when the root is activated before some other devices are activated (just like the encrypted devices), we could probably end without being asked for password (when I added a check for existence of an encrypted device's node into block.sh script as well, I was asked about the password in dracut directly and it worked like in F12). So it's just a matter of timing, I suppose. Dracut just exits too early from its main loop...

Sure:

[root@tlondon udev]# ls -ld /etc/udev/rules.d
drwxr-xr-x. 2 root root 4096 Dec  2 10:25 /etc/udev/rules.d
[root@tlondon udev]# ls -l /etc/udev/rules.d
total 76
-rw-r--r--. 1 root root 6733 Nov 26 07:28 40-hplip.rules
-rw-r--r--. 1 root root  445 Nov 16 22:48 40-multipath.rules
-rw-r--r--. 1 root root  495 Nov 26 07:28 56-hpmud_support.rules
-rw-r--r--. 1 root root 1316 Dec  1 06:42 60-fprint-autosuspend.rules
-rw-r--r--. 1 root root 1060 Aug  6 03:41 60-pcmcia.rules
-rw-r--r--. 1 root root   55 Nov  3 10:32 60-sysprof.rules
-rw-r--r--. 1 root root  292 Nov 23 05:15 70-cups-libusb.rules
-rw-r--r--. 1 root root  599 Jul  2 14:17 70-persistent-cd.rules
-rw-r--r--. 1 root root  557 Jul  2 14:17 70-persistent-net.rules
-rw-r--r--. 1 root root   40 Nov 20 10:40 80-kvm.rules
-rw-r--r--. 1 root root 1914 Nov 19 04:30 85-pcscd_ccid.rules
-rw-r--r--. 1 root root  244 Jul 26 04:39 85-pcscd_egate.rules
-rw-r--r--. 1 root root  320 Sep 18  2008 90-alsa.rules
-rw-r--r--. 1 root root   83 Oct 18 22:53 90-hal.rules
-rw-r--r--. 1 root root   53 Nov 30 17:14 91-drm-modeset.rules
-rw-r--r--. 1 root root   96 Oct  1 18:10 92-video-post.rules
-rw-r--r--. 1 root root 2486 Nov 16 02:01 97-bluetooth-serial.rules
-rw-r--r--. 1 root root   54 Nov 19 11:23 99-fuse.rules
[root@tlondon udev]# 

I don't recall adding/modifying anything here.

A quick check of each of the via "rpm -qif ...." shows '70-persistent-cd.rules' and '70-persistent-net.rules' not owned by any package:

file /etc/udev/rules.d/70-persistent-cd.rules is not owned by any package
file /etc/udev/rules.d/70-persistent-net.rules is not owned by any package

Remove these?

(In reply to comment #21)
> [root@tlondon udev]# ls -ld /etc/udev/rules.d
> drwxr-xr-x. 2 root root 4096 Dec  2 10:25 /etc/udev/rules.d
> [root@tlondon udev]# ls -l /etc/udev/rules.d

..and /lib/udev/rules.d too, please :)
Maybe attach "rpm -q DeviceKit-disks" as well..

> file /etc/udev/rules.d/70-persistent-cd.rules is not owned by any package
> file /etc/udev/rules.d/70-persistent-net.rules is not owned by any package
> 
> Remove these?  

There's no need - these two are harmless with respect to DM.

Oops... Sorry.  Here it is:

[root@tlondon rules.d]# ls -l /lib/udev/rules.d
total 488
-rw-r--r--. 1 root root    421 Oct 27 13:11 10-console.rules
-rw-r--r--. 1 root root   4042 Nov 24 11:16 10-dm.rules
-rw-r--r--. 1 root root   1283 Nov 24 11:16 11-dm-lvm.rules
-rw-r--r--. 1 root root   1011 Nov 24 11:16 13-dm-disk.rules
-rw-r--r--. 1 root root    180 Nov 24 03:30 40-isdn.rules
-rw-r--r--. 1 root root 105286 Oct 23 07:19 40-libgphoto2.rules
-rw-r--r--. 1 root root   1533 Nov 24 03:30 40-redhat.rules
-rw-r--r--. 1 root root    172 Nov 24 03:30 50-firmware.rules
-rw-r--r--. 1 root root   4304 Nov 24 03:30 50-udev-default.rules
-rw-r--r--. 1 root root    249 Nov 24 03:30 60-cdrom_id.rules
-rw-r--r--. 1 root root  60235 Dec  1 09:26 60-libmtp.rules
-rw-r--r--. 1 root root    283 Oct 27 13:11 60-net.rules
-rw-r--r--. 1 root root    676 Nov 24 03:30 60-persistent-alsa.rules
-rw-r--r--. 1 root root   2235 Nov 24 03:30 60-persistent-input.rules
-rw-r--r--. 1 root root    893 Nov 24 03:30 60-persistent-serial.rules
-rw-r--r--. 1 root root   5073 Nov 24 03:30 60-persistent-storage.rules
-rw-r--r--. 1 root root   1450 Nov 24 03:30 60-persistent-storage-tape.rules
-rw-r--r--. 1 root root    789 Nov 24 03:30 60-persistent-v4l.rules
-rw-r--r--. 1 root root    133 Nov 30 11:24 61-gnome-bluetooth-rfkill.rules
-rw-r--r--. 1 root root    610 Nov 24 03:30 61-mobile-action.rules
-rw-r--r--. 1 root root   4301 Nov 24 03:30 61-option-modem-modeswitch.rules
-rw-r--r--. 1 root root    532 Nov 24 03:30 61-persistent-storage-edd.rules
-rw-r--r--. 1 root root    107 Nov 24 03:30 64-device-mapper.rules
-rw-r--r--. 1 root root   1907 Nov 24 03:30 64-md-raid.rules
-rw-r--r--. 1 root root  62210 Oct 22 08:15 65-libsane.rules
-rw-r--r--. 1 root root    350 Mar 20  2009 65-md-incremental.rules
-rw-r--r--. 1 root root   3173 Nov 15 16:08 69-pilot-link.rules
-rw-r--r--. 1 root root   1782 Nov 24 03:30 70-acl.rules
-rw-r--r--. 1 root root   1369 Nov 24 03:30 70-hid2hci.rules
-rw-r--r--. 1 root root    450 Dec  3 09:33 70-printers.rules
-rw-r--r--. 1 root root    462 Nov 24 03:30 75-cd-aliases-generator.rules
-rw-r--r--. 1 root root    658 Nov 24 03:30 75-net-description.rules
-rw-r--r--. 1 root root   3770 Nov 24 03:30 75-persistent-net-generator.rules
-rw-r--r--. 1 root root    658 Nov 24 03:30 75-tty-description.rules
-rw-r--r--. 1 root root   1551 Nov  5 09:43 77-mm-ericsson-mbm.rules
-rw-r--r--. 1 root root   4195 Nov  5 09:43 77-mm-zte-port-types.rules
-rw-r--r--. 1 root root    284 Nov 13 12:05 77-nm-olpc-mesh.rules
-rw-r--r--. 1 root root   4905 Nov 24 03:30 78-sound-card.rules
-rw-r--r--. 1 root root    137 Nov 24 03:30 79-fstab_import.rules
-rw-r--r--. 1 root root    647 Nov 24 03:30 80-drivers.rules
-rw-r--r--. 1 root root    288 Dec  2 13:50 85-regulatory.rules
-rw-r--r--. 1 root root    430 Oct 27 13:11 88-clock.rules
-rw-r--r--. 1 root root   1207 Dec  2 13:22 90-pulseaudio.rules
-rw-r--r--. 1 root root  12380 Sep  1 19:59 90-usb-media-players.rules
-rw-r--r--. 1 root root   6975 Nov  3 13:11 95-devkit-disks.rules
-rw-r--r--. 1 root root   2738 Oct 28 19:48 95-devkit-power-battery-recall-dell.rules
-rw-r--r--. 1 root root   1173 Oct 28 19:48 95-devkit-power-battery-recall-fujitsu.rules
-rw-r--r--. 1 root root    991 Oct 28 19:48 95-devkit-power-battery-recall-gateway.rules
-rw-r--r--. 1 root root   1357 Oct 28 19:48 95-devkit-power-battery-recall-ibm.rules
-rw-r--r--. 1 root root    757 Oct 28 19:48 95-devkit-power-battery-recall-lenovo.rules
-rw-r--r--. 1 root root   1029 Oct 28 19:48 95-devkit-power-battery-recall-toshiba.rules
-rw-r--r--. 1 root root   1552 Oct 28 19:48 95-devkit-power-csr.rules
-rw-r--r--. 1 root root   3029 Oct 28 19:48 95-devkit-power-hid.rules
-rw-r--r--. 1 root root    349 Oct 28 19:48 95-devkit-power-wup.rules
-rw-r--r--. 1 root root    492 Nov 24 11:16 95-dm-notify.rules
-rw-r--r--. 1 root root   7379 Nov 24 03:30 95-keymap.rules
-rw-r--r--. 1 root root    155 Nov 24 03:30 95-udev-late.rules
-rw-r--r--. 1 root root    182 Nov 16 02:01 97-bluetooth.rules
[root@tlondon rules.d]#

Created attachment 376103 [details]
Error popup from entering passphrase

On a fresh reboot to gnome, plugging in the USB hard drive and entering the passphrase to the popup request produces an error:

Error unlocking device: cryptsetup exited with exit code 251: /dev/mapper/temporary-cryptsetup-2533: lsetfilecon failed: No such file or directory
/dev/mapper/temporary-cryptsetup-2533: open failed: No such file or directory
Failed to open temporary keystore device.
Failed to read from key storage.

Here is stuff from /var/log/messages:



Dec  4 07:19:23 tlondon kernel: usb 1-5.3: new high speed USB device using ehci_hcd and address 7
Dec  4 07:19:23 tlondon kernel: usb 1-5.3: New USB device found, idVendor=04b4, idProduct=6830
Dec  4 07:19:23 tlondon kernel: usb 1-5.3: New USB device strings: Mfr=56, Product=78, SerialNumber=100
Dec  4 07:19:23 tlondon kernel: usb 1-5.3: Product: USB2.0 Storage Device
Dec  4 07:19:23 tlondon kernel: usb 1-5.3: Manufacturer: Cypress Semiconductor
Dec  4 07:19:23 tlondon kernel: usb 1-5.3: SerialNumber: DEF107679C83
Dec  4 07:19:23 tlondon kernel: usb 1-5.3: configuration #1 chosen from 1 choice
Dec  4 07:19:23 tlondon kernel: scsi5 : SCSI emulation for USB Mass Storage devices
Dec  4 07:19:23 tlondon kernel: usbcore: registered new interface driver ums-cypress
Dec  4 07:19:30 tlondon kernel: scsi 5:0:0:0: Direct-Access     MAXTOR S TM3320620A            PQ: 0 ANSI: 0
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: [sdc] Write Protect is off
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
Dec  4 07:19:30 tlondon kernel: sdc: sdc1
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
Dec  4 07:19:30 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk
Dec  4 07:19:37 tlondon kernel: usb 1-5.3: reset high speed USB device using ehci_hcd and address 7
Dec  4 07:19:39 tlondon kernel: padlock: VIA PadLock Hash Engine not detected.
Dec  4 07:19:39 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.32-1.fc13.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device
Dec  4 07:19:39 tlondon kernel: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-2486

The 'unable to remove open....' message came before I entered passphrase.

Unfortunately I won't be able to test the "ENV{DISK_RO}=="1", GOTO="dm_disable"" addition until tonight (8 to 12 hours from now). But I will get it tested.

The suggestion from comment #19 (the DISK_RO check) is working for me. I haven't made any of the other suggested modifications to the udev rules, so it looks like this bit is sufficient to fix the problem.

A single test of power cycling encrypted USB hard drive after making the "ENV{DISK_RO}" change also worked for me...

Neither kernel-PAE-2.6.32-1.fc13.i686 nor kernel-PAE-2.6.32-0.65.rc8.git5.fc13.i686 is getting far enough into the boot process to retest this.

(In reply to comment #28)
> Neither ... is getting far enough into the boot
> process to retest this.

So now you can't boot at all, even when you specify selinux=0, like it worked for you before?

(Actually, the change udev event with DISK_RO causes a form of a race, so it's sensitive to timing and that could probably explain why I'm not able to reproduce this.)

On a cold boot with kernel-2.6.32-1.fc13.x86_64, plugging in USB Hard Drive with LUKS encrypted partition after boot up to gnome, the FS gets mounted properly (this is with the above DISK_RO change).

I don't get the usual nautilus window with the root directory however.  Also, the desktop icon for the drive does not show the "unlocked padlock" as was the case previously.

No longer get the "unable to remove message":


Dec  5 07:27:42 tlondon kernel: usb 1-5.3: new high speed USB device using ehci_hcd and address 7
Dec  5 07:27:42 tlondon kernel: usb 1-5.3: New USB device found, idVendor=04b4, idProduct=6830
Dec  5 07:27:42 tlondon kernel: usb 1-5.3: New USB device strings: Mfr=56, Product=78, SerialNumber=100
Dec  5 07:27:42 tlondon kernel: usb 1-5.3: Product: USB2.0 Storage Device
Dec  5 07:27:42 tlondon kernel: usb 1-5.3: Manufacturer: Cypress Semiconductor
Dec  5 07:27:42 tlondon kernel: usb 1-5.3: SerialNumber: DEF107679C83
Dec  5 07:27:42 tlondon kernel: usb 1-5.3: configuration #1 chosen from 1 choice
Dec  5 07:27:42 tlondon kernel: scsi5 : SCSI emulation for USB Mass Storage devices
Dec  5 07:27:42 tlondon kernel: usbcore: registered new interface driver ums-cypress
Dec  5 07:27:49 tlondon kernel: scsi 5:0:0:0: Direct-Access     MAXTOR S TM3320620A            PQ: 0 ANSI: 0
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: Attached scsi generic sg3 type 0
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: [sdc] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: [sdc] Write Protect is off
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
Dec  5 07:27:49 tlondon kernel: sdc: sdc1
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: [sdc] Assuming drive cache: write through
Dec  5 07:27:49 tlondon kernel: sd 5:0:0:0: [sdc] Attached SCSI disk
Dec  5 07:27:56 tlondon kernel: usb 1-5.3: reset high speed USB device using ehci_hcd and address 7
Dec  5 07:27:58 tlondon kernel: padlock: VIA PadLock Hash Engine not detected.
Dec  5 07:27:58 tlondon modprobe: FATAL: Error inserting padlock_sha (/lib/modules/2.6.32-1.fc13.x86_64/kernel/drivers/crypto/padlock-sha.ko): No such device
Dec  5 07:27:59 tlondon kernel: EXT4-fs (dm-2): mounted filesystem with ordered data mode

I don't think the rules change had anything to do with the new issue. I hadn't tried to boot the last few rawhide kernels until there was something new with this issue to test. I don't have any of the 2.6.32 kernels that were getting out of dracut installed any more. I get around to fetching one of them and testing it later.

Using nomodeset and the work around from comment 19 allowed me to get the system booted up with a 2.6.32 kernel.

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

(In reply to comment #30)
> I don't get the usual nautilus window with the root directory however.  Also,
> the desktop icon for the drive does not show the "unlocked padlock" as was the
> case previously.

Hmm, I think that should be reported in the other component... this is out of device-mapper/lvm2.

So I consider this as resolved. The above mentioned fix for the rules is in upstream already and it will be included in next rawhide version (2.02.57).

In rawhide, lvm2-2.02.57-1.fc13.