Comment 5 for bug 1153661

I've gotten to the bottom of this, and in the process figured out why I was never able to reproduce it in a VM.

Basically, because random-crypted swap (as set up by the ecryptfs helper in ubiquity) is a raw, randomly-keyed block device, there is no UUID on the container device - which means blkid will never return any useful information about the partition, so /etc/init/cryptsetup-udev.conf will never trigger for such a swap device.

As a result, the swap device is only set up once /etc/init/cryptsetup-enable.conf triggers, which only happens after all hardware has been probed and udev has settled. Depending on hardware this can easily take more than 3 seconds, which is long enough for mountall's "idle" trigger to fire and ask the user whether to keep waiting.

So the only way to fix this is to fix cryptsetup to create an actual container for random-crypted swap, so that this can be detected by udev sooner and we avoid the timeout.

This is arguably a good idea anyway, because there is a small but non-zero chance of a completely-random use of the space matching a signature for a real filesystem type and causing confusion. So it would be better for cryptsetup to use LUKS encapsulation even for random-encrypted devices, but this is currently not supported.