FS#11571 - [cryptsetup] encrypt hook must wait for root usb device to settle

Attached to Project: Arch Linux
Opened by Jose Manuel Cejudo Gausi (jmcejudo) - Tuesday, 23 September 2008, 21:36 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 June 2009, 13:25 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

When booting into a root and encrypted (luks) usb device the encrypt hook doesn't wait for the usb device to settle, so cryptsetup doesn't recognizes the device.

I can solve the issue adding the following line to the beginning of run_hook() in the encrypt hook file:

/bin/sleep "${rootdelay}"

Additional info:

mkinitcpio.conf:
MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev usb encrypt filesystems"

Steps to reproduce:
Setup a "live usb" system with the boot partition encrypted.

sorry for my english :)
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 07 June 2009, 13:25 GMT
Reason for closing:  Fixed
Additional comments about closing:  In the next cryptsetup version (1.0.6-3), this will respect the rootdelay parameter and use the poll_device method. Your problem should be gone then.
Comment by kludge (kludge) - Saturday, 22 November 2008, 06:30 GMT
confirmed.

put a new hard drive into my laptop and moved my arch-installed drive to a usb enclosure.
booted a live disk to create a /boot partition on the new hdd
copied over the contents of arch's /boot
edited menu.lst appropriately (grub on /dev/sda1, root on /dev/sdb1)
booted to the same error condition

my fix is documented at: http://bbs.archlinux.org/viewtopic.php?id=59084
Comment by Shawn (Kassanova708) - Saturday, 22 November 2008, 15:21 GMT
Same here. I installed Arch on a USB Stick, and couldn't figure out what was the problem. The bug is reproducible, as boot will fail every time.
Comment by Aaron Griffin (phrakture) - Sunday, 23 November 2008, 03:06 GMT
Hmm, should we use $rootdelay for this or should we use udevadm? (hit submit way too fast there)
Comment by kludge (kludge) - Sunday, 23 November 2008, 19:33 GMT
i vote for udevadm. five seconds wasn't enough time for my usb / to settle, so i had to set it to 8. but how long does it really take? dunno. could it occasionally be longer or shorter? sure. 'udevadm --settle' is a much "smarter" test, if it works as advertised. i'd test it, but i can't reboot for a while yet, / is on usb, and i only have one port.

i'd suggest the test go in .../hooks/usb. i'm guessing the placment of the $rootdelay check lines in .../hooks/filesystems predates the encrypt and lvm hooks, since both can depend on settled usb devices but come before filesystems and kinit.

if the usb hook uses udevadm to achieve rootdelay's purpose, is rootdelay needed at all?
Comment by Thomas Bächler (brain0) - Sunday, 23 November 2008, 19:44 GMT
udevadm won't help! We actually call udevadm settle before any other hook is run and the usb devices still take longer. rootdelay in the encrypt and lvm2 hooks is the only way.
Comment by Aaron Griffin (phrakture) - Sunday, 23 November 2008, 19:55 GMT
Thomas, that's right, but I think we call udevadm before usb modules are loaded. Perhaps if we added it into the USB hook itself...
Comment by kludge (kludge) - Sunday, 23 November 2008, 20:13 GMT
i won't claim to understand the inner workings of /sys and udev, but what about logic that

(a) looks in sysfs for all usb block devices
(b) waits until their nodes exist in /dev

or is that what udevadm settle should do?
Comment by Thomas Bächler (brain0) - Sunday, 23 November 2008, 22:05 GMT
No, it waits until all uevents have been processed.

The USB-based block devices appear later. However, once udev sees them, the device nodes are there immediately, udevadm cannot help us here.
Comment by kludge (kludge) - Monday, 24 November 2008, 18:02 GMT
*where* later? and *why* later? digging around in the mkinicpio scripts has made very curious. i'd like to (help) make the [usb] hook "smarter, but i'm not sure how to proceed investigating.

i've tried building an initcpio with udevd --daemon --debug, and i tried adding udevadm monitor (both to the [udev] hook). the former produced *way* too much output, and then latter didn't seem to produce any.

can you explain/advise?

thanks!
Comment by Thomas Bächler (brain0) - Monday, 24 November 2008, 20:59 GMT
"later" in a sense that the kernel announces them later. We have no influence on that.
Comment by Greg Erwin (Odysseus) - Sunday, 15 February 2009, 23:10 GMT
This problem also affects a RAID array using partitions on usb drives.
My solution to add something like this to the usb hook:

until [ -e /dev/sdb ];
do
sleep 1;
done

Related forum thread here: http://bbs.archlinux.org/viewtopic.php?id=65407
Comment by Aaron Griffin (phrakture) - Monday, 16 February 2009, 23:01 GMT
Thomas, should we add the same USB tricks we added to the archiso hooks here? Think that would help?
Comment by David Pflug (Viaken) - Monday, 04 May 2009, 15:16 GMT
So, to clarify, the problem is that it tries to decrypt a dev node that doesn't exist yet, but udevadm --settle doesn't wait for USB devices to settle and create nodes? Wouldn't that be a udevadm bug?
Comment by Tobias Powalowski (tpowa) - Monday, 04 May 2009, 15:57 GMT
well the next kernel .30 series will use fastboot by default there this is also an issue and udev will ignore it.
Comment by David Pflug (Viaken) - Monday, 04 May 2009, 17:19 GMT
So udev will ignore udevadm settle if fastboot is enabled?
Comment by Tobias Powalowski (tpowa) - Monday, 04 May 2009, 17:25 GMT
yes modprobe doesn't will not wait anymore and says everything is done.
Comment by Phyrok (Raizha_Phyrok) - Friday, 29 May 2009, 17:25 GMT
At least I was able to resolv the problem:

My hooks array in /etc/mkinitcpio.conf looks like this:

HOOKS="base udev usb encrypt autodetect ide pata scsi sata filesystems"

Nothe that I was only able to boot from encrypted usb when usb and encrypt opions was before autodetect, etc... and filesystems at the last position.

I added too this line to the end, after the last curly brace, on the usb hook

sleep 15

but I think that the hooks order did the trick

Loading...