Hi,
On a 12.04 system I've been in the process of creating some custom udev
rules for removable USB devices lately. 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. Anyway, I was just
about finished, as my udev rule 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. Then came udev-175-0ubuntu9.1 (precise-updates) I
did not think that this would break my work, but it seems to have. My basis
for this is that when I call cryptsetup luksOpen from the command line, the
command works successfully, as it did before from my udev rule too. Now,
luksOpen only works correctly from the command line. 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, the udev rule contains.
(/dev/mapper/cryptstorage1) 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 the udev update, 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.

Besides forcing a rollback to udev-175-0ubuntu9 (precise), what else can I
do to verify that this is the latest udev release causing this issue.

Thank you,
Chris
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reply via email to