Comment 2 for bug 665789

[not sure if you get a reply on closed bugs, so Cc just in case. My apologies if it's redundant]

On Sun, Oct 24, 2010 at 06:36:53AM -0000, Steve Langasek wrote:
> plymouth is the standard boot-time I/O multiplexer. The initramfs
> script is not there for eye candy, it's there for the express purpose of
> prompting for passphrases for encrypted filesystems. Why are you not
> using the standard cryptsetup initramfs script here instead? The
> cryptsetup hook is *why* plymouth was pulled into your initramfs.

I've been doing encrypted filesystems for almost 5 years and reading with 'read' just fine without any help from plymouth which obviously didn't exist.

I am using the cryptsetup initramfs script (and by that I'm guessing you mean cryptroot), and I am using its keyscript feature.
cat /etc/initramfs-tools/conf.d/cryptroot
source=/dev/sda2,keyscript=/sbin/cryptgetpw

I diffed cryptroot between karmic and maverick and do not see anything that changed and would 'plug with' plymouth, nor do I see what plymouth adds to the equation besides breaking keyscript in cryptroot for me.
I also did not find any documentation on what plymouth changes in the I/O system, why it has to do so in initramfs (obviously things work without it, actually only without it for me right now), and I was hoping that its lack of documentation would be improved in maverick, but no:

gandalfthegrey:~$ man plymouth
No manual entry for plymouth
See 'man 7 undocumented' for help when manual pages are not available.
gandalfthegrey:~$ man plymouthd
No manual entry for plymouthd
See 'man 7 undocumented' for help when manual pages are not available.

If I may, for something that changes your system in many ways that can make
it not work, not so cool...

> If you want to override the standard behavior, you can add a file to
> /etc/initramfs-tools/conf.d/ that sets FRAMEBUFFER=n to override the
> inclusion of plymouth in the initramfs. If you want to avoid splash

Thanks, that helps.

> screens altogether, you can remove 'splash' from the boot commandline.
> This will not stop plymouth from being run by init, because it's still
> needed to handle I/O for processes such as mountall which need to
> communicate with the user at boot time in the event of filesystem
> problems.

I'm not going to fork this bug as I'm not certain it's actually 'invalid' since I have a valid use of cryptsetup and keyscript that was broken by plymouth, but in case anyone ends up on this bug from google looking for anwers to plymouth issues:

- plymouth is unfortunately still badly documented, and last I checked, removing 'splash' does not stop plymouth from messing with boot messages. Last I tried, one also needs to add the hard to find 'noplymouth' to have a mostly normal boot (or you get a stupid text mode ubuntu with rolling progress dots instead of your expected boot messages).

- in that 'as normal text mode boot as one can still get with plymouth', just yesterday, plymouth maverick did the following while I was debugging my system:
* I finally got a single user prompt to fix a corrupted /usr partition, but only after /usr was already mounted and unmountable despite fuser -kvm /usr
* After more tries (boot single), I got a root prompt where plymouth managed to multiplex my keyboard input to another process that was still asking for my root password to get me a 2nd root prompt, both processes stealing keystrokes at the same time.
* Later, plymouth got into a code path where it decided to just fsck -f -y /usr without my approval, which scrolled a lot of messages I needed to see, and that were lost forever (a few ended up in /var/log/boot.log, but only the last hundred lines or so, everything else was lost).

The problem I just described is not easily repeatable unfortunately, so I wasn't able to file useful bugs about it outside of "plymouth sucks and it prevented me from properly fixing an ailing filesystem".
So, that's my plymouth rant (sorry, not shooting the messenger): it definitely only made linux worse and more undebuggable for me (and apparently many others).

I'm not expecting you to act on the second part of this bug since it's not related, but I think it's at least useful for the relevant folks to hear that for at least of portions of your users, plymouth definitely made interacting with a booting system worse, much more than it made it better, and that it would be urgent by now to document all about how it changes your system, what it is trying to fix outside of eye candy that many don't like or want, and how to reliably interact with it or work around it when it's misbehaving.

However, all that said, since plymouth breaks cryptsetup initramfs with keyscript, can you re-visit the first part of this reply and whether this bug is really invalid?

Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/