Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451241 - cryptsetup is 100 times slower then in f8
Summary: cryptsetup is 100 times slower then in f8
Alias: None
Product: Fedora
Classification: Fedora
Component: cryptsetup-luks
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: LVM and device-mapper development team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-13 16:11 UTC by Levente Farkas
Modified: 2008-08-25 15:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-08-25 15:34:16 UTC

Attachments (Terms of Use)
10-local.rules (deleted)
2008-06-16 22:19 UTC, Levente Farkas
no flags Details
home-up (deleted)
2008-06-16 22:25 UTC, Levente Farkas
no flags Details
luks-up (deleted)
2008-06-16 22:26 UTC, Levente Farkas
no flags Details
Bootchart of stalled cryptsetup/udevsettle (deleted)
2008-07-13 08:55 UTC, Martin Blom
no flags Details

Description Levente Farkas 2008-06-13 16:11:44 UTC
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
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
 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:
Actual results:

Expected results:

Additional info:

Comment 1 Till Maas 2008-06-16 21:38:37 UTC
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

Comment 2 Levente Farkas 2008-06-16 22:17:53 UTC
fully updated f9:
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:-(((

Comment 3 Levente Farkas 2008-06-16 22:18:54 UTC
if it's help i can attach the scripts

Comment 4 Levente Farkas 2008-06-16 22:19:53 UTC
Created attachment 309544 [details]

Comment 5 Levente Farkas 2008-06-16 22:25:24 UTC
Created attachment 309546 [details]

Comment 6 Levente Farkas 2008-06-16 22:26:13 UTC
Created attachment 309547 [details]

Comment 7 Till Maas 2008-06-16 22:32:30 UTC
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

Comment 8 Till Maas 2008-06-16 22:57:05 UTC
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. ;-)

Comment 9 Levente Farkas 2008-06-18 10:11:59 UTC
what kind of info needed for you? i see you set the status to "NEEDINFO
requested from" but not requested any kind of info:-(

Comment 10 Till Maas 2008-06-18 10:40:10 UTC
(In reply to comment #9)
> what kind of info needed for you? i see you set the status to "NEEDINFO
> requested from" 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"
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.

Comment 11 Levente Farkas 2008-06-18 13:57:53 UTC
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.

Comment 12 Milan Broz 2008-06-19 15:45:16 UTC
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.

Comment 13 Levente Farkas 2008-06-19 21:21:53 UTC
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:-(

Comment 14 Martin Blom 2008-07-13 08:53:45 UTC
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).

Comment 15 Martin Blom 2008-07-13 08:55:18 UTC
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

Comment 16 Martin Blom 2008-07-21 18:44:56 UTC
No progress on this one?

I've binary patched /lib64/ to execute /bin/true instead
of /sbin/udevsettle and thereby cut my boot time with 6 minutes, but that
doesn't feel quite right ...

Comment 17 Levente Farkas 2008-07-22 08:49:23 UTC
i simple rewrite my rules to workaround this problem since udev and cryptsetup
people thing the current behavior is right:-(

Note You need to log in before you can comment on or make changes to this bug.