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