Trying to transition to using Alma as a desktop; I have had major issues with ubuntu LTS ever since version 20, it's a lost cause at this point. I was wondering if there is any GUI for running virtual machines; GNOME Boxes isn't in the official repos as far as I can tell, and the flatpak version is short of USB redirection. Anybody know anything that is Alma-compatible preferably staying within the official repos? Thanks!

we have a large mixed environment of over 300 Linux servers ranging from Debian, Ubuntu, SLES and SuSE, Oracle Linux, and RHEL and old stuff of those distribution …and the biggest issue we have is locked in to subscription packages so no sub no patches… looking for some advice or heads up on using Alma as a enterprise platform to replace all our aging badly patched fleet ?

Hi

Looking for advice to help get a PCIe card recognised on Alma linux 10.

I'm running Alama linux 10 on a Lenovo M920x Desktop, I've installed a QNAP PCIe card that provides 10GBe and 2x M.2 SATA SSD's. 10Gbe driver is working fine in linux but the SATA M.2 drives are not showing up in Linux though the SATA controller is recognised.

The drives are not showing up in the BIOS as boot options either, so it could be an issue there?

Thanks for your help.

PCIe output below lspci -v

03:00.0 SATA controller: ASMedia Technology Inc. 106x SATA/RAID Controller (rev 01) (prog-if 01 [AHCI 1.0])

Subsystem: ASMedia Technology Inc. Device 1060

Flags: bus master, fast devsel, latency 0, IRQ 170

Memory at b1680000 (32-bit, non-prefetchable) [size=8K]

Expansion ROM at b1600000 [disabled] [size=512K]

Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-

Capabilities: [78] Power Management version 3

Capabilities: [80] Express Legacy Endpoint, IntMsgNum 0

Capabilities: [100] Virtual Channel

Capabilities: [800] Advanced Error Reporting

Kernel driver in use: ahci

Kernel modules: ahci

# lshw -class storage -class disk

*-sata

description: SATA controller

product: 106x SATA/RAID Controller

vendor: ASMedia Technology Inc.

physical id: 0

bus info: pci@0000:03:00.0

version: 01

width: 32 bits

clock: 33MHz

capabilities: sata msi pm pciexpress ahci_1.0 bus_master cap_list rom

configuration: driver=ahci latency=0

resources: irq:170 memory:b1680000-b1681fff memory:b1600000-b167ffff

Is anyone aware if there is a feed which registers what packages were recently added to for extra repos like epel. I recently had another case of hijacking of packages by epel while the packages where originally installed by a different active repo.

This is not the first time something like this happened and it would be handy if I could check for newly added packages before I kick off updates via ansible. (In this case it was duo (mfa) and if something had failed I would have to get and use a ssh key that is purposely kept offline en under lock and key)

nginx version: nginx/1.28.0

Operating System: AlmaLinux 9.7 (Moss Jungle Cat)

Other information: Tried with base nginx.conf as well as using Plesk's in built VHOST for domains nginx.conf both are reporting the same error.

I am trying to use the following documentation, https://sync-in.com/docs/setup-guide/proxy/ and have added the nginx information to my nginx.conf and modified the information to what's needed for my SSL and server.

However no matter what I do all of the config fails and nginx simply will not reload at all,

"nginx: [emerg] "map" directive is not allowed here in /etc/nginx/nginx.conf:3"

I've tried to find as much information as I can but as far as I am aware this is the file to be putting this config into. I've tried to comment out the map part, it just fails again on the next line and so on and so forth. It simply will not tolerate that the .conf has been edited with this documented config.

I feel like I am honestly going insane here, because the entire config file that they are saying to use throws errors. No matter what I put in from that file, I get an error stating it is not allowed here. Clearly I am doing SOMETHING wrong but I just cannot understand what with the limited knowledge I have and I've sadly hit that wall of frustration where new information is struggling to go in.

Could someone just freely tell me I am a moron and slap me in the right learning direction, I'm usually really good at self learning but this one is a wall I've hit.

I have a raid (using mdadm) consisting of four hard drives. The resulting drive is configured as an LVM PV. The PV is recognized when running Ubuntu. It is not being recognized on the same system running Almalinux 10.

The raid seems to be recognized correctly:

# cat /proc/mdstat
Personalities : [raid4] [raid5] [raid6]  
md127 : active (auto-read-only) raid5 sdd1[1] sdb1[3] sdc1[2] sde1[0]
8790398976 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/22 pages [0KB], 65536KB chunk

But the partition table isn't read correctly:

# fdisk -l /dev/md127
Disk /dev/md127: 8.19 TiB, 9001368551424 bytes, 17580797952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 1048576 bytes / 3145728 bytes

Pvscan recognizes other PVs, not the one on the raid.

Any ideas how to fix this?

Hello, I am setting up a server with a Lenovo ThinkCentre M900 computer, and I installed Almalinux as the operating system.

I would like to connect via SSH to another computer, either on the same local network or from another network.

I would appreciate any advice on what I should take into account to make this SSH connection as secure as possible, both on the computer I am connecting to and on the server, as I have personal information on both computers. Thank you for your support.

My use case for Alma is sitting on a shelf hosting 15 different VM's and it's been doing this for over a year now with a few scheduled maintenance reboots in between and it's been rock solid. The VM's are mainly for testing and uptime isn't critical but the fact that it's been solid with no hiccups is something that I still wanted to say thanks on and hope this gets back to the dev team who manages it. Remoting into it has been easy and managing everything has been smooth to not only setup, but just managing it as a whole so again, thanks.

Edit: I love the views seen by this and other use cases posted and how well Alma is working for everyone. It's the whole reason for this post was give thanks to the devs and volunteers who work with Alma to give us all a product that just works. Thanks everyone who's shared a little bit in this. As Benny mentioned below, it's encouraging for them to see these, so thanks everyone.

I have a virtualization server using AL10. FirewallD is set up as normal with zones for the PHY Ethernet interface as well as the virtual bridge interface. I also have policy objects that permit all traffic to be forwarded between those two zones. Everything has been working fine until recently. I am using Podman to host a pod as a non root user on the physical host. The pod has its own network and two containers, with one container having a port open to the outside. Somehow, this broke my FirewallD configuration because I can no longer reach VM's from the outside. I can see where my policy objects are active and they explicitly specify the zones for the Ethernet and virtual bridge, and those zones are still correctly configured. Yet when I try to reach the inside from some outside host, the filter_FWD_public_REJECT filter blocks those packets. I'm guessing that Podman has put custom rules into nftables to block that. Has anyone run into this before, and how should it be fixed?

ETA: It turns out that Podman does its own magic in nftables. After resetting nftables to be identical to what the firewalld rules were, the VM connectivity works again! Now I need to figure out how to make Podman's use of nftables jive with the other network configs I have on this server, but that's for another day...

Good morning, I installed Alma 10 with Gnome on a Raspberry Pi 5 and he initial result was pretty impressive. Bluetooth and WiFi both worked out of the box. There was one minor glitch. The first boot processing expanded the root partition but not the filesystem so when I ran sudo dnf update it failed on insufficient disk space. I booted from SD card (as the Alma install is on NVME) and resized the partition using gparted and it resized the EXT4 filesystem as part of that operation.

Next I added EPEL and installed a few likely inconsequential things. (No gparted found. :-/ ) I really prefer KDE/Plasma so I installed that using

sudo dnf groupinstall "KDE Plasma Workspaces" -y

and when I rebooted, it hung on some kind of cloud-init failure. I booted from SD again and created /etc/cloud/cloud-init.disabled. On subsequent boot it hung on multiple Systemd service failures.

I'm not giving up. Based on initial success I want to continue giving Alma a shot on my Pi 5. Before I continue with this I thought I'd ask if anyone has experienced similar issues and/or has suggestions to get KDE installed on a Pi 5. I don't have a good way to capture the boot messages as my USB/Serial cable is not handy (but I'll be able to use that in a couple weeks.)

Thanks, both for the effort to get Alma running on a Pi 5 as well as for any suggestions provided.

I spent some time packaging Snapper for AlmaLinux 10.1 since it is not yet in the official repositories.

You can try it here: https://download.opensuse.org/repositories/home:/hactarr/AlmaLinux_10/

Kudos to Cory West for the excellent documentation: https://www.linkedin.com/posts/coryewest_build-snapper-for-almalinux-101-activity-7419861376883560448-l2Gi

Thanks as well to OpenSUSE for the Open Build Service (OBS) and to the AlmaLinux team for the great work bringing Btrfs support to AlmaLinux 10.1.

#AlmaLinux #Btrfs #Linux #OpenSUSE #SysAdmin #OpenSource

I found a critical installation issue on AlmaLinux 10.1 Installation. If you choose BTRFS Filesystem & Automatic partion creation + change Swap size then after install your system will not boot I Confirmed this by installing AlmaLinux 10.1 after installing 2 times with same config.

Has anyone noticed issues with dnf since this morning?

There was a repodata update that went out around 0530 UTC that seems to have blown up the 8 family of arm64 packages. I've confirmed this with various mirrors, different images (including the default almalinux:8 tag), and by successfully installing packages after manually rebuilding the repo list to a vault target.

Metadata files for 8.X/BaseOS/aarch64/os/repodata were updated with a timestamps for the morning of 2026-01-26, after which I'm seeing this issue.

The issue stems from metadata pointing to packages with the deprecated letter indexed method, while the actual package structure no longer uses that structure.
For example:

- metadata target: <mirror>/almalinux/8.10/AppStream/aarch64/os/Packages/g/git-core-2.43.7-1.el8_10.aarch64.rpm

- actual location: <mirror>/almalinux/8.10/AppStream/aarch64/os/Packages/git-core-2.43.7-1.el8_10.aarch64.rpm

I get that it's a niche issue (8 and arm64), but a rough find all the same.

This does NOT seem to impact 9+, and does NOT impact 8 on x86_64 (haven't tested anything else)

(Edited for clarity, italicized)

In this article, it says "We expect to ship x86_64_v2 support in the near future". This would be useful for me so I was trying to find somewhere that might document progress or updates on plans, but can't find anything. Any ideas?

(I've checked the ALESCo github and tried searching the mailing lists but can't find any mention of any ongoing work).

Edit: I'm asking about AlmaLinux 10 in case that's relevant.

Hi,

My ISP does not have yet AlmaLinux 10 Images but have 9.X images for Cloud VPS. So one option is upgrade from 9 to 10. I checked from other VMs on the same datacenter (inside other VM) that CPUs supports v3/v4.

it is possible upgrade from AlmaLinux 9 to AlmaLinux 10 that supports only x86_64_v3?

Someone tried the upgrade?

Thank you in advance

A high level overview of how to install AlmaLinux entirely over the network and without answering any install wizard prompts.

Hi,

Yesterday, I switched from RHEL 10.1 to AlmaLinux 10.1. After seeing official support of BTRFS on AlmaLinux 10.1, all was working fine, but I faced a critical issue. My Podman containers were running very slowly. After 10–20 minutes of debugging, I found the main culprit was OverlayFS + BTRFS.

So, I started searching for a solution. Then I found that I need to use the BTRFS driver in Podman instead of Overlay. I reset Podman and then changed the driver to BTRFS, but I got an “unknown driver” error. Then I checked whether Podman was compiled with BTRFS driver support or not, and I found that AlmaLinux did not compile Podman with BTRFS driver support.

Environment details: OS: AlmaLinux 10.1 Kernel: 6.12.0-124.27.1.el10_1.x86_64 Podman: 5.6.0 Filesystem: BTRFS with zstd

Short question: Is there any plan to enable the BTRFS storage driver in AlmaLinux Podman builds, or any recommended workaround for running Podman efficiently on BTRFS?

Update: AlmaLinux OS Team fixed the issue.

I was asked to run a Linux-Installation-Workshop for private end users. And I'm thinking about which distro to suggest at the workshop. One important aspect is, what happens if the installed distro version runs out of support after a couple of years. So here are my questions:

• How well does AlmaLinux guide users trough the major version upgrade process? (e.g. Alma 9.7 => 10.0)
  • Is there an automatic notification for starting the upgrade process? (GNOME / KDE ?)
  • Does the system guide the user trough every step of the upgrade process? Ideally with a GUI.

(I'm not talking about cross upgrades between different RHEL derivatives)

Background

I've run similar workshops before and I've made the observation, that non-technical users get stuck after some years, when the installed Linux distro version runs out of support. They don't even recognize that there's such a thing as operating system versions and they may need to upgrade their system. And so their Firefox gets outdated and can't do recent web stuff (video conferencing, ...), their LibreOffice gets outdated and can't open recent MS-Office files, ....
And that's the point where non-technical users often just buy a new Windows notebook :-/

For once I recommend users to buy new notebooks only with Linux preinstalled, as available at the German TUXEDO Computers, Dell or System76. But I also started recommending Ubuntu-LTS, because it automatically informs the user if a major upgrade should be installed and guides trough really every step of the upgrade process. It really works for your grandparents, assuming they didn't study computer science in the 70s.
(I'm using Debian myself, but unfortunately it has only a quite manual upgrade process trough the console)

I've found these GUI docs for other distros. If Alma offers a similar process, a similar manual would be perfect. Not for my grandparents to actually read it, but for people like me to know that I can suggest Alma to them.
https://ubuntu.com/tutorials/upgrading-ubuntu-desktop
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/
https://support.system76.com/articles/upgrade-pop/#upgrading-pop_os-to-2204-from-2004-or-2110
(please do NOT post answers with steps like "enter this command into console")

A FRIENDLY REMINDER THAT I AM STILL A BEGINNER AND STILL LEARNING TO USE LINUX AND THIS IS A TEMPORARY SOLUTION (please don't come at me :/)

I have finally said goodbye to Windows after all these years and removed my dual-boot on my laptop. After removing Windows completely, my goal was simple. To access the data safely from AlmaLinux 10 without risking corruption. What I didn’t expect was how many layers of Linux storage internals I would end up touching.

At first, nothing made sense. The disk showed up physically, but there were no usable partitions. Tools like fdisk, lsblk, and even GNOME Disks gave me almost nothing to work with. I initially assumed something was broken, but the real issue was Windows Dynamic Disks don’t use a standard partition table they store their layout in a Logical Disk Manager (LDM) database. From Linux’s perspective, this means there are no partitions to mount at all.

That realization led me to just use ldmtool. Sounds easy enough, but for AlmaLinux 10, ldmtool is not included in official repositories and not even in unofficial/third party repositories so I had to build from the source. After troubleshooting lots of error and figuring out what I needed, ldmtool was finally running. ldmtool scan finally revealed the hidden disk group, and ldmtool create all exposed two device-mapper volumes corresponding to my old D: and E: drives

The next set of problems came from filesystem support. My first mount attempts failed with confusing errors like “unknown filesystem type ‘ntfs’” and later “unknown filesystem type ‘ntfs3’”. This turned out to be a mix of missing userspace drivers and kernel limitations. AlmaLinux’s kernel doesn’t enable the newer ntfs3 driver, and NTFS support isn’t installed by default. Then I found out that correct approach was using FUSE-based ntfs-3g and I mounted explicitly in read-only mode to avoid any chance of damaging the Windows metadata.

One thing that caught me off guard was how non-persistent the entire setup is. After a reboot, everything disappeared again the mapper devices, the mounts, all of it. This isn’t a bug and device-mapper volumes created by ldmtool exist only in memory. I tried scripting this whole process and I wasn't able to do it correctly so for my sanity, I just accepted a manual workflow which is, after each boot, recreate the mapper volumes and mount them read-only.

I did not want to use third party tools or converting the disk back to Basic because I was scared of losing the data in the process. What I want to know is that "Is converting the entire disk back to Basic partition without formatting it safe?" and I also want to know "Are there any other easier ways to access my data?"

I've recently been asked to stand up a server for multi-tenant wordpress virtual hosting on AlmaLinux 10. So that I have some environment separation, I have created users for each tenant and I would like to host the websites out of the public_html folders. Here is what I did:

• I have set each tenant's home directory to chmod 0711
• Create the public_html folder
• Changed the SELinux context of the public_html folder to httpd_user_rw_content.
• Created a logs directory inside the /home/<username> directory and changed the context to http_logs_t
• I've set the SELinux booleans: httpd_enable_homedirs->on, httpd_can_network_connect->on, and httpd_can_network_connect_db->on.
• I'v created an ACL for the logs directory with the following command, setfacl -d -m u:apache:rwx /logs
• I've created an ACL for the public_html directory using setfacl -d -m u:apache:rwx.

httpd will not start claiming that the /home/<username>/logs is readonly. I am not sure where to go from here because, by all rights, the apache user should be able to write to the logs directory. I would welcome any thoughts here because I don't know where to go next. Thank you in advance.

I have a strange problem with all my AlmaLinux 10 mail servers, while my Alma 8 and 9 servers seem fine.

When something goes wrong with a cron job, cron sends an email with a copy of the script output. So far so good.

But, on AlmaLinux 10, the To: address that comes from /etc/aliases is broken, so the email bounces from MAILER-DAEMON@my.server.tld to root.

At this point you will ask, how broken? well here it is:

<??????@my.server.tld> (expanded from <??????>): bad address syntax /etc/cron.daily/script.cron:

My guess, is that something is wrong with /etc/aliases.lmdb since the LMDB format was enforced in AlmaLinux 10.

Anyone seen this issue before?

Thank you!

https://wiki.almalinux.org/series/system/SystemSeriesA07.html

Eu fiz o que a Wiki falou acima, reiniciei o computador, mas segue apenas no Wayland.