I can also reproduce this bug on a fresh install of precise. mountall is missing the notification that /dev/mapper/cryptswap1 is available, so waits for it; the system seems to only boot all the way for me because the lo interface happens to come up after this and triggers mountall to rescan (/etc/init/mountall-net.conf).
Since the standard crypted swap being offered here is not luks, there is no filesystem metadata on the partition, so /etc/init/cryptdisks-udev.conf will not match this device.
In /var/log/upstart/cryptdisks-enable.log, I see this:
* cryptswap1 (starting)..
The node /dev/mapper/cryptswap1_unformatted should have been renamed to /dev/mapper/cryptswap1 by udev but old node is still present. Falling back to direct old node removal.
...done.
I can also reproduce this bug on a fresh install of precise. mountall is missing the notification that /dev/mapper/ cryptswap1 is available, so waits for it; the system seems to only boot all the way for me because the lo interface happens to come up after this and triggers mountall to rescan (/etc/init/ mountall- net.conf) .
Since the standard crypted swap being offered here is not luks, there is no filesystem metadata on the partition, so /etc/init/ cryptdisks- udev.conf will not match this device.
In /var/log/ upstart/ cryptdisks- enable. log, I see this:
* cryptswap1 (starting).. cryptswap1_ unformatted should have been renamed to /dev/mapper/ cryptswap1 by udev but old node is still present. Falling back to direct old node removal.
The node /dev/mapper/
...done.
That looks like a smoking gun.