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
