Hello ladies and gents,
I am an amateur Linux user and have been on OpenSuse for the past few weeks.
I updated the Kernal today using: Sudo zypper dup.
However afterwards it would not start and I would receive this answer:
Failed to start X display manager.
I used my snapshot and reverted back to my previous time and it is working well.
I’m pretty sure it is due to the Nvidia package but not certain.
How do I update the kernel without having this issue?
Thank you very much
From Neofetch of my system:
OS: openSUSE Tumbleweed
Host: GL65 Leopard 10SDR
Kernel: 6.11.3-1-default
Uptime: 9 mins
'Packages: 3176 (rpm), 21
Shell: bash 5.2.37
Resolution: 1920x1080
DE: MATE 1.28.0
WM: Metacity (Marco)
Theme: Blue-Submarine [G
Icons: mate [GTK2/3]
Terminal: mate-terminal
Terminal Font: Monospace
CPU: Intel i7-10750H (12
GPU: NVIDIA GeForce GTX
GPU: Intel CometLake-H G
Memory: 1574MiB / 15805M
I tried to reinstall the update again but it continues to say
“Failed to start X display manager”
Also having a hard time with software update on Yast - it gets stuck and says it has an issue with Packman…
Could these issues be related?
Thank you
They well could be. Optimal update method is zypper dup, providing maximum dependency resolution. Is this what you last tried? There are currently known Packman issues that are expected to resolve soon. If you have any Mesa packages installed from Packman, switch them all back to opensuse and you might be good to go right away.
Inxi utility does much better than neofetch in providing data useful to would be assistants.
MrMazda thank you very much for the quick response, I really appreciate the help. Yes sir I did use zypper dup and then when I restart the computer it gives me the failed X display manager on a black screen.
I will use your suggestions and will see what happens!
Cheers!
Did you get an update of the nvidia drivers. Note in TW this often lags behind kernel updates
MrMazda - I was able to change my Mesa repository which fixed my software update issue on Yast - thank you!
I reinstalled the kernel with zypper dup but I had the failure display manager error again.
Gogalthorp - I believe I updated by nvidia drivers - I performed the zypper update/refresh and it stated they were uptodate…
> inxi -GSaz | wc -l
31
> inxi -GSaz
System:
Kernel: 5.14.21-150500.55.83-default arch: x86_64 bits: 64 compiler: gcc
v: 7.5.0 clocksource: tsc avail: hpet,acpi_pm
parameters: root=LABEL=root10zt12 ipv6.disable=1 net.ifnames=0 noresume
consoleblank=0 preempt=full mitigations=auto i915.enable_guc=2 vga=791
video=1440x900@60
Desktop: KDE v: 3.5.10 tk: Qt v: 3.3.8c wm: kwin with: kicker vt: 7 dm:
1: KDM 2: XDM Distro: openSUSE Leap 15.5
Graphics:
Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel
arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports: active: HDMI-A-2
empty: DP-1, DP-2, HDMI-A-1, HDMI-A-3 bus-ID: 00:02.0 chip-ID: 8086:5912
class-ID: 0300
Display: x11 server: X.Org v: 1.21.1.4 compositor: kwin driver: X:
loaded: modesetting alternate: fbdev,intel,vesa dri: iris gpu: i915
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (15.98x10.00")
s-diag: 479mm (18.85")
Monitor-1: HDMI-A-2 mapped: HDMI-2 model: Samsung SMS24A850
serial: <filter> built: 2012 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 518x324mm (20.39x12.76") diag: 611mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 720x400
API: EGL v: 1.5 hw: drv: intel iris platforms: device: 0 drv: iris
device: 1 drv: swrast gbm: drv: iris surfaceless: drv: iris x11: drv: iris
inactive: wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 22.3.5 glx-v: 1.4
direct-render: yes renderer: Mesa Intel HD Graphics 630 (KBL GT2)
device-ID: 8086:5912 memory: 30.08 GiB unified: yes
API: Vulkan v: 1.2.133 layers: 1 device: 0 type: integrated-gpu name: Intel
HD Graphics 630 (KBL GT2) driver: mesa intel v: 22.3.5
device-ID: 8086:5912 surfaces: xcb,xlib
>
More than the above from inxi is generally irrelevant to graphics issues.
Is your 6.11.3 kernel also not starting X? I am generally unaffected by this kind of problem, because once an initrd has proven its worth, I apply chattr +i against it to make it immutable, unable to be regenerated (or removed) without removing the immutable bit, thus making prior kernels good backup when new one fails to do its job properly.
mrmazda - If I am not mistaken my 6.11.3 Kernel is working fine, but it is when I update it to the new version I have the issue. When I update it I have the problem, then I revert to my last snapshot and it works fine.
mrmazda -just want to thank you for your help, I do appreciate your time.
I am not aware of whether NVidia’s proprietary drivers are ready to support 6.11.8. Others in this forum would know this because they use them themselves, while I never do. There is often lag between when a new kernel is released, and suitable proprietary NVidia drivers are ready for duty with it.
To keep operating at maximum security level, what I would do is boot the newest installation state (after the most recent zypper dup, which provided the 6.11.8 kernel), but choose to boot the prior kernel from the Grub menu instead of the 6.11.8 default. Next I would remove 6.11.8 so that 6.11.3 becomes the default, and lock the kernel so that 6.11.8 is not reinstalled before being aware NVidia’s drivers are ready to support it.
Nvidia driver modules get build automatically on the user machine when a new kernel arives. It is a persistent missinformation that the driver needs to match the kernel and that they are lagging after each other.
Written from an actual Tumbleweed snapshot 20241121 with proprietary G06 Nvidia drivers (nvidia-driver-G06-550.127.05-27.1) from the repo for openSUSE.
Thank you mrmazda for your help, I really appreciate it. However I’m not sure that I know how to perform what you are suggesting…It may be a little over my head as I’m not that Linux savvy… 
Hey Hui, if the drivers are updated and not the issue would you have any recommendations? I appreciate your insight.
Cheers
WRT to booting from a choice of snapshots, I am virtually ignorant, as I have only one BTRFS filesystem among several hundred hardware installations, which is on a laptop given me with Leap already installed, and is only used maybe 2-3 hours per year. Thus, occasions to boot a snapshot have yet to occur here.
WRT NVidia drivers, I must defer to those who actually use them.
Locking is called “taboo” when running yast software. I use yast software very little, and would do:
sudo zypper al kernel-defaul*
to lock all kernels default, or
sudo zypper al kernel-default-6.11.8*
to lock only 6.11.8. It is not necessary to unlock when wishing to install or remove a kernel-default while the lock exists. Zypper provides a menu from which to select how to proceed when a kernel-default installation or removal is attempted while a lock exists, one of which is to remove the lock. Locks that include any wildcard will not actually be removed, only ignored for the current transaction, contrary to zypper’s language.
Removing an unwanted kernel is simple in yast software, and:
sudo zypper rm kernel-default-6.11.8
is just one among other methods, the one I would most likely use.
Hi
Hope this helps.
Some years ago I had trouble with an Adobe update, so …
When zypper asks for a confirmation to install the updates I said NO.
Looked at the list of updates and chose, one by one, to INSTALL them.
Leaving Adobe until the end.
In YAST2 you would normally get a list of updates with a tick box (check box?) adjacent to it.
De-Select the Nvidia and try that.