Willkommen bei Arch Linux

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:

• nvidia wird mit nvidia-open ersetzt
• nvidia-dkms wird mit nvidia-open-dkms ersetzt
• nvidia-lts wird mit nvidia-open-lts ersetzt

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:

1. Die Pakete nvidia, nvidia-lts, oder nvidia-dkms deinstallieren
2. 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 reflector verwendet wird, auf archlinux.org gehostet wird, verwendet bitte während eines Ausfalls standardmäßig die im Paket pacman-mirrorlist aufgeführten Spiegelserver.
  • ISO: Installationsmedien findet ihr unter Arch Linux Downloads.
• 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>

Zusätzliche Anmerkungen

• 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).

1. Vor dem Bau eines Pakets aus dem AUR sollte man auf jeden Fall die Kommentare lesen.
2. Wenn man ein Paket baut, sollte dies mit einem Useraccount geschehen, der keine Rootrechte hat.
3. Die im PKGBUILD referenzierten Quellen (url= und source=) sollten nicht auf „Alternativen“ verweisen, sondern den Originalquellen des Programmentwicklers entsprechen.
4. 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.

Vor etwa zwei Jahren wurde das [community]-Repo im Zuge der Git-Migration mit [extra] zusammengeführt. Um die Installationen der Anwender nicht kaputt zu machen, wurde das Repository noch in einem leeren Zustand beibehalten. Zum 1. März 2025 wurde dieses Repository endgültig gelöscht.

Auf Systemen auf denen in der /etc/pacman.conf das Repository noch eingetragen ist, wird ein Update mittels pacman -Sy nun eine Fehlermeldung beim Abrufen der Repository-Metadaten ausgeben.

Die folgenden veralteten Repositorys wurden entfernt: [community], [community-testing], [testing], [testing-debug], [staging], und [staging-debug].

Es ist sicherzustellen, dass die zuvor genannten Repositorys aus der /etc/pacman.conf entfernt werden. Eine .pacnew-Datei wurde mit pacman>=6.0.2-7 ausgeliefert.

Update/Entwarnung: Es wurde eine Arch-spezifisch gepatchte Version des Kernels 6.13.1 veröffentlicht: 6.13.1.arch2-1. Laut der Berichte in den jeweiligen Diskussionen behebt dieser das Problem mit dem Kernel 6.13.1 für Arch Linux.

Das Update auf Kernel 6.13.1 kann also durchgeführt werden, sobald der verwendete Mirror aktualisiert wurde und die Version 6.13.1.arch2-1 verfügbar ist.

In der Diskussion in der LKML wird gemeldet, dass das Problem über einen Patch in 6.14.0-rc1 auch direkt im Kernel behoben werden kann

Originalmeldung: Es tauchen aktuell Informationen auf, dass ein Update auf den Kernel 6.13.1.arch1-1 Probleme verursacht. Laut initialer Meldung sollte dies die Interaktion mit Flatpak betreffen, laut der Kommentare scheint es aber ein Problem zu sein das den Kernel selbst betrifft.

Siehe #110 auf der Arch-GitLab-Instanz

Im englischen Arch-Forum gibt es zudem eine Diskussion, die auch Probleme mit der Grafikdarstellung hat. Dies Betrifft laut der Diskutanten sowohl Nvidia- als auch AMD-Karten.

Es wird daher empfohlen, vor dem Update des Kernels die genannten Quellen daraufhin zu überprüfen ob das Problem behoben wurde, und bis dahin den Kernel von den zu aktualisierenden Paketen auszuschließen, dazu kann man IgnorePkg in /etc/pacman.conf ergänzen.

[options]
IgnorePkg = linux
...

Sollte das Kernelupdate auf einem System bereits durchgeführt worden sein, so kann man entweder ein Kerneldowngrade durchführen, oder den LTS-Kernel verwenden.

Diese Meldung wird aktualisiert, sobald weitere Erkenntnisse vorliegen, oder die beschriebene Problematik als Gelöst angesehen wird.

6. Februar: Die Problematik scheint darin zu liegen, wie der Kernel FUSE verwendet. In der LKML gibt es dazu inzwischen auch einen Mailverlauf. Das Problem scheint zudem inzwischen auch auf einen spezifischen Patch eingeschränkt worden zu sein.

7. Februar: Der Bugreport, der aus der Diskussion auf der Arch-Gitlab-Instanz heraus in der LKML gestellt wurde, und wird nun auch in der LKML diskutiert. Aktuell besteht das Problem auch noch im ersten Release Candidate für den Kernel 6.14.

8. Februar: Im Arch-Bugtracker kommen Rückmeldungen rein, das das Problem mit durch den Kernel 6.13.1.arch2-1 behoben wird. Dieser beinhaltet einen Arch-Linux-spezifischen Patch. In der Diskussion in der LKML wird gemeldet, dass das Problem über einen Kernel-Patch in 6.14.0-rc1 behoben werden kann.