Comment 5 for bug 473615

lvm2 is not provided by an init script, correct; this is handled via udev rules. This is also racy, because there's no guarantee that all the LVM devices will be up when 'udevadm settle' ends.

"So both before and after, this is racy" - I was actually referring to the fact that there's no guarantee *in general* that the underlying volumes are available, either before calling /etc/init.d/rcS or before calling /etc/init/cryptdisks-enable.conf. In both cases, it's possible that the volumes won't become available until after the script has run.

The difference before and after this change is that before, we get three chances to catch the underlying volume. After, we only have one chance. This means we can say with a high degree of certainty that this change will regress /for some users/. One example where it will regress is:

 - /dev/sdh is a USB-attached disk which is slow to power up, and routinely does not register with the kernel until well after the coldplugging stage.
 - /dev/sdh1 is mounted as /home.
 - /dev/sdh2 is the PV for a luks encrypted device, which is listed in /etc/crypttab and configured to be mounted as /mnt/S3kritProj3ct.

Prior to this change, what happens is:

 - /etc/init/udevtrigger.conf finishes; /dev/sdh is not yet available.
 - /etc/init/cryptdisks-enable.conf is run (start on stopped udevtrigger). it exits without doing anything, because /dev/sdh2 is not yet present.
 - /dev/sdh is detected; events are emitted for /dev/sdh, /dev/sdh1, and /dev/sdh2.
 - mountall mounts /dev/sdh1 as /home, and emits the "filesystems" signal
 - /etc/init/rc-sysinit.conf runs, calling /etc/init.d/rcS
 - /etc/init.d/cryptdisks-early runs, and sets up the device, resulting in new udev events being emitted
 - mountall mounts /mnt/S3kritProj3ct.

After the change, /etc/init/rc-sysinit.conf doesn't do anything relevant, and /mnt/S3kritProj3ct is never decrypted or mounted.

The same fundamental race is still present - /dev/sdh2 becoming available, vs. udev cold plugging finshing and /etc/init/cryptdisks-enable.conf being called. But there are cases where the behavior after this change is demonstrably more likely to hit the race condition.

Now, the specific example I came up with here probably didn't work in jaunty either, because we didn't have mountall to wait for /home to become available before telling /etc/init.d/rcS to go. But after all, it's racy - and I'm pretty sure this change will make things worse for some users (and will definitely make things better for others).

Does that clarify?

> This would mean to run all the parsing, modprobe, dmsetup mknodes, etc. code each time
> an ecrypted device gets added >(which could be on an USB key). Semantically this would
> probably be correct, since these could be handled in crypttab as well. I'm just not sure
> about how much overhead this would introduce for a running session.

As Scott has argued, users don't choose disk encryption if their priority is boot performance. And users can always mark devices 'noauto' in /etc/crypttab, if they don't want them autostarted - if they *do* want them autostarted, it would be nice to do so more reliably than we do currently.