Willkommen bei Arch Linux
Arch Linux ist eine flexible und leichtgewichtige Distribution für jeden erdenklichen Einsatz-Zweck. Ein einfaches Grundsystem kann nach den Bedürfnissen des jeweiligen Nutzers nahezu beliebig erweitert werden.
Nach einem gleitenden Release-System bieten wir zur Zeit kompilierte Pakete für die x86_64-Architektur an. Zusätzliche Werkzeuge ermöglichen zudem den schnellen Eigenbau von Paketen.
Arch Linux ist daher eine perfekte Distribution für erfahrene Anwender — und solche, die es werden wollen...
Das Paket kea hat alle Dienste so umgestellt, dass sie unter einem dedizierten Benutzerkonto namens kea (anstatt root) ausgeführt werden, um die Sicherheit zu verbessern. Diese Änderung erfordert Aktualisierungen der Berechtigungen für die Laufzeitdateien, die von den kea-Diensten erstellt werden.
Nutzer, die von einer bestehenden kea-Installation aktualisieren, sollten daher nach dem Upgrade die folgenden Befehle ausführen:
chown kea: /var/lib/kea/* /var/log/kea/* /run/lock/kea/logger_lockfile
systemctl try-restart kea-ctrl-agent.service kea-dhcp{4,6,-ddns}.service
Benutzerkonten, die mit den Dateien der kea-Dienste interagieren müssen (z.B. Lease-Dateien unter /var/lib/kea, Logdateien unter /var/log/kea oder Konfigurationsdateien unter /etc/kea), sollten der Gruppe kea hinzugefügt werden.
Der alte Paketname iptables-nft wurde durch iptables ersetzt, und das Legacy-Backend ist unter dem Namen iptables-legacy verfügbar.
Beim Wechsel zwischen den Paketen (zwischen iptables-nft, iptables und iptables-legacy) sollte in den Verzeichnissen /etc/iptables/ nach .pacsave-Dateien gesucht und die dort gespeicherten Regeln gegebenenfalls wiederhergestellt werden:
/etc/iptables/iptables.rules.pacsave/etc/iptables/ip6tables.rules.pacsave
Die meisten Konfigurationen sollten ohne Änderungen funktionieren. Nutzer, die auf ungewöhnliche xtables-Erweiterungen oder Legacy-Funktionen angewiesen sind, sollten jedoch sorgfältig testen und gegebenenfalls iptables-legacy verwenden.
Mit der Version 590 der offiziellen Nvidia-Treiber wird seitens Nvidia der Support der „Pascal“-GPUs eingestellt. Dieser Treiber funktioniert dann nicht mehr für Karten dieser Serie. Darunter fallen alle GTX-10xx-Modelle, sowie alle älteren Modelle dieser GPU-Serie.
Arch wird mit dieser Treiberversion zudem die installierten proprietären Treiberpakete ersetzen, um die offiziellen offenen Kernelmodule zu verwenden:
nvidiawird mitnvidia-openersetztnvidia-dkmswird mitnvidia-open-dkmsersetztnvidia-ltswird mitnvidia-open-ltsersetzt
Auswirkungen: Wenn das Treiberupdate auf Systemen durchgeführt wird, die eine „Pascal“-GPU (oder älter) benutzen, wird das Laden des Treibers fehlschlagen und das grafische System nicht mehr richtig funktionieren.
Nutzer mit „Pascal“-GPUs müssen in den Updateprozess eingreifen: Wenn eine Nvidia-Grafikkarte mit „Pascal“-GPU im System steckt, muss zur weiteren Verwendung auf die Legacy-Version des proprietären offiziellen Treibers zurückgegriffen werden:
- Die Pakete
nvidia,nvidia-lts, odernvidia-dkmsdeinstallieren - Das Paket nvidia-580xx-dkms aus dem AUR installieren
Systeme die GPUs aus der „Turing“-Serie (20xx und die GTX1650-Serie) oder neuer benutzen, werden automatisch auf die offiziellen offenen Kernelmodule umgestellt. Die User müssen hier nicht in den Updateprozess eingreifen.
Wir möchten ein Update zu den jüngsten Server-Ausfällen geben, die unsere Infrastruktur betreffen. Das Arch Linux Projekt erlebt derzeit einen anhaltenden Denial-of-Service-Angriff, der hauptsächlich unsere Hauptwebseite, das Arch User Repository (AUR) und die englischen Foren beeinträchtigt.
Wir sind uns der Probleme bewusst, die dies für unsere Endnutzer schafft. Dies betrifft insbesondere die Dienste von archlinux.org. Wir werden weiterhin aktiv mit unserem Hosting-Anbieter zusammenarbeiten, um den Angriff abzuschwächen. Zudem evaluieren wir Anbieter für DDoS-Schutz und berücksichtigen dabei sorgfältig Faktoren wie Kosten, Sicherheit und ethische Standards.
Um die Kommunikation zu diesem Thema zu verbessern, werden wir zukünftig regelmäßige Updates auf unserer Dienststatusseite bereitstellen.
Als ehrenamtlich geführtes Projekt wissen wir die Geduld der Community zu schätzen, während unser DevOps-Team daran arbeitet, diese Probleme zu lösen. Bitte habt Geduld mit uns und vielen Dank für die bisher gezeigte Unterstützung.
Workarounds während Dienstunterbrechungen- Im Falle eines Ausfalls von archlinux.org:
- Spiegelserver: Eine Liste aller Spiegelserver findet ihr unter Mirror-Status. Da der Endpunkt der Spiegelserverliste, der in Tools wie
reflectorverwendet wird, auf archlinux.org gehostet wird, verwendet bitte während eines Ausfalls standardmäßig die im Paketpacman-mirrorlistaufgeführten Spiegelserver. - ISO: Installationsmedien findet ihr unter Arch Linux Downloads.
- Spiegelserver: Eine Liste aller Spiegelserver findet ihr unter Mirror-Status. Da der Endpunkt der Spiegelserverliste, der in Tools wie
- Im Falle eines Ausfalls von aur.archlinux.org:
- Pakete: Wir pflegen einen Spiegel der AUR-Pakete auf GitHub. Ihr könnt ein Paket abrufen mit:
$ git clone --branch <package_name> --single-branch https://github.com/archlinux/aur.git <package_name>
- Pakete: Wir pflegen einen Spiegel der AUR-Pakete auf GitHub. Ihr könnt ein Paket abrufen mit:
Unsere Dienste können aufgrund der vom Hosting-Anbieter durchgeführten TCP-SYN-Authentifizierung eine anfängliche Verbindungsrücksetzung senden, aber nachfolgende Anfragen sollten wie erwartet funktionieren.
Wir halten technische Details über den Angriff, seinen Ursprung und unsere Abwehrmaßnahmen intern, solange der Angriff noch andauert.
In den letzten paar Wochen kam es gelegentlich zu Berichten auf einschlägigen Newsseiten über Fernzugriffstrojaner in AUR-Paketen die vorgaben, beliebte Software bereitzustellen.
Auch wenn die Berichte oft etwas reißerisch formuliert sind, und man sich von ihnen nicht verrückt machen lassen sollte (zumal die betroffenen Pakete schon vor dem Erscheinen der Berichte gemeldet und entfernt wurden), so haben sie dennoch einen wahren Kern.
Das AUR – Arch User Repository – ist keine Sammlung an Software, die durch Arch-Maintainer geprüft und administriert wird. Im AUR kann jeder der es möchte, PKGBUILDs bereitstellen aus denen dann ohne weitergehende Prüfung oder Validierung seitens der Arch-Maintainer Installationspakete gebaut und Programme installiert werden können.
Dies bedeutet daher auch, dass es Möglich ist, Pakete zu erstellen die schädliche oder zerstörerische Aktionen ausführen können. Und das nicht nur nach der Installation, sondern schon beim bauen des Installationspakets aus dem heruntergeladenen PKGBUILD.
Es sei daher aus gegebenem Anlass an dieser Stelle noch mal darauf hingewiesen, dass beim bauen von Paketen aus dem AUR, die AUR-Sicherheitshinweise berücksichtigt werden sollten (siehe auch der Wiki-Artikel dazu, inklusive Beispiel eines problematischen PKGBUILDs).
- Vor dem Bau eines Pakets aus dem AUR sollte man auf jeden Fall die Kommentare lesen.
- Wenn man ein Paket baut, sollte dies mit einem Useraccount geschehen, der keine Rootrechte hat.
- Die im PKGBUILD referenzierten Quellen (
url=undsource=) sollten nicht auf „Alternativen“ verweisen, sondern den Originalquellen des Programmentwicklers entsprechen. - Wenn im PKGBUILD Scripte ausgeführt werden, sollten diese vor dem Bauen des Programms ebenfalls geprüft werden.
Diese Sicherheitshinweise sollten auch beachtet werden, wenn man Pakete mithilfe eines AUR-Hilfsprogramms erstellt. Moderne AUR-Hilfsprogramme bieten dazu entsprechende Funktionen an, die man auch nutzen sollte.
Darüber hinaus sollte man Programme aus dem AUR mit bedacht auswählen. Wenn es sich um ein „beliebtes Programm“ handelt, ist es eventuell in den normalen Repositorys schon verfügbar.
Auch bei Programmen im AUR die zum Beispiel keine Downloads und keine Kommentare haben, und von einem nagelneuen Useraccount gerade erst hochgeladen wurden und sich namentlich an ein beliebtes Programm anlehnen, sollte man Vorsicht walten lassen.
Wenn man sich unsicher ist, besteht die Möglichkeit, im Wiki nach dem Programm zu suchen, eventuell gibt es ja einen Artikel der das richtige Vorgehen zur Installation beschreibt. Auch kann man natürlich jederzeit bei uns im Forum fragen oder das englische Forum konsultieren. Zudem gibt es mit aur-general auch eine Mailingliste mit AUR-spezifischen Themen.
Mit der Version 20250613.12fe085f-5 von linux-firmware wurde das Paket auf herstellerspezifische Pakete aufgeteilt. linux-firmware ist nun ein leeres Paket, das das Standard-Set an Firmware-Paketen als Abhängigkeit hat.
Dies fällt zufälliger Weise mit der Neuorganisation des Symlink-Layouts der NVIDIA-Firmware zusammen, was zu einer Situation führt, mit der Pacman nicht umgehen kann.
Wenn man von Version 20250508.788aadc8-2 oder älter auf die aktuelle Version updaten will, erscheinen folgende Fehlermeldungen.
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem
Um das Update durchführen zu können, muss zuerst das Paket linux-firmware entfernt und danach wieder installiert werden.
pacman -Rdd linux-firmware
pacman -Syu linux-firmware
Danach kann mittels pacman -Syu das System wie gewohnt aktualisiert werden.
Aktuelle Pakete
| python-lxml-docs | 6.0.4-1 |
| python-lxml | 6.0.4-1 |
| openrct2 | 0.5.0-1 |
| python-tifffile | 2026.4.11-1 |
| shadowsocks-v2ray-plugin | 5.33.0-1 |
| nwg-hello | 0.4.4-2 |
| slumber | 5.2.5-1 |
| gtkwave | 3.3.127-1 |
| python-rich | 15.0.0-1 |
| tectonic | 0.16.8-1 |
| beets | 2.9.0-1 |
| dovecot | 2.4.3-3 |
| nushell | 0.112.1-1 |
| ultramaster-kr106-vst3 | 2.5.4-1 |
| ultramaster-kr106-lv2 | 2.5.4-1 |
| ultramaster-kr106-clap | 2.5.4-1 |
| rtosc | 0.3.1-4 |
| rtosc-docs | 0.3.1-4 |
| rtaudio | 6.0.1-4 |
| rtaudio-docs | 6.0.1-4 |