Snapshot start-up slowdown 18112024

Hi, The latest snapshot has slowed down the system boot and after the grub the screen stays black for 30 seconds until it starts loading the system. Journactl returns this message:

nov 20 14:08:13 localhost.localdomain systemd[1543]: Failed to start Application launched by gnome-session-binary.

System:
  Host: localhost.localdomain Kernel: 6.11.8-1-default arch: x86_64 bits: 64
  Desktop: GNOME v: 47.1 Distro: openSUSE Tumbleweed 20241118
Machine:
  Type: Mini-pc System: AZW product: SER v: N/A serial: <superuser required>
  Mobo: AZW model: SER v: V2.0 serial: <superuser required> UEFI: American
    Megatrends LLC. v: FP655U508 date: 03/31/2023
CPU:
  Info: 6-core model: AMD Ryzen 5 5560U with Radeon Graphics bits: 64
    type: MT MCP cache: L2: 3 MiB
  Speed (MHz): avg: 1101 min/max: 400/4062 cores: 1: 1101 2: 1101 3: 1101
    4: 1101 5: 1101 6: 1101 7: 1101 8: 1101 9: 1101 10: 1101 11: 1101 12: 1101
Graphics:
  Device-1: Advanced Micro Devices [AMD/ATI] Cezanne [Radeon Vega Series /
    Radeon Mobile Series] driver: amdgpu v: kernel
  Display: wayland server: X.org v: 1.21.1.14 with: Xwayland v: 24.1.4
    compositor: gnome-shell driver: gpu: amdgpu resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 vendor: amd mesa v: 24.2.6 renderer: AMD Radeon
    Graphics (radeonsi renoir LLVM 19.1.3 DRM 3.59 6.11.8-1-default)
  API: Vulkan v: 1.3.296 drivers: N/A surfaces: xcb,xlib,wayland
  API: EGL Message: EGL data requires eglinfo. Check --recommends.

Thank you

I’m getting the same 30-35 second delay after grub menu to KDE login screen.
this is after I applied the 20241118 snapshot
Also I noticed if I hit “esc” during boot after grub I do not see any info messages as the system is booting up, just a black screen until the gui login screen shows

my specs

     OS: openSUSE Tumbleweed x86_64 
     Host: ASUSTeK COMPUTER INC. ROG MAXIMUS XI EXTREME 
     Kernel: 6.11.8-1-default 
     Uptime: 1 hour, 38 mins 
     Packages: 3130 (rpm), 12 (flatpak) 
     Shell: bash 5.2.37 
     Resolution: 2560x1440 
     DE: Plasma 6.2.3 
     WM: KWin 
     Theme: Breeze [GTK2/3] 
     Icons: breeze [GTK2/3] 
     Terminal: konsole 
     CPU: Intel i9-9900K (16) @ 5.000GHz 
     GPU: NVIDIA GeForce RTX 2070 Rev. A 
     Memory: 4441MiB / 31882MiB 

1 Like

It seems machine specific. There is no bugreport about such an issue up to now. On my machines no difference in booting time with latest snapshot 20241118 . Also no issues with VB VMs.

So the ususal steps would be checking the journal. That means searching for errors and the lines with the 30 seconds gap (and not only picking and posting one single line). If not able to analyze them on your own, simply paste them at https://paste.opensuse.org/

Also the basics like systemd-analyze blame may give a hint.

Maybe related to my problem?

I rebooted then ran this command:

systemd-analyze
Startup finished in 4.263s (firmware) + 2.568s (loader) + 1.214s (kernel) + 33.675s (initrd) + 6.296s (userspace) = 48.018s 
graphical.target reached after 6.296s in userspace.

I also notice the flashing cursor in the very upper left corner on the monitor for the 30-35 sec delay. So the screen is not completely black.

ran systemd-analyze blame

29.671s plymouth-switch-root.service
 2.775s dracut-initqueue.service
 1.998s plymouth-start.service
 1.249s plymouth-read-write.service
 1.181s NetworkManager.service
 1.160s display-manager.service
  694ms initrd-switch-root.service

For me the issue is the plymouth proccess crashing.
Adding

plymouth.enable=0

to the kernel parameters and running

sudo update-bootloader

afterwards removes the delay for me.

1 Like

Follow this guide at your own risk!

Spoiler: How to add plymouth.enable=0 to the kernel parameters
  1. Open up the file /etc/default/grub in a text editor with root access, e.g. nano:
sudo nano /etc/default/grub
  1. Find the line that starts with GRUB_CMDLINE_LINUX_DEFAULT=
  2. Put plymouth.enable=0 in front of everything that’s already in the quote behind GRUB_CMDLINE_LINUX_DEFAULT=.
  3. For example, your line could look like this:
GRUB_CMDLINE_LINUX_DEFAULT="plymouth.enable=0 splash=silent quiet security=selinux selinux=1 mitigations=auto"
  1. Save the file with CTRL+O and then ENTER.
  2. Update your GRUB config by running
sudo update-bootloader
  1. Reboot your machine. The last shutdown delay will remain, but all subsequent boots/shutdowns should not be delayed any more.

It seems at least one guy who is affected by this issue, had a look at the journal and reported it:
https://bugzilla.opensuse.org/show_bug.cgi?id=1233532

Hi. You are right. It is better to put the output of journalctl. Regards.

29.372s plymouth-switch-root.service
20.570s plymouth-quit-wait.service
 3.618s dracut-initqueue.service
 3.399s NetworkManager-wait-online.service
 1.160s plymouth-start.service

The time jump occurs on these lines, in the service plymouth-switch-root.service

Hi, I have done a clean install to test if the boot delay is reproduced and it is only reproduced if the microcode of the processor is installed in my case (amd). If you do an offline installation of the system, there is no boot delay, it only occurs when YAST installs the microcode on the first connection of the system to the servers.

Which AMD CPU???

Did you test booting with kernel parameter mitigations=off?

Hi, I’ve reinstalled a new installation online and the boot is no longer delayed. When doing the clean offline install the boot delay only occurred once Yast downloaded the microcode on first connection.

I tried with in Yast->Boot Loader Settings CPU Mitigations off.
-Reboot still 30 delay ,black screen No blinking white cursor in the very top left corner.
Change Yast->boot Loader Setting CPU Mitigations to Auto.
-Reboot still 30 delay, black screen , Blinking white cursor in very upper left corner.

This does not change with CPU Mitigations on Auto or OFF

29.437s plymouth-switch-root.service
 2.972s dracut-initqueue.service
 1.409s plymouth-start.service

1 Like

I have the same Issue now. I am using a 7800x3d.
Now my boot takes over 2 minutes :sob: (because of my other problem).

Ever since the plasma version changed to 6, the updates have become really unstable, even though I did the update by the book. For example, I just noticed that my bluetooth service suddenly stopped working (rarely use it).

Before that, Tumbleweed was rock solid.

mwahhaha i dont have this problem because i disabled plymouth when i installed my system muwhahahahah

1 Like

Good for you! May you also explain, with your high level of experience, why this issue does not affect all users with installed and enabled Plymouth?

Plymouth may be a red herring here. There is not enough data yet to draw a conclusion. Some AMD users are affected, some Intel users, some Nvidia users…

But the combination of hardware and Plymouth seems not the issue. None of my bare metal machines with Intel CPU and Nvidia GPU with enabled Plymouth show a start delay. Also VB VMs do not show an issue here.

Usually Plymouth gets installed and stays enabled on all bare metal machines and VB test boxes. Only the “quite” and “splash=silent” parameters get removed from the kernel command line.

There are also other bugreports popping up at bugzilla atm, with the same 30 seconds delay but without showing plymouth as the responsible process.

https://bugzilla.opensuse.org/show_bug.cgi?id=1233675

https://bugzilla.opensuse.org/show_bug.cgi?id=1233684

Hi all,
So I enabled plymouth to see what will happen.
Once I rebooted I saw the blinking cursor and stays for at least more than 30 seconds.
It took probably a minute before I got the login screen. Shutting down my machine also takes a while, when I disabled plymouth I was able to go back from the faster boot time.
Could be my old machine is one of the affected or maybe there is something missing with the installed plymouth and I don’t have any knowledge regarding this issue.
Screenshot_20241123_130419
my GPU is nvidia RTX 3050

Can you add the “strace” command to Plymouth and and send that to a plain text file somewhere to see if that provides any info? That’s what I would try, not that I can even read its output I really only use it for find files an app is accessing

If plymouth is in question, one should inspect the logs.

sudo cat /var/log/plymouth-debug.log
(Make sure you have set console/terminal history to unlimited to show all lines.)

If you don’t have plymouth debugging enabled (debugging should be default), enable it via the kernel command line parameter:

plymouth.debug