Plymouth does not display the graphical boot splash

[Martin Wimpress]

When booting from Ubuntu 14.10 daily-live image from 17th September 2014 Plymouth does display the graphical boot splash. However, once Ubuntu 14.10 is installed Plymouth does not display the graphical boot splash while the system is booting. Instead just a black screen is present up until Unity Greeter is loaded.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: plymouth 0.9.0-0ubuntu4
ProcVersionSignature: Ubuntu 3.16.0-14.20-generic 3.16.2
Uname: Linux 3.16.0-14-generic i686
ApportVersion: 2.14.7-0ubuntu2
Architecture: i386
BootLog: Error: [Errno 2] No such file or directory: '/var/log/boot.log'
CurrentDesktop: Unity
Date: Wed Sep 17 21:55:35 2014
DefaultPlymouth: /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth
InstallationDate: Installed on 2014-09-17 (0 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha i386 (20140917)
MachineType: IBM 2668Q1G
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-14-generic root=UUID=a9e0ac17-222f-4b0b-861d-a8b24df9c911 ro quiet splash vt.handoff=7
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-14-generic root=UUID=a9e0ac17-222f-4b0b-861d-a8b24df9c911 ro quiet splash vt.handoff=7
SourcePackage: plymouth
TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/21/2006
dmi.bios.vendor: IBM
dmi.bios.version: 1YET65WW (1.29 )
dmi.board.name: 2668Q1G
dmi.board.vendor: IBM
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: IBM
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnIBM:bvr1YET65WW(1.29):bd08/21/2006:svnIBM:pn2668Q1G:pvrThinkPadT43p:rvnIBM:rn2668Q1G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:
dmi.product.name: 2668Q1G
dmi.product.version: ThinkPad T43p
dmi.sys.vendor: IBM

[Lukas Anzinger (lukas0907)]

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

[Rstrode (rstrode)]

if you wrap the entire added lines in

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

does it also continue to work?

[Lukas Anzinger (lukas0907)]

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

[Lukas Anzinger (lukas0907)]

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

[Lukas Anzinger (lukas0907)]

Created attachment 101817
plymouth debug log file for 0.9.0 (check for seat->terminal != NULL)

[Lukas Anzinger (lukas0907)]

Hi,

I've also tried plymouth with seat->terminal != NULL and the seat patch from Debian:

diff --git a/src/libply-splash-core/ply-device-manager.c b/src/libply-splash-core/ply-device-manager.c
index dbc203d..e9f8519 100644
--- a/src/libply-splash-core/ply-device-manager.c
+++ b/src/libply-splash-core/ply-device-manager.c
@@ -313,7 +313,7 @@ create_seats_for_subsystem (ply_device_manager_t *manager,
           /* We only care about devices assigned to a (any) seat. Floating
            * devices should be ignored.
            */
- if (udev_device_has_tag (device, "seat"))
+ if (true)
             {
               const char *node;
               node = udev_device_get_devnode (device);

Now a seat is immediately created for /dev/fb0 because a frame buffer device is found but the terminal for that device is still NULL.

[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:322] create_seats_for_subsystem:found node /dev/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: (null))
[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 plugin /usr/lib/i386-linux-gnu/plymouth/renderers/frame-buffer.so
[ply-seat.c:80] add_pixel_displays:Adding displays for 1 heads
[ply-seat.c:123] add_text_displays:seat->terminal == NULL

Regards,

Lukas

[Lukas Anzinger (lukas0907)]

Created attachment 101818
plymouth debug log file for 0.9.0 (check for seat->terminal != NULL and udev seat always true)

[Lukas Anzinger (lukas0907)]

Is there anything I can do to help you resolving that issue? I could also send you hardware and a preinstalled Debian.

[Rstrode (rstrode)]

Hey, sorry for the slow reply with this. So I think what's probably happening is device_is_for_local_console() in ply-device-manager.c is probably failing, so create_seat_for_udev_device() is creating a seat with a NULL terminal, and then we're failing to handle a NULL terminal seat very well.

I've pushed this commit to master:

http://cgit.freedesktop.org/plymouth/commit/?id=84eb4381db85877a9a56b35994e6c10d43e46ebe

to try to handle the NULL terminal case better.

There's more to the story though. device_is_for_local_console() is a function that checks if the video device is the "boot_vga" device, the one that was active at boot time. I think the idea in my mind was to avoid opening a terminal more than once if there were multiple video cards associated with the machine. This idea has two failings:

1) There may be a case where no video device has boot_vga, I guess, in which case a terminal won't ever get opened and so password input won't work
2) if conceptually, a seat is a "monitor and a keyboard" then the abstraction is just wrong.

So I need to rework this a bit...

[Leho Kraav (lkraav)]

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 :/

[David Lechner (dlech)]

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.

[David Lechner (dlech)]

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.

[David Lechner (dlech)]

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.

[Launchpad Janitor (janitor)]

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

[Ivan Larionov (xeron-oskom)]

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

[Ivan Larionov (xeron-oskom)]

Also bug 1343841 looks like the same.

[theghost (theghost)]

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

[Elfy (elfy)]

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

[Ubuntu QA Website (ubuntuqa)]

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

[Esa Peuha (esa-peuha)]

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?

[Da Xue (daxue)]

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)]

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)]

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)]

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)]

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)]

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.

[pst007x (turone)]

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

[Simon Quigley (tsimonq2)]

Confirmed in Lubuntu Xenial Xerus Alpha 2.

[jiaowen520li (jiaowen520li)]

Confirmed in Ubuntu Kylin Xenial Alpha 2.

[Chris Bainbridge (chris-bainbridge)]

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

[Phill Whiteside (phillw)]

Present in Beta 2

[sudodus (nio-wiklund)]

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)]

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)]

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

[Ivan S. (ivan-sushik)]

Same thing on Xubuntu 15.10.

[Martin Wimpress (flexiondotorg)]

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)]

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)]

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)]

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)]

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)]

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.

[i2000s (i2000s)]

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

[Gitlab-migration (gitlab-migration)]

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