Comment 18 for bug 509487

Yep, there we are - it's trying to load files from disk, but apparently the process is still using the initramfs as its root, so fails to load any files off the disk past the point of exec()ing upstart.

Since we don't want to force plymouth to waste more cycles in the initramfs reading all the files into memory before run-init unlinks them, we should instead fix this by giving plymouth a way to be notified of the change in root device and chroot at the same time. (In your particular case, it would also work to just ensure cryptsetup doesn't force plymouth into the initramfs - but there are still other reasons to want plymouth to not be fragile in this respect.)

> Also, I noticed something weird that I'm not sure is related or not.
> When booting with no mountpoint requiring a luks volume (basically how
> I boot at the moment by commenting the right line in my fstab),
> cryptsetup seems to start anyway in the background and waits for a
> key. Only issue is that plymouth never asks for that key and boots as
> if no key was needed at all (it's actually right as no mountpoint
> require it but then cryptsetup shouldn't start either).

Commenting it out of the fstab will not prevent cryptsetup from triggering when the device becomes available. For that, you would need to set 'noauto' in the options in /etc/crypttab as well.