Bug 451241

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:-(