Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 18/02/2008 Piotr Roszatycki wrote: 2008/2/18, Jonas Meurer [EMAIL PROTECTED]: Yes, indeed this delay is implemented in udev package, at least in sid. Even that, I think this is not the best option because it is hard to guess how much time the USB device starts up. I think the safe option is to check if the proper device will appear as /dev/sd? entry. Piotr, what do you think about adding the check to the udev script instead of bloating cryptroot script with yet another delay? David pointed me to the fact that the proper fix would rather be to fix the udev initramfs script, not to add yet another delay option to cryptsetup initramfs script. The udev ROOTDELAY implementation already is at the right place, it just needs to be extended to actually check for existence of the device. I think the udev have completly no idea on what device is encrypted volume. Do you think the udev package should read /etc/crypttab file? If so, then please reassign this bugreport to udev package. Hey Piotr, you're right, the udev scripts should not know about /etc/crypttab at all. But still some issues exist with your patch. Here's the reply by David: I see Piotr's point, but there are still two issues: 1) The rootdelay would be implemented in no less than 3 places 2) Since udev uses it...if you set rootdelay to e.g. 20 seconds, udev will cause a 20 sec wait since root will be set to something like /dev/mapper/blabla and udev waits (if I remember correctly) for the device set as root to appear. So I still don't see the point in re-implementing it in cryptsetup...since you will get the maximum delay from udev long before the cryptsetup script is executed. Let's take an example...let's say you know it takes 10 seconds for your slow disk to show up. With Piotr's implementation (unless I misunderstood it), the minimum you could set rootdelay to would be 5 seconds (5 for udev, 5 for cryptsetup). If you do less, both will time out before the disk is ready. If you do between 5 and 10 seconds, you will get an optimal delay because udev will time out before the disk appears and cryptsetup will wait an optimum amount of time. If you set the delay to more than 10 seconds, you will still have unnecessary waiting since udev will wait past the time when the disk has already shown up. So the only effect is that if rootdelay is between 5 and 10 seconds, you can get the optimal waiting time of 10 seconds. Sounds like a tiny benefit to me. Not that I'm going to argue the point. I feel it's quite uninteresting :) If he is serious about it, perhaps it would be better to write a patch such that rootdelay could also (instead of) a time, specify a device path which would cause the boot to wait indefinately until said device path appears (say rootdelay=/dev/whatever). what do you think about it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 17/02/2008 Piotr Roszatycki wrote: 2008/2/17, Jonas Meurer [EMAIL PROTECTED]: Also I suggest to read and analyze the /usr/share/initramfs-tools/scripts/local file. You can see there what and in what order is called at boot time. You're correct, that $ROOTDELAY is used in scripts/local, but it's also used in scripts/init-premount/udev, and this is invoked _before_ scripts/local-top/cryptsetup. Please read /usr/share/initramfs-tools/scripts/init-premount/udev Yes, indeed this delay is implemented in udev package, at least in sid. Even that, I think this is not the best option because it is hard to guess how much time the USB device starts up. I think the safe option is to check if the proper device will appear as /dev/sd? entry. Piotr, what do you think about adding the check to the udev script instead of bloating cryptroot script with yet another delay? David pointed me to the fact that the proper fix would rather be to fix the udev initramfs script, not to add yet another delay option to cryptsetup initramfs script. The udev ROOTDELAY implementation already is at the right place, it just needs to be extended to actually check for existence of the device. greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
2008/2/18, Jonas Meurer [EMAIL PROTECTED]: Yes, indeed this delay is implemented in udev package, at least in sid. Even that, I think this is not the best option because it is hard to guess how much time the USB device starts up. I think the safe option is to check if the proper device will appear as /dev/sd? entry. Piotr, what do you think about adding the check to the udev script instead of bloating cryptroot script with yet another delay? David pointed me to the fact that the proper fix would rather be to fix the udev initramfs script, not to add yet another delay option to cryptsetup initramfs script. The udev ROOTDELAY implementation already is at the right place, it just needs to be extended to actually check for existence of the device. I think the udev have completly no idea on what device is encrypted volume. Do you think the udev package should read /etc/crypttab file? If so, then please reassign this bugreport to udev package. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
2008/2/16, Jonas Meurer [EMAIL PROTECTED]: But it doesn't work for USB devices, because cryptsetup is called too early. In such case there is missing following step: 0. sleep $cryptsourcedelay If i got it right, your statement is untrue. rootdelay is implemented in /usr/share/initramfs-tools/scripts/init-premount/udev, which is executed before any cryptsetup action is done in You're wrong, because the local-premount is called *after* local-top actions. See: $ grep Running /usr/share/initramfs-tools/scripts/locals [ $quiet != y ] log_begin_msg Running /scripts/local-top [ $quiet != y ] log_begin_msg Running /scripts/local-premount [ $quiet != y ] log_begin_msg Running /scripts/local-bottom The cryptsetup is called in local-top, the rootdelay is called after local-top and before local-premount. It is too late for cryptsetup! -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
2008/2/16, David Härdeman [EMAIL PROTECTED]: If rootdelay doesn't work for you, you might raise the value. If you still object, then please proof that I'm wrong. I agree...the initramfs-tools check for rootdelay should see that the root device doesn't exist and wait (since root will be set to something like /dev/mapper/blablabla)...so the sleep should already be there unless I'm mistaken. It doesn't resolve the problem because rootdelay waits for root device but before this will happen, the cryptsetup luksOpen fails because it can't find the crypt source device. Look, if you can't imagine the whole booting process, I think it could be possible to see it in action with help of QEMU. AFAIR, it emulates USB devices like usb-storage. I think it can't boot from usb-storage, yet, but I think the crypted root filesystem could be on USB device. Also I suggest to read and analyze the /usr/share/initramfs-tools/scripts/local file. You can see there what and in what order is called at boot time. TIA. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `-
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 17/02/2008 Piotr Roszatycki wrote: 2008/2/16, David Härdeman [EMAIL PROTECTED]: If rootdelay doesn't work for you, you might raise the value. If you still object, then please proof that I'm wrong. I agree...the initramfs-tools check for rootdelay should see that the root device doesn't exist and wait (since root will be set to something like /dev/mapper/blablabla)...so the sleep should already be there unless I'm mistaken. It doesn't resolve the problem because rootdelay waits for root device but before this will happen, the cryptsetup luksOpen fails because it can't find the crypt source device. Look, if you can't imagine the whole booting process, I think it could be possible to see it in action with help of QEMU. AFAIR, it emulates USB devices like usb-storage. I think it can't boot from usb-storage, yet, but I think the crypted root filesystem could be on USB device. Also I suggest to read and analyze the /usr/share/initramfs-tools/scripts/local file. You can see there what and in what order is called at boot time. You're correct, that $ROOTDELAY is used in scripts/local, but it's also used in scripts/init-premount/udev, and this is invoked _before_ scripts/local-top/cryptsetup. Please read /usr/share/initramfs-tools/scripts/init-premount/udev greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 17/02/2008 Piotr Roszatycki wrote:
2008/2/16, Jonas Meurer [EMAIL PROTECTED]:
But it doesn't work for USB devices, because cryptsetup is called too
early. In such case there is missing following step:
0. sleep $cryptsourcedelay
If i got it right, your statement is untrue. rootdelay is implemented in
/usr/share/initramfs-tools/scripts/init-premount/udev, which is executed
before any cryptsetup action is done in
You're wrong, because the local-premount is called *after* local-top actions.
See:
udev is not run in *LOCAL*-premount, but in *INIT*-premount, and the
init-{top,premount} scripts are invoked before local-* or nfs-* scripts:
$ grep -e /scripts/ /usr/share/initramfs-tools/init
. /scripts/functions
run_scripts /scripts/init-top
[ $quiet != y ] log_begin_msg Running /scripts/init-premount
run_scripts /scripts/init-premount
. /scripts/${BOOT}
[ $quiet != y ] log_begin_msg Running /scripts/init-bottom
run_scripts /scripts/init-bottom
${BOOT} is either local or nfs. Do you still object?
$ grep Running /usr/share/initramfs-tools/scripts/locals
[ $quiet != y ] log_begin_msg Running /scripts/local-top
[ $quiet != y ] log_begin_msg Running /scripts/local-premount
[ $quiet != y ] log_begin_msg Running /scripts/local-bottom
The cryptsetup is called in local-top, the rootdelay is called after
local-top and before local-premount. It is too late for cryptsetup!
why do you think that rootdelay is called between local-top and
local-premount? do you have any evidence?
greetings,
jonas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
2008/2/17, Jonas Meurer [EMAIL PROTECTED]:
udev is not run in *LOCAL*-premount, but in *INIT*-premount, and the
init-{top,premount} scripts are invoked before local-* or nfs-* scripts:
why do you think that rootdelay is called between local-top and
local-premount? do you have any evidence?
Ok, I see that there is another delay in udev package (grep ROOTDELAY
/usr/share/initramfs-tools/script/local will show you the first). I
think the delay implemented in udev package is wrong. It doesn't check
if the device really appears as /dev/sd* node.
--
.''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
`-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
2008/2/17, Jonas Meurer [EMAIL PROTECTED]: Also I suggest to read and analyze the /usr/share/initramfs-tools/scripts/local file. You can see there what and in what order is called at boot time. You're correct, that $ROOTDELAY is used in scripts/local, but it's also used in scripts/init-premount/udev, and this is invoked _before_ scripts/local-top/cryptsetup. Please read /usr/share/initramfs-tools/scripts/init-premount/udev Yes, indeed this delay is implemented in udev package, at least in sid. Even that, I think this is not the best option because it is hard to guess how much time the USB device starts up. I think the safe option is to check if the proper device will appear as /dev/sd? entry. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 15/02/2008 Piotr Roszatycki wrote: I'm talking exactly about booting from an encrypted usb volume. This is implemented as following scenario: 1. cryptsetup luksOpen $cryptsource $root 2. sleep $rootdelay 3. mount $root But it doesn't work for USB devices, because cryptsetup is called too early. In such case there is missing following step: 0. sleep $cryptsourcedelay and my patch implements such step. Without this additional delay there is no possibility to boot from USB device. Sounds reasonable, even though I don't like the way all the sleeps are implemented. For me they rather smell like workarounds, and not like real fixes. I guess that the underlying problem is to be found somewhere else. The kernel version is no matter. So did you just setup your new system with rootfs on an usb device, or did you suffer from this bug all the time? I'm asking because as I already reported, newest kernel upgrades obviously introduced longer delay before usb/firewire devices appear in boot process. Can you give your exact kernel version, and if it is (built from) 2.6.24-4, would you mind trying an older version to verify that the bug is not related to some specific kernel version? greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 15/02/2008 Piotr Roszatycki wrote: I'm talking exactly about booting from an encrypted usb volume. This is implemented as following scenario: 1. cryptsetup luksOpen $cryptsource $root 2. sleep $rootdelay 3. mount $root But it doesn't work for USB devices, because cryptsetup is called too early. In such case there is missing following step: 0. sleep $cryptsourcedelay If i got it right, your statement is untrue. rootdelay is implemented in /usr/share/initramfs-tools/scripts/init-premount/udev, which is executed before any cryptsetup action is done in /usr/share/initramfs-tools/scripts/local-top/cryptroot. According to the initramfs-tools manpage, init-premount scripts are executed before local-top, so sleep $rootdelay (2) is invoked before cryptsetup luksOpen (1). If rootdelay doesn't work for you, you might raise the value. If you still object, then please proof that I'm wrong. and my patch implements such step. Without this additional delay there is no possibility to boot from USB device. The kernel version is no matter. your delay is implemented at the top of local-top/cryptroot, which still is executed after init-premount/udev, so all you do is implementing yet another delay at the same place (between start of udev and start of cryptsetup). greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On Sat, Feb 16, 2008 at 09:37:26PM +0100, Jonas Meurer wrote: On 15/02/2008 Piotr Roszatycki wrote: I'm talking exactly about booting from an encrypted usb volume. This is implemented as following scenario: 1. cryptsetup luksOpen $cryptsource $root 2. sleep $rootdelay 3. mount $root But it doesn't work for USB devices, because cryptsetup is called too early. In such case there is missing following step: 0. sleep $cryptsourcedelay If i got it right, your statement is untrue. rootdelay is implemented in /usr/share/initramfs-tools/scripts/init-premount/udev, which is executed before any cryptsetup action is done in /usr/share/initramfs-tools/scripts/local-top/cryptroot. According to the initramfs-tools manpage, init-premount scripts are executed before local-top, so sleep $rootdelay (2) is invoked before cryptsetup luksOpen (1). If rootdelay doesn't work for you, you might raise the value. If you still object, then please proof that I'm wrong. I agree...the initramfs-tools check for rootdelay should see that the root device doesn't exist and wait (since root will be set to something like /dev/mapper/blablabla)...so the sleep should already be there unless I'm mistaken. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: cryptsetup: can't boot from USB device
2008/2/14, David Härdeman [EMAIL PROTECTED]: The attached patch tries to resolve this problem in the same way like main initramfs' script: it just gives a little more time for usb-storage driver. If I remember correctly, the initramfs-tools scripts (i.e. the ones that run before the cryptsetup scripts) already wait if the rootdelay parameter is set...so doesn't the present situation already provide this? The rootdelay parameter wait only for root device, not for source device for encrypted volume. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `-
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
On 15/02/2008 Piotr Roszatycki wrote: 2008/2/14, David Härdeman [EMAIL PROTECTED]: The attached patch tries to resolve this problem in the same way like main initramfs' script: it just gives a little more time for usb-storage driver. If I remember correctly, the initramfs-tools scripts (i.e. the ones that run before the cryptsetup scripts) already wait if the rootdelay parameter is set...so doesn't the present situation already provide this? The rootdelay parameter wait only for root device, not for source device for encrypted volume. So you're not talking about booting from an encrypted usb volume, but rather about starting/mounting an encrypted usb volume during boot process? I have to admit that I suffer from the same issue, my external firewire device is not available early enough in boot process to be found by cryptsetup. But for me, this happens only with the latest linux-2.6.24-4 kernel (selfcompiled). With earlier kernels (even linux-2.6.24-1), same .config I'm unable to reproduce that. Can you verify that the bug happens only with latest 2.6.24-4 kernel? greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: Bug#465763: cryptsetup: can't boot from USB device
2008/2/15, Jonas Meurer [EMAIL PROTECTED]: The rootdelay parameter wait only for root device, not for source device for encrypted volume. So you're not talking about booting from an encrypted usb volume, but rather about starting/mounting an encrypted usb volume during boot process? I have to admit that I suffer from the same issue, my external firewire device is not available early enough in boot process to be found by cryptsetup. But for me, this happens only with the latest linux-2.6.24-4 kernel (selfcompiled). With earlier kernels (even linux-2.6.24-1), same .config I'm unable to reproduce that. Can you verify that the bug happens only with latest 2.6.24-4 kernel? I'm talking exactly about booting from an encrypted usb volume. This is implemented as following scenario: 1. cryptsetup luksOpen $cryptsource $root 2. sleep $rootdelay 3. mount $root But it doesn't work for USB devices, because cryptsetup is called too early. In such case there is missing following step: 0. sleep $cryptsourcedelay and my patch implements such step. Without this additional delay there is no possibility to boot from USB device. The kernel version is no matter. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465763: cryptsetup: can't boot from USB device
Package: cryptsetup
Version: 2:1.0.6~pre1+svn45-1
Severity: important
Tags: patch
The system can't boot from USB device if it is encrypted volume. The
reason is that initramfs cryptroot-script don't wait for USB and tries
immediately to open the nonexistent device.
The attached patch tries to resolve this problem in the same way like
main initramfs' script: it just gives a little more time for
usb-storage driver.
This bug is important for anybody who want to boot up from USB device.
--
.''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
`-
diff -ru cryptsetup-1.0.6~pre1+svn45.orig/debian/initramfs/cryptroot-script cryptsetup-1.0.6~pre1+svn45/debian/initramfs/cryptroot-script
--- cryptsetup-1.0.6~pre1+svn45.orig/debian/initramfs/cryptroot-script 2008-02-14 13:26:55.0 +0100
+++ cryptsetup-1.0.6~pre1+svn45/debian/initramfs/cryptroot-script 2008-02-14 13:25:23.0 +0100
@@ -163,6 +158,37 @@
/sbin/udevsettle --timeout=30
fi
+ # If the crypto device hasn't shown up yet, give it a little while
+ # to deal with removable devices
+ if [ ! -e $cryptsource ] || ! /lib/udev/vol_id $cryptsource /dev/null 21; then
+ log_begin_msg Waiting for 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 21; 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
if [ ! -e $cryptsource ]; then
echo cryptsetup: Source device $cryptsource not found
return 1
Bug#465763: [Pkg-cryptsetup-devel] Bug#465763: cryptsetup: can't boot from USB device
On Thu, Feb 14, 2008 at 05:37:44PM +0100, Piotr Roszatycki wrote: The system can't boot from USB device if it is encrypted volume. The reason is that initramfs cryptroot-script don't wait for USB and tries immediately to open the nonexistent device. The attached patch tries to resolve this problem in the same way like main initramfs' script: it just gives a little more time for usb-storage driver. If I remember correctly, the initramfs-tools scripts (i.e. the ones that run before the cryptsetup scripts) already wait if the rootdelay parameter is set...so doesn't the present situation already provide this? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
