AlmaLinux Errata: What It Is, How It Works, and How to Use It

If you run AlmaLinux in production, errata are what separate a maintained host from an exposed one. The advisories published at errata.almalinux.org are not marketing surface for a distribution; they are the machine-readable contract between the AlmaLinux OS Foundation and every server, container, and appliance that pulls updates from its mirrors. Understanding how that contract is structured, where the data lives, and how dnf consumes it is the difference between patching confidently and guessing.

This reference is written against the April 2026 state of the AlmaLinux errata system, with every command, URL, GPG fingerprint, and advisory ID verified against primary sources: the AlmaLinux wiki, the AlmaLinux security page at almalinux.org/security, the errata portal, the OVAL index at security.almalinux.org/oval/, the DNF and DNF5 command references, the AlmaLinux build-system roadmap on GitHub, and the live osv-database repository.

What AlmaLinux Errata Really Is

In the RPM world, an erratum is a published notice that a package has been updated, along with structured information describing why. AlmaLinux inherits this model directly from Red Hat Enterprise Linux and publishes its own equivalents under the ALSA, ALBA, and ALEA namespaces.

The AlmaLinux wiki defines the system in one line. Errata are described as package updates like some enhancements and features, bug fixes and security patches (AlmaLinux Security Errata wiki). That one sentence is the whole contract: every ALSA, ALBA, and ALEA is an update with a human-readable description, a machine-readable package list, and a release date.

The AlmaLinux Errata Index at errata.almalinux.org is the public-facing view of this dataset. According to the errata_index repository, the portal is a Vue.js application built on the Quasar Framework that consumes JSON exported from the AlmaLinux Build System. It lets you filter by version (8, 9, or 10) and severity (Critical, Important, Moderate, or Low), and every row links to a full advisory page with the description, updated package list, CVE references, and release date.

Advisory Types: ALSA, ALBA, ALEA

AlmaLinux follows the RHEL convention of splitting errata into three categories by the kind of change they deliver. The prefix on the advisory ID tells you immediately which bucket it falls into.

The ALSA advisories are the ones that matter for security operations. Each one is tagged with a severity that drives patch cadence for most compliance frameworks. Critical typically means remote, unauthenticated code execution. Important covers issues an attacker can realistically weaponize but that need authentication or a specific configuration. Moderate and Low cover issues mitigated by defaults, hardening, or limited attack surface.

An advisory ID follows a predictable shape: ALSA-YYYY:NNNN, where YYYY is the year and NNNN is a sequence number inherited from Red Hat, since AlmaLinux rebuilds the upstream fix and preserves the numbering. The rendered page for any advisory lives at https://errata.almalinux.org/{version}/ALSA-YYYY-NNNN.html with the colon converted to a hyphen in the URL slug.

A concrete example makes the structure tangible. The OpenSSL advisory ALSA-2024:9333 for AlmaLinux 9, released on 20 November 2024 and rated Low severity, bundled four CVEs — CVE-2024-2511, CVE-2024-4603, CVE-2024-4741, and CVE-2024-5535 — into a single rebuilt openssl package set. That advisory ID is the anchor a change ticket, a Nessus finding, an OpenSCAP report, and a dnf upgrade --advisory= command all share. The OSV version of the same record is published at github.com/AlmaLinux/osv-database/blob/master/advisories/almalinux9/ALSA-2024:9333.json, listing the same four CVEs plus the fixed NEVRA for every openssl subpackage.

ALSA numbering and the RHSA relationship

Because AlmaLinux preserves the Red Hat numbering when it rebuilds upstream fixes, the ALSA sequence number generally matches the corresponding RHSA. RHSA-2024:9333 is an OpenSSL advisory on RHEL 9; ALSA-2024:9333 is the AlmaLinux rebuild of the same fix. The two records describe the same package change, signed by different keys and distributed through different mirrors. A mapping lookup between the two namespaces is therefore most often just a prefix swap, which is why tools like convert2rhel and migration scanners treat them as equivalent for inventory purposes.

How the Errata Pipeline Really Works

The errata system is a pipeline, not a single component. Knowing the pieces is what lets you troubleshoot when advisories show up on the web portal but not in dnf, or vice versa.

Stage 1: Upstream source data

AlmaLinux pulls security data from Red Hat's public feeds. Historically this came from CVRF and OVAL v2, but Red Hat has been migrating away from both. Per the AlmaLinux build-system Red Hat OVAL deprecation milestone, CVRF was replaced with CSAF documents in VEX format, and Red Hat has introduced per-CVE VEX files as a separate feed. AlmaLinux's errata service parses these inputs and emits a normalized internal representation.

Non-security advisories (ALBA, ALEA) were originally not available through OVAL v2 and are now scraped from the Red Hat errata website by a dedicated AlmaLinux parser service. Once processed, the non-security records flow through the same internal database as security ones but carry an is_security=false flag. That flag is the reason non-security advisories appear in updateinfo.xml, in the JSON exports, and on the web portal but are deliberately excluded from AlmaLinux OVAL.

Stage 2: AlmaLinux Build System rebuild

When a Red Hat fix lands, the AlmaLinux Build System (ALBS) rebuilds the corresponding source RPM from AlmaLinux sources and generates binaries for every supported architecture. According to the AlmaLinux Wikipedia entry, ALBS consists of five components — Git Service, Release System, Sign Server, Test System, and Build Node — coordinated by a Master Service. The advisory is only published once the rebuilt packages are signed by the Sign Server with the AlmaLinux GPG key and pushed to mirrors. This is why occasional lag between an RHSA and the matching ALSA is normal and expected.

Supported build architectures are x86_64, aarch64, ppc64le, and s390x across all live versions, with one wrinkle: AlmaLinux 9 uses x86_64-v2 as its baseline (matching RHEL 9), and AlmaLinux 10 ships a default x86_64-v3 build (matching RHEL 10) plus an additional x86_64-v2 build for older hardware that Red Hat dropped support for. There is online disagreement about whether to call x86_64-v2 a separate architecture or a feature level — we describe it as a separate build because that is how the mirrors are organized and how dnf resolves it. AlmaLinux 8 images shipped with x86_64 only in early minor versions before ppc64le and s390x were added.

Stage 3: Errata generation and distribution

The build system writes the advisory into a database and emits several artifacts from it:

• updateinfo.xml embedded in each repository's metadata (what dnf reads)
• errata.full.json and errata.json at errata.almalinux.org (what third-party tooling consumes)
• OVAL XML at security.almalinux.org (what OpenSCAP and vulnerability scanners consume)
• Individual HTML pages at errata.almalinux.org (the human-readable view)
• A per-version entry committed to the AlmaLinux osv-database repository

The OSV database is not scraped from the other outputs; it is generated directly from errata using the errata2osv tool, a dedicated Python utility that maps AlmaLinux collection names (like almalinux-9-for-x86_64-appstream-rpms__9_default) to OSV ecosystem identifiers (AlmaLinux:9). Because OSV requires advisory IDs to be unique per source, AlmaLinux 8, 9, and 10 are configured as separate OSV sources — the same ALSA number can appear under almalinux8/, almalinux9/, and almalinux10/ with different package lists for each major version.

Stage 4: Repository metadata

Inside every AlmaLinux repo directory there is a repodata/ folder. The repomd.xml file is the index; it references hash-prefixed archives including primary.xml.gz, filelists.xml.gz, other.xml.gz, comps.xml, and — the relevant file for errata — a hash-prefixed updateinfo.xml.gz. A real example from an AlmaLinux 8 BaseOS mirror looks like 6f463017a4e105b3ae223da65a18af51968a9e2b0629586f4470863bcffbdbb7-updateinfo.xml.gz, alongside a repomd.xml.asc detached GPG signature covering the index itself.

When dnf refreshes metadata, it downloads repomd.xml, sees a new hash for the updateinfo entry, and pulls the fresh file. Because the filename is hash-prefixed, a changed updateinfo always lives at a new URL, which makes aggressive caching at CDN and proxy layers safe.

Stage 5: Client-side consumption

On the client, dnf uses the cached updateinfo.xml to link installed package versions to advisory IDs. That linkage is what makes dnf upgrade --security possible: dnf can identify which available upgrades are flagged as security fixes and filter on that flag. OpenSCAP uses the OVAL feed for the same purpose at the compliance-scanning level, cross-referencing the running system against the advisory catalog. Third-party scanners (Tenable, Greenbone, Trivy, Wiz, and others) typically consume the JSON export or the OSV feed instead, depending on which ecosystem their vulnerability matching is built around.

DNF4 versus DNF5 on AlmaLinux 10

AlmaLinux 8 and 9 ship DNF4, where the subcommand is dnf updateinfo. AlmaLinux 10 and AlmaLinux OS Kitten 10 follow RHEL 10 and CentOS Stream 10 into DNF5. Per the DNF5 changes reference, several things are renamed: dnf updateinfo summary becomes dnf5 advisory summary, dnf updateinfo list becomes dnf5 advisory list, and dnf updateinfo info becomes dnf5 advisory info. The --sec-severity option is renamed to --advisory-severities, and advisory commands now take advisory IDs only — to filter by package, use --contains-pkgs=PACKAGE_NAME. The high-level filters on dnf5 upgrade (--security, --advisory, --cve) keep the same spelling.

Why the Errata System Matters

On the surface, you could ignore advisories entirely and just run dnf upgrade on a schedule. That covers the basic case, but it gives up several properties that matter once systems scale or compliance enters the picture.

The first reason to care about errata is selective patching. A financial services box under change control does not want every package update every week. It wants the security fixes now and everything else deferred to a maintenance window. Errata metadata is what makes that split possible. Without it, dnf has no way to distinguish a CVE fix from a cosmetic enhancement.

The second reason is auditability. When an auditor asks which CVEs were patched on a host and when, the answer comes from dnf updateinfo list security --installed paired with the advisory dates. That list is only meaningful because the errata system is the ground truth linking CVE identifiers to specific RPMs.

The third reason is minimal-change upgrades. The dnf upgrade-minimal command upgrades each package only to the earliest version that contains the security fix, rather than jumping to the latest. On a long-lived system where newer versions of a library might pull in unfamiliar behavior, upgrade-minimal is often the safer path, and it only works because errata metadata records which fix landed in which exact version.

The fourth reason is vulnerability scanning. Tools like OpenSCAP, Greenbone, Tenable Nessus, and Trivy consume the OVAL or JSON feeds to determine whether a given installed NEVRA is vulnerable. If a scanner says your host is clean, it is making that claim against the published errata data.

Supported Versions and Their Errata Streams

AlmaLinux commits to long-term security support that runs in parallel with Red Hat's maintenance cycle. The AlmaLinux Release Notes page is the authoritative source for current dates, and as of April 2026 the timelines are:

AlmaLinux 8's active support ended in May 2024 with the release of 8.10; it still receives security errata on the 2029 clock but no new feature updates. Each minor version reaches end of life when the next minor version is released — 9.6 reached EOL with 9.7, and 10.0 reached EOL with the 24 November 2025 release of 10.1, for instance — so staying on a specific minor means pinning the repo URLs to a vault mirror and accepting that security advisories for that minor will stop arriving once the next one ships. Vault URLs follow the pattern vault.almalinux.org/{version}/: a host pinned to AlmaLinux 9.5, for example, points its baseurl entries at vault.almalinux.org/9.5/BaseOS/$basearch/os/ instead of the rolling repo.almalinux.org/almalinux/9/... path. Once you switch to a vault URL, set enabled=0 on the previously active rolling repo or you will see metadata fights between the two.

AlmaLinux 10's source pipeline is also a frequent point of confusion. The original beta of AlmaLinux 10 was built directly against Red Hat's source streams, while a parallel preview distribution called AlmaLinux OS Kitten 10 was built from CentOS Stream 10. Several blog posts written during late 2024 still describe these as two separate things. The current arrangement, as of the 10.0 stable release on 27 May 2025 and confirmed in the Purple Lion announcement, is that Kitten is the direct upstream for stable AlmaLinux 10. AlmaLinux 10.x is built from Kitten, Kitten is built from CentOS Stream 10, and CentOS Stream 10 is upstream of RHEL 10. ALSA advisories for AlmaLinux 10 are still numbered to match RHSA, and the package set still aims for ABI compatibility with RHEL 10. Kitten itself does not publish ALSA-numbered advisories on the same cadence as production AlmaLinux 10; its errata is handled separately while it serves as the integration upstream. The 10.1 release on 24 November 2025 (codename Heliotrope Lion, kernel 6.12.0-124.8.1.el10_1) added Btrfs as a first-class installer-level filesystem and shipped OpenSSL 3.5 with post-quantum ML-KEM, ML-DSA, and SLH-DSA enabled in the default crypto policy — useful context for any ALSA touching openssl on AlmaLinux 10 from late 2025 onward, since the underlying crypto surface is now broader than RHEL 10's.

Command-Line Workflows with dnf

The dnf utility exposes the errata system through the updateinfo subcommand and through flags on upgrade. Once you are comfortable with these patterns, errata-aware patching becomes routine.

Listing advisories

$ sudo dnf makecache

$ sudo dnf updateinfo summary

$ sudo dnf updateinfo list

$ sudo dnf updateinfo list security

$ sudo dnf updateinfo list security --installed

$ sudo dnf updateinfo list --sec-severity=Critical

The summary variant gives you a count by type and severity, which is useful for scripting compliance dashboards. The --installed flag pivots the view to advisories that have already been applied, which is what auditors want to see.

Inspecting a specific advisory

$ sudo dnf updateinfo info ALSA-2024:9333

$ sudo dnf updateinfo info --cve CVE-2024-5535

$ sudo dnf updateinfo list --with-cve

$ sudo dnf5 advisory info ALSA-2024:9333

$ sudo dnf5 advisory list --advisory-severities=critical,important

The info command dumps the full advisory text, including the CVE list, bug references, updated package NEVRAs, and the release date. Pair it with the web portal view (for example errata.almalinux.org/9/ALSA-2024-9333.html) when you need to confirm the advisory has been signed and mirrored, since the portal shows the final published state. The --with-cve flag is a filter, not a lookup — it restricts the listing to advisories that reference any CVE and prints CVE IDs in place of advisory IDs in the output, which is useful for piping into a vulnerability tracker. To search for a specific CVE, use --cve CVE-... as shown above. The last two commands show the DNF5 equivalents on AlmaLinux 10 — note that updateinfo is spelled advisory, --sec-severity becomes --advisory-severities, and the severity values are lowercase (critical, important, moderate, low, none). DNF4 accepted capitalized forms like Critical; DNF5 will not match them.

Applying errata

$ sudo dnf upgrade --security

$ sudo dnf upgrade-minimal --security

$ sudo dnf upgrade --advisory=ALSA-2024:9333

$ sudo dnf upgrade --cve=CVE-2024-5535

$ sudo dnf upgrade --sec-severity=Critical

$ sudo dnf upgrade --bugfix

$ sudo dnf upgrade --enhancement

The distinction between upgrade --security and upgrade-minimal --security is worth internalizing. The first installs the latest available version of every package that carries any outstanding security advisory. The second installs only the earliest version that resolves the advisory, keeping the delta from the current install as small as possible. On a system that pins to a specific minor release train, upgrade-minimal is usually what you want.

After the upgrade

$ sudo dnf install dnf-plugins-core

$ sudo dnf needs-restarting

$ sudo dnf needs-restarting -r

$ sudo dnf needs-restarting -s

$ sudo dnf updateinfo list security --installed | grep ALSA-2024:9333

$ sudo dnf history list

$ sudo dnf history info <transaction-id>

$ sudo dnf history undo <transaction-id>

The needs-restarting command is provided by the dnf-plugins-core package, which is installed by default on most AlmaLinux profiles but may be missing on minimal installs. Without arguments it lists processes still running against pre-upgrade binaries. The -r flag asks dnf to decide whether a full reboot is required — it returns exit code 1 when it is, which makes it scriptable. The -s flag lists only the affected systemd services, which is useful when you want to issue targeted systemctl restart calls instead of rebooting. Any kernel, glibc, systemd, or openssl ALSA should be assumed to require a reboot regardless of what needs-restarting reports — the kernel because the running image cannot be hot-swapped without kpatch, glibc because nearly every userspace process maps it and a stale copy stays resident in long-lived processes, systemd because it is PID 1 and re-execing it cleanly mid-session is fragile, and openssl because the TLS surface touches sshd, httpd, and most network daemons that hold persistent connections to a now-superseded library version.

The dnf history trio is the safety net. Every dnf upgrade is recorded as a numbered transaction, and dnf history undo <id> reverses it by downgrading the affected packages. In DNF5 on AlmaLinux 10, needs-restarting behavior changed: the default now aligns with what DNF4's --reboothint used to do, suggesting a reboot based on package metadata flags rather than by scanning open file descriptors, and the -r and -u options were dropped since the default behavior replaces them.

Automating Errata Application

For unattended patching, AlmaLinux ships dnf-automatic, a systemd-timer-driven wrapper around dnf that can be configured to apply only security updates. The configuration file lives at /etc/dnf/automatic.conf. The dnf-automatic(8) man page and the DNF Automatic reference document every option.

[commands]
upgrade_type = security
random_sleep = 0
network_online_timeout = 60
download_updates = yes
apply_updates = yes
reboot = never

[emitters]
emit_via = email

[email]
email_from = patching@example.com
email_to = ops@example.com
email_host = localhost

Setting upgrade_type = security restricts the automatic transaction to security-flagged packages; the valid values are default (all available updates) and security (only advisories with an issued security advisory). The reboot option accepts never, when-changed, or when-needed; leaving it at never is the safer default for production, so reboots stay under human control.

Enable the timer with sudo systemctl enable --now dnf-automatic.timer — that specific timer respects the download_updates and apply_updates values in the config file. Alternative timers override those settings, which is the source of a common configuration surprise. The DNF Automatic documentation states this directly: the helper timers run regardless of the configuration file settings. So dnf-automatic-notifyonly.timer only notifies (use this for systems where humans drive every install), dnf-automatic-download.timer only downloads (use this when you want patches staged locally so the actual install during the maintenance window is fast and offline-capable), and dnf-automatic-install.timer always installs regardless of config (this is the one that catches operators off guard — enabling it ignores any apply_updates = no safety net you set). The systemd timers also apply a random delay of up to one hour by default on top of any random_sleep value in the config file, which exists so that thousands of hosts pulling from the same mirror do not hammer it simultaneously.

The upgrade_type setting accepts only two literal values: default (every available update) and security (only packages tied to a security advisory, which on AlmaLinux means ALSA records). There is no bugfix or enhancement mode for unattended runs — ALBA-only and ALEA-only restriction is a manual dnf upgrade --bugfix or --enhancement operation, not a dnf-automatic one. The reboot setting takes never, when-changed (reboot whenever a transaction installs anything at all), or when-needed (reboot only if dnf flags packages that need it, which on DNF4 means kernel/glibc/systemd/openssl-class updates, and on DNF5 is driven by the same package metadata that dnf5 needs-restarting consults). For production fleets the safe default is reboot = never paired with a separate orchestration layer that drains, reboots, and re-adds nodes on a controlled schedule. Anything else turns dnf-automatic into a fleet-wide outage generator the first time a kernel ALSA lands at 03:00.

On AlmaLinux 10, DNF5 ships its own equivalent under the dnf5-automatic package, with its config file at /etc/dnf/automatic.conf plus a read-only default at /usr/share/dnf5/dnf5-plugins/automatic.conf. The timer unit is dnf5-automatic.timer. The configuration schema is nearly identical; the main practical difference is the unit name, plus the fact that DNF5 ships dnf5-automatic as a separate plugin package rather than pulling it in by default — on a minimal AlmaLinux 10 install the package is not installed and systemctl enable dnf5-automatic.timer will fail with a "unit not found" error until you run dnf install dnf5-plugin-automatic first. Logging on both DNF4 and DNF5 automatic runs is captured in the systemd journal under the corresponding service unit (journalctl -u dnf-automatic.service on 8/9, journalctl -u dnf5-automatic.service on 10), which is the canonical place to look for "did the security advisory I expected to land actually land last night" questions.

Consuming Errata Data Programmatically

For fleet-scale vulnerability management, individual dnf queries are not enough. AlmaLinux exposes the errata dataset through several machine-readable endpoints that you can pull from a central monitoring system. Each endpoint is live and can be fetched with curl without authentication.

For a typical automation recipe, you can pull errata.full.json nightly, diff against the previous day, and push new ALSA entries into a ticketing system. Because every record carries the complete updated package NEVRA list and CVE references, the resulting tickets can be enriched with exactly the information a patching team needs before touching a server.

Errata in Containers and Cloud Images

The errata system was designed for long-lived bare-metal hosts where dnf runs in place. Container images break that assumption in three ways and none of them are obvious unless you have hit them in production. First, the patching unit is the image, not the running container — you do not dnf upgrade a running container, you rebuild the image from a freshly pulled base and roll the deployment. Second, the AlmaLinux UBI-alternative variants (almalinux/8-base, almalinux/8-init, almalinux/8-micro, almalinux/8-minimal, plus the matching 9-* and 10-* tags) ship with substantially smaller package footprints than the platform images, which means a given ALSA may not affect a given image at all — checking dnf updateinfo list security against an image's installed package set is the only reliable way to know. Third, the almalinux:minimal and almalinux/N-minimal images do not ship full DNF; they ship microdnf, a libdnf-backed CLI that supports microdnf upgrade --refresh and microdnf install but lacks the updateinfo subcommand entirely. You cannot run microdnf updateinfo list security inside a minimal image — the right pattern is to do errata querying on a fuller image (or on the build host), then construct the minimal image with the specific package versions you need pinned.

The almalinux/N-micro image takes this further: it ships without any package manager at all. Patching a micro image means using Buildah or multi-stage Podman to install packages from the build host into a target rootfs and then commit. For errata workflows this means the build host owns the patching responsibility, not the runtime — your CI pipeline must be on a current AlmaLinux base with current errata metadata, because that is what determines which package versions get baked into the micro image you ship.

The official AlmaLinux container tags are mirrored to Docker Hub, Quay.io, and AWS ECR Public Gallery, and a registry choice can subtly change errata behavior. The Docker Hub almalinux:N tag is rebuilt and pushed when AlmaLinux releases a new ISO or when a high-impact ALSA lands; intermediate ALSAs are picked up by dnf upgrade at FROM almalinux:N build time, not by the upstream tag itself. So a Dockerfile that ends with a fresh RUN dnf upgrade --security -y always produces a current image even if the upstream tag is two weeks old, while one that omits the upgrade step inherits whatever security state the tag had on the day it was last rebuilt. The almalinux:N.M minor-version-pinned tags are the closest container equivalent to vault URLs — they will keep pulling the same minor's package set even after the next minor releases, so you stop receiving ALSAs at the moment that minor reaches EOL.

Kernel Live Patching and ALSAs

Most kernel ALSAs imply a reboot. The exception is kpatch, the live-patching framework AlmaLinux inherits from upstream that ships modules to redirect vulnerable kernel functions to fixed versions without taking the running kernel down. The kpatch userspace package has been in the AlmaLinux 8 BaseOS repository since release, and AlmaLinux 9 and 10 carry the same machinery. The activation pattern is identical to RHEL's: install kpatch-dnf, then dnf kpatch auto subscribes the currently running kernel to its live-patch stream, and subsequent dnf upgrade transactions pull in any kpatch-patch-* RPMs that match.

The critical operational fact buried in the upstream documentation is which ALSAs are eligible for live patching at all. Kpatch can rewrite leaf functions that do not touch deep kernel state — out-of-bounds reads, integer overflows in well-bounded routines, missing checks in syscall paths. It cannot live-patch changes to data structures, locking primitives, scheduler internals, or anything that requires re-initializing a subsystem. Red Hat's documentation describes the cadence constraint plainly: per the RHEL 10 kernel live patching guide, live patches are unavailable until you update to a supported kernel release. In practice this means roughly the most recent two kernel z-streams per AlmaLinux minor receive live patches; older kernels do not, and the live-patch availability window closes when the next minor ships. A host pinned to AlmaLinux 9.5 with no plan to move to 9.6 is also a host with no live-patch path — it must reboot for kernel ALSAs.

Two practical commands are worth committing to muscle memory. kpatch list shows which patches are loaded into the running kernel and which are installed but not loaded. rpm -q --changelog kpatch-patch-* shows the CVE list each installed patch addresses, which is the cross-reference back to the originating ALSA. For audit reports, the canonical answer to "is CVE-X live-patched on this host" is the conjunction of those two commands plus the matching ALSA on errata.almalinux.org. There is also a third-party path: TuxCare's KernelCare is a commercial live-patching service that supports AlmaLinux among many other distributions on a separate subscription, with its own patch cadence independent of the AlmaLinux ALSA stream. KernelCare patches are not ALSAs — they are TuxCare-issued — so a host running KernelCare may show as live-patched against a CVE while dnf updateinfo info ALSA-... still lists the matching advisory as outstanding. That is expected, not a bug, and is worth flagging in scanner exception lists.

Errata During Major-Version Migration

Major-version upgrades on AlmaLinux are handled by ELevate, a community fork of Red Hat's Leapp framework that ships its own leapp-data-almalinux package with the metadata needed to upgrade EL7 to 8, 8 to 9, 9 to 10, or 9 to AlmaLinux Kitten 10. The errata story during a Leapp run is genuinely subtle and trips up first-time users. During the upgrade window itself, the system is in a hybrid state — ELevate installs the target-version almalinux-release package, swaps the repo definitions, imports the new GPG key (for example RPM-GPG-KEY-AlmaLinux-9 when going 8 to 9, RPM-GPG-KEY-AlmaLinux-10 when going 9 to 10), and only then does the package transaction. Until the post-upgrade reboot completes, a dnf updateinfo list will return either nothing or a confused mix because the cached metadata is mid-transition. Don't trust scanner output during this window — wait for the system to come up on the target version, refresh the cache with dnf makecache, and then re-query.

The post-upgrade cleanup matters for errata accuracy more than people realize. ELevate intentionally leaves Leapp's own packages and the source-OS GPG keys installed so that the system can be inspected for migration issues. Until you remove the source-OS keys with rpm -e gpg-pubkey-... (the AlmaLinux ELevate Offline Guide gives the exact rpm -q gpg-pubkey incantation to find them), rpm -qa gpg-pubkey will keep listing them and any compliance scanner that audits trusted keys will flag the host as having extra trust roots. The ELevate offline guide is also the reference for migrating air-gapped systems through major versions: rsync the source and target version mirrors locally with rsync rsync://rsync.repo.almalinux.org/almalinux/ /local-mirror/, then point the Leapp repository configuration files at the local mirror before running the upgrade. The errata stream on the post-migration system comes from whichever repo URLs Leapp wrote into /etc/yum.repos.d/, so an air-gapped migration produces an air-gapped errata stream by default — you have to wire reposync into the target's repos for advisories to keep flowing.

One detail specific to the 9-to-10 path: ELevate currently does not support migrating to the x86_64_v2 variant of AlmaLinux 10. A host on 9.x running on a CPU that is x86_64_v2 but not v3 capable will fail the ELevate pre-upgrade check, because the leapp-data-almalinux package only knows how to point at the x86_64_v3 (default) target. The workaround until ELevate adds v2 target support is the EPEL-hosted v2 build of AlmaLinux 10 with a fresh install rather than an in-place migration. This is an under-documented operational detail that has burned operators expecting the same hardware-compatibility story across major versions.

Errata in Air-Gapped Environments

Air-gapped or proxy-isolated environments do not get to consume errata directly from repo.almalinux.org, but they can run an internal mirror that preserves the full updateinfo pipeline. The right tool depends on which formats matter to your downstream consumers. For dnf updateinfo and OVAL to work end-to-end on isolated hosts, you need to reproduce the repository structure including the repodata/ directory's updateinfo.xml.gz entry — cp -R alone is enough if you are mirroring a single point in time, but for a continuously-updated mirror, reposync followed by createrepo_c --update is the standard pattern. Critically, reposync with --download-metadata pulls the upstream updateinfo.xml intact so that createrepo_c --update --keep-all-metadata can fold it into the regenerated repomd.xml; without those flags the mirror will serve packages but no errata, and isolated hosts will see dnf updateinfo list return empty.

The simpler path for whole-mirror sync is rsync directly against rsync://rsync.repo.almalinux.org/almalinux/, which preserves the entire directory layout including the OVAL feed at security/, errata JSON exports, GPG key files, and repository data — everything an isolated environment needs to be a self-contained errata source. The AlmaLinux ELevate offline guide quotes 500 GB per major version as the working storage estimate, and that figure is realistic once you include AppStream, BaseOS, CRB, HighAvailability, NFV, ResilientStorage, RT, and SAP repos for each supported architecture. For a v2-and-v3 split on AlmaLinux 10 the figure roughly doubles. The single hardest-to-troubleshoot air-gapped bug is a mirror that pulls package RPMs but fails to refresh the repomd.xml hash for the updateinfo entry — symptoms are dnf updateinfo info ALSA-2024:NNNN returning No matches found for advisories everyone else's scanner shows as published. The fix is always re-running createrepo_c --update --update-md-path=<path-to-old-updateinfo> on the mirror so that the regenerated index includes the latest errata XML.

The Errata RSS Feed and Security Mailing List

For human-driven workflows, AlmaLinux exposes errata through two notification channels that are easy to overlook because they predate the JSON and OSV pipelines. The errata RSS feed is published per major version at errata.almalinux.org/{8|9|10}/errata.rss and is the single best input for ticketing integrations that already speak RSS — Jira's RSS gateway, Splunk's RSS modular input, OpsGenie's RSS-to-alert connector, and almost every modern SIEM accept it directly. The feed contains every advisory (ALSA, ALBA, ALEA) with publication timestamp, title, and a link back to the rendered errata page; it does not include the full package NEVRA list, so the typical pipeline is RSS-as-trigger followed by an automated curl errata.almalinux.org/{N}/{ALSA-ID}.json fetch for the structured detail.

The AlmaLinux security mailing list at lists.almalinux.org/mailman3/lists/security.lists.almalinux.org/ is the announcement channel for ALSAs only — bug and enhancement advisories do not generate list traffic. Each message contains the advisory ID, the affected versions, the CVE list, and a one-line description, with a link back to the full errata page. For teams that want a low-volume "the world has changed" signal without writing any integration code, the list is a viable alternative to the RSS feed. The two channels are generated from the same database and emit at the same time as the JSON exports refresh, so any apparent lag between the list and the website is mirror propagation rather than a real publication delay.

Excluding Packages and Holding Versions

Errata-aware patching becomes operationally fragile once you have packages you specifically do not want errata to touch — typically database engines, application runtimes, and kernel modules tied to vendor support contracts. The two mechanisms for this are the exclude= directive in /etc/dnf/dnf.conf (or any repo file) and the versionlock plugin from python3-dnf-plugin-versionlock (python3-dnf-plugins-extras-versionlock on older 8 hosts). They behave differently in important ways. exclude=postgresql* in dnf.conf hides matching packages from every dnf operation including dnf upgrade --advisory=ALSA-..., which means an excluded package will silently fail to update even when an explicit advisory targets it. versionlock instead pins specific NEVRA values: dnf versionlock add postgresql-15.6-2.el9_4 permits upgrades up to that version and refuses to install any other version, including ALSAs that target a newer release.

The right choice depends on intent. Use exclude= when a package family is genuinely off-limits to dnf and is managed by some other process (vendor RPMs, Ansible templates pushing custom builds). Use versionlock when you want errata-aware behavior — the host should know the ALSA exists and be flagged by dnf updateinfo list security as having outstanding advisories — but should not auto-apply them. The auditing benefit matters: a versionlocked host still shows up correctly in dnf updateinfo list security --installed as missing the advisory, so compliance scanners catch the gap. An excluded host shows up as having no available advisory at all, which looks healthy when it is not. For most production fleets, versionlock is the better default unless the package is genuinely outside dnf's purview.

When ALSA on the Web Differs from dnf updateinfo

The single most common ticket in any AlmaLinux operations queue is "errata.almalinux.org shows ALSA-YYYY:NNNN exists but my host doesn't see it in dnf updateinfo." Nine times out of ten this is a propagation gap, not a bug, and the remedy is always the same sequence. First, sudo dnf clean expire-cache followed by sudo dnf makecache — the local cache TTL is several hours by default and a freshly-published ALSA may not appear until that cache rolls over. Second, check which mirror your host actually pulled from with dnf repolist -v; mirror sync from repo.almalinux.org can lag by anywhere from minutes to a few hours depending on the downstream operator, and a heavily-cached corporate proxy can stretch that to a day or more. Third, check whether the ALSA was published to the version you are running — an ALSA-2024:9333 record exists separately for AlmaLinux 8, 9, and 10, and the web portal shows them all even when only one applies to your installed version.

The diagnostic that resolves the remaining 10% of cases is comparing the upstream updateinfo.xml hash against your local cache. Pull the live repomd.xml with curl -s https://repo.almalinux.org/almalinux/{N}/BaseOS/{arch}/os/repodata/repomd.xml | grep -A1 updateinfo, compare the hash against the file under /var/cache/dnf/, and you have a definitive answer about whether the host is genuinely behind or whether the ALSA simply has not been built into updateinfo.xml yet on the upstream side. If both hashes match and the advisory is missing, that is the rare case where the AlmaLinux build pipeline has the advisory metadata in the database but has not yet folded it into the next mirror sync — which the AlmaLinux team typically resolves within hours of a report on the bug tracker or community chat.

Deep Facts Even Experienced Operators Often Miss

Most of what operators know about AlmaLinux errata comes from running dnf upgrade in production for years. The following facts are rarely surfaced in tutorials and tend to be discovered only through reading commit history, reproducing edge cases, or running into them at 03:00 during an incident. Each one has direct operational consequences for how errata behaves, gets verified, or breaks.

The first out-of-band ALSA in AlmaLinux history was CVE-2024-1086

Until late March 2024 the implicit rule for AlmaLinux ALSAs was "wait for RHSA, rebuild, ship." That changed with CVE-2024-1086, an nf_tables use-after-free that grants trivial unprivileged local privilege escalation on any EL8 or EL9 host with netfilter loaded and user namespaces enabled (the default on every AlmaLinux installation). Red Hat originally classified the bug as Moderate. The AlmaLinux team disagreed publicly and on 30 March 2024 produced kernel builds — kernel-4.18.0-513.18.2.el8_9 for AlmaLinux 8 and kernel-5.14.0-362.24.2.el9_3 for AlmaLinux 9 — that were available to install before any matching RHSA existed. The interim install path went through the AlmaLinux Build System's Pulp endpoint with dnf upgrade --repofrompath cve-2024-1086,https://build.almalinux.org/pulp/content/builds/AlmaLinux-9-$(arch)-8923-br/, and both builds were already AlmaLinux-signed and Secure Boot-ready. Production repository availability followed on 1 April 2024. Red Hat subsequently re-evaluated the severity from Moderate to Important. This was only possible because of the post-July-2023 ABI-compatibility shift we discussed earlier — pre-9.3, an AlmaLinux fix ahead of an RHSA would have violated the 1:1 contract that no longer exists. Two operationally important facts come out of this: first, the --repofrompath flag exists specifically for one-off installs from non-default URLs without permanently editing repo configuration; second, build IDs like 8923-br (the -br means "build rep") are valid Pulp endpoint identifiers any operator can browse at build.almalinux.org/pulp/content/builds/ when they need to verify what a specific advisory was rebuilt from.

The Testing repository is the staging area for "we patched, RHEL hasn't yet" packages

AlmaLinux quietly added two new repositories in August 2023 after the post-1:1 shift: almalinux-testing and almalinux-synergy. The Testing repo is specifically the home for security updates AlmaLinux releases ahead of upstream — the same channel that carried the CVE-2024-1086 kernels in late March 2024 before they hit production. It is not enabled by default and most operators have never enabled it. Install via dnf install -y https://repo.almalinux.org/almalinux/almalinux-release-testing-latest-$(rpm -E %rhel).noarch.rpm, which drops almalinux-testing.repo into /etc/yum.repos.d/ with enabled=0. Selectively pull a specific advisory with dnf upgrade --enablerepo=testing --advisory=ALSA-... rather than enabling it globally. The Synergy repo is unrelated to errata — it is the home for packages requested by the community that are not in RHEL or EPEL, such as the Pantheon desktop environment and Warpinator. Enabling it auto-enables EPEL and CRB/PowerTools, which is a side effect worth knowing before pulling it onto a hardened host.

The Plus repository ships intentionally divergent packages with .plus in the version tag

The almalinux-plus repository contains core packages with patched functionality that explicitly diverge from RHEL behavior. Every Plus package carries .plus in its release tag (for example openssh-server-8.7p1-43.el9.plus) so it is identifiable by version string alone. The Plus repo is shipped disabled by default and the AlmaLinux wiki phrases its status carefully: these packages are not tested nor available in the upstream product, which means they receive ALSA-style errata advisories on the AlmaLinux side but no RHSA equivalent will ever exist. Because dnf compares version strings during upgrade, a host that pulls a Plus package will keep that .plus variant for the lifetime of the package — a subsequent BaseOS rebuild without the Plus changes will be considered an older version and will not replace it. This makes Plus a one-way door operationally: enable it deliberately, version-lock the affected packages, and treat scanner reports against Plus packages by their AlmaLinux ALSA mapping rather than by upstream RHSA.

Every AlmaLinux package is notarized in immudb — and you can independently verify it

The AlmaLinux Build System integrates Codenotary CAS (Community Attestation Service), backed by the open-source immudb tamper-evident database, at every stage of the pipeline. From notarized commit by commit source intake through build, test, sign, and release, every artifact gets a CAS hash recorded in immudb that cannot be modified retroactively. The AlmaLinux Build System UI shows this with a blue key icon next to trusted builds and a red crossed-key icon for builds whose sources or artifacts failed authentication. Because immudb's history is append-only and cryptographically chained, any tampering would break every subsequent verification — meaning if your scanner finds a package whose CAS hash does not match what immudb records, that is a strong signal of supply-chain compromise rather than a benign mismatch.

The alma-sbom tool (Python, available at github.com/AlmaLinux/alma-sbom) is the operator-facing way to retrieve and verify these records. After installing it, the canonical command to fetch a SBOM for a specific RPM is python alma_sbom.py --output-file out.json --file-format cyclonedx-json --rpm-package-hash <immudb-hash>, and the resulting CycloneDX or SPDX document includes the full attestation chain back to the source commit. There is one redundancy detail rarely mentioned: AlmaLinux runs an independent cryptographic validator node for the Codenotary CAS instance, separate from Codenotary's own infrastructure, so that no single party (not even AlmaLinux) can silently rewrite the ledger. This was announced in April 2022 and has been quietly running ever since. For audit-grade work that needs to certify a package's origin chain, this is the gold-standard verification path — stronger than GPG signature verification alone, because GPG only certifies the final binary, while immudb certifies the entire build process that produced it.

The updateinfo.xml schema has a reboot_suggested element that DNF actually reads

The XML schema for updateinfo.xml, originally formalized for openSUSE/zypper but adopted across the RPM ecosystem, defines a per-package <reboot_suggested>True</reboot_suggested> element nested inside <pkglist><collection><package>. AlmaLinux's errata generation honors this field: kernel, glibc, systemd, and openssl ALSAs typically set it to True. This is the upstream signal that drives dnf needs-restarting -r's exit code. When you see needs-restarting recommend a reboot after a transaction, it is often because the applied advisory's updateinfo.xml entry carried reboot_suggested=True, not because dnf scanned running processes. The same schema also defines <restart_suggested> for the package manager itself (rare in the AlmaLinux context because dnf-on-dnf restart is uncommon) and a per-update <updated date="..."/> separate from <issued date="..."/> — the first records original publication, the second records the most recent metadata refresh, and audit reports that confuse the two will misattribute when a fix actually shipped.

The dnf-makecache.timer default is hourly, gated by a 3-hour minimum sync window

Almost every AlmaLinux host runs dnf-makecache.timer by default, and almost no one knows how it actually fires. The unit ships with OnBootSec=10min, OnUnitInactiveSec=1h, and RandomizedDelaySec=60m — meaning it activates 10 minutes after boot, then approximately once per hour with up to an hour of randomized jitter. The actual metadata refresh, however, is gated by the metadata_timer_sync option in /etc/dnf/dnf.conf, which defaults to 3 hours (10800 seconds): the timer fires hourly, but a real makecache only runs if at least three hours have passed since the last successful one. The practical effect is that a freshly published ALSA appears in dnf updateinfo list within roughly three to four hours of mirror availability on an otherwise idle host. For operations teams that care about latency between publication and visibility, the right pattern is to set metadata_timer_sync=1800 (30 minutes) in dnf.conf for hosts in critical patch paths, since the timer itself already fires often enough; lowering the sync interval is what actually accelerates refresh. The defaults are tuned for mirror-friendly behavior across millions of hosts, not for individual operator latency.

The countme=1 flag in every default repo file is anonymous mirror telemetry

Open /etc/yum.repos.d/almalinux-baseos.repo on any AlmaLinux host and you will find countme=1 alongside the baseurl, gpgcheck, and enabled lines. This is the DNF "count me" feature inherited from Fedora: roughly once a week, the repo client appends a ?countme=N parameter to its mirrorlist request, where N indicates how long the system has been pulling from that repo (1 = first week, 2 = first month, 3 = first six months, 4 = older). The mirror operator's logs aggregate these to estimate active host counts without per-system identification. There is no PII in the request, but in genuinely air-gapped or compliance-sensitive environments the field can be set to countme=0 to disable it. Most operators have never noticed the line.

The almalinux-release RPM is what makes a host "AlmaLinux"

From dnf's perspective and from any compliance scanner, what makes a system AlmaLinux is the presence of almalinux-release-{N}.x86_64.rpm (and its companion almalinux-repos). This package owns /etc/os-release, /etc/redhat-release, the GPG key files at /etc/pki/rpm-gpg/, the default repo files at /etc/yum.repos.d/, and the $releasever macro every other repo file expands. The Migration Guide ships almalinux-release-latest-{N}.x86_64.rpm at repo.almalinux.org/almalinux/ as the standalone bootstrap RPM — this is the package that gets installed first during distribution conversion (CentOS to AlmaLinux, Rocky to AlmaLinux) and during ELevate major-version migrations. After migration the OS identifies as AlmaLinux purely because almalinux-release is now installed; remove it and the host's identity becomes ambiguous (most scanners will fall back to whichever release package they find next in rpm -q --whatprovides /etc/redhat-release).

Mirror metadata can carry stale updateinfo.xml.gz files that never get cleaned up

This is a Pulp-specific quirk of how AlmaLinux's mirrors and many third-party mirrors are built. Each time the upstream errata feed is regenerated and re-published, a new hash-prefixed updateinfo.xml.gz is dropped into repodata/. The old file is no longer referenced by repomd.xml but, depending on the mirror operator's cleanup policy, may not be deleted — meaning long-running mirrors can accumulate dozens of {hash}-updateinfo.xml.gz files in the same directory. Only the one currently referenced in repomd.xml is authoritative; dnf ignores the rest. If an audit script tries to parse every *-updateinfo.xml.gz in a repodata directory and union the results, it can produce a confused picture of which advisories are "available" because it is reading historical snapshots that the mirror has not yet pruned. The defensive pattern is to always parse repomd.xml first, follow the updateinfo data location it points to, and ignore everything else in the directory.

AlmaLinux ships a separate enhanced rsync to mirror operators — with its own backport security pipeline

The January 2025 rsync vulnerability cluster (CVE-2024-12084 through CVE-2024-12747, six CVEs disclosed coordinated through CERT/CC) exposed a piece of AlmaLinux infrastructure most operators have never heard of. The Foundation maintains an optional rsync backport repository at repo.almalinux.org for mirror maintainers, because the rsync that ships in BaseOS lags upstream by feature and the project recommends a newer build for performance and feature completeness on mirror hosts. When the Google Project Zero rsync vulnerabilities landed, AlmaLinux had to patch two rsync code paths in parallel: the BaseOS rsync (via standard ALSA) and the backport rsync (via direct backport-repo updates). Red Hat had only released patches for one of the six CVEs at the time of disclosure, and AlmaLinux Kitten 10 received fixes for all six before any RHEL did. For operators whose mirror infrastructure pulls from this backport repo, security patching follows a separate cadence from the rest of the system — check dnf repolist for almalinux-backports and treat that repo's errata stream as a parallel advisory channel.

The line-by-line copy of RHEL ended with AlmaLinux 9.3 in November 2023

The 9.3 release in November 2023 is the precise temporal anchor for "post-1:1 AlmaLinux." Before 9.3, every AlmaLinux package was reproduced byte-for-byte from the corresponding RHEL source RPM; after 9.3, the project moved to ABI compatibility while reserving the right to ship its own fixes. This is more than a policy detail — it is the cutoff for evaluating any historical ALSA. ALSA records for 8.x, 9.0 through 9.2, and earlier 9.3 maintenance are guaranteed-equivalent to their RHSA counterparts; ALSA records from late 9.3 onward and all 10.x records are "generally equivalent, occasionally divergent." For audit reports that need to certify "this CVE was patched on the same date as RHEL," the answer is yes for ALSAs before 9.3, and "verify the dates per advisory" for everything after.

The errata announcement list lives at security.lists.almalinux.org on Mailman 3

The AlmaLinux wiki currently directs subscribers to lists.almalinux.org/mailman3/lists/ running Mailman 3, with the canonical errata announcement list at security.lists.almalinux.org (described on the security page as the "AlmaLinux Security Mailing List"). The list slug is security, even though the wiki sometimes refers to it colloquially as the "errata mailing list" — subscribers receive automated messages from AlmaLinux Errata Notifications for every ALSA. Subscriptions made through older URLs (the Mailman 2 paths from the 2021 launch period) were migrated automatically. The list emits one message per ALSA at the moment the advisory enters the production database — which is generally before the mirrors have finished propagating the package changes, so a subscriber who reads mail in real time will frequently see the announcement before dnf updateinfo reflects it on their hosts. For operators wiring email-driven alerting, this is a useful early-warning signal: if a Critical ALSA arrives by email and your hosts do not see it in dnf within 30 minutes, that is the moment to check mirror sync rather than wait for the next scheduled makecache run.

The git.almalinux.org repository is the source of truth for "what changed from RHEL"

Every AlmaLinux package source lives in a per-package Git repository at git.almalinux.org/rpms/<package>, and each repo has a recognizable branch structure: c{N} for the CentOS Stream-derived branch (auto-synced for unmodified packages), a{N} for AlmaLinux modifications, and tags matching specific release versions. To find out what AlmaLinux specifically changed in any package — the literal patches applied on top of upstream — a git log c10..a10 between the matching branches shows every divergence. This is the cleanest way to answer "did AlmaLinux apply an extra patch to this package that RHEL doesn't have?" without parsing rebuild logs. The wiki maintains a Modified Packages list at wiki.almalinux.org/development/Modified-packages.html that catalogs the deliberately-modified packages by major version, and that page is the right starting point when a scanner flags a package as "AlmaLinux-specific" and you need to know why.

Verifying Package Signatures

Errata is only trustworthy if the packages it points at are trustworthy. AlmaLinux signs every RPM with its GPG key, and dnf verifies that signature by default. If the signature is missing or invalid, the package will not install.

$ rpm -qa gpg-pubkey --qf '%{SUMMARY}\n'

$ gpg --with-subkey-fingerprints /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9

$ gpg --with-subkey-fingerprints /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-10

$ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9

$ rpm -K /var/cache/dnf/*/packages/*.rpm

The AlmaLinux OS Foundation distributes its keys under /etc/pki/rpm-gpg/ with separate files per major version on a running system: RPM-GPG-KEY-AlmaLinux (AlmaLinux 8 — note the absence of a -8 suffix on the installed path, which is a quirk of how the AlmaLinux 8 release packages were originally laid out before the multi-version mirror layout took shape), RPM-GPG-KEY-AlmaLinux-9, and RPM-GPG-KEY-AlmaLinux-10. The keys are also mirrored at repo.almalinux.org/almalinux/ — where a parallel RPM-GPG-KEY-AlmaLinux-8 file is also available for download, alongside an RPM-GPG-KEY-AlmaLinux-legacy file for the expired 2021 key — and on pgp.mit.edu. The current fingerprints, verified against the AlmaLinux security page, are:

Both AlmaLinux 8 keys remain trusted. The 2021 key was set to expire in January 2024 and the AlmaLinux team rotated to a new key on 12 January 2024 after losing the master key needed to extend the original (per the AlmaLinux 8 GPG key change announcement). Packages built and signed under the old key before rotation are still valid and were never re-signed, so both fingerprints are expected to show up in rpm -qa gpg-pubkey output on long-lived AlmaLinux 8 hosts — that is by design, not configuration drift to clean up. If you are building internal mirrors or pulling packages through a proxy, make sure your cache preserves the signatures — stripping them will break errata trust downstream and turn every patch into a manual integrity check.

How to Review and Apply an AlmaLinux ALSA

Step 1: Refresh repository metadata

Run sudo dnf makecache so that dnf pulls the current updateinfo.xml from AlmaLinux mirrors. This makes sure your advisory list matches what errata.almalinux.org currently publishes.

Step 2: List available security advisories

Run sudo dnf updateinfo list security. This prints each ALSA identifier, its severity, and the package it applies to. Use sudo dnf updateinfo list security --installed to see advisories already applied to your system.

Step 3: Inspect a specific advisory

Run sudo dnf updateinfo info ALSA-2024:9333 to read the full advisory text, affected packages, and linked CVEs. Cross-reference the same advisory at errata.almalinux.org/9/ALSA-2024-9333.html for the web view and Red Hat bug references.

Step 4: Apply the advisory and verify

Run sudo dnf upgrade --advisory=ALSA-2024:9333 to install only the packages tied to that advisory. After the transaction, run sudo dnf needs-restarting to find processes that still reference pre-update binaries, and reboot if the advisory touched the kernel, glibc, systemd, or openssl.

The errata system is the contract. dnf is how you read it. Everything else — scanners, dashboards, compliance reports — is just a different view of the same signed, versioned, machine-readable record.

Wrapping Up

AlmaLinux Errata is the substrate on which every serious patching workflow on the distribution rests. The web portal at errata.almalinux.org is the friendly front door, but the real infrastructure — updateinfo.xml in every repo, OVAL streams at security.almalinux.org, JSON exports, GPG-signed packages, and the osv-database syndication — is what lets dnf, scanners, and compliance tooling all agree on what is fixed and what is not.

Treat the ALSA identifier as a first-class object in your operations. Cite it in change tickets, reference it in post-incident reports, and use it as the anchor when you need to prove to an auditor that a CVE was closed on a specific date. The errata system already gives you all the information you need. The only thing left is to wire it into your workflow.

Frequently Asked Questions

What is the difference between ALSA, ALBA, and ALEA in AlmaLinux?

ALSA stands for AlmaLinux Security Advisory and covers security fixes. ALBA stands for AlmaLinux Bug Advisory and covers non-security bug fixes. ALEA stands for AlmaLinux Enhancement Advisory and covers new features or enhancements. Only ALSA advisories carry a severity rating of Critical, Important, Moderate, or Low, and only ALSA records are published in the AlmaLinux OVAL stream; ALBA and ALEA are available through the web portal, JSON exports, and updateinfo.xml but are deliberately excluded from OVAL.

How do I apply only security errata on AlmaLinux?

Run sudo dnf upgrade --security on AlmaLinux 8 and 9 to install every package that carries a security advisory. To apply a single advisory, run sudo dnf upgrade --advisory=ALSA-2024:9333. To preview first, use sudo dnf updateinfo list security before committing to the upgrade. On AlmaLinux 10 and DNF5, the inspection commands become dnf5 advisory list and dnf5 advisory info, but the upgrade filters like --security and --advisory remain.

Where does dnf get its AlmaLinux errata data from?

dnf reads errata from the updateinfo.xml file that AlmaLinux publishes alongside repository metadata. Each repo directory contains a repodata/ folder with a repomd.xml index that points to a hash-prefixed updateinfo.xml.gz file. When you run dnf makecache, the errata metadata is downloaded and cached locally, which is why dnf updateinfo can show advisory IDs, severities, and the CVEs each advisory resolves.

Is errata.almalinux.org the only way to consume AlmaLinux advisories?

No. The web portal is the human-friendly view, but the same data is available as errata.full.json and errata.json for AlmaLinux 8 and 9, as OVAL XML streams at security.almalinux.org for versions 8, 9, and 10, as updateinfo.xml embedded in every AlmaLinux repository, as an RSS feed at errata.almalinux.org/{N}/errata.rss, through the AlmaLinux security mailing list, and in the OSV database at github.com/AlmaLinux/osv-database, which is compiled from AlmaLinux errata using the errata2osv tool after each update.

Which AlmaLinux versions currently have errata published?

AlmaLinux OS 8, 9, and 10 all have live errata streams. AlmaLinux 8 receives security-only updates until 31 May 2029. AlmaLinux 9 has active support until 31 May 2027 and security support until 31 May 2032. AlmaLinux 10, with the 10.1 Heliotrope Lion point release published 24 November 2025, has active support until 31 May 2030 and security support until 31 May 2035. Each minor version reaches end of life when the next minor version ships.

How do I verify AlmaLinux package signatures?

AlmaLinux signs every RPM with its GPG key and dnf verifies signatures by default, which is what makes the errata system trustworthy — an unsigned or mis-signed package is rejected before it can install. The installed paths on a running system are /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux for version 8 (the on-disk file has no -8 suffix, which surprises users who assume parallel naming with the 9 and 10 keys; a separate RPM-GPG-KEY-AlmaLinux-8 file does exist on the public mirror at repo.almalinux.org for download but is not the canonical installed path), RPM-GPG-KEY-AlmaLinux-9, and RPM-GPG-KEY-AlmaLinux-10. The AlmaLinux 9 fingerprint is BF18 AC28 7617 8908 D6E7 1267 D36C B86C B86B 3716 and the AlmaLinux 10 fingerprint is EE6D B7B9 8F5B F5ED D9DA 0DE5 DEE5 C11C C2A1 E572. Use rpm -K on a cached package to check a specific file, and rpm -qa gpg-pubkey to list installed keys.

How does AlmaLinux errata work in containers?

The AlmaLinux platform images (almalinux:8, almalinux:9, almalinux:10) ship full DNF, so dnf upgrade --security works inside them as it does on a host. The UBI-alternative variants (almalinux/N-base, -init, -micro, -minimal) ship smaller package sets, and the -minimal variants use microdnf, which lacks the updateinfo subcommand. The -micro variant ships no package manager at all and must be patched via Buildah or multi-stage Podman from the build host. The patching unit for any container is the image, not the running container — apply errata by rebuilding from a freshly pulled base and rolling the deployment.

Can I avoid rebooting after a kernel ALSA on AlmaLinux?

Sometimes. AlmaLinux ships kpatch in BaseOS for versions 8, 9, and 10, with kpatch-dnf as the subscription helper and kpatch-patch-* RPMs as the per-kernel live-patch packages. Not every kernel ALSA is eligible — kpatch can rewrite leaf functions but cannot live-patch data structures, scheduler internals, or anything requiring subsystem re-initialization. Live-patch availability is also tied to the cadence: roughly the most recent kernels per minor receive patches, and the window closes when the next minor ships. Use kpatch list to see what is currently loaded and rpm -q --changelog kpatch-patch-* to see which CVEs are covered by what is installed.

Why does the errata web portal show an ALSA that dnf updateinfo doesn't?

Almost always a propagation gap. Run sudo dnf clean expire-cache followed by sudo dnf makecache to force a fresh metadata pull. If that does not surface it, check which mirror the host is using with dnf repolist -v — mirror sync from repo.almalinux.org can lag minutes to hours, and corporate proxies can stretch that further. Compare the upstream repomd.xml updateinfo hash against your local cache to confirm whether the mirror is genuinely behind. Also confirm the ALSA was published for the major version you are running; the same advisory ID exists separately for AlmaLinux 8, 9, and 10.

How do I keep specific packages from being touched by errata?

Use versionlock when you want errata-aware behavior — the host should still report the ALSA as outstanding in dnf updateinfo list security --installed but should refuse to apply it. Install python3-dnf-plugin-versionlock, then dnf versionlock add <package-NEVRA>. Use exclude= in /etc/dnf/dnf.conf only when a package family is genuinely outside dnf's purview (vendor RPMs, custom builds), because exclude= hides matching packages from every dnf operation including explicit --advisory= targeting, which makes the host appear cleaner in scans than it actually is.

Has AlmaLinux ever shipped a security patch before Red Hat?

Yes, beginning with the post-9.3 era (November 2023). The first publicly tracked out-of-band ALSA was for CVE-2024-1086, an nf_tables use-after-free local privilege escalation. AlmaLinux published kernel builds (kernel-4.18.0-513.18.2.el8_9 and kernel-5.14.0-362.24.2.el9_3) on 30 March 2024 with production repository availability on 1 April 2024, while Red Hat had only rated the bug as Moderate. Red Hat subsequently re-evaluated the severity to Important. The January 2025 rsync vulnerability cluster (six CVEs disclosed coordinated through CERT/CC) is another example: AlmaLinux Kitten 10 received fixes for all six before any RHEL did, and Red Hat had only released patches for one of the six at the time of disclosure.

What is the AlmaLinux Testing repository, and when should I use it?

The almalinux-testing repo, introduced in August 2023, is the staging area for security updates AlmaLinux ships ahead of upstream. Install with dnf install -y https://repo.almalinux.org/almalinux/almalinux-release-testing-latest-$(rpm -E %rhel).noarch.rpm. It ships disabled by default. The recommended pattern is selective use, not global enablement: pull a specific advisory with dnf upgrade --enablerepo=testing --advisory=ALSA-.... Production-critical hosts should not enable Testing globally because, by definition, packages there have not yet completed full validation.

How can I cryptographically verify the build provenance of an AlmaLinux package?

Beyond GPG signature verification, every AlmaLinux package has an immudb hash recorded in Codenotary's tamper-evident database that attests to its full build chain. Install the alma-sbom tool from github.com/AlmaLinux/alma-sbom, then run python alma_sbom.py --output-file out.json --file-format cyclonedx-json --rpm-package-hash <immudb-hash> to retrieve a CycloneDX or SPDX SBOM that traces the package back to its source commit. The AlmaLinux Build System UI shows trust state with a blue key icon for verified builds and a red crossed-key icon for unverified builds. AlmaLinux also runs an independent CAS validator node so no single party can rewrite the ledger silently.

Sources and References

Every technical claim in this guide was verified against primary documentation. The list below is the exact set of sources consulted during writing, in the order they contributed to the article.

• AlmaLinux Security Errata Wiki — advisory type definitions, severity classifications, and access methods
• AlmaLinux Security Portal — GPG key fingerprints, OVAL stream links, mailing list, SBOM, and Secure Boot details
• AlmaLinux Errata Portal — live advisory index with filtering by version and severity
• AlmaLinux OVAL Streams Documentation — canonical URLs for OVAL XML feeds on AlmaLinux 8, 9, and 10
• AlmaLinux Release Notes Index — active support and security support dates for every supported major version
• AlmaLinux errata_index source code — Vue.js portal source, Quasar Framework, data-file layout
• AlmaLinux osv-database repository — OSV-format records for every ALSA, ALBA, and ALEA, one directory per major version
• AlmaLinux errata2osv tool — converter from AlmaLinux errata schema to OSV format, with collection-to-ecosystem mappings
• AlmaLinux build-system milestone: Red Hat OVAL deprecation — design notes on CSAF, VEX, and non-security advisory handling
• DNF Command Reference — updateinfo, --security, --advisory, --cve, and --sec-severity flag behavior
• DNF Automatic documentation — configuration file options, timer units, and override behavior
• dnf-automatic(8) man page — defaults, valid values for upgrade_type and reboot, and timer override rules
• Changes between DNF and DNF5 — rename of updateinfo to advisory, --sec-severity to --advisory-severities, and needs-restarting behavior
• Red Hat: Managing and Monitoring Security Updates (RHEL 9) — upstream workflow patterns inherited by AlmaLinux
• AlmaLinux Docker Images Wiki — Default, Minimal, Base, Init, Micro variants and microdnf usage notes
• RHEL 10 Kernel Live Patching Guide — kpatch-dnf workflow, supported-kernel cadence, and live-patch eligibility
• AlmaLinux ELevate Quickstart Guide — supported migration paths, leapp-data packages, repo configuration
• AlmaLinux ELevate Offline Guide — air-gapped major-version upgrade procedure with local mirror configuration
• AlmaLinux Migration Guide — rsync-based mirror setup and air-gapped distribution conversion
• AlmaLinux 10.1 release announcement — Heliotrope Lion release date, Btrfs enablement, EPEL-hosted x86_64_v2 build, post-quantum cryptography
• AlmaLinux CVE-2024-1086 announcement — first out-of-band kernel ALSA, exact kernel NEVRAs, the --repofrompath install path, and Pulp build IDs
• AlmaLinux Testing and Synergy repository announcement — the post-1:1 staging area for advance security patches
• AlmaLinux Repositories Wiki — BaseOS, AppStream, Plus, PowerTools, Devel, Vault, Testing, Synergy, SAP, SAPHANA descriptions and the .plus tag convention
• AlmaLinux Build System repository — immudb notarization, CAS hashes, the blue/red key UI indicators
• AlmaLinux SBOM User Guide — alma-sbom tool usage, CycloneDX/SPDX output, immudb hash retrieval syntax
• AlmaLinux Codenotary SBOM integration — per-stage notarization design, independent validator architecture
• openSUSE updateinfo.xml schema reference — canonical schema for reboot_suggested, restart_suggested, issued vs updated elements
• AlmaLinux rsync CVE cluster advisory — six-CVE January 2025 disclosure, parallel BaseOS and rsync-backport repo patching
• AlmaLinux Modified Packages list — the catalog of packages where AlmaLinux deliberately diverges from upstream