Debian Bug report logs - #488271
cryptsetup: use a loop to wait for the root device

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: James Westby <jw+debian@jameswestby.net>

To: submit@bugs.debian.org

Subject: cryptsetup: use a loop to wait for the root device

Date: Fri, 27 Jun 2008 14:31:50 +0100

[Message part 1 (text/plain, inline)]

Package: cryptsetup
Version: 2:1.0.6-2
Severity: wishlist
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu intrepid ubuntu-patch

Hi,

In

  https://launchpad.net/bugs/164044

a user said that he was unable to boot with the root device
being a slow USB device, as the udevsettle call was only
sufficient if the kernel was currently processing an event
which would cause the device to appear. If the event is so slow
that the udevsettle call is made prior to it's arrival
the boot will fail.

The attached patch is used in Ubuntu to implement a sleeping
loop waiting for the device to appear, as is done for a
normal root device. Please consider applying the patch.

Thanks,

James

diff -pruN 2:1.0.6-2/debian/initramfs/cryptroot-script
2:1.0.6-2ubuntu7/debian/initramfs/cryptroot-script
--- 2:1.0.6-2/debian/initramfs/cryptroot-script	2008-06-20 22:19:57.000000000 +0100
+++ 2:1.0.6-2ubuntu7/debian/initramfs/cryptroot-script	2008-06-20 22:16:41.000000000 +0100
@@ -193,13 +193,49 @@ setup_mapping()
 		activate_evms $cryptsource
 	fi
 
-	udev_settle
+	# If the encrypted source device hasn't shown up yet, give it a
+	# little while to deal with removable devices
 
-	if [ ! -e $cryptsource ]; then
-		message "cryptsetup: source device $cryptsource not found"
-		return 1
+	# the following lines below have been taken from
+	# /usr/share/initramfs-tools/scripts/local, as suggested per
+	# https://launchpad.net/bugs/164044
+	if [ ! -e "$cryptsource" ] || ! /lib/udev/vol_id "$cryptsource" >/dev/null 2>&1; then
+		log_begin_msg "Waiting for encrypted source device..."
+
+		# Default delay is 180s
+		if [ -z "${ROOTDELAY}" ]; then
+			slumber=180
+		else
+			slumber=${ROOTDELAY}
+		fi
+		if [ -x /sbin/usplash_write ]; then
+			/sbin/usplash_write "TIMEOUT ${slumber}" || true
+		fi
+
+		slumber=$(( ${slumber} * 10 ))
+		while [ ! -e "$cryptsource" ] || ! /lib/udev/vol_id "$cryptsource" >/dev/null 2>&1; do
+			/bin/sleep 0.1
+			slumber=$(( ${slumber} - 1 ))
+			[ ${slumber} -gt 0 ] || break
+		done
+
+		if [ ${slumber} -gt 0 ]; then
+			log_end_msg 0
+		else
+			log_end_msg 1 || true
+		fi
+		if [ -x /sbin/usplash_write ]; then
+			/sbin/usplash_write "TIMEOUT 15" || true
+		fi
 	fi
 
+	# We've given up, but we'll let the user fix matters if they can
+	while [ ! -e "${cryptsource}" ]; do
+		echo "	Check cryptopts=source= bootarg cat /proc/cmdline"
+		echo "	or missing modules, devices: cat /proc/modules ls /dev"
+		panic -r "ALERT!  ${cryptsource} does not exist.  Dropping to a shell!"
+	done
+
 	# Prepare commands
 	if /sbin/cryptsetup isLuks $cryptsource > /dev/null 2>&1; then
 		cryptcreate="/sbin/cryptsetup -T 1 luksOpen $cryptsource $crypttarget"
@@ -275,6 +311,8 @@ setup_mapping()
 # Begin real processing
 #
 
+. ./scripts/functions
+
 # Do we have any kernel boot arguments?
 found=''
 for opt in $(cat /proc/cmdline); do

[cryptsetup-wait-loop.diff (text/x-patch, attachment)]

Message #10 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: James Westby <jw+debian@jameswestby.net>

Cc: 488271@bugs.debian.org

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Sun, 29 Jun 2008 23:42:08 +0200

On Fri, Jun 27, 2008 at 02:31:50PM +0100, James Westby wrote:
>  https://launchpad.net/bugs/164044
>
>a user said that he was unable to boot with the root device
>being a slow USB device, as the udevsettle call was only
>sufficient if the kernel was currently processing an event
>which would cause the device to appear. If the event is so slow
>that the udevsettle call is made prior to it's arrival
>the boot will fail.
>
>The attached patch is used in Ubuntu to implement a sleeping
>loop waiting for the device to appear, as is done for a
>normal root device. Please consider applying the patch.

initramfs-tools already has a rootdelay parameter which is executed 
before the cryptsetup initramfs script. What is the advantage of 
duplicating that functionality?

-- 
David Härdeman

Message #15 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@tauware.de>

To: David Härdeman <david@hardeman.nu>

Cc: James Westby <jw+debian@jameswestby.net>, 488271@bugs.debian.org

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 01 Jul 2008 17:46:15 +0200

David Härdeman <david@hardeman.nu> writes:

> On Fri, Jun 27, 2008 at 02:31:50PM +0100, James Westby wrote:
>>  https://launchpad.net/bugs/164044
>>
>>a user said that he was unable to boot with the root device
>>being a slow USB device, as the udevsettle call was only
>>sufficient if the kernel was currently processing an event
>>which would cause the device to appear. If the event is so slow
>>that the udevsettle call is made prior to it's arrival
>>the boot will fail.
>>
>>The attached patch is used in Ubuntu to implement a sleeping
>>loop waiting for the device to appear, as is done for a
>>normal root device. Please consider applying the patch.
>
> initramfs-tools already has a rootdelay parameter which is executed
> before the cryptsetup initramfs script. What is the advantage of
> duplicating that functionality?

the rootdelay parameter makes the initramfs loop until the root device
appears. It does not help the cryptsetup hook in any way. If the control
flow reaches the point the patch adds the loop and the device holding
the crypted volume it will silently fail and pass control to the
initramfs, which itself fails after 5 minutes (by default). This usually
happens with slow devices like usb sticks, according to bug reports in
launchpad.

I agree that it would be nice if we could re-use the functionality from
initramfs-tools. However it is not written in a reusable way.

Do you see a better way solving the problem? 

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Message #20 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Reinhard Tartler <siretart@tauware.de>, 488271@bugs.debian.org

Cc: James Westby <jw+debian@jameswestby.net>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 1 Jul 2008 20:11:37 +0200

On Tue, Jul 01, 2008 at 05:46:15PM +0200, Reinhard Tartler wrote:
>David Härdeman <david@hardeman.nu> writes:
>
>> On Fri, Jun 27, 2008 at 02:31:50PM +0100, James Westby wrote:
>>>  https://launchpad.net/bugs/164044
>>>
>>>a user said that he was unable to boot with the root device
>>>being a slow USB device, as the udevsettle call was only
>>>sufficient if the kernel was currently processing an event
>>>which would cause the device to appear. If the event is so slow
>>>that the udevsettle call is made prior to it's arrival
>>>the boot will fail.
>>>
>>>The attached patch is used in Ubuntu to implement a sleeping
>>>loop waiting for the device to appear, as is done for a
>>>normal root device. Please consider applying the patch.
>>
>> initramfs-tools already has a rootdelay parameter which is executed
>> before the cryptsetup initramfs script. What is the advantage of
>> duplicating that functionality?
>
>the rootdelay parameter makes the initramfs loop until the root device
>appears. It does not help the cryptsetup hook in any way.

Well, unless my memory serves me wrong, it does....with a rootdelay=5, 
initramfs-tools will sleep 5 secs extra before cryptsetup gets a chance 
of executing which might be enough for the USB device to show up.

>If the control
>flow reaches the point the patch adds the loop and the device holding
>the crypted volume it will silently fail and pass control to the
>initramfs, which itself fails after 5 minutes (by default). This usually
>happens with slow devices like usb sticks, according to bug reports in
>launchpad.
>
>I agree that it would be nice if we could re-use the functionality from
>initramfs-tools. However it is not written in a reusable way.
>
>Do you see a better way solving the problem? 

Yes, teach initramfs-tools to take a path as an argument to rootdelay 
and make it wait until that path appears.

-- 
David Härdeman

Message #25 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@tauware.de>

To: David Härdeman <david@hardeman.nu>

Cc: 488271@bugs.debian.org, James Westby <jw+debian@jameswestby.net>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 01 Jul 2008 20:28:52 +0200

David Härdeman <david@hardeman.nu> writes:

>>> initramfs-tools already has a rootdelay parameter which is executed
>>> before the cryptsetup initramfs script. What is the advantage of
>>> duplicating that functionality?
>>
>>the rootdelay parameter makes the initramfs loop until the root device
>>appears. It does not help the cryptsetup hook in any way.
>
> Well, unless my memory serves me wrong, it does....with a rootdelay=5,
> initramfs-tools will sleep 5 secs extra before cryptsetup gets a chance
> of executing which might be enough for the USB device to show up.

Looking at the code:

mountroot ()
{
        [ "$quiet" != "y" ] && log_begin_msg "Running
        /scripts/local-top"
        run_scripts /scripts/local-top
        [ "$quiet" != "y" ] && log_end_msg

        # If the root device hasn't shown up yet, give it a little while
        # to deal with removable devices
        if [ ! -e "${ROOT}" ] || ! /lib/udev/vol_id "${ROOT}" >/dev/null
        # 2>&1; then
                log_begin_msg "Waiting for root file system..."

                # Default delay is 180s
                if [ -z "${ROOTDELAY}" ]; then
                        slumber=180
                else
                        slumber=${ROOTDELAY}
                fi
                if [ -x /sbin/usplash_write ]; then
                        /sbin/usplash_write "TIMEOUT ${slumber}" || true
                fi

                slumber=$(( ${slumber} * 10 ))
                while [ ! -e "${ROOT}" ] || ! /lib/udev/vol_id "${ROOT}"
                >/dev/null 2>&1; do
                        /bin/sleep 0.1
                        slumber=$(( ${slumber} - 1 ))
                        [ ${slumber} -gt 0 ] || break
                done

                if [ ${slumber} -gt 0 ]; then
                        log_end_msg 0
                else
                        log_end_msg 1 || true
                fi
                if [ -x /sbin/usplash_write ]; then
                        /sbin/usplash_write "TIMEOUT 15" || true
                fi
        fi
[...]

I fear your memory indeed does serve you wrong :(


>>If the control flow reaches the point the patch adds the loop and the
>>device holding the crypted volume it will silently fail and pass
>>control to the initramfs, which itself fails after 5 minutes (by
>>default). This usually happens with slow devices like usb sticks,
>>according to bug reports in launchpad.
>>
>>I agree that it would be nice if we could re-use the functionality from
>>initramfs-tools. However it is not written in a reusable way.
>>
>> Do you see a better way solving the problem? 
>
> Yes, teach initramfs-tools to take a path as an argument to rootdelay
> and make it wait until that path appears.

If you can make the initramfs-tools maintainer refactor the code I cited
above as a function and usable for cryptsetup, I'd agree with you.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Message #30 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Reinhard Tartler <siretart@tauware.de>, 488271@bugs.debian.org

Cc: James Westby <jw+debian@jameswestby.net>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: Bug#488271: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 1 Jul 2008 21:02:30 +0200

On Tue, Jul 01, 2008 at 08:28:52PM +0200, Reinhard Tartler wrote:
>David Härdeman <david@hardeman.nu> writes:
>
>>>> initramfs-tools already has a rootdelay parameter which is executed
>>>> before the cryptsetup initramfs script. What is the advantage of
>>>> duplicating that functionality?
>>>
>>>the rootdelay parameter makes the initramfs loop until the root device
>>>appears. It does not help the cryptsetup hook in any way.
>>
>> Well, unless my memory serves me wrong, it does....with a rootdelay=5,
>> initramfs-tools will sleep 5 secs extra before cryptsetup gets a chance
>> of executing which might be enough for the USB device to show up.
>
>Looking at the code:
...
>I fear your memory indeed does serve you wrong :(

I think you missed /usr/share/initramfs-tools/scripts/init-premount/udev

>>> Do you see a better way solving the problem? 
>>
>> Yes, teach initramfs-tools to take a path as an argument to rootdelay
>> and make it wait until that path appears.
>
>If you can make the initramfs-tools maintainer refactor the code I cited
>above as a function and usable for cryptsetup, I'd agree with you.

I don't think a rootdelay in cryptsetup is very satisfactory. There are 
already two rootdelays, one before the cryptsetup script and one after 
it. Adding a third will help in a quite limited way:

a) Assume crypto-usb-stick takes 10 seconds to show up

b) root= will be set to something which udev won't find

c) rootdelay= is set

Situation A - rootdelay < 10 secs

	udev times out, cryptsetup fails

Situation B - rootdelay > 10 secs

	udev times out, cryptsetup works

d) With an additional rootdelay in cryptsetup

Situation C - rootdelay < 5 secs

	udev + cryptsetup times out, cryptsetup fails

Situation D - rootdelay > 5 secs, rootdelay < 10 secs

	udev times out, cryptsetup waits minimum time, cryptsetup works

Situation E - rootdelay > 10 secs

	udev times out, cryptsetup works


So you see..the patch saves a few seconds max...and the user still has 
to pick an optimal rootdelay time...

-- 
David Härdeman

Message #35 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@tauware.de>

To: David Härdeman <david@hardeman.nu>

Cc: 488271@bugs.debian.org, James Westby <jw+debian@jameswestby.net>, scott@ubuntu.com

Subject: Re: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 01 Jul 2008 22:03:23 +0200

David Härdeman <david@hardeman.nu> writes:

> On Tue, Jul 01, 2008 at 08:28:52PM +0200, Reinhard Tartler wrote:
>>David Härdeman <david@hardeman.nu> writes:
>>
>>>>> initramfs-tools already has a rootdelay parameter which is executed
>>>>> before the cryptsetup initramfs script. What is the advantage of
>>>>> duplicating that functionality?
>>>>
>>>>the rootdelay parameter makes the initramfs loop until the root device
>>>>appears. It does not help the cryptsetup hook in any way.
>>>
>>> Well, unless my memory serves me wrong, it does....with a rootdelay=5,
>>> initramfs-tools will sleep 5 secs extra before cryptsetup gets a chance
>>> of executing which might be enough for the USB device to show up.
>>
>>Looking at the code:
> ...
>>I fear your memory indeed does serve you wrong :(
>
> I think you missed /usr/share/initramfs-tools/scripts/init-premount/udev

Oh, I needed to do some investiagtions about that file, it has been
submitted by you as #414842. However, that particular patch has not been
applied to ubuntu's udev.

Scott, can you have a look at this patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842

Is that acceptable for ubuntu?

>>>> Do you see a better way solving the problem? 
>>>
>>> Yes, teach initramfs-tools to take a path as an argument to rootdelay
>>> and make it wait until that path appears.
>>
>>If you can make the initramfs-tools maintainer refactor the code I cited
>>above as a function and usable for cryptsetup, I'd agree with you.
>
> I don't think a rootdelay in cryptsetup is very satisfactory. There are
> already two rootdelays, one before the cryptsetup script and one after
> it. Adding a third will help in a quite limited way:

(in ubuntu the one before does not exist)

> a) Assume crypto-usb-stick takes 10 seconds to show up

Can you be sure that it needs 'only' 10 seconds? Perhaps there are even
slower devices out there?

okay, you use 10 seconds as example, let's see

> b) root= will be set to something which udev won't find
>
> c) rootdelay= is set
>
> Situation A - rootdelay < 10 secs
>
> 	udev times out, cryptsetup fails
>
> Situation B - rootdelay > 10 secs
>
> 	udev times out, cryptsetup works

So in both situations the system fails to boot.

> d) With an additional rootdelay in cryptsetup
>
> Situation C - rootdelay < 5 secs
> 
> 	udev + cryptsetup times out, cryptsetup fails
>
> Situation D - rootdelay > 5 secs, rootdelay < 10 secs
>
> 	udev times out, cryptsetup waits minimum time, cryptsetup works
>
> Situation E - rootdelay > 10 secs
>
> 	udev times out, cryptsetup works
>
>
> So you see..the patch saves a few seconds max...and the user still has
> to pick an optimal rootdelay time...

well, thats the purpose of the "3rd" (2nd in ubuntu) delay: the user
doesn't need to specify magic boot parameters but make it 'just
work'. At least on some more machines.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Message #40 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Scott James Remnant <scott@ubuntu.com>

To: Reinhard Tartler <siretart@tauware.de>

Cc: David Härdeman <david@hardeman.nu>, 488271@bugs.debian.org, James Westby <jw+debian@jameswestby.net>

Subject: Re: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 01 Jul 2008 21:09:19 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2008-07-01 at 22:03 +0200, Reinhard Tartler wrote:

> Oh, I needed to do some investiagtions about that file, it has been
> submitted by you as #414842. However, that particular patch has not been
> applied to ubuntu's udev.
> 
> Scott, can you have a look at this patch:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842
> 
> Is that acceptable for ubuntu?
> 
No.

We already have a loop in mountroot() to deal with this problem, it
waits until the root device is actually available before proceeeding.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Scott James Remnant <scott@ubuntu.com>, 488271@bugs.debian.org

Cc: Reinhard Tartler <siretart@tauware.de>, James Westby <jw+debian@jameswestby.net>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 1 Jul 2008 23:11:26 +0200

On Tue, Jul 01, 2008 at 09:09:19PM +0100, Scott James Remnant wrote:
>On Tue, 2008-07-01 at 22:03 +0200, Reinhard Tartler wrote:
>> Oh, I needed to do some investiagtions about that file, it has been
>> submitted by you as #414842. However, that particular patch has not been
>> applied to ubuntu's udev.
>> 
>> Scott, can you have a look at this patch:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842
>> 
>> Is that acceptable for ubuntu?
>> 
>No.
>
>We already have a loop in mountroot() to deal with this problem, it
>waits until the root device is actually available before proceeeding.

Which is after all initramfs scripts have already had their chance of 
executing.

-- 
David Härdeman

Message #50 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Reinhard Tartler <siretart@tauware.de>

Cc: 488271@bugs.debian.org, James Westby <jw+debian@jameswestby.net>, scott@ubuntu.com

Subject: Re: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 1 Jul 2008 23:21:04 +0200

On Tue, Jul 01, 2008 at 10:03:23PM +0200, Reinhard Tartler wrote:
>David Härdeman <david@hardeman.nu> writes:
>> On Tue, Jul 01, 2008 at 08:28:52PM +0200, Reinhard Tartler wrote:
>>>David Härdeman <david@hardeman.nu> writes:
>> I think you missed /usr/share/initramfs-tools/scripts/init-premount/udev
>
>Oh, I needed to do some investiagtions about that file, it has been
>submitted by you as #414842. However, that particular patch has not been
>applied to ubuntu's udev.
>
>Scott, can you have a look at this patch:
>http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842
>
>Is that acceptable for ubuntu?
>
>>>>> Do you see a better way solving the problem? 
>>>>
>>>> Yes, teach initramfs-tools to take a path as an argument to rootdelay
>>>> and make it wait until that path appears.
>>>
>>>If you can make the initramfs-tools maintainer refactor the code I cited
>>>above as a function and usable for cryptsetup, I'd agree with you.
>>
>> I don't think a rootdelay in cryptsetup is very satisfactory. There are
>> already two rootdelays, one before the cryptsetup script and one after
>> it. Adding a third will help in a quite limited way:
>
>(in ubuntu the one before does not exist)
>
>> a) Assume crypto-usb-stick takes 10 seconds to show up
>
>Can you be sure that it needs 'only' 10 seconds? Perhaps there are even
>slower devices out there?
>
>okay, you use 10 seconds as example, let's see
>
>> b) root= will be set to something which udev won't find
>>
>> c) rootdelay= is set
>>
>> Situation A - rootdelay < 10 secs
>>
>> 	udev times out, cryptsetup fails
>>
>> Situation B - rootdelay > 10 secs
>>
>> 	udev times out, cryptsetup works
>
>So in both situations the system fails to boot.

No, in situation B the system boots...udev times out after > 10 seconds 
which means the device has appeared when the cryptsetup script runs 
(after udev).

I actually suggested a completely different approach at one time to the 
udev maintainer...to let udev run a number of scripts for each new 
blockdev that appeared in the system until the rootdevice shows up 
(which would have the advantage of auto-executing cryptsetup's initramfs 
script on demand). But it was refused :)

>> d) With an additional rootdelay in cryptsetup
>>
>> Situation C - rootdelay < 5 secs
>> 
>> 	udev + cryptsetup times out, cryptsetup fails
>>
>> Situation D - rootdelay > 5 secs, rootdelay < 10 secs
>>
>> 	udev times out, cryptsetup waits minimum time, cryptsetup works
>>
>> Situation E - rootdelay > 10 secs
>>
>> 	udev times out, cryptsetup works
>>
>>
>> So you see..the patch saves a few seconds max...and the user still has
>> to pick an optimal rootdelay time...
>
>well, thats the purpose of the "3rd" (2nd in ubuntu) delay: the user
>doesn't need to specify magic boot parameters but make it 'just
>work'. At least on some more machines.

If a rootdelay= parameter is set it will behave exactly as I described 
above. The advantage of the patch is the magic delay if *no* rootdelay 
parameter is set...which will give a 3 minute additional boot time if 
e.g. the swap device is not available.

I'm not convinced, but if you want to go down this path I'd suggest a 
patch to initramfs-tools first which adds a delay() function, 
preferrably one that takes two arguments (a device and a timeout). Then 
initramfs-tools, cryptsetup and udev could use it.

Oh, also note that the current patch appears racy...you set the usplash 
timeout to e.g. 180 secs then run 1800 loop iterations in the cryptsetup 
script with a 0.1 sec sleep in each. If you get close to those 1800 
iterations it seems likely that you'll have spent more than 180 secs in 
cryptsetup (quite minor nitpick though considering that anything that 
happends close to the 180 sec mark is quite unlikely to be sane).

-- 
David Härdeman

Message #55 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Scott James Remnant <scott@ubuntu.com>

To: David Härdeman <david@hardeman.nu>

Cc: 488271@bugs.debian.org, Reinhard Tartler <siretart@tauware.de>, James Westby <jw+debian@jameswestby.net>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 01 Jul 2008 22:25:50 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2008-07-01 at 23:11 +0200, David Härdeman wrote:

> On Tue, Jul 01, 2008 at 09:09:19PM +0100, Scott James Remnant wrote:
> >On Tue, 2008-07-01 at 22:03 +0200, Reinhard Tartler wrote:
> >> Oh, I needed to do some investiagtions about that file, it has been
> >> submitted by you as #414842. However, that particular patch has not been
> >> applied to ubuntu's udev.
> >> 
> >> Scott, can you have a look at this patch:
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842
> >> 
> >> Is that acceptable for ubuntu?
> >> 
> >No.
> >
> >We already have a loop in mountroot() to deal with this problem, it
> >waits until the root device is actually available before proceeeding.
> 
> Which is after all initramfs scripts have already had their chance of 
> executing.
> 
No initramfs script should use the root device before it has been
mounted.

If you want to modify or create root devices, it should be done with a
udev rule.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: Scott James Remnant <scott@ubuntu.com>, 488271@bugs.debian.org

Cc: James Westby <jw+debian@jameswestby.net>, Reinhard Tartler <siretart@tauware.de>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 1 Jul 2008 23:44:10 +0200

On Tue, Jul 01, 2008 at 10:25:50PM +0100, Scott James Remnant wrote:
>On Tue, 2008-07-01 at 23:11 +0200, David Härdeman wrote:
>> On Tue, Jul 01, 2008 at 09:09:19PM +0100, Scott James Remnant wrote:
>> >We already have a loop in mountroot() to deal with this problem, it
>> >waits until the root device is actually available before proceeeding.
>> 
>> Which is after all initramfs scripts have already had their chance of 
>> executing.
>> 
>No initramfs script should use the root device before it has been
>mounted.
>
>If you want to modify or create root devices, it should be done with a
>udev rule.

Ummm, are we still talking about the same thing? cryptsetup creates the 
root device in an initramfs script...of course it won't use any root 
devices...

-- 
David Härdeman

Message #65 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Scott James Remnant <scott@ubuntu.com>

To: David Härdeman <david@hardeman.nu>

Cc: 488271@bugs.debian.org, James Westby <jw+debian@jameswestby.net>, Reinhard Tartler <siretart@tauware.de>

Subject: Re: [Pkg-cryptsetup-devel] Bug#488271: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Tue, 01 Jul 2008 23:33:14 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2008-07-01 at 23:44 +0200, David Härdeman wrote:

> On Tue, Jul 01, 2008 at 10:25:50PM +0100, Scott James Remnant wrote:
> >On Tue, 2008-07-01 at 23:11 +0200, David Härdeman wrote:
> >> On Tue, Jul 01, 2008 at 09:09:19PM +0100, Scott James Remnant wrote:
> >> >We already have a loop in mountroot() to deal with this problem, it
> >> >waits until the root device is actually available before proceeeding.
> >> 
> >> Which is after all initramfs scripts have already had their chance of 
> >> executing.
> >> 
> >No initramfs script should use the root device before it has been
> >mounted.
> >
> >If you want to modify or create root devices, it should be done with a
> >udev rule.
> 
> Ummm, are we still talking about the same thing? cryptsetup creates the 
> root device in an initramfs script...of course it won't use any root 
> devices...
> 
What does it create it from?

If it creates it from block devices, it should be written as a script
called by a udev rule, not as an initramfs script.

See mdadm, lvm, etc. for comparison -- in Ubuntu, those are called from
udev, when the underlying block device is actually ready.

cryptsetup should behave in the same way; when a block device is ready
for use, it should be called by a udev rule and make the devmapper
device -- that will release the loop in mountroot() and allow the
initramfs to exit.

This is one of a number of major differences between Ubuntu and Debian.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[signature.asc (application/pgp-signature, inline)]

Message #70 received at 488271@bugs.debian.org (full text, mbox, reply):

From: David Härdeman <david@hardeman.nu>

To: "Scott James Remnant" <scott@ubuntu.com>, 488271@bugs.debian.org

Cc: "James Westby" <jw+debian@jameswestby.net>, "Reinhard Tartler" <siretart@tauware.de>

Subject: Re: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Wed, 2 Jul 2008 09:35:43 +0200 (CEST)

On Wed, July 2, 2008 00:33, Scott James Remnant wrote:
> On Tue, 2008-07-01 at 23:44 +0200, David Härdeman wrote:
>> On Tue, Jul 01, 2008 at 10:25:50PM +0100, Scott James Remnant wrote:
>>> If you want to modify or create root devices, it should be done with a
>>> udev rule.
>>
>> Ummm, are we still talking about the same thing? cryptsetup creates the
>> root device in an initramfs script...of course it won't use any root
>> devices...
...
> If it creates it from block devices, it should be written as a script
> called by a udev rule, not as an initramfs script.

We're discussing in the context of Debian bug #488271 right now. That is,
the discussion is whether we need a proposed rootdelay patch in Debian's
version of cryptsetup or not...

> See mdadm, lvm, etc. for comparison -- in Ubuntu, those are called from
> udev, when the underlying block device is actually ready.
>
> cryptsetup should behave in the same way; when a block device is ready
> for use, it should be called by a udev rule and make the devmapper
> device -- that will release the loop in mountroot() and allow the
> initramfs to exit.

I completely agree with this approach. In fact I proposed it to Marco
d'Itri (Debian's udev maintainer) in April 2007 and pushed a testing
branch to the initramfs-tools git repo at about the same time.
Unfortunately it was rejected by the udev maintainer. I should probably
raise that proposal again when I have time...

Anyway, we're going offtopic.

-- 
David Härdeman

Message #75 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Markus Mandalka <debian@mandalka.name>

To: 488271@bugs.debian.org

Subject: Re: Bug#488271: cryptsetup: use a loop to wait for the root device

Date: Sun, 21 Sep 2008 23:19:18 +0200

I needed a solution for a live-system-setup that has to boot from
dm-crypt/luks-encrypted usb-devices (more about the live-system at
http://mandalka.name/privatix/ ...), so i copied some code into a quick
and dirty workarround-script which i use for my live-system-setups until
after the discussion and development there will be a solution in the
cryptsetup-package or/and initrd-package.

Maybe it can help some people getting here using a searchengine and
reading this thread because they need a solution before this issue will
be solved:

Because cryptroot waits until all other scripts in
initramfs/scripts/local-top/ are finished, this workarround needs no
patches. It has to be copied into the ramdisk (copy
http://mandalka.name/privatix/source/cryptrootwait to
/usr/share/initramfs-tools/scripts/local-top/, make it executable (chmod
+x cryptrootwait) and start update-initramfs or mkinitramfs to get it
into the initramdisk).

This workarround works in a "standard usb-cryptroot-setup" like my or
for example configurations made by the debian-installer if you choose
the guided encryption-setup there, but it won't help if your setup needs
the activate_evms() or activate_vg() - functions in
scripts/local-top/cryptroot !

Message #80 received at 488271@bugs.debian.org (full text, mbox, reply):

From: Kees Cook <kees@debian.org>

To: 488271@bugs.debian.org

Subject: updated patch

Date: Sun, 10 May 2009 17:22:19 -0700

[Message part 1 (text/plain, inline)]

Hello,

While I realize the method for solving the problem hasn't been fully
identified, I just wanted to provide an updated patch for cryptsource
delay that is being used in Ubuntu...

-Kees

-- 
Kees Cook                                            @debian.org

[cryptsource-wait.patch (text/x-diff, attachment)]

Message #87 received at 488271-close@bugs.debian.org (full text, mbox, reply):

From: Jonas Meurer <mejo@debian.org>

To: 488271-close@bugs.debian.org

Subject: Bug#488271: fixed in cryptsetup 2:1.0.7-1

Date: Thu, 30 Jul 2009 17:02:04 +0000

Source: cryptsetup
Source-Version: 2:1.0.7-1

We believe that the bug you reported is fixed in the latest version of
cryptsetup, which is due to be installed in the Debian FTP archive:

cryptsetup-udeb_1.0.7-1_amd64.udeb
  to pool/main/c/cryptsetup/cryptsetup-udeb_1.0.7-1_amd64.udeb
cryptsetup_1.0.7-1.diff.gz
  to pool/main/c/cryptsetup/cryptsetup_1.0.7-1.diff.gz
cryptsetup_1.0.7-1.dsc
  to pool/main/c/cryptsetup/cryptsetup_1.0.7-1.dsc
cryptsetup_1.0.7-1_amd64.deb
  to pool/main/c/cryptsetup/cryptsetup_1.0.7-1_amd64.deb
cryptsetup_1.0.7.orig.tar.gz
  to pool/main/c/cryptsetup/cryptsetup_1.0.7.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 488271@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Meurer <mejo@debian.org> (supplier of updated cryptsetup package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 30 Jul 2009 17:41:16 +0200
Source: cryptsetup
Binary: cryptsetup cryptsetup-udeb
Architecture: source amd64
Version: 2:1.0.7-1
Distribution: unstable
Urgency: low
Maintainer: Jonas Meurer <mejo@debian.org>
Changed-By: Jonas Meurer <mejo@debian.org>
Description: 
 cryptsetup - configures encrypted block devices
 cryptsetup-udeb - configures encrypted block devices (udeb)
Closes: 488271 502598 514538 524173 524485 529527 537344
Changes: 
 cryptsetup (2:1.0.7-1) unstable; urgency=low
 .
   * new upstream release, highlights include (diff from ~rc1):
     - allow removal of last slot in luksRemoveKey and luksKillSlot
     - eject unsupported --offset and --skip options for luksFormat
   * make passdev accept a timeout option, thanks to Evgeni Golov for the patch.
     (closes: #502598)
   * finally add the cryptsource delay implementation from ubuntu, as it seems
     to workaround some issues where appearance of the root device takes longer
     than expected. (closes: #488271)
   * execute udev_settle before $cryptremove if $cryptcreate fails at
     setup_mapping() in the initramfs cryptroot script. it seems like a short
     delay and/or udev_settly is needed in between of 'cryptsetup create' and
     'cryptsetup remove'. thanks to Gernot Schilling for the bugreport.
     (closes: #529527)
   * talk about /dev/urandom instead of /dev/random in crypttab manpage.
     (closes: #537344)
   * check for $IGNORE before check_key() in handle_crypttab_line_start()
   * rewrite error code handling:
     - return 1 for errors in handle_crypttab_line_{start|stop}
     - handle_crypttab_line_... || true needed due to set -e in initscript
     - check for exit code of handle_crypttab_line_{start<stop} in
       cryptdisks_{start|stop}, exit with proper status code (closes: #524173)
   * add a counter to the while loop in cryptdisks_{start|stop}, in order to
     detect if $dst was not found in crypttab. (closes: #524485)
   * check for keyscript in the new location in initramfs/cryptopensc-hook.
   * add README.opensc to docs, thanks to Benjamin Kiessling for writing it.
     (closes: #514538)
   * add patches/03_rework_read.patch [rework write_blockwise() and
     read_blockwise()], but don't apply it yet as it's still experimental.
     applying it will increase the speed of luksOpen.
Checksums-Sha1: 
 9c76e69f7d16535c2bcc8ff7d4698a7098ad66ff 1486 cryptsetup_1.0.7-1.dsc
 476b3ec0168db2e1e104c7aa0d7154af2083df82 489436 cryptsetup_1.0.7.orig.tar.gz
 351ba3570553bcd212deb6c6278476e5dd86455f 66372 cryptsetup_1.0.7-1.diff.gz
 78351f2b67781e93c4a87dc543c1a79343b5720c 345792 cryptsetup_1.0.7-1_amd64.deb
 63d34a9ebcab4171dba8044603c4ce01b016bd15 277610 cryptsetup-udeb_1.0.7-1_amd64.udeb
Checksums-Sha256: 
 93c4e8252a6fc891f92512ed9e20a8742a3c9a473412bc20f61555ac762e144f 1486 cryptsetup_1.0.7-1.dsc
 28a144720fe95bb452e243dcc722daa7d6b1215ee6ac4a1c0f4f320a1251a791 489436 cryptsetup_1.0.7.orig.tar.gz
 2c2ca29f7b0154dd546464f0db6674005773cdb4e459000f44eb5b01025783e9 66372 cryptsetup_1.0.7-1.diff.gz
 c0fcd3d0f4582a924b0f79d0b6bf74537609e64fba429e47866b2f99191f546c 345792 cryptsetup_1.0.7-1_amd64.deb
 94c441ac23d0ae8a2aa638b73cb89483be3b89f429dfbd09167b9ec1753b131b 277610 cryptsetup-udeb_1.0.7-1_amd64.udeb
Files: 
 3ceba3456b0b7944008abe10e65348e2 1486 admin optional cryptsetup_1.0.7-1.dsc
 459d219846f36501648c1c898bd50a08 489436 admin optional cryptsetup_1.0.7.orig.tar.gz
 c3074eb011232fae3c66303ab9197f01 66372 admin optional cryptsetup_1.0.7-1.diff.gz
 b1e3b218f06555927fc3e466929707de 345792 admin optional cryptsetup_1.0.7-1_amd64.deb
 18577c229ddcca6dbe01f4dca63344cd 277610 debian-installer optional cryptsetup-udeb_1.0.7-1_amd64.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpxz2sACgkQd6lUs+JfIQIWcACeIm6H9BRb/Alvi+xFFgnaV5rx
r0AAoI9WWfOGBclFkS+e1mLKf76LFi7L
=lQH/
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.