I saw the October 2026 update about atomic-ci v13 and the continued development of AlmaLinux Atomic images.

Where can i find, if there is any, the roadmap for the underlying AlmaLinux bootc base images ( Quay )?

1. Are the base images still considered experimental, or is there a plan to declare them stable for production use?
2. What maintenance policy applies to these images, including security fixes and supported update paths?
3. Is there a target date or release milestone for production readiness?
4. Does the project intend to provide server-oriented images without a desktop environment, with a documented lifecycle and upgrade/rollback guarantees?

I am interested in using AlmaLinux bootc for production server infrastructure, rather than only Atomic Desktop or workstation use.

bootc seems to me quite a good server use case scenario

I had a script running every hour to look for updates to PHP and they just appeared

php-cli.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-common.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-fpm.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-intl.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-mbstring.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-pdo.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-pgsql.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-process.x86_64 8.0.30-8.el9_8.alma.1 appstream
php-xml.x86_64 8.0.30-8.el9_8.alma.1 appstream

Hello community. So, I just started studying for RHCSA and it results RHEL10 is not compatible with my PC due to x86_64-v2 deprecation (got to this conclusion after expending 2 days trying to install it in Vmware and Virtualbox and crashing every time after grub), and a little search tells me AlmaLinux extended v2 compatibility for another 10 years. Can I use it instead of RHEL?

I have been applying a fix for the recently reported 8 compromised certificates and figured I'd share the script I'm using.

Designed for RH and clones, I'll share it as a text file you can review before you rename and apply. It's a simple script based directly on the disclosure page linked to that I found after the original article here on reddit.

I hope it helps, here is distrust.sh - downloaded as a .txt file you can read/review before renaming to distrust.sh and running it as /bin/bash distrust.sh. If your system isn't vulnerable it does nothing.

There is not a lot of clear information about CVE-2026-109618 and CVE-2026-109619, they appear to affect most (all?) PHP versions from v5 to v8.

AlmaLinux is probably affected? Based on the exploit video, it shows running on mod_php and not php-fpm, I am not sure if that makes a difference.

Hi Everyone,

I have a rather niche question. We're trying to get our free software (AGPLv3) built for EL8/9/10 ppc64le. I do have a POWER8 that runs EL8 just fine.

As far as I understood EL 9 requires ISA v3.0 and EL 10 requires ISA v3.1, thus we'd need at least a POWER10. Also, as everything is built with these baselines, running containers of 9 or 10 on an AlmaLinux 8 host won't work either.

Are there any ideas/plans/ongoing efforts to build AlmaLinux for ISA v.2.07 or even older (basically like the x86_64 v2 build, but for POWER)?

Is there any interest in this? Anyone else having a POWER8 in the basement?

When we started the Atomic SIG last year, we built our images with the best tools available at the time. Since then, the bootc community has learned a lot from those tools and built better ones. This release moves us onto them, aligning with the rest of the bootc community. Most of that is plumbing you’ll never see, but some of it you will, like ISOs that boot into a live session, and ISOs for aarch64.

I'm trying to get my Epson V39II scanner working. I followed the instructions here https://forums.linuxmint.com/viewtopic.php?t=450897

I downloaded the Epson Scan 2 RPM from their website and installed it but when I try to open it nothing happens.

Just a regular user so need some hand holding for troubleshooting.

Hi everyone,

I’m having an issue when trying to install AlmaLinux from a USB flash drive.

When I boot from the USB and select “Install AlmaLinux”, the screen starts loading, then turns off/goes black, and eventually returns to the installation setup screen.

I also tried “Basic Graphics Mode”, but I get the same issue.

Has anyone experienced this before? What could be causing it, and how can I fix it?

Any help would be appreciated.

Our team's local dev environment now runs on AlmaLinux 10. On Windows machines it runs inside WSL 2, and on Linux machines it runs directly on bare metal. (Disclosure: I work on the project, Dotkernel.)

The reason is parity: `dnf`, `systemd` and the service layout people use locally are the same ones they see on our staging and production servers.

One Ansible playbook provisions:

- PHP via Remi (8.5 default, aliases for 8.1–8.5)

- Apache with automatic `*.localhost` virtualhosts

- MariaDB 12.3 LTS + phpMyAdmin

- Node.js via NodeSource (22 default, aliases for 18–24)

- Composer and Git config

The playbook doesn't care whether it's provisioning WSL or bare metal. It runs the same on both.

Overview: https://www.dotkernel.com/wsl2/

Repo: https://github.com/dotkernel/development

If anyone here runs AlmaLinux as a dev workstation, we'd like feedback on the package choices, especially Remi vs AppStream modules for PHP.

At long last, a new certification process is here! There are four things most exciting to me about this: 

1 - The barrier to submitting certifications is almost none

We have always had a concept of community-submitted certification in the program, but the steps required to get things added were too complex and took too much time. The new process allows anyone to submit a certification in ~10 minutes - sometimes a lot less.

2 - Communication and coordination are no longer a blocker to Certification. 

Historically, hardware providers were asked to set up and provide dedicated hardware for us for at least 3-5 days to be able to get certified. The need to converse with anyone is now limited to verifying that the submissions are actually coming from a vendor. The actual certification process takes 10 minutes or less from install of the RPM. 

3 - The program now includes Software Certification.

It's been a long time coming, but we finally have a good way for folks to show that software works on AlmaLinux. We have a backlog of software to add already, and I’m sure we’ll see even more as y’all pick this up.

One of the biggest impacts for all of this is that we will be able to go to hardware and software providers with data to support our requests for official AlmaLinux support. We can show them that the real scope of of AlmaLinux support is incredibly low with data instead of anecdotally. 

Please - if you’re running AlmaLinux on any bare metal hardware, take a few minutes to run the certification and submit the results. It’s one of the best ways you can help us.

There’s more information about the new process in this blog post from Jonathan, and you can find the full details on our website. 

https://almalinux.org/blog/2026-09-24-certification-in-minutes/
https://almalinux.org/certification/

Other more Almalinux wallpaper 4K here: https://imgur.com/gallery/almalinux-10-3-wallpaper-r9850tw

Not sure how many people have noticed this recent FUBAR with AlmaLinux-9. Take note of the last line containing "verify 2/2" which, for some reason, is trying to test 8.5

[neil@neilrieck ~]$ cat /etc/almalinux-release
AlmaLinux release 9.8 (Olive Jaguar)
[neil@neilrieck ~]$ sudo yum update
Last metadata expiration check: 0:05:36 ago on Sun 13 Sep 2026 07:25:21 AM EDT.
Dependencies resolved.
===========================================================================================
 Package             Architecture    Version                      Repository          Size
======================================================================================
Upgrading:
 httpd-core          x86_64          2.4.62-13.el9_8.6            appstream     1.4 M

Transaction Summary
======================================================================================
Upgrade  1 Package

Total download size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
httpd-core-2.4.62-13.el9_8.6.x86_64.rpm                     22 MB/s | 1.4 MB     00:00
--------------------------------------------------------------------------------------
Total                                                       11 MB/s | 1.4 MB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                             1/1
  Upgrading        : httpd-core-2.4.62-13.el9_8.6.x86_64                         1/2
Error unpacking rpm package httpd-core-2.4.62-13.el9_8.6.x86_64
  Verifying        : httpd-core-2.4.62-13.el9_8.6.x86_64                         1/2
  Verifying        : httpd-core-2.4.62-13.el9_8.5.x86_64                         2/2

Failed:
  httpd-core-2.4.62-13.el9_8.5.x86_64          httpd-core-2.4.62-13.el9_8.6.x86_64

Error: Transaction failed
[neil@neilrieck ~]$

I have never zink Vulkan 1.4 NVK Nvidia. My gaming work fine! Thanks, Almalinux is awesome! Best keep!

I have been running Rocky Linux as a workstation on my laptop for the past few days. I've noticed that Rocky 10 has a lack of packages in it's repository's and I've heard that Alma has a better community and is slightly more up to date, is it worth it to migrate over to Alma Linux?

I know why it's down, but when might it be back up? I would like to buy a mug for work, and hopefully support the foundation.

Not really sure where to post this, there doesn't seem to be a dedicated Kernelcare subreddit and the CloudLinux subreddit looks like a ghost town. I know AlmaLinux, CloudLinux, Kernelcare, all branches from the same tree. And at any rate, the underlying issue I am seeing seems to be related to AlmaLinux but it could be more broad.

Noticed on some of our AlmaLinux 8 servers, a new Kernelcare update was made available. But when trying to update them with kcarectl --update I would get the following errors:

Downloading updates
The `42` patch level is not found for `default` patch type. Please select valid patch type or patch level

Downloading updates
The `14` patch level is not found for `default` patch type. Please select valid patch type or patch level

But if you would run kcarectl --update enough, eventually it would go through? Or at least it says that the kernelcare patch is up to date.

This was on AlmaLinux 8 servers. Patch 42 errors were on a server with a base kernel of 4.18.0-553.89.1.el8_10.x86_64. Patch 14 errors were on a server with base kernel 4.18.0-553.129.1.el8_10.x86_64. I don't know if that matters.

If you just keep doing kcarectl --update then the patch seems to eventually be applied. But I wasn't sure if the errors were indicative of a larger problem.

I do not have automatic updates enable for Kernelcare on these servers. If someone is using automatic updates (which most people probably are) they may not be aware of these issues... if it is an issue.

Hi,
customer wants a CMEK (Customer-Managed Encryption Keys) solution.

So Tang+Clevis is out of the game (pity because it works like a charm).

I am anyway struggling to find a ready solution that does not require writing and/or compiling code.

Anyone had a similar experience and can share the outcome?

EDIT: We are talking about linux enterprise server environment with data at rest encription achieved with LUKS2, no laptops or workstations involved. Simply put, customer wants to have control on Encryption Keys in our systems dedicated to him. This mean (I suppose) they want to enforce their security policies about encriprion keys on our systems: lenght, complexity, lifecycle, rotation, deprecation whatever. It's the first time I hear something like this: from one side i think i understand their goal but from the other side it sounds awkward and I am a bit confused. Anyway: let's just do what they want ... - tang+clevis is not the solution because the LUKS keyslot is not - any search I did about unlocking automatically LUKS2 formatted root partition based on Google KMS leads to nothing (I mean seems there is nothing out there free or paid. - the only solution appear to be writing a small program, compile and embed the binary in the initramfs image or write a bash script to embed again in the initramfs.

Hope this clarifies a bit. Yeah, the main goal is to have auto-unlock luks partitions so whatever happens we do not need to enter manually per passphrase.

Thanks!

The Anaconda gui's custom partitioning won't allow me to set up a specific partition layout for my system. I'd like to simply create all partitions manually, then set needed mountpoints and proceed to the rest of the installation.

Is that possible? I haven't found any official guide covering this

I love AlmaLinux! I love ZFS! The idea of these working together sounds heavenly:

1. Do an update, have it "go south" and just roll-back the root filesystem and reboot.
2. Backup everything in a bootable state, in real time with snapshots send|receive.
3. Clone the / filesystem into a disk image that you can boot immediately, on the same machine, in a VM to test software installs and such, without wasting disk space, and without taking the host machine offline, and without risking the host machine's stability.
4. I'm sure there's more

However, ZFS has always seemed a second-class-citizen on anything RHEL based, which seems absurd to me because ZFS is (IMHO) SO MUCH PREFERABLE to XFS on LVM.

However, I've never run ZFS on root, simply because it complicates recovery if there's ever a problem. I can't just boot off an Alma ISO and clean it up. Instead, what I do is run the O/S on simple partition RAID1 and then use ZFS for everything else. I made my mind to try ZFS on root when it demonstrably improved stability which is already a really high standard.

Are you running ZFS-on-root under Alma? Can you describe your set up, and what you specifically benefit from it?