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