A few days back, I installed Tumbleweed on my other desktop and everything was running fine until the upgrade dated 12 October, when the default Plymouth bootsplash (Spinner with the Tumbleweed logo) no longer appeared and was replaced with three small green blocks. The kernel was also upgraded during this from 6.5.4 to 6.5.6.
I ran (as sudo) plymouth-set-default-theme spinner -R to try to get it back, but this did not work and it still displays the green blocks.
The GPU in the system is an AMD Radeon HD 5450 on a PCI-E x16 card. Although Linux is displaying (using?) 256MB for video memory, the card actually has 2GB on it:
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] (prog-if 00 [VGA controller])
Subsystem: VISIONTEK Device 5450
Flags: bus master, fast devsel, latency 0, IRQ 24, NUMA node 0
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at fdcc0000 (64-bit, non-prefetchable) [size=128K]
I/O ports at dc00 [size=256]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu
Is there a fix to restore the bootsplash? During the install, I did not enable snapshots.
No need to upload a huge screenshot just to show system info. SImply tap the âCopy to Clipboardâ at bottom of window, then insert the text into a Preformatted Text option </> on the forum title-bar, as such
Operating System: openSUSE Tumbleweed --20231013--
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.11
Kernel Version: 6.5.6-1-default (64-bit)
Graphics Platform: X11
Processors: 8 à IntelŽ Core⢠i5-8365U CPU @ 1.60GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa IntelÂŽ UHD Graphics 620
Manufacturer: Dell Inc.
Product Name: Latitude 5500
Anyway, back to the issue. There has been a newer Snapshot Release - have you installed that and try again - it appears thereâs a patch that might affect sddm (?)
Thank you for the reply. I will attempt an upgrrade of it and post an update.
On (what Iâll call) the original desktop I installed Tumbleweed on, which has different specs (below), the bootsplash has been fine, from the install through 20231012 and with the 20231013 upgrade it just received.
Well, maybe there wasnât an update to anything with [specifically] âsddmâ in the name.
However, immediately after I run a âzypper -vvv dupâ, I always run âzypper ps -sâ (before a reboot or re-login) to see what is affected by the update, and it did show, âsddmâ. So yea, sometimes there are supporting library(ies) that are updated, which affects the actual application
Does the â-vvvâ flag do anything different WRT zypper? I found a verbose command for â-vâ in its man entry. I have run it with âps -sâ afterwards to see what changed.
Upon the second reboot, the three green blocks returned.
-v, --verbose
Increase verbosity. For debugging output specify this option twice.
Three vâs might be one too many, but wonât hurt output, just ensures an increase in verbosity.
When you see the three green blocks, press ESC key - do you see detailed text output? (itâs expected output). Seems you might have some oddball graphics issue.
Have you run âjournalctlâ for output for the most recent boot for any clues?
When I turned it on this morning, the Spinner bootsplash appeared (again, without the Tumblweed branding), so I did not press ESC or run journalctl. I will do this, the next time the blocks appear.
I hit ESC twice, once when the spinner appeared (still no Tw branding) and again with the three blocks. Although the messages were scrolling down extremely fast (this is installed to a SATA SSD), I caught where it said Plymouth was loading, but nothing that looked like an error message displayed.
I then installed the tribar theme and Iâve set Plymouth to use that.
The kernel command line includes splash=silent and quiet, which I did not touch.
journalctl -b had the following items pertaining to Plymouth. This was after I changed the default back to Spinner and rebooted. There is one entry that looks like it could be an error (SIGRTMIN+20), occurring before the boot screen appearance, but the three blocks came up again.
Oct 16 19:26:31 opensusedn systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit uses KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update the service to use a safer KillMode=, such as 'mixed'
or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
Oct 16 19:26:32 opensusedn systemd[1]: Starting Show Plymouth Boot Screen...
Oct 16 19:26:32 opensusedn plymouthd[320]: 00:00:02.203 ply-utils.c:932:ply_get_kernel_command_line : opening /proc/cmdline
Oct 16 19:26:32 opensusedn plymouthd[320]: 00:00:02.204 ply-utils.c:940:ply_get_kernel_command_line : reading kernel command line
Oct 16 19:26:32 opensusedn plymouthd[320]: '
Oct 16 19:26:32 opensusedn plymouthd[320]: 00:00:02.204 main.c:1938:check_logging : checking if console messages should be redirected and logged
Oct 16 19:26:32 opensusedn plymouthd[320]: 00:00:02.204 main.c:1947:check_logging : logging will be enabled!
Oct 16 19:26:32 opensusedn plymouthd[320]: 00:00:02.204 main.c:2017:initialize_environment : source built on Aug 28 2023
Oct 16 19:26:32 opensusedn systemd[1]: Received SIGRTMIN+20 from PID 320 (plymouthd).
Oct 16 19:26:32 opensusedn systemd[1]: Started Show Plymouth Boot Screen.
Oct 16 19:26:40 opensusedn systemd[1]: Finished Plymouth switch root service.
Oct 16 19:26:42 opensusedn systemd[1]: plymouth-start.service: Deactivated successfully.
Oct 16 19:26:42 opensusedn systemd[1]: plymouth-start.service: Unit process 320 (plymouthd) remains running after unit stopped.
Oct 16 19:26:42 opensusedn systemd[1]: Stopped Show Plymouth Boot Screen.
Oct 16 19:26:42 opensusedn systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid).
Oct 16 19:26:42 opensusedn systemd[1]: plymouth-switch-root.service: Deactivated successfully.
Oct 16 19:26:42 opensusedn systemd[1]: Stopped Plymouth switch root service.
At times, problems with plymouth or sddm can be traced back to graphics and drivers. Your earlier post showed that the memory was being misread or misreported by the system. It also shows an apparently available expansion ROM as âdisabledâ which may or may not be a flag. I am not sure about the âaccess deniedâ output of âcapabilitiesâ. I have had times when the 32bit versions of some graphics drivers came up in the solver as unavailable during a zypper dup. The solver allows keeping the older versions, but it did cause graphics problems with my Ryzen 9 machine causing Plasma desktop affects issues. Now when I get the solver notices, I reject all of the graphics updates. The 32bit versions often show up as available in a day or two, at which time I allow all graphics drivers to be installed.
âCapabilitiesâ are displayed if lspci -v is run as root.
This is the full information on the GPU from my other desktop, which doesnât have the bootsplash issue - as an example of the command run as root. Note that it also displays the Expansion ROM as âdisabledâ. This GPU is integrated on the motherboard.
I have not yet run this (as root) on the desktop with the issue. I will do that and add to this thread. Both desktops are 64-bit.
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device 2ab7
Flags: bus master, fast devsel, latency 0, IRQ 18, NUMA node 0
Memory at d0000000 (32-bit, prefetchable) [size=256M]
I/O ports at c000 [size=256]
Memory at fe9f0000 (32-bit, non-prefetchable) [size=64K]
Memory at fe800000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu
It is the full hardware information, not so much the software. Full relevant information includes more of the applicable software, and less of the hardware minutia. A good job of providing both comes from inxi -GSaz run in an Xterm. The S is included to pick up the kernel cmdline options, some of which can impact graphics matters.
The S is included to pick up the kernel cmdline options, some of which can impact graphics matters.