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.
** Changed in: plymouth (Ubuntu)
Status: New => Triaged
** Also affects: cryptsetup (Ubuntu)
Importance: Undecided
Status: New
--
[lucid] plymouth in initramfs doesn't know to chroot() when init does, can't
load files from disk
https://bugs.launchpad.net/bugs/509487
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
