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.
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
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.
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.
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
I have the same Issue now. I am using a 7800x3d.
Now my boot takes over 2 minutes (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).
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.
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.
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