[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/
--
plymouth breaks 'read' in initramfs
https://bugs.launchpad.net/bugs/665789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
