spinner theme, sometimes does not render splash without output

Bug #1871717 reported by Dimitri John Ledkov
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
plymouth (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

spinner theme, sometimes does not render splash without output

desktop installer initrd starts plymouthd, executes show-splash, then casper md5check starts.

Sometimes the progress bar and splash are shown with all the messages.

Sometimes the screen remains black, but upon pressing ESC, one can see plymouth-text messages. pressing ESC again, rerenders the splash with casper-md5check progress bar with progress message, and file under check message, but not the Ctrl+C message.

So plymouthd is there, and accepting input, but choosing not to paint things?

From the 20200408 image.

It is as if plymouth theme has a delay built in, and despite show splash.... it is not shown.

When booting with plymouth:debug set, splash is rendered straight away.

Tags: focal
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Could you include the journal log from a buggy boot? even without plymouth debug it might stil give some hints?

Changed in plymouth (Ubuntu):
status: New → Incomplete
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

I wonder if it is initramfs-tools bug.

It starts plymouthd and immediately executes show-splash, without doing ping. Meaning plymouthd might not yet fully forked/started, and show-splash is never executed.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@seb128 not sure, because there is no journal during initramfs. When journal is running we only tell plymouth to quit.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Well /usr/share/initramfs-tools/scripts/init-premount/plymouth bug.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sounds like this might be timeout related, like bug 1838725 and bug 1868240 are. I would need to see a plymouth debug log of the issue in action to be sure.

tags: added: focal
Changed in plymouth (Ubuntu):
status: Incomplete → New
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Please update and verify the problem still happens.

If the problem still happens then add kernel parameter:

   plymouth:debug

and reboot. Then attach the resulting log file from:

   /var/log/plymouth-debug.log

Changed in plymouth (Ubuntu):
status: New → Incomplete
Revision history for this message
Paride Legovini (paride) wrote :

This still happens when booting the latest Focal ISO images (20200417), see the attached screenshot. The problem appears to be racey, as sometimes plymouth does start in time, and the graphical background is shown, sometimes it does not, and the installer boots in text mode. I can reproduce the problem on both actual hardware and QEMU.

The problem it likely caused by the fact that plymouthd is not ready yet when `plymouth show-splash` or casper try to connect to it. If this is the case, booting with plymouth:debug wouldn't really help, as there is nothing to connect to.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes plymouth is racey by design, which may be part of the problem. That race involves waiting for 8 seconds for kernel DRM devices to appear and if they don't appear in that time then they won't be used. Even if other more basic kernel graphics devices do exist (like that used by the BIOS). That issue is most recently being discussed in: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/103 although the underlying problem is not Nvidia-specific.

But it's unclear to me if that's the original problem here so I would still wait for Dimitri to answer comment #6.

Revision history for this message
Paride Legovini (paride) wrote :

I did try to add "plymouth:debug" to the kernel cmdline but no plymouth-debug.log was generated. I did check /proc/cmdline and the parameter is there. `journalctl -b` shows these plymouth related errors:

Apr 21 09:44:10 u plymouth[529]: 00:00:05.338 ./ply-boot-client.c:183:ply_boot_client_connect : could not connect to /org/freedesktop/plymouthd: Connection refused
Apr 21 09:44:10 u plymouth[529]: 00:00:05.339 ./ply-boot-client.c:190:ply_boot_client_connect : could not connect to /ply-boot-protocol: Connection refused
Apr 21 09:44:15 u plymouth[656]: 00:00:10.740 ./ply-boot-client.c:183:ply_boot_client_connect : could not connect to /org/freedesktop/plymouthd: Connection refused
Apr 21 09:44:15 u plymouth[656]: 00:00:10.740 ./ply-boot-client.c:190:ply_boot_client_connect : could not connect to /ply-boot-protocol: Connection refused
Apr 21 09:44:15 u plymouth[657]: 00:00:10.761 ./ply-boot-client.c:183:ply_boot_client_connect : could not connect to /org/freedesktop/plymouthd: Connection refused
Apr 21 09:44:15 u plymouth[657]: 00:00:10.762 ./ply-boot-client.c:190:ply_boot_client_connect : could not connect to /ply-boot-protocol: Connection refused

I am now reproducing the issue in a QEMU VM.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Paride,

Just in case yours is a different bug with a different root cause, please open a new bug by running:

  ubuntu-bug plymouth

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.