After GRUB delay issue

Hello community,

I’ve just landed here after being 1.5 years on MX Linux and I am very happy about this.

I’ve always wanted a distro that is rolling release but stable at the same time with a very well done Plasma implementation and this distro simply rocks it! This one fits me perfectly and will be my daily driver from now on.

Everything runs very well and smooth with just only one exception. My issue is regarding with a delay that appears after GRUB disappears. Then a black screen with some ACPI errors appear which are fine, I would say, they also appeared on MX Linux disregarding the kernel used and never had a problem.

But on SUSE there is also this loading Nvidia Kernel Module line that might be the cause? Not sure.

Anyway, as I was saying, after the GRUB and these errors on black screen what follows is a complete delay with black screen which turn into half black and the other half grey. This thing stays like this for like 2 minutes and only after that the log in screen appears. Then the distro works fine but it’s really not okay to be like that.

I attach pictures here:
https://i.imgur.com/xbp8rhr.jpg
https://i.imgur.com/tnpwpSU.jpg

The only things I did after installation is to a couple of basic software like GIMP and Kde Connect as well as the codecs and Nivida driver using these scripts from opensuse-community dot org and nothing more. Everything automated via Yast, which I love.

What do you think the problem might be and what can I do to fix it? Thanks :penguin:

I am also adding this information here:
dmesg - Pastebin.com - dmesg
sudo journalctl --lines=all - Pastebin.com - sudo journalctl --lines=all

That’s probably the plymouth screen.

Personally, I always remove the “splash=silent” from the boot parameters, so that I see more detailed information about what is happening.

Thanks for your reply.
Is there any command I can use to show specific information rather than to catch a screen with the phone for a picture?

You can perhaps try:

systemd-analyze blame

To avoid using the camera to capture the screen. Maybe this can be of help:

# cat /var/log/boot.log

With systemd-analyze blame I get this: systemd-analyze blame - Pastebin.com

For some reason, I cannot get anything with cat.
I also tried opening the terminal in that specific folder and going just sudo cat boot.log and nothing came out.

Also, I see that the system does not record what happened more than 1-2 boots in the past?

The issue happened again today. After GRUB it goes into that black screen which changes a couple of times 2-4 times, the grey area gradually overs more and more of the screen. After a short change, then it reaches those 3 loading green buttons which are specific to SUSE and only after than another black-reload of the screen happens and finally login screen appears.

I think it’s related to the latest Nvidia update ( 545 from 16 November ), after making this update the usual loading screen after grub was replaced with graphical glitch and later three green dot, not to mention that it did take way more time than usual to show the login screen, but after that the x11 session seems to work fine I did not notice anything suspicious compared to the previous 535 version, I still did a rollback to go back to 535 and no issues on boot there.

Some other people are affected by this https://www.reddit.com/r/openSUSE/comments/17wrr76/new_nvidia_drivers_545_multiple_problems/

Those times (from “blame”) do see a tad slow.

Maybe try:

# systemd-analyze critical-chain

@no5xmega

The system thinks your posts are spam because you use multiple links to the same site. I have no doubt this is a bout pastebin.com

I have undone the systems actions, but please remark that not many people here love it visit such commercial sites. We have paste.opensuse.org available for long computer texts and images.

1 Like

@hcvv thanks for letting me know!
and
Thanks for your continued support :+1:

This is the critical chain: https://paste.opensuse.org/pastes/484e568f4e99

This is what I have installed from Nvidia

  • kernel-firmware-nvidia - Kernel firmware files for Nvidia Tegra and graphics drivers
  • libdrm_nouveau2 - Userspace interface for Kernel DRM services for NVIDIA chips
  • libnvidia-egl-wayland1 - The EGLStream-based Wayland external platform
  • nvidia-compute-G06 - NVIDIA driver for computing with GPGPU
  • nvidia-compute-G06-32bit - 32bit NVIDIA driver for computing with GPGPU
  • nvidia-compute-utils-G06 - NVIDIA driver tools for computing with GPGPU
  • nvidia-driver-G06-kmp-default - NVIDIA graphics driver kernel module for GeForce 700 series and newer
  • nvidia-gl-G06 - NVIDIA OpenGL libraries for OpenGL acceleration
  • nvidia-gl-G06-32bit - 32bit NVIDIA OpenGL libraries for OpenGL acceleration
  • nvidia-utils-G06 - NVIDIA driver tools
  • nvidia-video-G06 - NVIDIA graphics driver for GeForce 700 series and newer
  • nvidia-video-G06-32bit - 32bit NVIDIA graphics driver for GeForce 700 series and newer
  • openSUSE-repos-MicroOS-NVIDIA - openSUSE NVIDIA repository definitions
  • openSUSE-repos-Tumbleweed-NVIDIA - openSUSE NVIDIA repository definitions

Is there a way I can easily downgrade Nvidia? With a command script or perhaps somehow from Yast?

The “critical-chain” times look reasonable to me. Perhaps nvidia problems are all.

It is several years since I last used Nvidia graphics, so I’ll leave it to others with more recent experience to comment on that.

It might help to read the thread before posting. The TO is using a Nvidia GPU. Why adding unrelated kernel command line parameters for AMD GPUs? :roll_eyes:

1 Like

Hi
Not had any issues with Nvidia GPU’s here, however I do install the Nvidia driver via the hardware, likewise, grub is hidden, no plymouth either…

systemd-analyze 

Startup finished in 890ms (kernel) + 1.851s (initrd) + 6.405s (userspace) = 9.148s 
graphical.target reached after 6.405s in userspace.

pinxi -GSaz

System:
  Kernel: 6.6.2-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc available: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.6.2-1-default
    root=UUID=2bf05dec-eccc-4077-a934-7e8106064659 splash=silent
    acpi_osi=Linux intel_iommu=on iommu=pt video=1920x1080@60
    nvidia_drm.modeset=1 quiet mitigations=auto
  Desktop: GNOME v: 45.1 tk: GTK v: 3.24.38 wm: gnome-shell tools:
    avail: swaylock,xlock,xscreensaver dm: GDM v: 45.0.1 Distro: openSUSE
    Tumbleweed 20231122
Graphics:
  Device-1: NVIDIA GP104GL [Tesla P4] driver: nvidia v: 545.29.06
    alternate: nouveau,nvidia_drm non-free: 545.xx+ status: current (as of
    2023-11; EOL~2026-12-xx) arch: Pascal code: GP10x process: TSMC 16nm
    built: 2016-2021 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3
    speed: 8 GT/s bus-ID: 03:00.0 chip-ID: 10de:1bb3 class-ID: 0302
  Device-2: NVIDIA TU117GLM [Quadro T400 Mobile] driver: nvidia v: 545.29.06
    alternate: nouveau,nvidia_drm non-free: 545.xx+ status: current (as of
    2023-11; EOL~2026-12-xx) arch: Turing code: TUxxx process: TSMC 12nm FF
    built: 2018-2022 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3
    speed: 8 GT/s ports: active: none off: DP-1,DP-2,DP-3 empty: none
    bus-ID: 04:00.0 chip-ID: 10de:1fb2 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.9 with: Xwayland v: 23.2.2
    compositor: gnome-shell driver: X: loaded: nvidia
    gpu: nvidia,nvidia-nvswitch display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3840x2160 s-dpi: 96 s-size: 1016x572mm (40.00x22.52")
    s-diag: 1166mm (45.9")
  Monitor-1: DP-1 pos: top-left res: 1920x1080 hz: 60 dpi: 94
    size: 521x293mm (20.51x11.54") diag: 598mm (23.53") modes: N/A
  Monitor-2: DP-3 pos: primary,bottom-c res: 1920x1080 hz: 60 dpi: 94
    size: 521x293mm (20.51x11.54") diag: 598mm (23.53") modes: N/A
  Monitor-3: DP-5 pos: top-right res: 1920x1080 hz: 60 dpi: 94
    size: 521x293mm (20.51x11.54") diag: 598mm (23.53") modes: N/A
  Monitor-4: DVI-D-1-0 size-res: N/A modes: N/A
  API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 1
    drv: nvidia device: 4 drv: swrast gbm: drv: nvidia surfaceless: drv: nvidia
    x11: drv: nvidia inactive: wayland,device-2,device-3
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 545.29.06
    glx-v: 1.4 direct-render: yes renderer: NVIDIA T400/PCIe/SSE2
    memory: 1.95 GiB
  API: Vulkan v: 1.3.268 layers: 6 device: 0 type: discrete-gpu
    name: NVIDIA T400 driver: nvidia v: 545.29.06 device-ID: 10de:1fb2
    surfaces: xcb,xlib device: 1 type: discrete-gpu name: Tesla P4
    driver: nvidia v: 545.29.06 device-ID: 10de:1bb3 surfaces: N/A

My guess is, it is a misbehaving plymouth.
Nvidia here is smooth on the latest tumbleweed snapshot.
Lately the HP logo and the rotating splash screen showed up again til now with the new kernel.
It’s been a while I have not seen it during boot, it only shows up here only when shutting down.

Yesterday I had an update, although nothing related to Nvidia but I’m not sure it was anything there affecting Plymouth.

Today I got this on the screen which did not appear before: openSUSE Paste

@no5xmega Can you show the output from cat /proc/cmdline.

Yup, surething :

jimmy@192-168-0-105:~> sudo cat /proc/cmdline
[sudo] password for root: 
BOOT_IMAGE=/boot/vmlinuz-6.6.2-1-default root=UUID=2ef03e41-4641-449b-b99d-4c325940dd28 splash=silent mitigations=auto quiet security=apparmor

So I’ve updated again a moment ago since a new version of Nvidia driver is available ( 545.29.6 ) and … I have still the boot problem except that the screen do not glitch out like it used to do but it still take time to boot and on the last 3 consecutive reboot after the update I’ve seen the 3 green dot loader 2 times and the usual spinner one time, I have also more “Flip event timeout on head 0/1” logged for some reasons…

But I’ve noticed something interesting after a cat /var/log/boot.log ( full logs → openSUSE Paste )
I can see two line related to resuming from hibernation

[  OK  ] Reached target Initrd Root Device.
         Starting Resume from hibernation...
[  OK  ] Finished Resume from hibernation.

Maybe it’s normal and it doesn’t actually try to resume from hibernation since it’s a fresh boot but the very first time I’ve encountered the long broken boot was before the faulty update when I’ve accidentally put my computer to hibernation and try to resume it, it did result in a long broken boot and no session resumed so maybe it could be related to that ?

It’s important to mention that I have enabled “nvidia-hibernate” service

systemctl status nvidia-hibernate                                                                                                                                                                                     

○ nvidia-hibernate.service - NVIDIA system hibernate actions
     Loaded: loaded (/usr/lib/systemd/system/nvidia-hibernate.service; enabled; preset: disabled)
     Active: inactive (dead)

I will continue my investigation tomorrow there’s also something that could be tested, adding fbdev=1 to the boot parameters but I’m not sure how I’m supposed to do that from Grub so before breaking something …

This is reaaaaaaaally strange. I’ve been booting my desktops for 2-3 years now and never really paid too close attention to the actual boot screen output.

Except earlier today, I decided to take a quick video starting at the Grub boot selection screen, for about 5 seconds long. During playback, I stopped the video and took a screenshot - it’s what I’ve posted below.

I was gonna post about this and ask, and then I read your Reply. I never use Hibernate or Sleep mode on the desktops (and only Sleep on laptops).

This screen is shown, stops for about 2-3 seconds, the screen is cleared, then the startup sequence begins.

But yea, it’s a curious subject, but I don’t think it affects anything … as a I said, I never use Hibernate on any of my TW machines.
.

1 Like