plymouth breaks 'read' in initramfs

[Marc MERLIN]

Binary package hint: plymouth

In maverick plymouth 0.8.2-2ubuntu5.

I'll skip the amount of grief plymouth has cost me in multiple places, it has been echoed by enough other people in bugs and blogs (long story short, I never upgraded to lucid because of plymouth). I eventually went to maverick and it's a tiny bit better, but as far as encryption and initrd goes, it of course grabs the console away and stops script that read input from working.

My encryption script did a simple
read PASSWORD
feed password to cryptsetup

read never works because of plymouth.
I edited /usr/share/initramfs-tools/scripts/init-top/plymouth
and commented out
#printf '\033[?25l' > /dev/tty7
#/sbin/plymouthd --mode=boot --attach-to-session --pid-file=/dev/.initramfs/plymouth.pid
#/bin/plymouth show-splash

I have no idea why this is there, what purpose it serves, but now that I removed them, I can read the encryption password from the command line again and boot properly.

Please consider removing this if it's not absolutely necessary, and more generally when you design system enhancements, remember those who actually need boot messages and console access to work reliably and couldn't care less about splash screens and eye candy that removes access to the system when it boots.

Thanks.

[Steve Langasek (vorlon)]

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.

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 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.

The default behavior is correct for the common case, and if you really need a custom prompt instead of the standard cryptsetup script, it's overridable, so I'm closing this report as invalid.

[Marc MERLIN (marc-soft)]

[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 ...

[Marc MERLIN (marc-soft)]

Sorry, I'm going to re-open this because this is still an unaddressed bug:
- plymouth breaks initramfs' cryptsetup.
- it grabs stdin away from its shell scripts with no rationale as to why or how to turn it off
- i t is utterly undocumented whch is unacceptable for a core piece of the system (please point me to docs if I was unable to find them somehow).
- it breaks cryptsetup's keyscript=/sbin/cryptgetpw

At the very very least
"you can add a file to /etc/initramfs-tools/conf.d/ that sets FRAMEBUFFER=n to override the inclusion of plymouth in the initramfs"
needs to be documented somewhere if breaking cryptsetup functionality in initramfs is absolutely necessary.

[jhansonxi (jhansonxi)]

Seems related to bug #595648.

[Marc MERLIN (marc-soft)]

It likely is the same, yes.

Personally, I stopped caring. I got tired of ubuntu shoving things like plymouth down our throats and came to realize that it was my fault for realizing that ubuntu was not the appropriate distribution for my needs anymore.
It's meant for people who don't tinker with their systems, like windows like interactions with their computer, and it's often hard to change its behaviour as well as being a WONTFIX to make the distribution more configurable (like making plymouth optional).

So, I just went back to debian, and I'm happy camper. This doesn't fix this bug, but it fixes my problem :)

As a side note, things like upstart and plymouth would have gone so much better if they had been carefully documented instead of being rolled out "mostly working and very undocumented" like they were. Thankfully at least upstart now has pretty decent documentation, so better late than never on that front.