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-labelpackages are installed.- A theme is selected (I’ve tried
text, which displays basic text, and graphical themes likebgrtand others from standard packages). sudo update-initramfs -uhas been run after each configuration/theme change.- The
splashkernel boot parameter is present in/proc/cmdline. - The
plymouth-start.serviceis enabled (static). - The
getty@tty1.serviceis correctly masked (inactive (dead) masked), which imo is proper for a system with a display manager.
- Kernel Graphics & Framebuffer:
- The
/dev/fb0framebuffer device exists (ls -l /dev/fb0showscrw-rw---- 1 root video ... /dev/fb0). - Kernel logs (
dmesg) show that the kernel successfully initializes thetilcdcgraphics 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.serviceandjournalctl -b | grep -i plymouthshow that theplymouth-start.serviceunit is started, and the mainplymouthdprocess (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/fb0exists and dmesg shows framebuffer setup success. - Reviewed
journalctl -u plymouth-start.serviceandjournalctl -b | grep -i plymouthextensively. While the service starts and stops, and the main daemon PID (255/265) is active, there are no error messages or warnings from the mainplymouthdprocess in the journal indicating why the graphical initialization, theme loading, or rendering fails. The only errors are harmlessKillMode=nonewarnings. - Tried adding
--debugand--debug-file=/run/plymouth/debug.logto 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-livedplymouthdinstance, PID 369/370, that reported “already running” and exited).--debug-file: The specifieddebug.logfile was not created in/run/plymouth/, and there were no errors logged about file creation failure.- This suggests debugging output from the main
plymouthdprocess is not captured by the journal or redirected as expected on this setup, making diagnosis difficult.
- Removed the
quietkernel 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
ExecStartline 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
tilcdcdriver? - 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
plymouthdprocess (PID 255/265) on early boot on this hardware, given that standard--debuglogging 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! ![]()