MantisBT - Issues

0000623: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 8

Wed, 10 Jun 2026 21:49:37 +0000

Currently, the maximum queue depth supported for gVNIC on overcommited Gen3+ VMs such as N4 is 1K, whereas the maximum queue depth supported on Gen1/Gen2 VMs is 2K. Customers who are migrating their workloads from N2 to N4 have requested higher queue depth support on N4 VMs.

GVE driver changes to support greater than 1K queue depth for overcommitted Gen3+ have been upstreamed to Linux kernel recently:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=a2f19184014f
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=07993df56091

0000621: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 10

Fri, 05 Jun 2026 13:20:21 +0000

0000622: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 9

Thu, 04 Jun 2026 17:48:30 +0000

0000631: [AlmaLinux][RDMA/DPDK] [Backport] mana_ib patch to distro to support RX traffic stop on MANA hotplug events

Thu, 04 Jun 2026 14:13:25 +0000

Request backport of the following patch to all active kernels.

This patch correctly shutdown receive traffic when MANA device is hot plugged from DPDK. Without this patch, the kernel may send interrupts under heavy traffic when MANA is hot removed.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v7.1-rc1&id=dbeb256e8dd87233d891b170c0b32a6466467036

0000630: Downloading ISO's from your server

Tue, 02 Jun 2026 05:19:00 +0000

When downloading ISO files from repo.almalinux.org, the Content-Length header is missing from GET responses.
However doing a HEAD request to the same URL returns it correctly.

Example URL:
https://repo.almalinux.org/almalinux/10/live/x86_64_v2/AlmaLinux-10.2-x86_64_v2-Live-KDE.iso
HEAD returns: Content-Length: 2638260224
GET returns: no Content-Length header
This means download managers cannot show progress, percentage or ETA without using a workaround such as doing a HEAD request first.

0000587: Unable to install perl-DBD-MySQL-4.053 in a MySQL 8.4 (libmysqlclient.so.24)

Tue, 02 Jun 2026 05:18:37 +0000

Unable to install perl-DBD-MySQL-4.053 in a MySQL 8.4 (libmysqlclient.so.24) environment
due to a dependency on libmysqlclient.so.21.

0000629: SSSD install/setup issue due to insufficient permissions and ownership

Fri, 29 May 2026 12:36:33 +0000

Hello,
we're having trouble connecting AlmaLinux 10.2 to an Active Directory using SSSD. Previously we were able to set it up just fine using AlmaLinux 10.1.
The following text describes the issues and how to solve them. However, it would be better if the issues were fixed at the source.
Firstly, sssd doesn't own the paths /var/lib/sss and /var/log/sssd.

# systemctl status sssd
× sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Fri 2026-05-29 11:10:06 UTC; 7min ago
Invocation: cddf4fea77444dab88d80a37de5875f2
Process: 4346 ExecStartPre=/bin/chown -f -R -H root:sssd /etc/sssd (code=exited, status=0/SUCCESS)
Process: 4348 ExecStartPre=/bin/chmod -f -R g+r /etc/sssd (code=exited, status=0/SUCCESS)
Process: 4350 ExecStartPre=/bin/chmod -f g+x /etc/sssd (code=exited, status=0/SUCCESS)
Process: 4352 ExecStartPre=/bin/chmod -f g+x /etc/sssd/conf.d (code=exited, status=0/SUCCESS)
Process: 4354 ExecStartPre=/bin/chmod -f g+x /etc/sssd/pki (code=exited, status=0/SUCCESS)
Process: 4356 ExecStartPre=/bin/sh -c /bin/chown -f -h sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=1/FAILURE)
Process: 4358 ExecStartPre=/bin/chown -f -R -h sssd:sssd /var/lib/sss/gpo_cache (code=exited, status=0/SUCCESS)
Process: 4360 ExecStartPre=/bin/sh -c /bin/chown -f -h sssd:sssd /var/log/sssd/*.log* (code=exited, status=1/FAILURE)
Process: 4362 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=8)
Main PID: 4362 (code=exited, status=8)
Mem peak: 2.3M
CPU: 49ms

May 29 11:10:06 redacted sssd[4362]: Could not open file [/var/log/sssd/sssd.log]. Error: [13][Permission denied]
May 29 11:10:06 redacted sssd[4362]: Error opening log file, falling back to stderr
May 29 11:10:06 redacted sssd[4362]: [sssd] [main] (0x3f7c0): Started under uid=997 (euid=997) : gid=997 (egid=997) with SECBIT_KEEP_CAPS = 0 and following capabilities:
May 29 11:10:06 redacted sssd[4362]: (nothing)
May 29 11:10:06 redacted sssd[4362]: [sssd] [sss_ini_call_validators] (0x0020): [rule/allowed_sssd_options]: Attribute 'config_file_version' is not allowed in section 'sssd'. Check for typos.
May 29 11:10:06 redacted sssd[4362]: [sssd] [confdb_write_ini] (0x0010): Can't delete old '/var/lib/sss/db/config.ldb'
May 29 11:10:06 redacted sssd[4362]: [sssd] [main] (0x0010): Failed to write config DB: 'Permission denied'
May 29 11:10:06 redacted systemd[1]: sssd.service: Main process exited, code=exited, status=8/n/a
May 29 11:10:06 redacted systemd[1]: sssd.service: Failed with result 'exit-code'.
May 29 11:10:06 redacted systemd[1]: Failed to start sssd.service - System Security Services Daemon.

# ls -la /var/log/sssd
total 4
drwxrwx---. 2 root root 6 Apr 14 00:00 .
drwxr-xr-x. 9 root root 4096 May 29 11:09 ..

# ls -la /var/lib/sss
total 4
drwxrwxr-x. 10 root root 120 May 29 11:09 .
drwxr-xr-x. 27 root root 4096 May 29 11:09 ..
drwxrwx---. 2 root root 6 Apr 14 00:00 db
drwxrwx--x. 2 root root 6 Apr 14 00:00 deskprofile
drwxrwx---. 2 sssd sssd 6 Apr 14 00:00 gpo_cache
drwxrwx---. 2 sssd sssd 6 Apr 14 00:00 keytabs
drwxrwxr-x. 2 root root 6 Apr 14 00:00 mc
drwxrwxr-x. 3 root root 21 May 26 13:48 pipes
drwxrwxr-x. 3 root root 28 May 26 13:48 pubconf
drwxrwx---. 2 root root 6 Apr 14 00:00 secrets

The second issue is that the current file permissions for executables are insufficient, that are required for running sssd.

# ls -la /usr/libexec/sssd/
total 2200
drwxr-xr-x. 2 root root 4096 May 29 11:09 .
drwxr-xr-x. 30 root root 4096 May 29 11:09 ..
-rwxr-xr-x. 1 root root 40608 Apr 14 00:00 gpo_child
-rwxr-x---. 1 root root 140016 Apr 14 00:00 krb5_child
-rwxr-x---. 1 root root 53112 Apr 14 00:00 ldap_child
-rwxr-xr-x. 1 root root 73384 Apr 14 00:00 p11_child
-rwxr-x---. 1 root sssd 32368 Apr 14 00:00 proxy_child
-rwxr-x---. 1 root sssd 32416 Apr 14 00:00 selinux_child
-rwxr-xr-x. 1 root root 186968 Apr 14 00:00 sssd_autofs
-rwxr-xr-x. 1 root root 261800 Apr 14 00:00 sssd_be
-rwxr-xr-x. 1 root root 15840 Apr 14 00:00 sssd_check_socket_activated_responders
-rwxr-xr-x. 1 root root 215640 Apr 14 00:00 sssd_kcm
-rwxr-xr-x. 1 root root 266888 Apr 14 00:00 sssd_nss
-rwxr-xr-x. 1 root root 195056 Apr 14 00:00 sssd_pac
-rwxr-x---. 1 root root 306768 Apr 14 00:00 sssd_pam
-rwxr-xr-x. 1 root root 195176 Apr 14 00:00 sssd_ssh
-rwxr-xr-x. 1 root root 195224 Apr 14 00:00 sssd_sudo
-rwxr-xr-x. 1 root root 15800 Apr 14 00:00 sss_signal

This issue can be resolved by running the three commands below and then restarting the SSSD service.

chown -R sssd:sssd /var/lib/sss
chown sssd:sssd /var/log/sssd
chmod o+rx /usr/libexec/sssd/*

0000628: [AlmaLinux][Mana][Backport] net: mana: Avoid queue struct allocation failure under memory fragmentation

Thu, 28 May 2026 13:06:37 +0000

Backport Justification (ADO)

1. Problem Summary

MANA driver does large contiguous kmallocs during queue setup that may fail in system with highly fragmented memory:

- mana_create_txq (tx_qp array): 0000005:0000002.2 MB @ 64 queues
- mana_create_rxq (rxq + flex array): 0000005:0000002.4 MB per queue @ depth 8192
- mana_pre_alloc_rxbufs: 0000007:0000004 MB @ 64 queues / depth 8192

Failures occur on driver open and on runtime reconfig (channels, ring size, MTU).

Mellanox (mlx5) previously hit the same class of issue — large contiguous allocations (0000057:0000128 KB / 0000198:0000512 KB) failed on fragmented systems and were fixed by switching to smaller page-sized units.
2. Impact on Customer VMs

- Driver load failure → VM loses networking / availability.
- Runtime reconfig (ethtool, MTU) fails → blocks workload tuning.
- Worst on long-running VMs, high-memory workloads (AI/HPC, in-memory DBs), and max queue/ring configs (64 queues, depth 8192).
3. Reproduction Details (If Available)

- Trigger: High memory fragmentation + MANA driver load / queue reconfiguration.
- Symptom: kmalloc order-N allocation failure during mana_create_txq / mana_create_rxq / mana_pre_alloc_rxbufs; driver open/reconfig returns -ENOMEM.
- No deterministic repro; observed on fragmented systems and reproducible by forcing high-order allocation pressure.
4. Relationship to Larger Feature

None
5. Patch Criticality

- Medium
- Customer-visible loss of VM networking on memory fragmented systems on reloading driver or reconfiguring queue depth, queue size etc.
6. Classification (Select All That Apply)

- Bug fix – driver fails to load or reconfigure queues when contiguous high-order memory is unavailable due to memory fragmentation.
7. Upstream References

Upstream commit:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=3af0820c878e
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d07efe5a6e64

Request backport of the above patches to the active kernel versions. Thanks.

0000627: [AlmaLinux][MANA][Backport][Distros] porting patch: net: mana: Expose hardware diagnostic info via debugfs

Wed, 27 May 2026 13:00:42 +0000

Hello,

Problem Summary
Add debugfs entries to expose hardware configuration and diagnostic information that aids in debugging driver initialization and runtime operations without adding noise to dmesg.

The debugfs directory for each PCI device is named using pci_name() (the unique BDF address), and its creation and removal is integrated into mana_gd_setup() and mana_gd_cleanup_device() respectively, so that all callers (probe, remove, suspend, resume, shutdown) share a single code path.
Impact on Customer VMs
All VMs
Repro details
Additional details exposed from debugfs via this patch
Relationship to large feature
None
Patch Criticality
Medium

Request backport of the following patch to all active LTS Kernel versions.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c227f8aaf22c

0000626: [AlmaLInux][Backport][MANA] net: mana: validate rx_req_idx to prevent out-of-bounds array access

Wed, 27 May 2026 12:30:41 +0000

Hello,

This is a Sev 2 on our side with impact on all customer VM's

Problem Summary
In mana_hwc_rx_event_handler(), rx_req_idx is derived from
sge->address in DMA-coherent memory. In Confidential VMs
(SEV-SNP/TDX), this memory is shared unencrypted and HW can modify
WQE contents at any time. No bounds check exists on rx_req_idx,
which can lead to an out-of-bounds access into reqs[].

Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before
using it to index the reqs[] array.
Impact on Customer VMs
All VMs

Requesting backport of the below fix to all LTS kernels versions.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b809d0409991

0000625: ssss

Wed, 27 May 2026 12:29:10 +0000

ssss

0000624: [AlmaLinux][Backport][MANA] net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer

Thu, 21 May 2026 06:02:56 +0000

This is a Sev 2 on our side with customer facing issues.

Problem Summary
In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from
DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp()
re-reads the same field from the same DMA buffer for test_bit() and
pointer arithmetic.

DMA-coherent memory is mapped uncacheable on x86 and is shared,
unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes
directly to host-visible memory. A H/W can modify the value
between the check and the use, bypassing the bounds validation.

Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a
stack-local variable in mana_hwc_rx_event_handler(), and passing the
validated value as a parameter to mana_hwc_handle_resp().
Impact on Customer VMs
All VMs

Requesting backport of the below fix to all LTS kernels.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=35f0f0a2536a

0000619: System Health Check

Thu, 09 Apr 2026 20:08:51 +0000

Automated verification report

0000618: [AlmaLinux][Mana][Backport] P0] Rx CQE coalescing Feature

Wed, 08 Apr 2026 00:29:03 +0000

Request backport of the following patches

kernel Space
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d01440e10a82cae2c4a28c76e46e6a8b94b27a84
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c2fe3ff3d66d6f53ec5857c277fae5b3ff9881c1
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=dc3d720e12f602059490c1ab2bfee84a7465998f

UserSpace
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?h=next&id=d35d87fbcda97fe31df79d62277743214641892a
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?h=next&id=bf023af442f63e16f1699128c7ce467eddc6d340

0000617: h5pfc script uses incorrect `includedir` for OpenMPI on AlmaLinux 10

Sat, 28 Mar 2026 20:00:12 +0000

After installing parallel HDF5 via `dnf install hdf5-openmpi`, the `h5pfc` compiler wrapper fails due to an incorrect include directory.

File affected:
`/usr/lib64/openmpi/bin/h5pfc`

The script defines an `includedir` that does not point to the correct location of OpenMPI Fortran modules, causing compilation failures for parallel HDF5 Fortran programs.

**System:**

* OS: AlmaLinux 10
* Architecture: x86_64

**Package Information:**
(Output of `rpm -qi hdf5-openmpi`)

```
Name : hdf5-openmpi
Version : 1.14.5
Release : 1.el10_0
Architecture: x86_64
Install Date: Thu 26 Mar 2026 12:10:19 PM EDT
Group : Unspecified
Size : 7476900
License : BSD-3-Clause
Signature :
RSA/SHA256, Thu 24 Oct 2024 11:50:21 AM EDT, Key ID 33d98517e37ed158
Source RPM : hdf5-1.14.5-1.el10_0.src.rpm
Build Date : Thu 24 Oct 2024 09:51:10 AM EDT
Build Host : buildvm-x86-09.iad2.fedoraproject.org
Packager : Fedora Project
Vendor : Fedora Project
URL : https://www.hdfgroup.org/solutions/hdf5/
Bug URL : https://bugz.fedoraproject.org/hdf5
Summary : HDF5 openmpi libraries
Description :
HDF5 parallel openmpi libraries
```

**mpifort configuration:**
(Output of `mpifort --showme`)

```
gfortran -I/usr/include/openmpi-x86_64 -I/usr/lib64/openmpi/lib -L/usr/lib64/openmpi/lib -Wl,-rpath -Wl,/usr/lib64/openmpi/lib -Wl,--enable-new-dtags -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
```

**Problem:**
The `includedir` in `h5pfc` does not match the actual OpenMPI module include path used by the system compiler toolchain.

**Fix / Workaround:**
Manually editing the script resolves the issue:

```bash
sudo nano /usr/lib64/openmpi/bin/h5pfc
```

Change:

```bash
includedir="..."
```

To:

```bash
includedir="/usr/lib64/gfortran/modules/openmpi/"
```

After this change, `h5pfc` works correctly and parallel HDF5 Fortran programs compile successfully.

**Expected behavior:**
`h5pfc` should automatically use the correct OpenMPI Fortran module include path without requiring manual modification.

**Actual behavior:**
Compilation fails unless the script is manually edited.

**Additional notes:**
The correct include paths appear to be consistent with the output of `mpifort --showme`, suggesting a mismatch between the HDF5 wrapper configuration and the OpenMPI toolchain configuration.

0000579: Dependency for perl-DBD-MySQL-4.053-1.el9.x86_64 ignores MariaDB Installation

Fri, 27 Mar 2026 21:21:35 +0000

The package perl-DBD-MySQL-4.053-1.el9.x86_64 attempts to install the MySQL (Oracle) version of dependencies instead of relying upon the MariaDB common/libs
=============================================================================================================================================
Error: Transaction test error:
file /usr/share/mysql/charsets/Index.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/armscii8.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/ascii.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp1250.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp1251.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp1256.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp1257.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp850.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp852.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/cp866.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/dec8.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/geostd8.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/greek.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/hebrew.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/hp8.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/keybcs2.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/koi8r.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/koi8u.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/latin1.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/latin2.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/latin5.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/latin7.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/macce.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/macroman.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64
file /usr/share/mysql/charsets/swe7.xml from install of mysql-common-8.0.43-1.el9_6.x86_64 conflicts with file from package MariaDB-common-10.11.15-1.el9.x86_64

0000616: Latest grub2-efi-aa64 update fails to boot the system

Wed, 25 Mar 2026 00:06:21 +0000

The latest grub2-efi-aa64 patch to address CVE-2025-61662 updates grubaa64.efi under /boot/efi/EFI/almalinux results in

Synchronous Exception at 0xXXXXXXXXX

during boot up.

Reproduced in my installation of Almalinux 10.x running inside UTM in a MacBook Pro M4.

0000615: Linux reports optimal_io_size of 16776704 causing LVM data alignment inconsistency

Thu, 19 Mar 2026 10:23:47 +0000

Hi,

I've been noticing LVM alignment inconsistencies and performance issues with SAS HDDs. I found out that sysfs is reporting 16776704 optimal_io_size even though the Disks' VPD does not report maximum transfer length.
LVM is using this value to set the first physical extent of the physical volume. This does not align with the sector size of the disks of 4096 KB. I had to disable data alignment detection of LVM as a workaround.

The SAS controller within the machine is "Broadcom / LSI Fusion-MPT 12GSAS/PCIe Secure SAS38xx [1000:00e6]" and kernel is 5.14.0-570.28.1.el9_6.x86_64.

Thank you.

0000610: [AlmaLinux][Mana][Backport] net: mana: Fix use-after-free in reset service rescan path & net: mana: Fix double destroy_workqueue

Tue, 17 Mar 2026 17:09:57 +0000

Hi,
Request backport of the following patches on all active kernel versions. Thanks.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/ethernet/microsoft/mana?id=9bf66036d686b9a67000ba22bd94be13a4ea79ac
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/ethernet/microsoft/mana?id=3387a7ad478b46970ae8254049167d166e398aeb
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/ethernet/microsoft/mana?id=f975a0955276579e2176a134366ed586071c7c6a

Regards,
Sriram.

0000614: Kickstart installation crashes on package usbguard-selinux

Mon, 16 Mar 2026 18:59:14 +0000

Hello, running kickstart installation with AlmaLinux 10.1 iso, fails at installing package 'usbguard-selinux'.

0000613: gnome-remote-desktop not working depending on networking configuration

Mon, 16 Mar 2026 17:59:44 +0000

Hello, I'm using gnome-remote-desktop in AlmaLinux 10.1 (gnome 47).
I've applied the following instructions: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/administering_rhel_by_using_the_gnome_desktop_environment/remotely-accessing-the-desktop
I'm using the "headless multiuser" scenario. (chapter 1.5)

It probably works for majority of people, but I've found that it fails every time when using isolated network, static ip address, no default gateway.

0000612: kvdo.ko is not compatible with 9.7 kernels

Mon, 16 Mar 2026 16:43:12 +0000

# echo /lib/modules/5.14.0-611.5.1.el9_7.x86_64/extra/kmod-kvdo/vdo/kvdo.ko | weak-modules --dry-run --add-modules --verbose
Module kvdo.ko from kernel 5.14.0-611.5.1.el9_7.x86_64 is not compatible with kernel 5.14.0-611.34.1.el9_7.x86_64 in symbols: dm_noflush_suspending dm_put_device dm_device_name dm_unregister_target dm_set_target_max_io_len dm_disk dm_register_target dm_table_get_mode dm_table_get_md dm_get_device
Falling back weak-modules state for kernel 5.14.0-611.34.1.el9_7.x86_64
Module kvdo.ko from kernel 5.14.0-611.5.1.el9_7.x86_64 is not compatible with kernel 5.14.0-611.36.1.el9_7.x86_64 in symbols: dm_noflush_suspending dm_put_device dm_device_name dm_unregister_target dm_set_target_max_io_len dm_disk dm_register_target dm_table_get_mode dm_table_get_md dm_get_device
Falling back weak-modules state for kernel 5.14.0-611.36.1.el9_7.x86_64
Module kvdo.ko from kernel 5.14.0-611.5.1.el9_7.x86_64 is not compatible with kernel 5.14.0-611.38.1.el9_7.x86_64 in symbols: dm_noflush_suspending dm_put_device dm_device_name dm_unregister_target dm_set_target_max_io_len dm_disk dm_register_target dm_table_get_mode dm_table_get_md dm_get_device
Falling back weak-modules state for kernel 5.14.0-611.38.1.el9_7.x86_64
Skipping depmod for non-installed kernel 5.14.0-611.5.1.el9_7.x86_64

0000611: [AlmaLinux][Mana][Backport] net: mana: Trigger VF reset/recovery on health check failure due to HWC timeout

Thu, 12 Mar 2026 14:01:09 +0000

0000609: akmods rebuilds nvidia kmod on every boot on x86_64_v2 — weak-updates directory not RPM-owned

Mon, 09 Mar 2026 06:36:52 +0000

On AlmaLinux 10 x86_64_v2, akmods rebuilds the nvidia kmod from source on
every boot (0000017:0000020 seconds delay) despite the module being correctly installed
and functional.

Root cause: The check_kmod_up2date function in akmods uses:
rpm -qf "/lib/modules/${kernelver}/extra/${kmodname}/"
to verify the installed kmod package.

On x86_64_v2, the kmod RPM (kmod-nvidia-6.12.0-124.el10_1-580.95.05-1.el10.x86_64_v2)
only installs files into the kernel it was built for:
/lib/modules/6.12.0-124.13.1.el10_1.x86_64_v2/extra/nvidia/

For newer kernels, weak-modules creates symlinks in:
/lib/modules/6.12.0-124.38.1.el10_1.x86_64_v2/weak-updates/nvidia/

However the extra/nvidia/ directory for the newer kernel is NOT owned by
any RPM package — it is created by akmods itself during the rebuild.
Therefore rpm -qf returns "not owned by any package", version comparison
fails, and akmods triggers a full rebuild every boot.

The rebuild completes successfully but installs nothing new since the
package is already installed — confirmed by DNF output:
"Package already installed. Nothing to do."

This is a packaging bug specific to x86_64_v2 — the kmod RPM does not
include weak-updates entries or extra/ directories for kernels beyond
the one it was built against, and akmods does not check weak-updates
paths during its up-to-date verification.

Workaround applied:
sudo systemctl edit akmods.service

[Service]
ExecStart=
ExecStart=/bin/bash -c 'modinfo nvidia -k $(uname -r) -n 2>/dev/null | grep -q "nvidia.ko" && exit 0 || exec /usr/sbin/akmods --from-init'

This replaces the broken version check with a direct modinfo query,
skipping the rebuild when the module is already available for the
running kernel regardless of installation path.

0000608: Possible CC of "Compile bug: internal compiler error: Segmentation fault #20083"

Fri, 06 Mar 2026 13:59:10 +0000

Almalinux 10.1 on ppc64le (IBM Power 10) - Attempting to build llama.cpp fails with Internal Compiler Error.

May be similar to https://github.com/ggml-org/llama.cpp/issues/20083