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.
** Package changed: mountall (Ubuntu) => cryptsetup (Ubuntu)
** Changed in: cryptsetup (Ubuntu)
Status: Confirmed => Triaged
** Changed in: cryptsetup (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1153661
Title:
The disk drive for /dev/mapper/cryptswap1 is not ready yet or not
present
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1153661/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
