Solved – Troubleshooting Plymouth on RP 5

Symptom:

Not sure if this started after installing Tor Browser (which was subsequently uninstalled), but I’ve noticed an unstable system where I lose icons on the screen; appears to have frozen; and then issues with restarting (where I have needed to randomly disconnect power; HDMI; Cat-5) to get system running again.  This is a brand new install, with not much going on right now.  Only other thing I did was install Pi-Apps. Then, when I was restarting I noticed something about “Plymouth” being a factor, so I’m focusing on learning about this and troubleshooting it.  Will write the play-by-play here.

The red and white (generic stop sign symbol) circular stop sign in top right of desktop came on every so often, prior to system being locked.  It was odd, as the apparent fix after several times restarting, was to unplug Cat5 and then plug in again after an apparent good restart.

What is Plymouth:

Early days here, but I think it’s something to do with the initial splash-screen on startup.  A bunch of plymouth-related commands are run.

I’m seeing Plymouth to do with a “theme” as I read:  Theme or Icon Glitch: Certain desktop or window themes (like switching between dark/light modes in LXPanel) can fail to load standard applet icons properly, causing the panel to fall back to a generic stop sign or error symbol for items like the network manager or audio controls.

Experiential Learning approach:

Basic challenge nowadays is, when I do a web-search on something, I invariably get multiple perspectives of addressing the same thing.  Therefore, this approach will be all over the place.  Hopefully the outcome is both my collective understanding and system stability.

Quick disable attempt of Plymouth:

sudo systemctl disable plymouth

Not sure if this did anything, but I have noticed in last day or so of doing this that the system hasn’t locked up.  It also returned something about the unit files have no installation config, so not sure if this did anything.

systemctl is-enabled plymouth-start.service

Returns with “static”

sudo systemctl list-unit-files | grep plymouth

Returns a bunch of services that all say “static”

Upgrading system:

-I still have the CL window open from doing the systemctl commands, so within desktop, I’m still doing upgrades.  In this case, it was do with chromium.

Ruling out WiFi and network:

-The stop sign symbol  could be related to networking issue.  In this case, I have a Wired Cat5 go the Pi 5 from a 4 port switch which goes direct wire to the T-Mobile device.

I had read this: Network or Wi-Fi Status: The network manager applet often displays a prohibition or stop sign icon when a specific Wi-Fi network is disabled, out of range, or blocked (such as when country code rules aren’t set or radio frequencies are soft-blocked).

-In my case, I’m connected to both Ethernet network and WiFi with two different IP addresses.  Both are active.

sudo raspi-config

Confirm WiFi county is correct.  In my case, I did this via the Control Center App; Localisation, WiFi County  and confirmed it is: US – United States.

HDMI cable; hardware; power supply; UPS

I read somewhere to confirm the cables are good.  I had purchased all new and good quality from Vilros, so I’m ruling out physical cables and hardware.  Also the power-supply is brand name RaspBerry Pi and high-end and also connected to an APS UPS – complete overkill, I think

My HDMI cable goes between RP 5 (16GB) and a brand new Raspberry Pi 15″ monitor (White).  Also using a Raspberry Pi wired mouse and wired keyboard.

Errors from plymouth:

-I read to do this command to see if any errors

journalctl -u plymouth.service

It came back with — no entries —

Disable Plymouth and outcome

-I did the above disable plymouth and it’s true that I haven’t received the same symptom since.  In my case it was after leaving system on for about a day, it would freeze-up.  So far so good.  But, I also haven’t restarted the system since then.

Note: People on boards are saying that Plymouth causes “three white dots in top left”.  This is same symptom as I was having.

Pix:

I remember reading entering a command, which came back with Pix

Pix is the Raspberry Theme called Pix

Someone said, to the guy having same issues as me to run this to confirm theme, and it came back with Pix.

URL for his troublshooting was here: https://forums.raspberrypi.com/viewtopic.php?t=393289

plymouth-set-default-theme

Apt-full upgrade

Someone on boards said they did a clean install, and after doing Apt-Full Upgrade, they encountered the plymouth errors.  They had also done the same journalctl command I did and didn’t return errors.  He was also getting the same returns I was getting when attempting to systemctl stop the plymouth service.  Good thing is that someone else having the same symptoms as me.

Pi Imager troubleshooting:

Someone on boards said when they installed a fresh system using Pi Imager (which is what I had done) and then did the apt full upgrade, that’s when Plymouth had an issue. He ran debugger between the old and new kernel versions, and surmises this: As I can see, with new kernel on boot Plymouth can’t find output graphical device.

Kernel versions:

He went from Kernel version 6.12.47 kernel to version 6.12.62 kernel

If I boot the updated system with the old kernel, Plymouth starts working again. So it’s definitely an issue with the new kernel.  Based on what this guy said, we maybe getting close to the upgraded kernel version and Plymouth.

How to know which Kernel version I have?

uname -a

Returns with 6.18.39  (2026-07-29)

uname -r

Returns with 6.18.39-rpt -rpi -2712

So, it looks like I have a newer Kernel version, but same Plymouth symptomes

His Kernel debug for prior Kernel said “Showing splash screen”.  On the newer kernel it said, “No displays available to show splash on”

I’m not going to do this, but I see how you add an entry (plymouth.debug) to cmdline.txt and restart the system.

initramfs

Someone said the following, and then came up with the solution:

The only option I found to get splash to work on the new kernel was to disable initramfs.
(auto_initramfs=0 in config.txt)

Proposed solution posted by someone on boards:

Ok, finally the problem is solved!

After I realized that splash works without an initramfs, I noticed that the initramfs size in the preinstalled image is larger than the initramfs size built for the new kernel.

The preinstalled initramfs is built with the MODULES=most option, even though the system has this option set to MODULES=dep.
After I changed the settings in the “/etc/initramfs-tools/initramfs.conf” file to “MODULES=most,” rebuilt the initramfs with “sudo update-initramfs -k all -u,” and rebooted, everything worked!
Hope this helps someone.

Note: Someone came back with kudos to the solution and gave credit, so I’m going to do the same fix

My fix:

Setting in “/etc/initramfs-tools/initramfs.conf” file:

For me, it was set to: MODULES=dep

I changed it to: MODULES=most

Note: There’s a note in the file that says that most adds most filesystems and all hardware drivers

It said that the file is read-only.  I had opened the file from the file manager.  I have to do this at CLI

sudo nano /etc/initramfs-tools/initramfs.conf

Changed from dep to most

To save and exit: Ctrl + O, Enter, and then Ctrl +X (Ctrl, O is to Write Out and Ctrl, X is to Exit)

Confirmed in file manager as changed to most

sudo update-initramfs -k all -u

My observation was that it did a bunch of generating, and acknowledged version 6.18.39 and the last two commands for updating referenced version 6.18.34

Confirming kernel version:

uname -a

6.18.39 – no change

Reboot the system

Outcome:

-Rebooted and it was lickety-split fast with no delay on splash or startup.  Really fast.  Also showed me the network connections.  Went to desktop.

-Based on the boards; symptoms; solutions; collaboration with other; what I did; outcome, I feel REALLY GOOD about this fix.

I can also get back to my original project which is Nebula Raiders so I can play with the attached RP Zero WH via Thonny and play with C Programming using Geany

I also joined the Raspberry Pi Forum and thanked the poster with the fix

Addendum:

Now I have it more completely resolved.  I noticed relatively more stability for several days, and then effectively the same thing occuring with hangs.  I looked in to not uninstalling Plymouth, but more focusing on minimizing some of it’s runs during startup. Now I see more outcome of commands and logs being written upon startup.  I’m still understanding Plymouth to be do with a graphics startup that various things depend on. Goal is to minimize the changes as I go.  You can change parameters either using raspi-config or directly on the file /boot/cmdline.txt .

Some people have said: Read this: https://packages.debian.org/jessie/misc/plymouth and make a choice.  I like seeing boot messages on screen so it’s getting apt-get purged on my systems.

This maybe brute force, but has an issue with it:

sudo apt-get purge plymouth*
gets rid of it.

Edit: NOTE: that doing that removes raspberrypi-ui-mods and that disables the Pixel desktop. So don’t do this on a system that doesn’t always run headless.

Additional comments found: Plymouth is often unstable on the Raspberry Pi 5 because of conflicts with early DRM/KMS graphics initialization, initramfs path changes, and systemd service hangs during shutdown or reboot.

Here was the update to my system:

Went to terminal and edited the cmdline.txt file.  I had to do this because opening the file in file manager doesn’t work as it it’s locked

remove quiet and splash from /boot/firmware/cmdline.txt (or /boot/cmdline.txt)

In order to open the file from terminal I CD’d into the directory and then did

sudo nano cmdline.txt

What this does is ask for the root password and then goes into the nano text editor.  Found the reference to quiet and splash and removed them.  Then, saved the file (Ctrl-W and Ctrl-X) and rebooted the Pi 5.

What happened then was a bunch of commands fast-scrolling on the screen, and a relatively faster bootup to the desktop .