Feedback after AlmaLinux 9.7 → 9.8 (Olive Jaguar) update on a production workstation/server**

Henri · May 31, 2026, 8:38am

HI, I would like to share a recent experience after upgrading an AlmaLinux 9.7 system to 9.8.

The system is a physical workstation/server:
Système d’exploitation : AlmaLinux 9.8
Version de KDE Plasma : 5.27.12
Version de KDE Frameworks : 5.116.0
Version de Qt : 5.15.9
Version de noyau : 5.14.0-687.5.3.el9_8.x86_64 (64-bit)
Plate-forme graphique : X11
Processeurs : 12 × Intel® Xeon® E-2276G CPU @ 3.80GHz
Mémoire : 46,5 Gio de mémoire vive
Processeur graphique : NVIDIA GeForce RTX 3080/PCIe/SSE2
Fabricant : Dell Inc.
Nom du produit : PowerEdge T340
with LVM storage, NVIDIA RTX 3080 (proprietary driver), KDE/SDDM, Flatpak applications, and several self-hosted service (partial :OCIS, Ollama, Qdrant, Open-WebUI, etc.).

After the update and reboot into the new kernel, the system entered a degraded state a hang when opening services DBUS …:

Several core services failed to start correctly.
DBUS failed and services associated ; network, tty … system hang
The graphical environment became unavailable.
Some applications relying on the graphical stack no longer worked properly.
The overall behavior suggested that the boot environment was not fully consistent.
Only solution booting new kernel with modify boot : init=/bin/bash
Rebuilding manualy netwok, ssh, permit take the hand on distant ssh client ..

At first, NVIDIA old driver install appeared to be a possible cause, but subsequent investigation indicated that the issue was probably elsewhere. The most significant observation ( /boot FS was void afgetr update and first reboot !) was that normal operation was restored only after manually rebuilding the boot environment (initramfs/boot configuration) and performing additional recovery steps, but system hang with some dbus errors. patiently correcting each point pointed in logs or no, we arrive at a semi-stable system….

the system booted with several issues (root filesystem remounted read-only, bootloader repair required, PackageKit and local mail delivery failing). The root cause was not package corruption but a large number of SELinux labels lost during the recovery process. Thousands of AVC denials were generated and critical files such as DBus binaries were left with unlabeled_t contexts. Running a full SELinux relabel (touch /.autorelabel and reboot) restored all labels, fixed PackageKit, Discover, Postfix Maildir delivery and removed all remaining unlabeled files.

Returning temporarily to the previous kernel allowed the system to operate normally, which greatly helped the troubleshooting process. Now the system is in perfect state and running

At this stage I cannot identify the exact root cause, and I am not reporting this as a bug. However, I would be interested in hearing from other users who experienced similar issues after upgrading from AlmaLinux 9.7 to 9.8, especially on systems using:

LVM
NVIDIA proprietary drivers
KDE/SDDM
Complex service stacks running on the same host

If others have observed similar behavior or identified a specific cause, I would be grateful for any feedback.

Regards

Henri

redadmin · May 31, 2026, 1:02pm

Hi Henri,

Thank you for sharing the detailed notes.

At this stage, I would avoid attributing this directly to the AlmaLinux 9.8 update itself, because several layers seem to be involved: /boot, initramfs, bootloader, SELinux labels, DBus/systemd, NVIDIA, and the graphical stack.

As a temporary mitigation, I would suggest:

Boot the previous working kernel if available.
Verify that /boot and /boot/efi are correctly mounted.
Check the initramfs and bootloader configuration.
If many AVC denials or unlabeled_t contexts are found, perform a full SELinux relabel.

The SELinux issue may explain many of the DBus/systemd-related failures. If recovery work was done from an emergency or rescue environment, some files may have been created or modified without proper SELinux contexts.

So I would first focus on why /boot became inconsistent and why many SELinux labels were lost. Unless logs point directly to NVIDIA/KDE/SDDM, I would treat them as secondary victims for now.

Reference:
Red Hat Enterprise Linux 9 - Using SELinux

thanks

cako19 · June 3, 2026, 7:14am

Hello,

I have a similar (if not the same) problem, my computer with the new versions hangs just seconds after booting. Trying to access another tty doesn’t works and network isn’t initialized also. It justs freezes in the loading screen if activated or just after activating Wifi driver (which I don’t think is the problem as I have tried to blacklist it and did nothing) if removing quiet argument.

Booting 9.7 with kernel version 5.14.0-611.55.1.el9_7.x86_64 boots fine.

As Henri pointed out, I got dbus failures when booting the newer kernel.

This is the dbus log of the latest boots

– Boot d0a89482a11941349445785acf7453cf –
may 28 06:16:41 nuc systemd[1]: Starting D-Bus System Message Bus…
may 28 06:16:41 nuc systemd[1]: Started D-Bus System Message Bus.
may 28 06:16:41 nuc dbus-broker-lau[702]: Ready
may 28 06:16:44 nuc dbus-broker-launch[702]: Activation request for ‘org.freedesktop.resolve1’ failed: The systemd unit 'dbus-org.freedesktop.resolve1.serv>
may 30 06:26:12 nuc dbus-broker-launch[702]: Noticed file-system modification, trigger reload.
may 30 06:26:12 nuc dbus-broker-launch[702]: Noticed file-system modification, trigger reload.
may 30 06:26:12 nuc dbus-broker-launch[702]: Noticed file-system modification, trigger reload.
jun 03 06:47:49 nuc dbus-broker-launch[702]: Activation request for ‘org.freedesktop.nm_dispatcher’ failed.
jun 03 06:47:56 nuc dbus-broker-launch[702]: Activation request for ‘org.freedesktop.nm_dispatcher’ failed.
jun 03 06:47:56 nuc dbus-broker-launch[702]: Activation request for ‘org.freedesktop.nm_dispatcher’ failed.
jun 03 06:47:56 nuc dbus-broker[703]: Dispatched 1306856 messages @ 6(±7)μs / message.
jun 03 06:47:56 nuc systemd[1]: Stopping D-Bus System Message Bus…
jun 03 06:47:56 nuc systemd[1]: dbus-broker.service: Deactivated successfully.
jun 03 06:47:56 nuc systemd[1]: Stopped D-Bus System Message Bus.
jun 03 06:47:56 nuc systemd[1]: dbus-broker.service: Consumed 56.061s CPU time.
– Boot 5526d9639d2b4775bdeb8d7cac21f760 –
jun 03 08:10:30 nuc systemd[1]: Starting D-Bus System Message Bus…
jun 03 08:10:30 nuc systemd[1]: Started D-Bus System Message Bus.
jun 03 08:10:30 nuc dbus-broker-lau[717]: Ready
jun 03 08:10:33 nuc dbus-broker-launch[717]: Activation request for ‘org.freedesktop.resolve1’ failed: The systemd unit 'dbus-org.freedesktop.resolve1.serv

You can see the message “Activation request for ‘org.freedesktop.nm_dispatcher’ failed.“ after which the computer is unresponsive. Boot 5526d9639d2b4775bdeb8d7cac21f760 is the one with 9.7 kernel.

I also don’t really now, but it seems that after dnf-automatic runs, it performs a kernel reload if it was updated. This was in the dnf log from the last update some hours ago:

2026-06-03T06:42:48+0200 DEBUG Installed: kernel-5.14.0-687.5.4.el9_8.x86_64
2026-06-03T06:42:48+0200 DEBUG Installed: kernel-core-5.14.0-687.5.4.el9_8.x86_64
2026-06-03T06:42:48+0200 DEBUG Installed: kernel-modules-5.14.0-687.5.4.el9_8.x86_64
2026-06-03T06:42:48+0200 DEBUG Installed: kernel-modules-core-5.14.0-687.5.4.el9_8.x86_64
2026-06-03T06:42:48+0200 DEBUG Removed: kernel-5.14.0-611.54.6.el9_7.x86_64
2026-06-03T06:42:48+0200 DEBUG Removed: kernel-core-5.14.0-611.54.6.el9_7.x86_64
2026-06-03T06:42:48+0200 DEBUG Removed: kernel-modules-5.14.0-611.54.6.el9_7.x86_64
2026-06-03T06:42:48+0200 DEBUG Removed: kernel-modules-core-5.14.0-611.54.6.el9_7.x86_64

This is my system spec (it says it is running 9.7, but the booted kernel is the 9.7 version)

OS: AlmaLinux 9.8 (Olive Jaguar) x86_64
Host: NUC6CAYH
Kernel: 5.14.0-611.55.1.el9_7.x86_64
Uptime: 1 hour, 2 mins
Packages: 1466 (rpm)
Shell: bash 5.1.8
Terminal: /dev/pts/0
CPU: Intel Celeron J3455 (4) @ 2.300GHz
GPU: Intel Apollo Lake GT1 [HD Graphics 500]
Memory: 2081MiB / 7529MiB

Thank you.

Henri · June 3, 2026, 4:23pm

HI readmin & caco19,

Thanks for your feedback, my problem is solved, as I explained in my post. It wasn’t easy, but AlmaLinux is a perfectly structured and robust Linux OS, which made my task all the easier! After the error-free 9.8 update, my system wouldn’t boot with the old kernels and kept getting bogged down in multiple errors that started with DBUS. I realized that my filesystem was in OR order, and therefore my attempts to regain control were ineffective. This was the key that allowed me to get out of this predicament! A bit of trial and error, and careful communication allowed me to extricate myself from this predicament. I still don’t understand the mismatch that led to this seemingly simple situation. The remaining SELinux issues were just an indirect consequence, easily resolved with a command line and a reboot. The server is now stable and fully integrated. This morning, a new kernel update for the distribution was successfully completed. Good luck and helpful tips for those who may have experienced a similar mishap; the Almalinux kernel is robust, it has proven itself !

Best regards,

Henri

cako19 · June 3, 2026, 8:46pm

Hello,

I have done a further research and I think it is causing a kernel panic. I have enabled debug=7 , removed rhgb and quit and the last kernel log lines are this

BUG: kernel_NULL_pointer_dereference, address: 000000000000000

#PF: error_code(0x0000) - not-present page

PGD 0 P4D 0

Ooops: 0000 [#1] PREEMPT SMP NOPTI

CPU: 3 PID: 564 system-udevd Not tainted 5.14.0-687.5.4.el9_8.x86_64. #1

Hardware name: Intel (R) Client Systems NUC6CAYH/NUC6CAYB, BIOS AYAPLCEL.86A.0070.2021.0901.1556 09/01/2021

RIP: 0010:strstr+0x19/0x80

Code: cc 90 90 90 90 90 90 90 90 90 9 09 0 90 90 90 90 90 80 3e 00 74 68 48 89 f2 48 83 c2 01 80 3a 00 75 f7 49 89 f9 48 29 f2 74 3c <80< 3f 00 74 44 48 89 f9 48 83 c1 01 80 39 00 75 f7 48 29 f9 48 39

RSP: 0018:ffffcb2c80d2b878 EFLAGS: 00010212

RAX: FFFFFFFFFFC2062010 RBX FFFF88DE4532E028 RCX: 00000000000000000

RDX: 00000000000000004 RSI: fffffffffffffffffffc20660ac RDI: 00000000000000000

The problem seems to be in systemd-udevd.

Thanks

cako19 · June 11, 2026, 11:25am

Hello,

Has anyone encountered a solution to the problem? Or could you guide me to troubleshoot it?. I would prefer to fix it than to moving to debian.

Thank you.

Bedna · June 11, 2026, 1:14pm

Have you checked your filesystem(s)?
I assume @Henri meant RO (read only) mode.

Henri · June 11, 2026, 2:12pm

HI, 
Of course, my filesystems, and especially the root one, were checked. Otherwise, I wouldn't have been able to boot the kernel at level 1. The filesystems were compliant and in good condition! It's inexplicable to me that I was able to reboot in a healthy state with a root filesystem  bloched in R.O! Now  since 15 days after system is stable and OK !
Regards

Bedna · June 11, 2026, 2:32pm

Then what does above mean?
My previous post was aimed at @cako19 I only tagged you because to me it seemed to be the problem and interpreted OR as a typo and you meant RO.

I think it would be appreciated if you could clarify how you solved the issue so maybe cako could also solve his (if it’s the same problem)

cako19 · June 11, 2026, 2:58pm

The filesystem is totally fine. The system boots perfectly fine after selecting the 9.7 kernel. I don’t think it is something related to that.

Henri · June 11, 2026, 4:08pm

HI,

@cako19's problem seems different to me. He reports a kernel panic right from boot, which wasn't my case. My kernel would start, but the boot process would stop at the D-Bus level and when services started. I was able to boot the system by modifying the boot line and adding `init=/bin/bash`. This gave me a bash prompt, which allowed me to patiently investigate the blockages and isolate the D-Bus services and other blocking issues. And with patience, I was able to get my system back to a stable state! (I explained this in my previous posts.)
PS :  Let me know if you manage to boot into state 1;  with the latest kernel and provide the boot log messages!
Regards, 
Henri

cako19 · June 12, 2026, 7:14pm

Hello,

I kinda sort of managed to fix it. The problem is within i915 driver. It seems something is incompatible with the new kernel version.

I have used claude code to diagnose it and it found that running setting flag nomodeset, which starts the system without the graphics driver it boots fine, (but without gpu acceleration, which for a server it doesnt matter).

I will try to file a bug.

Thanks all for your help.