{"id":181758,"date":"2026-05-27T02:48:02","date_gmt":"2026-05-27T00:48:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-almalinux-9-8-i-10-2"},"modified":"2026-05-27T02:48:02","modified_gmt":"2026-05-27T00:48:02","slug":"reliz-almalinux-9-8-i-10-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/reliz-almalinux-9-8-i-10-2","title":{"rendered":"Release von AlmaLinux 9.8 und 10.2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Ver\u00f6ffentlichung der AlmaLinux 10.2-Distribution ist erfolgt, ebenso wie das Update der vorherigen Version \u2013 AlmaLinux 9.8. Die Releases sind mit Red Hat Enterprise Linux 9.8 und 10.2 synchronisiert und enthalten alle \u00c4nderungen, die in diesen Versionen vorgeschlagen wurden. Installationsbilder wurden f\u00fcr die Architekturen x86_64_v3, x86_64_v2, ARM64, ppc64le und s390x in Form von bootf\u00e4higen (1 GB), minimalen (1,6 GB) und vollst\u00e4ndigen Bildern (10 GB) vorbereitet. Sp\u00e4ter werden Live-Builds mit GNOME, KDE, MATE und Xfce sowie Bilder f\u00fcr Raspberry Pi, Container, WSL (Windows Subsystem for Linux) und Cloud-Plattformen erstellt.<\/p>\n
Das Distributionspaket ist nach M\u00f6glichkeit bin\u00e4r kompatibel mit Red Hat Enterprise Linux und kann als Ersatz f\u00fcr RHEL 10.2 und CentOS 10 Stream verwendet werden. Neben dem Rebranding und der Entfernung von RHEL-spezifischen Paketen weist AlmaLinux 10.2 folgende Unterschiede zu RHEL 10.2 auf:\n<\/p>\n
\n
Das Repository mit Paketen f\u00fcr die Architektur i686 sowie Docker-Container-Images f\u00fcr 32-Bit-x86-Systeme wurde ver\u00f6ffentlicht. Red Hat hat die Erstellung von 32-Bit-Versionen f\u00fcr die x86-Architektur mit der Ver\u00f6ffentlichung von RHEL 7 im Jahr 2014 eingestellt. In der CentOS 7-Version wurde die Erstellung von 32-Bit-Paketen weiterhin vom CentOS Linux AltArch SIG-Team fortgef\u00fchrt, jedoch wurde mit der Version CentOS 8 die Erstellung solcher Builds eingestellt. Der Grund f\u00fcr die Wiederbelebung der Builds f\u00fcr die i686-Architektur in AlmaLinux war der Wunsch, die Ausf\u00fchrung alter Anwendungen zu erm\u00f6glichen, die nur als ausf\u00fchrbare Dateien f\u00fcr 32-Bit-Systeme verf\u00fcgbar sind. Diese Builds k\u00f6nnen auch n\u00fctzlich sein, um 32-Bit-Umgebungen f\u00fcr Testzwecke in Continuous-Integration-Systemen zu erstellen und um Container f\u00fcr 32-Bit-Anwendungen auszuf\u00fchren.\n
Die Unterst\u00fctzung des Btrfs-Dateisystems wurde wiederhergestellt. Die M\u00f6glichkeit zur Partitionierung von Speichermedien mit Btrfs wurde im Installer hinzugef\u00fcgt, und das Kernelmodul btrfs.ko wurde installiert. Au\u00dferdem steht das Paket btrfs-progs zur Verf\u00fcgung, und es wurden Anpassungen f\u00fcr die Unterst\u00fctzung von Btrfs im Datenspeicher-Management-Stack vorgenommen. Die Funktionsweise der Pakete bcc, buildah, cockpit, ignition, libblockdev, libguestfs, osbuild, osbuild-composer, podman, pykickstart, python-blivet, skopeo, udisks2 und virt-v2v in Btrfs-Umgebungen wurde \u00fcberpr\u00fcft. Red Hat hat das Btrfs-Dateisystem mit der Ver\u00f6ffentlichung von RHEL 7.4 (2017) als veraltet erkl\u00e4rt und die Unterst\u00fctzung in der RHEL 8-Reihe vollst\u00e4ndig eingestellt.\n<\/li>\n
Standardm\u00e4\u00dfig ist das CRB (CodeReady Builder) Paket-Repository aktiviert, das eine Auswahl von Paketen enth\u00e4lt, die normalerweise nicht in Red Hat Enterprise Linux angeboten werden, wie Entwickleranwendungen, zus\u00e4tzliche Bibliotheken und Bindings sowie Pakete mit Debugging-Daten, Dokumentation, Header-Dateien, statischen Builds und Beispielcode (Pakete \u201e-devel\u201c, \u201e-example\u201c, \u201e-doc\u201c und \u201e-static\u201c). Unter anderem enth\u00e4lt CRB Bibliotheken, die als Abh\u00e4ngigkeiten in Paketen aus dem Repository verwendet werden. \nEPEL (Extra Packages for Enterprise Linux). <\/p>\n<\/li>\n
Es wurden Pakete f\u00fcr die Installation der NVIDIA-Treiber und des CUDA-Stacks erstellt. Die Treiber k\u00f6nnen in Konfigurationen mit UEFI Secure Boot verwendet werden. Kernelmodule aus dem offiziellen Satz propriet\u00e4rer Treiber von NVIDIA k\u00f6nnen im UEFI Secure Boot-Modus nicht geladen werden, da sie nicht digital signiert sind. Diese Einschr\u00e4nkung \nwurde durch die Verwendung von offenen Kernelmodulen, die von NVIDIA bereitgestellt werden, umgangen. Auf deren Basis wurde ein eigenes Paket nvidia-open-kmod mit Modulen erstellt, die mit einem digitalen Zertifikat von AlmaLinux signiert sind. Separat wurde das Paket almalinux-release-nvidia-driver mit der Konfiguration des von NVIDIA unterst\u00fctzten externen Repositories erstellt, aus dem die CUDA-Treiber und propriet\u00e4ren Komponenten des NVIDIA-Treibers, die im Benutzermodus arbeiten, heruntergeladen werden.<\/p>\n<\/li>\n
Es wurden separate Builds f\u00fcr die zweite Version der x86-64 Mikroarchitektur (x86-64-v2) erstellt, die parallel zu den Basis-Builds f\u00fcr x86-64 bereitgestellt werden, die f\u00fcr die x86-64-v3 Mikroarchitektur optimiert sind, die in RHEL 10 verwendet wird. Die zus\u00e4tzliche Unterst\u00fctzung f\u00fcr x86-64-v2 gew\u00e4hrleistet die Kompatibilit\u00e4t mit \u00e4lteren CPUs wie Intel Haswell und AMD Excavator, die vor 2013 entworfen wurden. Neben den Standard-Repositories wurden auch Builds f\u00fcr x86-64-v2 f\u00fcr Pakete aus dem EPEL-Repository vorbereitet.\n<\/li>\n
Die Server- und Client-Implementierungen des SPICE-Protokolls wurden zur\u00fcckgegeben, das eine Remote-Arbeit mit Desktops erm\u00f6glicht, die in einer virtuellen Umgebung unter QEMU\/KVM betrieben werden. Im Gegensatz zu den Protokollen VNC und RDP erfolgt bei SPICE die Darstellung des Bildschirminhalts und die Verarbeitung von Audiostreams auf der Client-Seite. Server<\/a>. In RHEL wurde die Unterst\u00fctzung f\u00fcr SPICE mit der Version 9.0 eingestellt.\n<\/li>\n