Bug #1370707 “Plymouth does not display the graphical boot splas...” : Bugs : plymouth package : Ubuntu

In freedesktop.org Bugzilla #80553, Lukas Anzinger (lukas0907) wrote on 2014-06-26:

#31

Created attachment 101794
plymouth debug log file for 0.9.0 (unpatched)

Hi,

I recently upgraded to plymouth 0.9.0 on Debian Sid and plymouth stopped working.

I'm using the following setup:

- Linux 3.14.7 (linux-image-3.14-1-686-pae 3.14.7-1)
- plymouth 0.9.0 (plymouth 0.9.0-3)
- uvesafb with AMD Radeon E6760 Embedded (uvesafb mode_option=1280x800-32 scroll=ywrap)

$ cat /etc/plymouth/plymouthd.conf
# Administrator customizations go in this file
[Daemon]
Theme=fade-in
ShowDelay=1

It's a clean installation with nothing more than a basic Debian Sid and plymouth on top. plymouth 0.8.8 worked but 0.9.0 doesn't. I've attached the log file that maybe could shed some light on the matter. It's rather short so I believe plymouthd exits prematurely.

I bisected the problem and I believe the following commit causes a regression on my setup:

commit 7e594f72550d5eeb02507ade602d7f95391e77ac
Author: Ray Strode <email address hidden>
Date: Thu Mar 6 14:42:16 2014 -0500

seat: make sure to open terminal when adding text displays

    If we have a pixel display, the renderer will handle opening the
    associated terminal. but if we don't have a pixel display, something
    needs to open the terminal.

This commit adds code to do that.

diff --git a/src/libply-splash-core/ply-seat.c b/src/libply-splash-core/ply-seat.c
index 541b29e..2ac8bf7 100644
--- a/src/libply-splash-core/ply-seat.c
+++ b/src/libply-splash-core/ply-seat.c
@@ -102,6 +102,19 @@ add_text_displays (ply_seat_t *seat)
{
ply_text_display_t *display;

+ if (!ply_terminal_is_open (seat->terminal))
+ {
+ if (!ply_terminal_open (seat->terminal))
+ {
+ ply_trace ("could not add terminal %s: %m",
+ ply_terminal_get_name (seat->terminal));
+ return;
+ }
+ }
+
+ ply_trace ("adding text display for terminal %s",
+ ply_terminal_get_name (seat->terminal));
+
display = ply_text_display_new (seat->terminal);
ply_list_append_data (seat->text_displays, display);
}

If I revert that commit on top of 0.9.0 plymouth works again.

Regards,

Lukas

In freedesktop.org Bugzilla #80553, Rstrode (rstrode) wrote on 2014-06-26:

#32

if you wrap the entire added lines in

if (seat->terminal != NULL) {
.... all the lines here ...
}

does it also continue to work?

In freedesktop.org Bugzilla #80553, Lukas Anzinger (lukas0907) wrote on 2014-06-26:

#33

Hi,

yes, it still works. I could reproduce the problem on a different hardware (Intel 855GM, i915) but only when using uvesafb (nomodeset on cmdline and uvesafb configuration in /etc/initramfs/modules).

diff --git a/src/libply-splash-core/ply-seat.c b/src/libply-splash-core/ply-seat.c
index 2ac8bf7..0f533d5 100644
--- a/src/libply-splash-core/ply-seat.c
+++ b/src/libply-splash-core/ply-seat.c
@@ -102,6 +102,8 @@ add_text_displays (ply_seat_t *seat)
{
ply_text_display_t *display;

+ if (seat->terminal != NULL)
+ {
   if (!ply_terminal_is_open (seat->terminal))
     {
       if (!ply_terminal_open (seat->terminal))
@@ -115,6 +117,12 @@ add_text_displays (ply_seat_t *seat)
   ply_trace ("adding text display for terminal %s",
              ply_terminal_get_name (seat->terminal));

+ }
+ else
+ {
+ ply_trace("seat->terminal == NULL");
+ }
+
display = ply_text_display_new (seat->terminal);
ply_list_append_data (seat->text_displays, display);
}

From the log file:

[ply-seat.c:123] add_text_displays:seat->terminal == NULL

So seat->terminal is NULL which isn't checked in ply_terminal_is_open() and so plymouthd dereferences a NULL pointer.

Regards,

Lukas

In freedesktop.org Bugzilla #80553, Lukas Anzinger (lukas0907) wrote on 2014-06-26:

#34

Download full text (3.4 KiB)

So the question is why seat->terminal can be NULL.

A seat is created in create_seats_from_udev() which calls create_seats_for_subsystem().

Digging through the log file ...

[ply-device-manager.c:705] create_seats_from_udev:Looking for devices from udev
[ply-device-manager.c:284] create_seats_for_subsystem:creating seats for drm devices
[ply-device-manager.c:284] create_seats_for_subsystem:creating seats for frame buffer devices
[ply-device-manager.c:303] create_seats_for_subsystem:found device /sys/devices/platform/uvesafb.0/graphics/fb0
[ply-device-manager.c:311] create_seats_for_subsystem:device is initialized
[ply-device-manager.c:329] create_seats_for_subsystem:device doesn't have a seat tag
[ply-device-manager.c:303] create_seats_for_subsystem:found device /sys/devices/virtual/graphics/fbcon
[ply-device-manager.c:334] create_seats_for_subsystem:it's not initialized

... we can see that a frame buffer device is found and device is initialized but it doesn't have a seat tag so create_seats_for_subsystem() ignores it (the latest patch in plymouth 0.9.0-3 kind of addresses that problem, see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751726 but in this build the patch is not applied).

Then non-graphical seat for /dev/tty7 is created.

[ply-device-manager.c:713] create_seats_from_udev:Creating non-graphical seat, since there's no suitable graphics hardware
[ply-device-manager.c:641] create_seat_for_terminal_and_renderer_type:creating seat for /dev/tty7 (renderer type: 4294967295) (terminal: /dev/tty7)

[...]

And after some time (in run level S and not in the initramfs) a seat for /dev/fb0 with no terminal attached (-> seat->terminal == NULL).

[ply-device-manager.c:357] on_udev_event:got add event for device fb0
[ply-device-manager.c:178] create_seat_for_udev_device:device is for local console: no
[ply-device-manager.c:191] create_seat_for_udev_device:device subsystem is graphics
[ply-device-manager.c:200] create_seat_for_udev_device:found frame buffer device /dev/fb0
[ply-device-manager.c:135] fb_device_has_drm_device:trying to find associated drm node for fb device (path: platform-uvesafb.0)
[ply-device-manager.c:161] fb_device_has_drm_device:no card entry!
[ply-device-manager.c:641] create_seat_for_terminal_and_renderer_type:creating seat for /dev/fb0 (renderer type: 2) (terminal: none)
[ply-renderer.c:234] ply_renderer_open_plugin:trying to open renderer plugin /usr/lib/i386-linux-gnu/plymouth/renderers/frame-buffer.so
[./plugin.c:259] create_backend:creating renderer backend for device /dev/fb0
[./plugin.c:515] query_device:32 bpp (8, 8, 8, 8) with rowstride 3200
[./plugin.c:275] initialize_head:initializing 800x600 head
[ply-renderer.c:256] ply_renderer_open_plugin:opened renderer ...

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2014-07-21:

#47

Hi Fabio,

I suppose genkernel-next can do a debug or verbose log of what's happening during the execution of the initramfs. I'm afraid I have no idea how. I use dracut, with the solar theme and plymouth 0.9.0 and works for me.

Please provide this debug log.

Cheers
Enrico

In Gentoo Bugzilla #517572, leho (leho-gentoo-bugs) wrote on 2014-08-01:

#48

I am also experiencing plymouth-0.9.0 not showing splash nor asking cryptroot password at bootup. initramfs built with dracut-038. Everything's been working dandy on plymouth-0.8.8 for months.

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2014-08-02:

#49

CC-ing lxnay just in case the bug is in genkernel-next and not in plymouth (do you use playmouth 9 with genkernel-next btw?).

@Leho can you compile dracut and plymouth with debug USE flag enabled and post debug logs for both please? For me it works very well and I have crypto as well. Also what's your graphic card and which drivers are you using for it (KMS vs. proprietary drivers vs (u)vesafb vs simple frambeuffer). Please share some more details.

For reference I test with Intel KMS, no FB since KMS provides fb as well.

In Gentoo Bugzilla #517572, leho (leho-gentoo-bugs) wrote on 2014-08-02:

#50

(In reply to Enrico Tagliavini from comment #3)
>
> @Leho can you compile dracut and plymouth with debug USE flag enabled and
> post debug logs for both please? For me it works very well and I have crypto
> as well. Also what's your graphic card and which drivers are you using for
> it (KMS vs. proprietary drivers vs (u)vesafb vs simple frambeuffer). Please
> share some more details.
>
> For reference I test with Intel KMS, no FB since KMS provides fb as well.

I run dracut off git checkout, although recent versions I guess are stable enough with systemd to be run off portage.

E7440 laptop, standard Intel Haswell gfx. Regular KMS and no other magic involved. Kernel is 3.15.8, fresh off the stove.

In Gentoo Bugzilla #517572, lxnay (lxnay-gentoo-bugs) wrote on 2014-08-02:

#51

This bug seems to be related:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=80553

I confirm that 0.9.0 does not work here as well (Sabayon, genkernel-next), while 0.8.8 did (and 0.8.9_pre1 from sabayon-distro).

In freedesktop.org Bugzilla #80553, Leho Kraav (lkraav) wrote on 2014-08-02:

#40

We are looking at this at https://bugs.gentoo.org/show_bug.cgi?id=517572 and I pulled git master yesterday. Still doesn't work :/

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2014-08-03:

#52

(In reply to Fabio Erculiani from comment #5)
> This bug seems to be related:
> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=80553
>
> I confirm that 0.9.0 does not work here as well (Sabayon, genkernel-next),
> while 0.8.8 did (and 0.8.9_pre1 from sabayon-distro).

Thank you Fabio I CCed to the bug if a solution comes up I'll look for a backport or version bump.

@Leho about the comment you posted on the freedesktop bugzilla: "Still doesn't work :/" is not going to help Ray to solve the problem. Please post debug logs and information about you setup on the freedesktop bugzilla or just avoid posting useless comments, thanks.

In Gentoo Bugzilla #517572, leho (leho-gentoo-bugs) wrote on 2014-08-03:

#53

"Useless" is a subjective conclusion. The bug on FDO had been inactive for two weeks. I'm pretty sure Ray gets *some* use out of the link to our discussion here, information about a testing result with very recent code, and a sign that there's actual interest in the bug getting resolved.

True, I didn't post debug logs. They were too difficult to obtain with the way the bug manifests itself (output just stops, with no keyboard controls available) and I don't have the time resource available right now to go deeper into it. When there's a choice between giving something or nothing at all, life has long proven giving even a small output piece has a higher % change of generating success than just sitting quietly in the corner.

I'm sure you know what you're doing and so do I, so I'd be happy to leave this topic at that. If all the smart people involved aren't already able to figure the whole thing out soon, I'll probably be able to post my debug logs within the next week. Not being lazy or uncooperative at all, it's simply that paying customers need a lot attention.

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2014-08-03:

#54

(In reply to Leho Kraav (:macmaN @lkraav) from comment #7)
> "Useless" is a subjective conclusion. The bug on FDO had been inactive for
> two weeks. I'm pretty sure Ray gets *some* use out of the link to our
> discussion here, information about a testing result with very recent code,
> and a sign that there's actual interest in the bug getting resolved.

No useless is not subjective at all. You added no information to the bug to be solved, and that's ok don't get me wrong. If you don't have time to post debug logs, fine. But than why the ":/"? This just makes it looking like a provocation to me, which lead me to the "useless" conclusion.

Anyway yes, let's leave the topic there.

In freedesktop.org Bugzilla #80553, David Lechner (dlech) wrote on 2014-08-05:

#41

I am getting this crash as well. For me, it turned out it is triggered by my kernel boot parameters. I have console=ttyS1, which is a serial terminal, then I also had plymouth.ignore-serial-consoles, which is why I think that the terminal variable is null and causing the crash.

Perhaps there should be some logic added to handle this case.

In freedesktop.org Bugzilla #80553, David Lechner (dlech) wrote on 2014-08-05:

#42

Hmm. I see now that if there is a serial console, then plymouth automatically does text instead of trying to use the framebuffer, so nevermind.

In freedesktop.org Bugzilla #80553, David Lechner (dlech) wrote on 2014-08-06:

#43

Ray, have you thought about this (comment 8) any more? I've dug a little deeper and am understanding this better now. With a little guideance, I might be able to come up with something to get this fixed.

My particular case is using a framebuffer driver on an embedded system, so it does not have the boot_vga attribute.

I patched ply-device-manager.c so that it does not call device_is_for_local_console() and just assumes that it is true. This fixed keyboard not working in bootsplash and it also fixed bug 73585 / bug 66260.

I also came across this at http://www.freedesktop.org/wiki/Software/systemd/multiseat/

> If you are writing a bootup splash tool (like Plymouth), then ignore all seat information completely and make use of all input devices and graphics cards as they become available. Stop using them as soon as the first X server starts up.

I also had an issue with the udev seat rules not being copied to the initrd and causing plymouth to fallback to text mode. Perhaps we should take this advice and not look at the seat tag and it will fix very many problems.

Martin Wimpress (flexiondotorg) wrote on 2014-09-17:

#1

BootDmesg.txt Edit (58.4 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (620 bytes, text/plain; charset="utf-8")
Dependencies.txt Edit (3.6 KiB, text/plain; charset="utf-8")
EtcDefaultGrub.txt Edit (1.2 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (11.7 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (385 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (631 bytes, text/plain; charset="utf-8")
ProcEnviron.txt Edit (106 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.3 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (2.3 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (103.5 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (245.7 KiB, text/plain; charset="utf-8")

Launchpad Janitor (janitor) wrote on 2014-09-17:

#2

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in plymouth (Ubuntu):
status:	New → Confirmed

Ivan Larionov (xeron-oskom) wrote on 2014-09-28:

#3

I'm experiencing this issue as well (nouveau). Removing of "vt.handoff=7" from cmdline fixes it.

Ivan Larionov (xeron-oskom) wrote on 2014-09-28:

#4

Also bug 1343841 looks like the same.

theghost (theghost) wrote on 2014-10-19:

#5

Also have this issue. Need to press a key to enable screen during boot.

Elfy (elfy) wrote on 2014-10-20:

#6

See the same here in Xubuntu.

removing vt.handoff=7 get 1 line of text, low then high resolution then plymouth

as post #5 - any key leads to plymouth showing

In Gentoo Bugzilla #517572, lxnay (lxnay-gentoo-bugs) wrote on 2014-10-20:

#55

It is also true that the way plymouth handles logging and debug logging is terrible: no actual way to log the damn thing to a file, little to no logging at all.

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2014-10-20:

#56

(In reply to Fabio Erculiani from comment #9)
> It is also true that the way plymouth handles logging and debug logging is
> terrible: no actual way to log the damn thing to a file, little to no
> logging at all.

I got quite the opposite impression to be honest. Yes it is messy as hell, since it is 100% undocumented and likely change from release to release, but with dracut I can debug to file with plymouth.debug. This was quite long time ago, so take my words with a grain of salt, but I'm 100% sure I got debug output to file with plymouth 0.9.0. You can also change the file location with plymouth.debug=file:<path>. It is all in src/main.c in case you need to work on it in the future for genkernel-next.

Ubuntu QA Website (ubuntuqa) wrote on 2014-10-22:

#7

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1370707

tags:

added: iso-testing

In Gentoo Bugzilla #517572, trefoils (trefoils-gentoo-bugs) wrote on 2014-10-31:

#57

Hi everyone,

I'm not sure if I have the same problem as Fabio had, but plymouth 0.9.0 and 0.8.8-r4 don't work for me. "plymouthd; plymouth --show-splash" do nothing.
I did everything according to the instructions at the gentoo wiki.

Kernel command line: "BOOT_IMAGE=/kernel-genkernel-x86_64-3.16.5-gentoo-dietconfig root=UUID=3461240b-dc33-4cf9-8575-df15ba795083 ro rootfstype=ext4 noslowusb console=tty1 resume=/dev/sda5 real_init=/usr/lib/systemd/systemd plymouth.debug=stream:/dev/kmsg quiet splash"

plymouth-0.9.0, use "debug gtk libkms pango"
genkernel-next-55, use "plymouth"
systemd-215-r3, use "acl firmware-loader gudev introspection kmod pam policykit python seccomp"

Video: i915

dmesg: http://pastebin.com/aYFQNcGb

Alberto Salvia Novella (es20490446e) on 2014-11-10

Changed in plymouth (Ubuntu):
importance:	Undecided → Medium
importance:	Medium → High

Esa Peuha (esa-peuha) wrote on 2014-12-05:

#8

I'm seeing this too, and I find it very annoying, because the screen goes blank long enough to make my monitor power down, and it takes over ten seconds to power back up when the video signal is returned.

So, I added "plymouth.debug=file:/var/log/plymouth-debug.log" to the kernel command line, and the result is attached. It seems that for some reason plymouth can't show the graphical splash screen, so it tries the text splash screen instead, but that isn't shown either. What can I do to debug this further?

Esa Peuha (esa-peuha) wrote on 2014-12-05:

#9

plymouth-debug.log Edit (27.8 KiB, text/plain)

In Gentoo Bugzilla #517572, leho (leho-gentoo-bugs) wrote on 2015-01-30:

#58

Has anything surfaced here lately about how to get plymouth-0.9.0 working? Alternatively, I may look for a way to get "tribar" theme going on 0.8.8.

In Gentoo Bugzilla #517572, phobosk (phobosk-gentoo-bugs) wrote on 2015-02-01:

#59

Created attachment 395328
early-boot-debug-plymouth-0.9.0.log

It is a complex bug involving udev (in the intramfs) and the plymouth code...

There are a couple of patches/fixes but none of them works properly actually (for me at least)...

The plymouth-9999 has some of the patches incorporated but it doesn't work too at present.

Here is a thread that discusses one of the problems (at least mine) - the new ply seat handling in plymouth...

http://lists.freedesktop.org/archives/plymouth/2014-June/000767.html

For reference my system is:

Grub kernel entry:
kernel /kernel-genkernel-x86_64-3.15.0-gentoo-r1 root=/dev/ram0 real_init=/usr/lib/systemd/systemd ramdisk=8192 crypt_root=/dev/sda2 dolvm real_root=/dev/lvm/root real_resume=/dev/lvm/swap rootfstype=ext4 video=uvesafb:1280x800-32,mtrr:3,ywrap quiet splash

plymouth-0.9.0, use "debug gtk libkms pango"
genkernel-next-60, use "cryptsetup gpg iscsi plymouth"
systemd-218-r2, use "acl cryptsetup curl gcrypt gudev http idn introspection kmod lzma pam policykit python qrcode seccomp ssl"
x11-drivers/nvidia-drivers-346.35, use "X acpi gtk3 multilib tools"

Video: NVIDIA Corporation GF104 [GeForce GTX 460]

I am attaching a part of the early boot debug log of plymouth...

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2015-02-01:

#60

@PhobosK seems the seat tag is missing from your fb0 hence plymouth ignores it. Quoting (and trimming) your log:
create_seats_for_subsystem:found device /sys/devices/platform/uvesafb.0/graphics/fb0
create_seats_for_subsystem:device is initialized
create_seats_for_subsystem:device doesn't have a seat tag

So it is pretty normal you see no splash. Can you unpack your initramfs and double check the seats rules are included? In the case of dracut that was a bug and it has been fixed. Are you currently using dracut or genkernel to generate the initramfs?

To me, at least about your case (which seems different from what others reported on this bug), is not a plymouth bug. Something is going wrong in the initramfs and th device is not tagged as a seat.

In Gentoo Bugzilla #517572, phobosk (phobosk-gentoo-bugs) wrote on 2015-02-01:

#61

Yeah I know why my plymouth is not working (the seat problem) :)

Others like @Alexander seem to have a problem with not initialized devices etc etc...
Its a complex problem involving udev/systemd and plymouth code itself, so debugging and fixing is very time consuming....

As a whole one of the important and leading problems is the initrd's created...

genkernel-next-60
-----------------
Doesn't include any seat udev rules in initramfs. I added them manually with everything needed but still plymouth 0.9.0 (and git master 9999) got problems with the console input and other problems with seat tagging again. I applied some patches gotten from Ubuntu (http://packages.ubuntu.com/vivid/plymouth) like 007-udev-seat-tag, ubuntu-seat-terminal-may-be-null etc (one by one testing with every 0.9.0 and git version), but every of these patches resolved one problem and brought another one :(

dracut-040-r3
-------------
As for the dracut I tested 040-r3 version but it lacks support for uvesafb's user helper v86d, and though I managed to include it in dracut's initramfs, I couldn't manage to add statically to the img file the nodes /dev/zero, /dev/mem and /dev/tty (needed by the helper to run very early in boot - before any udev are settled), so I get a frozen system immediately after boot... That is why I cannot tell if dracut works with plymouth BUT still it is not the gentoo way of creating initramfs img, so plymouth in portage cannot rely on using/working only with dracut....

Since all these tests consume a lot of time I removed dracut and reverted back to plymouth-0.8.8-r5 and now everything is fine...

BTW genkernel-next lacks support for uvesafb too, so I tweaked some of the source to have it...

In Gentoo Bugzilla #517572, fabio.coatti (fabio.coatti-gentoo-bugs) wrote on 2015-02-01:

#62

Hi All,
I tried to include seat rules in genkernel and suddenly the splash screen started to work (at startup, still problems on exit)

Basically the system has:
sys-kernel/genkernel-next-60
sys-boot/plymouth-0.9.0
sys-apps/systemd-218-r2

(intel graphic card)

I tweaked
/usr/share/genkernel/gen_initramfs.sh

adding the rule for seats, that is:

    udev_maybe_files="
        ${udev_dir}/rules.d/40-gentoo.rules
        ${udev_dir}/rules.d/99-systemd.rules
        ${udev_dir}/rules.d/71-seat.rules
        /etc/modprobe.d/blacklist.conf
        /lib/systemd/network/99-default.link
    "

(71-seat.rules)

and now plymouth-0.9.0 behaves like 0.8.8-r5 (it shows startup screen at least, the shutdown is still missing but this probably is another issue, dunno.

If needed, I can provide other details and debug logs, just let me know.

Thanks.

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2015-02-04:

#63

Ok since the original reporter confirmed adding the seat rules to the initramfs generated with genkernel-next fixes the problem I'm assigning this bug to the genkernel-next maintainer.

Da Xue (daxue) wrote on 2015-03-04:

#10

For me, this seems to be a kernel 3.16 bug. I can get 14.04.2 LTS to display the splash by using the 3.13 kernel. Once I boot to the 3.16 kernel, i lose the splash. I made a bug in the kernel meta package.

https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-utopic/+bug/1425304

Esa Peuha (esa-peuha) wrote on 2015-03-07:

#11

Just because the kernel does something differently doesn't mean it's a kernel bug. There's clearly a relevant bug in plymouth that I reported to plymouth upstream two months ago ( https://bugs.freedesktop.org/show_bug.cgi?id=87993 ) but forgot to mention here. Since there has been no response to that report, maybe it's time to fix the bug in ubuntu's plymouth package.

hectorsales (hectorvicente30) wrote on 2015-03-27:

#12

Same here, after upgrade recently from Ubuntu version 14.04.1 to 14.04.2 version( LTSEnablementStack)... if i boot with the kernel series 3.16.x the default ubuntu plymouth theme don't appears .. however if I starter with the kernel series 3.13.x this if it appears and this works fine. I open a thread on ubuntu forum:

http://ubuntuforums.org/showthread.php?t=2271061

Regards

D. Charles Pyle (dcharlespyle) wrote on 2015-03-27:

#13

Seeing the same in Trusty 14.04 LTS with kernel 3.16. I am now at 3.16.0-34 and still see the same behavior. Every fix I have tried fails to make it work as it did work in as late as 3.14 kernels, and did work in all the 3.13 series. I think that the problem is kernel configuration in the 3.16 kernels. I do not know about 3.15 kernels as none of those I attempted to use would boot my system properly at all.

I have yet to build my own 3.16 kernels to try to track this down but I have noticed that one of the differences between the 3.13 and 3.14 series kernels, and the 3.16 series kernels, is that CONFIG_DRM_RADEON_UMS is commented out in 3.16 kernels, but not in either 3.13 or 3.14 series kernels from Ubuntu (at least not the ones I used, and I have not been building too many of my own kernels this LTS release, as that kind of defeats the purpose of an LTS release).

I am using a Radeon HD 5750 card with dual, Dell S2440L monitors.

Any further information needed, let me know. I am going to attempt to use apport to send up my configuration, and so forth, in a couple minutes. Last time I tried it failed in another bug.

D. Charles Pyle (dcharlespyle) wrote on 2015-03-27:

#14

Tried and apport-collect failed again. Just let me know if any other information is necessary and I will do what I can to provide it to help track this down.

D. Charles Pyle (dcharlespyle) wrote on 2015-03-27:

#15

Per comment #3 I can confirm that manual deletion of $vt_handoff or vt_handoff=7 from the grub kernel line allows the plymouth splash screen to display on a 3.16 series kernel. Changing vt_handoff=1 to vt_handoff=0 in the /etc/grub.d/10_linux file does not change the behavior or omit this kernel parameter from the grub menu if you are running Ubuntu in a Wubi installation, as the parameter on the kernel line is replaced with $vt_handoff by the /etc/grub.d/10_lupin script.

Whatever is going on there with vt_handoff is affecting plymouth splash screen only when running a 3.16 series kernel. It does not affect 3.13 or 3.14 series kernels. Hope this additional information helps track down this bug. In my configuration, leaving $vt_handoff in the kernel line causes both monitors to shut down with no signal from the video card until it reaches the lightDM/Unity screen while also running on a 3.16 series kernel, so this bug is more severe than just a cosmetic issue.

In Gentoo Bugzilla #517572, leho (leho-gentoo-bugs) wrote on 2015-03-28:

#64

plymouth-0.9.2 based initramfs seems to work perfectly again. any objections to obsoleting this bug?

In Gentoo Bugzilla #517572, fabio.coatti (fabio.coatti-gentoo-bugs) wrote on 2015-03-30:

#65

Not really sure about this. According to this thread, the problem lies more into genkernel-next than in plymouth, and looking at genkernel-next github repo i see no changes applied.
Does anyone has a prior not working setup fixed by plymouth-0.9.2?
I will be able to test this only later...
If genkernel-next still needs to be fixed like in previuos comments, I can perform a pull request, just let me know.

Anyway, I'll try with plymouth 0.9.2 in a short while, it will be great to find it fixed my issue :)

Joshua (colmenar68) on 2015-04-01

no longer affects:

plymouth

In Gentoo Bugzilla #517572, andrzej.kardas (andrzej.kardas-gentoo-bugs) wrote on 2015-05-24:

#66

I checked today with sys-boot/plymouth-0.9.2, sys-apps/systemd-219_p112, sys-kernel/genkernel-next-63 (today's update) still 71-seat.rules is missing in genkernel script, and the outcome of generated initramfs is same as it was before no plymouth on boot, restart or shutdown.
After applying a fix from commment #c16, I have both integrated intel gfx and pci-e nvidia (using separate kernels to boot using different gfx driver) I boot the system with i915 Intel, nouveau and proprietary nvidia (if I'm correct the last one is using vesa for showing plymouth instead of kms) with the fix plymouth is showing on boot, but not at shutdown and restart. I also noticed that with proprietary nvidia i'm totaly unable to provide password for encryptyd volumes which makes plymouth unusable to boot the system, on kms drivers providing passwords via plymouth for encrypted volumes is working nice.
I just wonder why it's working well for some of you?

In Gentoo Bugzilla #517572, heiko (heiko-gentoo-bugs) wrote on 2015-07-20:

#67

Hi,

with 71-seat.rules included as in comment #16 the solar splash appears on my system (VirtualBox and genkernel-next-63) too, but - despite loglevel=3 and quiet - I get

* a blinking cursor
* random: nonblocking pool is initialized
* vboxguest kernel module messages

than most of the screens gets blacked out. The sun at the right lower border remains, some white dots (stars?) are splattered on the black area and the progress bar in the middle continues to run.

I tried a lot of things to get the kernel silent completely but to no avail.

Finally I get a correct agetty with /etc/issue displayed and all of the splash disappeared as it should be. I don't boot into the graphical.target, since I mostly work in a ssh session from my host.

BTW: there seems no more commits on genekernel-next's Github repo :-O

In Gentoo Bugzilla #517572, heiko (heiko-gentoo-bugs) wrote on 2015-07-20:

#68

Created attachment 407284
Broken plymouth boot

Screenshot of the broken plymouth

In Gentoo Bugzilla #517572, enrico.tagliavini (enrico.tagliavini-gentoo-bugs) wrote on 2015-07-20:

#69

(In reply to Heiko Schäfer from comment #22)
> Created attachment 407284 [details]
> Broken plymouth boot
>
> Screenshot of the broken plymouth

This is another bug, unrelated to the current one. In your case it looks like either the vbox framebuffer driver is going mad or plymouth is very confused when dealing with it.

My kernel is not silent as well when booting, and I keep it at is on purpose. Still I can't see those messages if I have plymouth enabled, I have to unhide them. You don't need a silent kernel to have the splash screen. You have something else wrong happening and, by accident, you can see under the splash screen. I advise you to get in touch with plymouth upstream and possibly also with vbox devs.

pst007x (turone) wrote on 2015-11-05:

#16

This bug also affects Ubuntu 15.10

Kernel 4.2.0-17-generic

NVIDIA V355.11 (open-source)

Boot screen only shows logo and black background, overlayed with text.

Tried usual fixes, changing screen resolution, etc, but no change

In Gentoo Bugzilla #517572, idevelop (idevelop-gentoo-bugs) wrote on 2015-11-10:

#70

I just spend over a day hunting down the problem of the splash not showing up, only to find that adding the single line with th seat.rules solves it (for me). This is now broken for over a year, if this isn't conidered a proper fix, could we at least get a ewarn/einfo of some sort to tell people about this?

In Gentoo Bugzilla #517572, fabio.coatti (fabio.coatti-gentoo-bugs) wrote on 2015-11-11:

#71

Meanwhile, I created a pull request to fix this issue, even if it seems that github repo is not very active..

Simon Quigley (tsimonq2) wrote on 2016-01-28:

#17

Confirmed in Lubuntu Xenial Xerus Alpha 2.

jiaowen520li (jiaowen520li) wrote on 2016-01-28:

#18

Confirmed in Ubuntu Kylin Xenial Alpha 2.

Mathew Hodson (mhodson) on 2016-01-30

Changed in plymouth (Ubuntu):
importance:	High → Medium

In freedesktop.org Bugzilla #80553, Chris Bainbridge (chris-bainbridge) wrote on 2016-02-06:

#44

*** Bug 87993 has been marked as a duplicate of this bug. ***

In Gentoo Bugzilla #517572, mudler (mudler-gentoo-bugs) wrote on 2016-03-07:

#72

Cutted a new release with the patch: https://github.com/Sabayon/genkernel-next/releases/tag/v64

Phill Whiteside (phillw) wrote on 2016-03-24:

#19

Present in Beta 2

sudodus (nio-wiklund) wrote on 2016-03-24:

#20

I can confirm that we have this problem in Lubuntu Beta 2 version dated 20160323. It is also affecting 'Encrypted home': the passphrase is not displayed, there is nothing but a blue screen.

But it is not BSOD, because the system is alive underneath ;-)

sudodus (nio-wiklund) wrote on 2016-03-24:

#21

Sorry, I mean 'Encrypted disk'. The passphrase is not displayed, but you can type it in and finish with the enter key, and after that arrive at the login screen of Lubuntu.

Wise Melon (wise-melon-deactivatedaccount) wrote on 2016-03-25:

#22

This bug is also present in Ubuntu GNOME 16.04 Beta 2.

In Gentoo Bugzilla #517572, mudler (mudler-gentoo-bugs) wrote on 2016-04-12:

#73

The new version is available in the sabayon overlay

Ivan S. (ivan-sushik) wrote on 2016-04-16:

#23

Same thing on Xubuntu 15.10.

Martin Wimpress (flexiondotorg) wrote on 2016-04-18:

#24

If you are seeing this issue in VirtualBox then it is the intended behaviour. The VirtualBox graphics device was blacklisted from Plymouth more than a year ago.

sudodus (nio-wiklund) wrote on 2016-04-18:

#25

No it is in real computers, for example my Toshiba laptop

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

Lubuntu has only a dark blue screen (not the text mode Plymouth text and dots), only a dark blue screen, no text at all. The bug affects i386 and amd64, bios mode and uefi mode.

sudodus (nio-wiklund) wrote on 2016-04-18:

#26

I should add that the text messages are there, and can be seen if you boot without the boot options 'quiet splash'. I think the splash option makes the difference.

sudodus (nio-wiklund) wrote on 2016-04-18:

#27

Lubuntu Xenial i386 desktop - live session:

Without the boot option splash, the text 'Please remove the installation medium, then press ENTER'.

Otherwise it is not seen, and the user gets the impression that the computer does not poweroff or reboot. I think that several different problems will be solved, when this bug is squashed,

Søren Weber (soren-jido) wrote on 2016-04-22:

#28

I have also seen this (as in #26) for Kubuntu 16.04 upgraded from 14.04.4 on HP EliteBook 2560p.
I did not see this on Lenovo X1 Carbon upgraded from Kubuntu 15.10.

David (karonzon) wrote on 2016-05-03:

#29

I'm experienceing the same bug as mentioned from comments #25 onwards with Lubuntu 16.04 i386. The PC is an eMachines EL1600. This could be related to the kernel. When I was running Lubuntu 14.04 with the 3.13 kernel, Plymouth worked as it should. When I updated the kernel to 3.16 a similar bug with the Plymouth theme was exprienced (basically half the screen being displayed) and that was fixed when I went back to the 3.13 kernel.

In Gentoo Bugzilla #517572, ago (ago-gentoo-bugs) wrote on 2016-06-10:

#74

amd64 stable

In Gentoo Bugzilla #517572, ago (ago-gentoo-bugs) wrote on 2016-06-25:

#75

x86 stable

In Gentoo Bugzilla #517572, ago (ago-gentoo-bugs) wrote on 2016-07-06:

#76

ppc stable

In Gentoo Bugzilla #517572, jon.roadleybattin (jon.roadleybattin-gentoo-bugs) wrote on 2016-09-17:

#77

NOTE: I have plymouth working using openrc. A stripped seat.rules to ensure /dev/fb0 has a seat tag is all that is needed

emerge plymouth dracut -va

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-boot/plymouth-0.9.2::gentoo USE="gtk libkms pango static-libs -debug -gdm" 0 KiB
[ebuild R ] sys-kernel/dracut-044::gentoo USE="-debug (-selinux) -systemd" 274 KiB

In Gentoo Bugzilla #517572, emanuilov.ivo (emanuilov.ivo-gentoo-bugs) wrote on 2016-09-23:

#78

(In reply to jon R-B from comment #31)
> NOTE: I have plymouth working using openrc. A stripped seat.rules to ensure
> /dev/fb0 has a seat tag is all that is needed
>
> emerge plymouth dracut -va
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] sys-boot/plymouth-0.9.2::gentoo USE="gtk libkms pango
> static-libs -debug -gdm" 0 KiB
> [ebuild R ] sys-kernel/dracut-044::gentoo USE="-debug (-selinux)
> -systemd" 274 KiB

Hi, can you elaborate a bit further on this fix? I'm not using dracut. Many thanks!

In Gentoo Bugzilla #517572, henning.f (henning.f-gentoo-bugs) wrote on 2016-11-20:

#79

I just created the file /lib/udev/rules.d/71-seat.rules and added the following to it:

ACTION=="remove", GOTO="seat_end"

TAG=="uaccess", SUBSYSTEM!="sound", TAG+="seat"
SUBSYSTEM=="sound", KERNEL=="card*", TAG+="seat"
SUBSYSTEM=="input", KERNEL=="input*", TAG+="seat"
SUBSYSTEM=="graphics", KERNEL=="fb[0-9]*", TAG+="seat", TAG+="master-of-seat"
SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="seat", TAG+="master-of-seat"
SUBSYSTEM=="usb", ATTR{bDeviceClass}=="09", TAG+="seat"

LABEL="seat_end"

And reran genkernel-next. It is now working with OpenRC.

I just cut out the first part of the systemd 71-seat.rules file, it might be possible to slim it down to just the fb line.

In Gentoo Bugzilla #517572, ago (ago-gentoo-bugs) wrote on 2016-12-28:

#80

Dear Maintainer (or who is mainly involved in this stable request),

This is an auto-generated message that will move the current component to the new component Stabilization.
To ensure that the stabilization will proceed correctly, please fill the fields "Atoms to stabilize" and "Runtime testing required" as described here:
https://archives.gentoo.org/gentoo-dev/message/4b2ef0e9aa7588224b8ae799c5fe31fa

In Gentoo Bugzilla #517572, pacho (pacho-gentoo-bugs) wrote on 2016-12-30:

#81

Remaining arches should jump to bug 603482

i2000s (i2000s) wrote on 2017-04-16:

#30

Not showing the splash screen after I reinstalled Ubuntu GNOME 16.04.2.

In freedesktop.org Bugzilla #80553, Gitlab-migration (gitlab-migration) wrote on 2018-08-07:

#45

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/plymouth/plymouth/issues/10.

Bug Watch Updater (bug-watch-updater) on 2018-08-08

Changed in plymouth:
importance:	Unknown → Medium

Bug Watch Updater (bug-watch-updater) on 2020-04-07

Changed in plymouth (Gentoo Linux):
importance:	Unknown → Medium
status:	Unknown → Fix Released

Ubuntu
plymouth package

Plymouth does not display the graphical boot splash

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntuplymouth package

Plymouth does not display the graphical boot splash

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
plymouth package