- AlmaLinux Users - AlmaLinux List Archives

cuda12 and cuda13.3 coexistence
by Oscar Conchillo-Solé 18 Jun '26

18 Jun '26

Dear All I' am a sysadmin with around 10 computers working with Almalinux 8 and 10 (I am in a small biology research institution) Several of them have cuda installed. We are Amber25 / pmemd24 heavy users so we need cuda-toolkit-12-8 which is the only one compatible. I try to keep my systems updated. I keep updating cuda every time a new one comes around. Recently I found that if I have cuda-toolkit-12-? I cannot install cuda-toolkit-13-3 or what is the same, I cannot update cuda-toolkit. If I have cuda-toolkit-13-3 installed I cannot install cuda-toolkit-12-?. I had no similar problems up until now. cuda-toolkit has been updated without a problem up until 13-2 and all previous 13 versions where coexisting with all 12. Here Is the error: # dnf -y --disablerepo=oneAPI update --exclude=kernel-ml* No repository match: oneAPI Last metadata expiration check: 0:59:10 ago on Thu 18 Jun 2026 11:06:46 AM CEST. Error: Problem 1: package cuda-cudart-devel-12-0-12.0.146-1.x86_64 from @System requires cuda-cccl-12-0, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-0 provided by cuda-cccl-12-0-12.0.140-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-0 provided by cuda-cccl-12-0-12.0.140-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-0 provided by cuda-cccl-12-0-12.0.90-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-0-12.0.146-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-0-12.0.140-1.x86_64 Problem 2: package cuda-cudart-devel-12-2-12.2.140-1.x86_64 from @System requires cuda-cccl-12-2, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.140-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.128-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.140-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-2 provided by cuda-cccl-12-2-12.2.53-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-2-12.2.140-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-2-12.2.140-1.x86_64 Problem 3: package cuda-cudart-devel-12-6-12.6.77-1.x86_64 from @System requires cuda-cccl-12-6, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-6 provided by cuda-cccl-12-6-12.6.77-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-6 provided by cuda-cccl-12-6-12.6.37-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-6 provided by cuda-cccl-12-6-12.6.77-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-6-12.6.77-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-6-12.6.77-1.x86_64 Problem 4: package cuda-cudart-devel-12-8-12.8.90-1.x86_64 from @System requires cuda-cccl-12-8, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-8 provided by cuda-cccl-12-8-12.8.90-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-8 provided by cuda-cccl-12-8-12.8.55-1.x86_64 from cuda-rhel8-x86_64 - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-8 provided by cuda-cccl-12-8-12.8.90-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-8-12.8.90-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-8-12.8.90-1.x86_64 Problem 5: package cuda-cudart-devel-12-9-12.9.79-1.x86_64 from @System requires cuda-cccl-12-9, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from cuda-rhel8-x86_64 - cannot install the best update candidate for package cuda-cudart-devel-12-9-12.9.79-1.x86_64 - cannot install the best update candidate for package cuda-cccl-12-9-12.9.27-1.x86_64 Problem 6: package cuda-libraries-devel-12-9-12.9.2-1.x86_64 from @System requires cuda-cccl-12-9 >= 12.9.27, but none of the providers can be installed - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from @System - package cccl-13-3-13.3.3.3.1-1.x86_64 from cuda-rhel8-x86_64 obsoletes cuda-cccl-12-9 provided by cuda-cccl-12-9-12.9.27-1.x86_64 from cuda-rhel8-x86_64 - package cuda-libraries-devel-13-3-13.3.0-1.x86_64 from cuda-rhel8-x86_64 requires cccl-13-3 >= 13.3.3.3.1, but none of the providers can be installed - package cuda-toolkit-13-3-13.3.0-1.x86_64 from cuda-rhel8-x86_64 requires cuda-libraries-devel-13-3 >= 13.3.0, but none of the providers can be installed - package cuda-toolkit-13.3.0-1.x86_64 from cuda-rhel8-x86_64 requires cuda-toolkit-13-3 >= 13.3.0, but none of the providers can be installed - cannot install the best update candidate for package cuda-toolkit-13.2.1-1.x86_64 - cannot install the best update candidate for package cuda-libraries-devel-12-9-12.9.2-1.x86_64 I'm using nvidia cuda repo here is my repolist: ]# dnf repolist repo id repo name appstream AlmaLinux 8 - AppStream baseos AlmaLinux 8 - BaseOS code Visual Studio Code cuda-rhel8-x86_64 cuda-rhel8-x86_64 docker-ce-stable Docker CE Stable - x86_64 elrepo ELRepo.org Community Enterprise Linux Repository - el8 epel Extra Packages for Enterprise Linux 8 - x86_64 extras AlmaLinux 8 - Extras libnvidia-container libnvidia-container powertools AlmaLinux 8 - PowerTools rpmfusion-free-updates RPM Fusion for EL 8 - Free - Updates By any chance anybody here knows if this is an unintended behavior or something planned? Do you believe that we could expect a different behavior in 13-4? Any suggestions to bypass this problem? thank you very much OCS -- Oscar Conchillo Solé Computational Biology Group Data Center Manager, Sysadmin and Bioinformatics Institut de Biotecnologia i Biomedicina (UAB) Department of Genetics and Microbiology (UAB) mail:Oscar.Conchillo@uab.cat telf: 0034 93581 4431

1 0

No audio after upgrading to 9.8
by Adrian P. van Bloois 31 May '26

31 May '26

Hi Folks, This Wednesday I upgraded to 9.8, everything went smoothly as usual. Only after the upgrade the audio was muted one way or another. On my old laptop it still functions but that is no aalternative. The card is different so I guess it has something to do with that, but I can't find it. THe card causing the prroblem is a Rapter Lake high definition. Any suggestion to how to solve this? Adrian -- Adri P. van Bloois It's never too late for early music!!!

1 0

Security roundup: Copy Fail, Dirty Frag, NGINX Rift, Fragnesia, and ssh-keysign-pwn
by Jonathan Wright 15 May '26

15 May '26

Howdy folks, The last two weeks have been unusual, to put it mildly. Five separate high-severity disclosures that affect AlmaLinux have been announced since 2026-05-01: four local-root kernel flaws and one unauthenticated nginx RCE/DoS. If you have lost track of the running tally, you're not alone. Our build servers want a break. Here is where each one stands as of today, where we still need help, and a brief word on what to expect going forward. At a glance: Copy Fail (CVE-2026-31431) <https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/>: in production Dirty Frag (CVE-2026-43284, CVE-2026-43500) <https://almalinux.org/blog/2026-05-07-dirty-frag/>: in production NGINX Rift (CVE-2026-42945) <https://almalinux.org/blog/2026-05-13-nginx-rift-cve-2026-42945/>: in production Fragnesia (CVE-2026-46300) <https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/>: testing, please verify ssh-keysign-pwn (CVE-2026-46333) <https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/>: testing, please verify To the community: thank you. The volume of testing reports we received on these rounds is the reason they moved from testing to production as quickly as they did. The Copy Fail rollout in particular was the highest-engagement community call for testing we have ever run. We do not take that lightly. Two patches are still sitting in the testing repository and need community verification before we can move them to production: Fragnesia (CVE-2026-46300) <https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/> test builds in almalinux-testing were refreshed on 2026-05-14 with additional upstream patches. ssh-keysign-pwn (CVE-2026-46333) <https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/> is a __ptrace_may_access() logic bug that lets an unprivileged user lift open file descriptors out of a dying privileged process and read root-owned files like /etc/shadow and SSH host keys. Public exploits are already out. The ssh-keysign-pwn build also carries the Fragnesia patches, so installing it gets you both fixes in a single reboot. See the blog post <https://almalinux.org/blog/2026-05-15-ssh-keysign-pwn-cve-2026-46333/> for testing instructions. A quick note on the pace. We are aware that "another week, another root" is becoming an actual schedule rather than a joke. Four local-root kernel disclosures in fifteen days is, statistically speaking, a lot. Here is what is not changing: 1. We will keep shipping ahead of upstream when the severity warrants it. ALESCo has approved every one of these fast-track rollouts so far, and that bar has not moved. If a critical fix is sitting upstream and our users are exposed, we will build it. 2. We will keep our patches strictly compatible. Every kernel and every nginx package we have shipped during this run uses the upstream fix backported and adapted to the AlmaLinux branch, with the same NVR scheme, the same module ABI, and the same repository layout you would expect from a normal Red Hat security update. Drop-in compatibility is the contract, and we are not breaking it to ship faster. 3. We will keep asking you to test. Community verification is what lets us move from testing to production with confidence. The reason these patches have rolled out cleanly so far is that you have been there to catch the things we cannot reproduce in our lab. Stay informed: Blog: https://almalinux.org/blog/ Mattermost: https://chat.almalinux.org/ Announce: https://lists.almalinux.org/mailman3/lists/announce.lists.almalinux.org/ Security: https://lists.almalinux.org/mailman3/lists/security.lists.almalinux.org/ -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Re: Security updates vs dnf release timing
by Jonathan Wright 29 Apr '26

29 Apr '26

Hi Scott, Usually by the time the CVE notices roll out the updates have already shipped. A technical glitch that's since been resolved caused this one to be a little behind on the actual rollout. On Mon, Apr 27, 2026 at 11:09 PM Scott Techlist via AlmaLinux Users < users(a)lists.almalinux.org> wrote: > I'm trying to get a handle on monitoring Almalinux 10 for security > updates. I am getting emails but there is usually a lag between the > announcement and an actual package. Or so it seems to me. > > For example I got this one on Friday the 24th, but as of today, the 27th, > I have not seen a package for it. > > What is the normal timeline from Redhat security announcement to Almalinux > to package deployment? Not complaining, just wanting to understand. > > Thanks Scott > > > -----Original Message----- > From: AlmaLinux Errata Notifications via Announce [mailto: > announce(a)lists.almalinux.org] > Sent: Friday, April 24, 2026 10:07 AM > To: announce(a)lists.almalinux.org > Subject: [Announce] [Security Advisory] ALSA-2026:9264: kernel security > update (Important) > > Hi, > > You are receiving an AlmaLinux Security update email because you > subscribed to receive errata notifications from AlmaLinux. > > AlmaLinux: 10 > Type: Security > Severity: Important > Release date: 2026-04-24 > > > > _______________________________________________ > AlmaLinux Users mailing list -- users(a)lists.almalinux.org > To unsubscribe send an email to users-leave(a)lists.almalinux.org > -- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

1 0

Security updates vs dnf release timing
by Scott Techlist 27 Apr '26

27 Apr '26

I'm trying to get a handle on monitoring Almalinux 10 for security updates. I am getting emails but there is usually a lag between the announcement and an actual package. Or so it seems to me. For example I got this one on Friday the 24th, but as of today, the 27th, I have not seen a package for it. What is the normal timeline from Redhat security announcement to Almalinux to package deployment? Not complaining, just wanting to understand. Thanks Scott -----Original Message----- From: AlmaLinux Errata Notifications via Announce [mailto:announce@lists.almalinux.org] Sent: Friday, April 24, 2026 10:07 AM To: announce(a)lists.almalinux.org Subject: [Announce] [Security Advisory] ALSA-2026:9264: kernel security update (Important) Hi, You are receiving an AlmaLinux Security update email because you subscribed to receive errata notifications from AlmaLinux. AlmaLinux: 10 Type: Security Severity: Important Release date: 2026-04-24

1 0

OpenStack RPMs - Call for packaging volunteers
by Francesco Di Nucci 16 Mar '26

16 Mar '26

Hi all, the RDO Project[0], that provided OpenStack RPM packages through the CentOS Cloud SIG, is switching to a container-based approach due to lack of maintainers.[1] This means *there will be no more RPM packages for OpenStack versions after 2025.1/Epoxy unless new maintainers come up*. *This is a call across the EL and OpenStack communities for volunteer maintainers of RPM build pipelines*. If you're interested you can: * Add your name to the dedicated Etherpad (https://etherpad.opendev.org/p/rdo-volunteers) * Register to the RDO devs mailing list (dev(a)lists.rdoproject.org) and ask for more information No previous experience with packaging/pipelines is required, just willingness to learn /Note: this email is being separately to different mailing lists. If you have subscribed to more than one and recieve it multiple times, sorry for the duplication./ Links [0] https://www.rdoproject.org/ [1] https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Francesco, another OpenStack on EL operator -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

1 0

Access db slow
by Nikos Gatsis 03 Mar '26

03 Mar '26

Hello. I have a 8.10 version as a file server and 4.19 samba on a gigabit local network. Although coping on network is fast, accessing Access db files, is slow. The same files on a common win 11 pc is very fast. I try socket options in smb.conf but the performance is worse. Is there a suggestion? Thank you in advance. Nikos.

1 0

grub scripts fo legacy system not running
by Sergey Seacher 19 Jan '26

19 Jan '26

Hello! When I enter the command grub2-mkconfig, I get: $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Adding boot menu entry for UEFI Firmware Settings ... done But my system isn't UEFI, it's legacy. It's a virtual machine. The /etc/grub.d/10_linux script isn't running. -- Best regards, Sergey

1 0

Re: AlmaLinux 9.7 Firefox slow to launch
by Bluejay Adametz 19 Jan '26

19 Jan '26

> Is there a way that I can > troubleshoot this and possibly get Firefox to load up more easily? Try launching firefox from the command line and see if any interesting errors show up. When launching things via GUI stderr and stdout either go to some obscure log or into the null device. Check your syslog (messages) too. 8gb isn't a lot of RAM these days; the syslog will show if the OOM killer is coming into play. - Bluejay Adametz "Although I must endure the unchangeable, I also am obligated to change the unendurable." - Aaron B. Cohen NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential, sensitive and/or privileged information, or information otherwise prohibited from dissemination or disclosure by law or regulation, including applicable export regulations. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.

1 0

AlmaLinux 9.7 Firefox slow to launch
by Paul Graff 16 Jan '26

16 Jan '26

Hi, on a machine with AlmaLinux 9.7 installed with KDE Desktop Environment. It seems that once the KDE DE is loaded and if/when Firefox is launched it just takes a long time (30 seconds or so), almost like it fails to launch. Multiple launch attempts can be made and eventually Firefox does launch but in most cases then other instances that launch need to be closed (due to multiple launch attempts). I do not know why this is. The machine is a Lenovo ThinkCentre Edge 72e small with 8GiB memory and a SSD installed. Is there a way that I can troubleshoot this and possibly get Firefox to load up more easily? -Thanks

1 0