Hello there,

For some reason my root filesystem (ext3 on encrypted lvm) had some errors and
fsck could not fix them automatically. Then a maintenance shell should be
started to solve the problem manually.

First plymouth problem (maybe a "feature" or not implemented yet):
The plymouth theme runs (and runs and runs ...) and gives no hint that
something is wrong. Only after pressing ESC you realize that there is a
problem.



Second problem (really annoying and important):
I see the following lines (probably from init):
Give root password for maintenance
(or type Control-D to continue)

When I want to enter my password after every single key the input is aborted
(nothing displayed) and a new line shows up:

Give root password for maintenance
(or type Control-D to continue)

The only way I found to work around is:
Restart and remove the kernel boot option "splash" in grub.
Then I'm able to enter my password.

Christian Meyer

Hi Christian,
Are both those problems reproducible in plymouth 0.8.3-17 (in unstable)?

Cheers,
Julien

Hello Julien,

I would be glad to find out if the two issues are still in plymouth 0.8.3-17.
Since I don't know much about filesystems (and I don't want to crash my encrypted LVM)
I have no glue how to "damage" my root partition just that little bit that is needed to
cause init to call the maintenance shell. Just forcing fsck at boot probably will not find any error.

Do you have a suggestion how to force the maintenance shell at boot time?
However. I will install 0.8.3-17 and wait for the next filesystem inconsistency.

Christian

I suppose you could change the root= parameter in grub so the initramfs
can't find the root device and gets you to the maintenance shell?

Cheers,
Julien

Am Donnerstag, den 04.11.2010, 20:53 +0100 schrieb Julien Cristau:

Sorry, this didn't work. I gave invalid (e.g. /abc) and wrong
(e.g. /home) parameters, but my system booted without maintenance shell
(only a kernel panic once).
Even creating /forcefsck and then powering off by unplugging power
supply (while copying a large file to /) didn't work (yet).
I will go on trying and report it when maintenance shell appear.

Christian

Hi there,

I found a way to force maintenance shell at boot time:
Adding an invalid UUID line to fstab (and auto fsck it at boot time) works:
# /dev/sdb1 (blue)
UUID=db7f927d-cf0b-4a1e-affe-6737e0396fdf /media/usb1 ext3 rw,defaults 0 1
(see: http://ubuntuforums.org/showthread.php?t=1200587 )

Both problems are still there in plymouth 0.8.3-17.
Only difference to the older version: you have to press ESC twice and you are
able to press two keys before input is interrupted.

Christian

I had similar problems in single-user mode. Using a shell was impossible, as I could only type one character.
Only the text mode theme was active. I ended up uninstalling plymouth, which is sad because it seems to be the only bootsplash possibility in squeeze.

Max

Hello,

I noticed earlier today, the problem still persists. Whenever Linux
drops the user into an emergency shell (you know the "Give root password
for maintenance (or type Control-D to continue)" dialog), this breaks
Plymouth.

This just blocks Plymouth forever. As it was mentioned earlier, even
worse, you can't use the shell Linux offers you as it is not possible to
enter the password and/or make use of the shell.

The only possibility to solve the problem is to do a reboot by hitting
the reboot button and booting with a "nosplash" kernel command line that
time.

I confirm this behavior for plymouth 0.8.3-20. To reproduce the issue
just provoke a problem e2fsck can't automatically solve. For example
change the system time to a date in the past (which is before the last
saved mount time in the metadata) and reboot.

Hi,

I think that "plymouth --hide-splash" should explicitly be called in the
panic() function of /usr/share/initramfs-tools/scripts/functions file.

Cheers

Laurent Bigonville

reassign 602331 initramfs-tools 0.106
affects 602331 plymouth
thanks

Hi,

I'm reassigning this to initramfs-tools so the panic() function can be
fixed to add the proper call to disable the splash screen.

Cheers

Laurent Bigonville

Hello,

An idea on how this could be fixed? In Ubuntu they have added a "panic"
hook to initramfs-tools that is being called in the "panic()" function.
Do you think it's the way to go here?

Otherwise I can also provide a patch for the same function to directly
call the needed plymouth command ("plymouth quit")

Cheers,

Laurent Bigonville

Hi,

* Laurent Bigonville [Fri Aug 01, 2014 at 03:55:17PM +0200]:

I just took a look at Ubuntu's i-t and their try_failure_hooks
function with features related to plymouth etc totally makes sense
for me, I'd love to see that in Debian's i-t as well, so if anyone
is willing to work on it you'd have my full support for that.

regards,
-mika-

I just encountered similar behaviour.  panic() really needs to call
"plymouth quit" before trying to do anything else.

Ubuntu's initramfs-tools has a system for running scripts on panic, which
Ubuntu's plymouth makes use of to do exactly this.  Any chance this can be
imported into Debian?  It seems fairly straightforward.

unmerge 805155
thanks

Hi,

Well this is not the same bug IMVHO, the try_failure_hooks is an other
mechanism where the system can try to automatically recover from a
failure. OTOH the panic hook is when something is really broken and
cannot be recovered.