Description of problem: my home directory is a luks encrypted volume. the key for this volume is on my pendrive. before i'd like to login i just plug my pendrive and it then: - udev recognize my pendrive - mount one of the partition on it (which hold the keyfile) - use the keyfile on the mounted partition and open the luks partirion - mount the device mapper as my home - umount my pendrive this was works perfectly on fedora 8 and takes about 2-4sec to my home dir be mounted. now on fedora 9 it's still works, but it takes about 3-4 minutes (!!!) to finish. when i look into what happened: - udev recognize my pendrive - mount one of the partition on it (which hold the keyfile) - use the keyfile on the mounted partition and open the luks partirion and here waits for minutes in this place what is see in ps axf: 522 ? S<s 0:00 /sbin/udevd -d 2523 ? S< 0:00 \_ /sbin/udevd -d 2536 ? S< 0:00 \_ /bin/bash /root/bin/home-up /dev/System/lfarkas 2553 ? S< 0:00 \_ /bin/bash /root/bin/luks-up /dev/System/lfarkas 2569 ? S<L 0:00 \_ /sbin/cryptsetup luksOpen /dev/System/lfarkas home-lfarkas 2718 ? S< 0:00 \_ /sbin/udevsettle i assume udevsettle what for something, but i don't know for what? and why? whould you like to see all of my scripts? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Can you please run cryptsetup luksOpen manually and report whether it also takes that long? Also, please remove the lines from the bug report template that you do not use in future bug reports, otherwise half of my screen is filled with useless space. Please also always report the version-release number, i.e. here the output of rpm --qf '%{name}-%{version}-%{release}\n' -q cryptsetup-luks udev
fully updated f9: cryptsetup-luks-1.0.6-2.fc9 udev-120-5.20080421git.fc9 and when i run it manually it doesn't takes so long... so it seems there are some 'interference' between the event i plugin my pendrive and luksOpen's call of udevsettle. the most annoying thing that it was working in f7 and f8 like a charm:-(((
if it's help i can attach the scripts
Created attachment 309544 [details] 10-local.rules
Created attachment 309546 [details] home-up
Created attachment 309547 [details] luks-up
I am pretty sure that the bug here is that udevsettle waits for cryptsetup to complete its task and therefore it waits 180 seconds, which is the default timeout. And cryptsetup waits for udevsettle, so there is a typical deadlock. I just read on the upstream mailing list, that calling udevsettle was introduced into cryptsetup recently, therefore this did not happen in earlier releases of Fedora.
Maybe it helps when you run the home-up script with nohup in the udev rule, i.e. change RUN+="/root/bin/home-up /dev/System/lfarkas" but this may be a stupid idea. ;-)
what kind of info needed for you? i see you set the status to "NEEDINFO requested from lfarkas" but not requested any kind of info:-(
(In reply to comment #9) > what kind of info needed for you? i see you set the status to "NEEDINFO > requested from lfarkas" but not requested any kind of info:-( Please try nohup in your udev rule: RUN+="/usr/bin/nohup /root/bin/home-up /dev/System/lfarkas" or RUN+="/root/bin/home-up /dev/System/lfarkas&" or in case this does not work, create a wrapper script that runs home-up in the background (with & attached). But I am not sure whether or not this will break something, because I am not an expert in writing udev rules.
imho it's not a solution. it's a deadlock which shouldn't have to happend. anyway nohup don't put the process in the background:-) and & not working in RUN. of course i can workaround this in my scripts (as i already did it), but this should have to be solved in an other way.
In upstream cryptsetup svn is patch which decrease udev settle timeout, maybe for short term fix it is enough. Anyway, I think that calling udevsettle directly from cryptsetup is not good idea. Better is somehow tell udev to not touch "temporary-cryptsetup-*" mapper devices, then udevsettle call is not needed IHMO.
does this means next cryptsetup on fedora won't call udevsettle? and where did you find cryptsetup svn??? anyway in my case any kind of short timeout is too long:-(
I think I have the same problem, only my encrypted partition is actually a HD partition one which I have local user's home directories. On bootup, I'm asked for password for /dev/sda8. Once entered, it takes serveral minutes until the "unlocked" message appears, and the again serveral minutes until the boot process proceeds! Meaning, my laptop takes 410 seconds to boot. :-( In F8, everything worked perfectly. This is a fresh F9 install (since upgrading F8->F9 messed up the system badly).
Created attachment 311659 [details] Bootchart of stalled cryptsetup/udevsettle Here is my boot sequence in F9. I entered the password as soon as the prompt appeared.
No progress on this one? I've binary patched /lib64/libcryptsetup.so.0.0.0 to execute /bin/true instead of /sbin/udevsettle and thereby cut my boot time with 6 minutes, but that doesn't feel quite right ...
i simple rewrite my rules to workaround this problem since udev and cryptsetup people thing the current behavior is right:-(