On a 12.04 system I've been in the process of creating some custom udev rules for removable USB devices. In fact I'm writing a udev rule that calls cryptsetup luksOpen --key-file=/media/uuid/of/my/keyfile/on/usb. The rule actually unlocks an internal spinning disk, and then mounts the disk. I was just about finished creating the udev rule, as it was correctly unlocking the encrypted container and mounting the real ext4 partition as well. The only thing left I had to do was add to the rule options for when the USB device is removed, run umount and luksClose. In between this came udev-175-0ubuntu9.1. I did not think that this would break my work, but it has. My basis for this is that when I call cryptsetup luksOpen from the command line when the latest update to udev is installed the commands work succesully. However, the same commands ran from my udev rule do not work correctly with 75-0ubuntu9.1.
In my syslog I see errors about timeouts, and dozens of temporary-crypt-00253 type entries in /dev/mapper, when there should only be the one entry the udev rule contains. (/dev/mapper/cryptstorage1) Additionally, The machine starts to lockup, and becomes unresponsive. It's an Intel Corei5 with 16GB ram, doing absolutely so heavy lifting, so there is no valid reason for the machine to be unresponsive. Since 175-0ubuntu9.1, I've seen errors about semaphores, and "check if the kernel has support for the aes-xts-plain64 cipher." This is especially infuriating because the root partition is encrypted with the same exact cipher, and the rest of the system works fine until my udev rule is brought into play. I am using kmod aesni_intel, for what it's worth.
To test my thoery, I have manually rolled back to the previous version of udev and libudev0, and then once again my udev rule works correctly again.
