Lost Plymouth bootsplash after Tumbleweed upgrade of 20231012

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.

Thank you in advance.

I did not see an option to edit my post above. This is the system info screen from KDE after the upgrade:

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 (?)

New Tumbleweed snapshot 20231013 released!

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.

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: Wayland
Processors: 2 × AMD Athlon(tm) II X2 260 Processor
Memory: 7.5 GiB of RAM
Graphics Processor: AMD RS780
Manufacturer: Hewlett-Packard
Product Name: CQ5826

The 20231013 upgrade had 52 packages, none of them had sddm in the name.

I did a reboot after the upgrade. The Spinner bootsplash returned, but without the Tumbleweed branding. :thinking:

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 :+1:

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.

From man page:

-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.

Interesting - my boot up shows the spinner, but with Asus ROG logo (the mobo branding).

After you login, you can still check journalctl entries for past boots. But yea, you could wait to check the journal after the next boot goof-up.

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. :man_shrugging:

I then installed the tribar theme and I’ve set Plymouth to use that.

Thanks for the replies.

Yea, the scrolling boot up messages is difficult to see.
However, after you login, you could jump to a command line and execute

# dmesg

… to see if there is an error … or you can execute

# journalctl -b

… to check for any errors

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. :smiley: The S is included to pick up the kernel cmdline options, some of which can impact graphics matters.

Thank you for that info. Was not aware of the extra switches, having looked at only -G previously.

~> inxi -GSaz
System:
  Kernel: 6.5.6-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.5.6-1-default
    root=UUID=66383625-3e67-484f-a557-dacb55cc3e26 splash=silent
    mitigations=auto quiet security=apparmor
  Desktop: KDE Plasma v: 5.27.8 tk: Qt v: 5.15.11 wm: kwin_x11 vt: 2
    dm: SDDM Distro: openSUSE Tumbleweed 20231019
Graphics:
  Device-1: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: VISIONTEK
    driver: radeon v: kernel alternate: amdgpu arch: TeraScale-2 code: Evergreen
    process: TSMC 32-40nm built: 2009-15 pcie: gen: 1 speed: 2.5 GT/s
    lanes: 16 ports: active: HDMI-A-1 empty: DVI-D-1,VGA-1 bus-ID: 02:00.0
    chip-ID: 1002:68f9 class-ID: 0300 temp: 64.0 C
  Device-2: Creative Live! Cam Sync 1080p driver: snd-usb-audio,uvcvideo
    type: USB rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-4.4.4:10
    chip-ID: 041e:409d class-ID: 0102 serial: <filter>
  Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.2.1
    compositor: kwin_x11 driver: X: loaded: modesetting unloaded: fbdev,vesa
    dri: r600 gpu: radeon display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: HDMI-A-1 mapped: HDMI-1 model: LG (GoldStar) FULL HD
    built: 2016 res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2
    size: 480x270mm (18.9x10.63") diag: 551mm (21.7") ratio: 16:9 modes:
    max: 1920x1080 min: 720x400
  API: OpenGL v: 4.5 Mesa 23.2.1 renderer: AMD CEDAR (DRM 2.50.0 /
    6.5.6-1-default LLVM 17.0.2) direct-render: Yes

we are beyond 20231012, by a few updates … have you updated to the current update - 20231019?

Uhm, what?

1 Like

I’ve filed a bug report on this (#1216517). Hopefully one of the developers will have a solution. I referenced this thread.