Presented is the release of the distribution kit AlmaLinux 10.1, synchronized with Red Hat Enterprise Linux 10.1 and containing all the changes proposed in this release. Installation images prepared for x86_64_v3, x86_64_v2, ARM64, ppc64le and s390x architectures in the form of boot (927 MB), minimal (1.4 GB) and full image (8.3 GB). Later, Live builds with GNOME, KDE, MATE and Xfce will be generated, as well as images for Raspberry Pi boards, containers, WSL (Windows Subsystem for Linux) and cloud platforms.
The distribution is, if possible, binary compatible with Red Hat Enterprise Linux and can be used as a replacement RHEL 10.1 and CentOS 10 Stream. In addition to the rebranding and removal of RHEL-specific packages, AlmaLinux 10.1 marked contains the following differences from RHEL 10.1:
- Support for the Btrfs file system has been restored. The ability to mark drives using Btrfs in the installer has been added, the installation of the btrfs.ko kernel module has been ensured, the btrfs-progs set of utilities has been returned, and work has been carried out to adapt the storage management stack to work with Btrfs and the correct functioning of the bcc, buildah, cockpit, ignition, libblockdev, libguestfs, osbuild, osbuild-composer packages has been checked. podman, pykickstart, python-blivet, skopeo, udisks2 and virt-v2v in Btrfs environments. Red Hat deprecated Btrfs in RHEL 7.4 (2017) and completely stopped supporting it in RHEL 8.
- By default, the package repository CRB (CodeReady Builder) is enabled, which ships a selectionof packages not offered by default on Red Hat Enterprise Linux, such as developer applications, additional libraries and bindings, and packages with debug data, documentation, header files, static builds, and code examples (“-devel” packages, “-example”, “-doc” and “-static”). Among other things, the CRB contains libraries that are used as dependencies in packages from the EPEL (Extra Packages for Enterprise Linux) repository.
- Packages for installing NVIDIA drivers and the CUDA stack have been created. Drivers can be used in configurations with UEFI Secure Boot. Kernel modules from the official set of proprietary drivers from NVIDIA cannot be loaded in UEFI Secure Boot mode, since they are not digitally signed by the distribution kit. This limitation was circumvented thanks to the use of kernel modules open by NVIDIA kernel modules