Hi everyone,
I’m facing an issue getting the graphical Plymouth splash screen to display during boot on my BeagleBone Black Industrial board. I’m running Debian Bullseye with kernel version 5.10.168-ti-r71.
During the system boot process, on the monitor connected via HDMI, I observe the following visual sequence:
- The Linux kernel logo (the Tux penguin with the BeagleBone dog on its belly) appears briefly in the top-left corner.
- A few lines of text from Plymouth (debug logs like
main.c:... redirecting debug output to /dev/tty1
) appear below the logo. This is not the graphical theme or the formatted text theme. - The screen then transitions, and the nodm display manager logo and graphical interface load, followed by the desktop.
The graphical Plymouth splash screen never appears.
What Works / What Has Been Checked:
- Basic Plymouth Setup:
plymouth
,plymouth-themes
,plymouth-label
packages are installed.- A theme is selected (I’ve tried
text
, which displays basic text, and graphical themes likebgrt
and others from standard packages). sudo update-initramfs -u
has been run after each configuration/theme change.- The
splash
kernel boot parameter is present in/proc/cmdline
. - The
plymouth-start.service
is enabled (static
). - The
getty@tty1.service
is correctly masked (inactive (dead) masked
), which imo is proper for a system with a display manager.
- Kernel Graphics & Framebuffer:
- The
/dev/fb0
framebuffer device exists (ls -l /dev/fb0
showscrw-rw---- 1 root video ... /dev/fb0
). - Kernel logs (
dmesg
) show that the kernel successfully initializes thetilcdc
graphics driver with DRM and switches the console to the framebuffer device around 4-5 seconds kernel time (~16-17 seconds system time):
[ ... ] tilcdc 4830e000.lcdc: [drm] Initialized tilcdc 1.0.0 ... for 4830e000.lcdc on minor 0
[ ... ] Console: switching to colour frame buffer device 128x37
[ ... ] tilcdc 4830e000.lcdc: [drm] fb0: tilcdcdrmfb frame buffer device
- The appearance of the kernel logo confirms the framebuffer is working at the kernel level.
- Plymouth Execution:
journalctl -u plymouth-start.service
andjournalctl -b | grep -i plymouth
show that theplymouth-start.service
unit is started, and the mainplymouthd
process (PID 255/265) starts and runs (receives SIGRTMIN+20) and is later properly terminated (receives SIGRTMIN+21).- Seeing the text output from Plymouth on the screen confirms that the daemon is running and can output text to the framebuffer console (
/dev/tty1
).
The Core Issue:
The problem is that the graphical part of Plymouth fails to initialize or render the graphical theme, causing it to fall back to text output, despite the underlying framebuffer being functional for text and the kernel logo.
Debugging Steps Taken & Logs Analysis:
- Checked
systemctl status plymouth-start.service
(enabled
,static
, correctly maskedgetty@tty1
). - Confirmed
/dev/fb0
exists and dmesg shows framebuffer setup success. - Reviewed
journalctl -u plymouth-start.service
andjournalctl -b | grep -i plymouth
extensively. While the service starts and stops, and the main daemon PID (255/265) is active, there are no error messages or warnings from the mainplymouthd
process in the journal indicating why the graphical initialization, theme loading, or rendering fails. The only errors are harmlessKillMode=none
warnings. - Tried adding
--debug
and--debug-file=/run/plymouth/debug.log
to theExecStart=
line in a systemd override file forplymouth-start.service
.--debug
: Debug output did not appear in the journal from the main PID (255/265). However, debug text was seen on the screen during boot (this output came from a secondary, short-livedplymouthd
instance, PID 369/370, that reported “already running” and exited).--debug-file
: The specifieddebug.log
file was not created in/run/plymouth/
, and there were no errors logged about file creation failure.- This suggests debugging output from the main
plymouthd
process is not captured by the journal or redirected as expected on this setup, making diagnosis difficult.
- Removed the
quiet
kernel parameter. This allowed seeing the kernel logo and confirmed the text output from Plymouth, but still did not reveal any graphical errors in dmesg or the full journal (journalctl -b
). - Tried simplifying the
ExecStart
line in the override (e.g.,ExecStart=/usr/sbin/plymouthd --debug --mode=boot
), but the logging behavior remained unchanged.
Problem Summary: The kernel prepares the display, /dev/fb0
exists, Plymouth starts and outputs text to the framebuffer console, but the graphical theme fails to display silently, without logging errors from the main daemon process. This points to a failure within Plymouth’s graphical rendering initialization specific to this hardware/driver, or a theme compatibility issue that is not being logged properly.
Please Help:
- Has anyone encountered a similar issue with the graphical Plymouth splash screen not showing (but text output working) on BeagleBone Black (Industrial) running Debian with a 5.10.x kernel and the
tilcdc
driver? - Are there specific kernel parameters (beyond
splash
), U-Boot configurations, driver versions, or Plymouth patches known to be necessary or problematic for graphical Plymouth on this platform? - Are there alternative methods to get verbose debugging output from the main
plymouthd
process (PID 255/265) on early boot on this hardware, given that standard--debug
logging to journal/file seems to be failing?
I have full journalctl -b --no-pager
logs available if needed for further analysis.
Thank you for any help and guidance!