Die naheliegende Lösung: /etc/fstab plus ein Dispatcher-Skript für NetworkManager, das anhand von SSID oder Server-Erreichbarkeit automatisch mountet. Klingt nach einer Feierabend-Sache. Ist es aber nicht ganz – ich bin dabei über drei Stolperfallen gestolpert, die einem erst auffallen, wenn der Rechner runterfährt, aufwacht oder in den Standby soll. Genau die drei nehme ich hier mit euch durch.

Getestet habe ich das Ganze auf Arch Linux, aber das Setup ist nicht Arch-spezifisch: Solange eure Distribution systemd und NetworkManager mitbringt – also etwa auch Fedora, Ubuntu, Debian oder openSUSE –, funktioniert alles hier eins zu eins.

Der Grundaufbau

Netzwerkfreigaben bekommen in der fstab klassischerweise noauto, damit sie beim Boot nicht sofort, sondern erst bei Bedarf eingehängt werden:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

Für den Mount-Typ selbst gibt’s je nach Protokoll gute Anleitungen im Arch Wiki, etwa zu Samba/CIFS und zu davfs2 für WebDAV – beide funktionieren unabhängig von der Distribution, solange cifs-utils beziehungsweise davfs2 installiert sind.

Das eigentliche Mounten übernimmt dann ein Skript unter /etc/NetworkManager/dispatcher.d/. NetworkManager ruft solche Skripte bei jeder Verbindungsänderung auf und übergibt Interface und Status (up, down, pre-down und ein paar weitere) mit – alle Details dazu stehen in der NetworkManager-dispatcher-Manpage. Ein simples Skript prüft die aktive WLAN-SSID und mountet, wenn’s passt:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Fertig, oder? Nicht ganz. Sobald ihr das System runterfahrt, aus dem Standby weckt oder in den Standby schickt, zeigt sich, dass die Sache Tücken hat.

Warum nicht einfach GVfs?

Ihr fragt euch jetzt vielleicht, wieso ich mir das mit fstab und Dispatcher-Skripten überhaupt antue – GNOME bietet über „Mit Server verbinden“ im Dateimanager doch einen viel einfacheren Weg, Netzwerkfreigaben per SMB oder WebDAV einzubinden. Genau da liegt für mich das Problem.

Solche Mounts laufen nicht über den Kernel, sondern über GVfs, GNOMEs virtuelles Dateisystem. Programme, die die GIO-Bibliothek nutzen – fast alle GTK-Anwendungen, allen voran der Dateimanager selbst –, sprechen Freigaben direkt über eigene URIs wie smb:// oder dav:// an und zeigen entsprechend auch Vorschaubilder und Metadaten korrekt an. Für Programme, die das nicht können, blendet GVfs die Freigabe zusätzlich unter /run/user/<uid>/gvfs als ganz normalen Pfad ein. Diese Brücke läuft tatsächlich über FUSE – GVfs selbst ist zwar kein klassisches FUSE-Dateisystem, sondern eine eigene Architektur mit Daemon-Prozessen pro Protokoll, stellt aber genau für diesen Fall über gvfsd-fuse einen POSIX-kompatiblen Pfad bereit.

Genau diese Brücke ist bei mir der Knackpunkt: Nicht jedes Programm kommt damit zuverlässig klar. Konkret zeigt sich das bei mir in einem Markdown-Editor, in den ich auch Bilder für Artikel einbinde. Der Dateimanager zeigt die Bilder auf dem Netzlaufwerk ganz normal an, weil er GVfs nativ spricht. Der Markdown-Editor dagegen zeigt für dasselbe Bild nur einen Platzhalter – die Einbindung über den FUSE-Pfad funktioniert schlicht nicht zuverlässig, obwohl die Datei nachweislich da ist.

Ein klassischer Kernel-Mount über CIFS oder davfs2, wie im Rest dieses Artikels beschrieben, taucht dagegen als ganz normaler, stabiler POSIX-Pfad im Dateisystem auf – ohne Sonderbehandlung, für jedes Programm gleich. Der Mehraufwand mit fstab und Dispatcher-Skripten zahlt sich also gerade dann aus, wenn ihr Freigaben nicht nur im Dateimanager, sondern in ganz unterschiedlichen Anwendungen zuverlässig nutzen wollt.

Problem 1: Der Rechner fährt nicht mehr sauber runter

Fehlt in der fstab die Option _netdev, weiß systemd nicht, dass es sich hier um eine Netzwerkfreigabe handelt. Beim Shutdown kann es dann passieren, dass systemd versucht auszuhängen, nachdem das Netzwerk schon weg ist – der umount blockiert, bis der Job-Timeout greift, und euer System hängt beim Herunterfahren fest.

_netdev behebt das, weil systemd damit die richtige Reihenfolge kennt: erst aushängen, dann Netzwerk kappen. Wichtig ist außerdem, dass ein Dispatcher-Skript nicht nur auf down, sondern auf pre-down reagiert – der Status feuert, bevor die Verbindung wirklich fällt, während down schon danach kommt und für ein sauberes Aushängen zu spät ist. Damit das klappt, braucht es zusätzlich einen Symlink im Unterordner pre-down.d/.

Problem 2: Nach dem Aufwachen hängt sich der Dateimanager auf

Ein mount-Aufruf für CIFS oder WebDAV läuft im Kernel und kann bei nicht erreichbarem Server ziemlich lange blockieren – gerade kurz nach dem Aufwachen, wenn DNS oder Routing noch nicht ganz da sind. NetworkManager wartet standardmäßig synchron, bis so ein Dispatcher-Skript fertig ist, bevor es weitermacht. Hängt der mount-Aufruf, hängt bei euch plötzlich auch der Dateimanager oder die Netzwerkanzeige, weil die vom Verbindungsstatus abhängen.

Die Lösung: Mount-Versuche einfach im Hintergrund laufen lassen, damit das Dispatcher-Skript selbst sofort zurückkehrt, egal wie lange der eigentliche Mount braucht.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Der Standby funktioniert plötzlich nicht mehr

Und hier wird’s spannend. Mit der Lösung aus Problem 2 stolpert ihr in ein neues, deutlich fieseres Problem, das sich in meinem Fall so äußerte: Der Bildschirm geht aus, aber Tastaturbeleuchtung und LEDs bleiben an – ihr müsst hart abschalten. Was war passiert?

Der mount-Syscall für CIFS oder davfs blockiert bei nicht erreichbarem Server im sogenannten D-Zustand (uninterruptible sleep) – einem Zustand, den kein Signal unterbricht, auch SIGKILL nicht. Bevor der Kernel tatsächlich schlafen legt, versucht er, alle Prozesse einzufrieren. Ein Prozess im D-Zustand lässt sich aber nicht einfrieren, und der ganze Standby hängt fest, bis die Netzwerkoperation im Kernel von selbst aufgibt – das kann durchaus ein paar Minuten dauern.

Weil die Mount-Versuche aus Problem 2 jetzt länger im Hintergrund weiterlaufen, steigt eben auch die Chance, dass genau in dem Moment, in dem ihr in Standby gehen wollt, so ein blockierender Verbindungsversuch gerade aktiv ist.

Der zuverlässige Ausweg: Vor jedem mount erst mit einem echten Userspace-Verbindungstest prüfen, ob der Server überhaupt erreichbar ist – so einer lässt sich per Timeout wirklich abbrechen, zum Beispiel über Bashs eingebautes /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Nur wenn der Test klappt, folgt der eigentliche mount. Damit landet ihr so gut wie nie mehr im riskanten, blockierenden Kernel-Connect, weil ihr zu dem Zeitpunkt schon wisst, dass der Server da ist.

Die Kombination, die bei mir funktioniert

Am Ende braucht ein robustes Setup vier Zutaten:

• _netdev in der fstab, damit systemd Netzwerkfreigaben beim Herunterfahren richtig einordnet.
• pre-down-Handling samt Symlink in pre-down.d/, damit das Aushängen garantiert vor dem Verbindungsabbau passiert – mit Timeout und Lazy-Unmount als Backup, falls der normale umount mal zickt.
• Asynchrone Mounts im up-Fall, damit NetworkManager und alles, was davon abhängt, nicht blockiert.
• Ein Erreichbarkeitstest vor jedem mount, damit der eigentliche, potenziell blockierende Kernel-Connect gar nicht erst passiert.

Dazu noch ein kleiner Healthcheck per systemd-Timer, der ein paar Minuten nach dem Boot und danach regelmäßig nachschaut, ob die Freigaben wirklich da sind, und notfalls nachhilft. Praktisch, falls der auslösende Netzwerk-Event mal zu früh oder zu spät kommt.

Alle Dateien im Überblick

Damit ihr das Ganze direkt nachbauen könnt, hier der komplette Satz an Dateien. Ich habe die Beispielnamen aus meinem eigenen Setup (ein Samba-Server namens bender, WebDAV via tuxedo) durch generische Platzhalter ersetzt – die müsst ihr natürlich an eure eigene Umgebung anpassen.

/etc/fstab – die beiden Freigaben, einmal Samba, einmal WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

Die fstab referenziert die Zugangsdaten nur, gespeichert werden sie in eigenen Dateien – schon damit das Passwort nicht im Klartext in einer Datei steht, die jeder lesen kann.

/etc/samba/server.credentials – Zugangsdaten für die Samba-Freigabe:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets – Zugangsdaten für die WebDAV-Freigabe, referenziert wird hier der Mountpunkt statt einer Option in der fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Beide Dateien gehören root und dürfen für niemand sonst lesbar sein:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh – die gemeinsame Bibliothek, die alle anderen Skripte einbinden:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        [[ "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount – Samba-Freigabe, gebunden an eine bestimmte WLAN-SSID oder ans Kabelnetz:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount – WebDAV-Freigabe, die einfach nur einen erreichbaren Cloud-Server voraussetzt:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

Für beide Skripte braucht ihr zusätzlich noch die passenden Symlinks, damit pre-down garantiert vor dem Verbindungsabbau feuert:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount \
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount \
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh – das Sicherheitsnetz, das regelmäßig nachschaut:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service und mount-healthcheck.timer – Systemd-Einheiten, die das Healthcheck-Skript 60 Sekunden nach dem Boot und danach alle 10 Minuten anstoßen:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Aktivieren nicht vergessen:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts – optionales Sicherheitsnetz vor dem Suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount\.cifs' 2>/dev/null
        pkill -9 -f 'mount\.davfs' 2>/dev/null
        ;;
esac

exit 0

Alle Skripte müssen ausführbar sein:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh \
              /etc/NetworkManager/dispatcher.d/90-server-mount \
              /etc/NetworkManager/dispatcher.d/90-webdav-mount \
              /usr/local/bin/mount-healthcheck.sh \
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Lange Reder, kurzer Sinn

Automatisches Einhängen von Netzwerkfreigaben über NetworkManager funktioniert gut, ist aber kein Fünf-Minuten-Job, wie es die Doku vermuten lässt. Wenn ihr nur den mount-Befehl in ein up-Skript packt, holt euch früher oder später eines der drei Probleme ein – meistens genau dann, wenn ihr unterwegs seid und kein Log zur Hand habt.

Mit _netdev, korrektem pre-down-Timing, asynchroner Ausführung und einem echten Erreichbarkeitstest vor jedem Mount seid ihr auf der sicheren Seite. Und das Muster lässt sich eins zu eins auf andere netzwerkabhängige Automatisierungen übertragen, etwa VPN-Verbindungen oder Backup-Jobs, die nur im richtigen Netz laufen sollen.

Schuld daran ist ein Update des offiziellen Linux-Clients auf Electron-Basis, das die GTK-Style-Window-Decoration durcheinandergebracht hat. Die Funktionalität von Spotify bleibt zwar unverändert, optisch sieht es aber alles andere als schick aus.

Lösungsmöglichkeiten für Spotify

Es gibt zwei einfache Wege, um das Problem zu beheben. Die bequemste Variante ist, Spotify als Flatpak zu installieren. Die Flatpak-Version zeigt den blauen Rahmen nicht und ihr müsst euch um nichts kümmern. Änderungen an der Konfiguration sind nicht nötig.

Falls ihr Spotify hingegen über den Spotify Launcher (Paket spotify-launcher aus den Extra-Quellen von Arch) oder direkt aus dem AUR (Eintrag spotify) installiert habt, müsst ihr das Start-Flag --ozone-platform=x11 setzen. Damit wird die GTK-Dekoration korrekt angezeigt. Je nach Installationsart fügt ihr das Flag wie folgt ein:

Für AUR-Spotify in der Datei ~/.config/spotify-flags.conf:

--ozone-platform=x11

Für Spotify Launcher in ~/.config/spotify-launcher.conf:

[spotify]
extra_arguments = ["--ozone-platform=x11"] 

Eventuell müsst ihr diese Dateien erst anlegen. Nach einem Neustart von Spotify sollte der blaue Rahmen verschwunden sein und alles wieder normal aussehen.

Korrektur von Fabian auf Mastodon: Das stimmt so nicht. Das ist ganz alleine dem geschulded das Spotify Wayland-nativ läuft und dort, unter GNOME, eine clientseitige Dekoration (CSD) braucht, die es über diese blaue bereit stellt. Das ganze wieder zu X11 zwingen schafft eventuell echte Probleme, wie verschwommene Schriften, schlechtes (kein) scaling und so weiter. Spotify ist auch nicht Elektron, sondern Chromium Embedded Framework (CEF).

Klar, es ist eine Krücke, aber eine die derzeit hilft. Die Änderung lässt sich ja auch schnell wieder rückgängig machen. Die anderen Optionen wären, Gnome unter X11 zu betreiben oder sich mit den blauen Rahmen anzufreunden. Beides in meinen Augen auch nicht gerade optimal. So ist es erstmal ein Workaround, den man natürlich nicht vergessen sollte, falls sich Spotify irgendwann einmal wieder komisch verhält.

GNOME geht hier andere Wege und setzt auf moderne Schnittstellen für Hintergrunddienste. Doch viele Anwendungen – insbesondere proprietäre oder ältere Programme – verlassen sich weiterhin auf das Tray-Modell. Wer solche Tools nutzt, stößt schnell an Grenzen.

GNOME und der Verzicht auf das Legacy-Tray

Statt dem altbekannten Tray setzt GNOME auf moderne Konzepte, um Hintergrunddienste zugänglich zu machen. Dazu gehören:

• Benachrichtigungen im Message Tray: Anwendungen senden Hinweise über das Notification-System – ohne visuelle Präsenz in einem Icon.
• Hintergrunddienste im Systemmenü: Einige Apps (z. B. VPNs oder Bildschirmfreigaben) nutzen spezielle Schnittstellen, um sich direkt im Quick Settings-Menü zu verankern.
• Portale und systemd-User-Services: Anwendungen wie z. B. Syncthing oder Flatpak-Apps nutzen systemd oder D-Bus Portale, um unabhängig vom GUI-Session-Zustand zu laufen.

Diese Architektur ist aus GNOMEs Sicht technisch eleganter – doch viele von euch, die etwa Nextcloud, das TUXEDO Control Center oder andere klassische Apps nutzen, vermissen schlicht die kleinen Icons, die früher dezent im Panel hockten.

Die Lösung heißt AppIndicator – mit Haken

Genau hier kommt die GNOME-Shell-Erweiterung AppIndicator and KStatusNotifierItem Support ins Spiel. Sie bringt das „alte“ Tray zurück in die „neue““ GNOME-Welt – wenn auch nur als Workaround in Form einer Shell-Erweiterung. Optisch macht sie dabei deutlich mehr her als die offizielle Ersatzlösung Status Icons und integriert sich wesentlich besser ins moderne GNOME-Design.

Das Problem: Die Erweiterung wird von Canonical (Ubuntu) gepflegt, und ihre Weiterentwicklung verläuft oft schleppend. Nach jedem neuen GNOME-Release vergehen nicht selten Wochen oder sogar Monate, bis eine kompatible Version bereitsteht. Mit GNOME 48 war das erneut der Fall – doch diesmal gibt es gute Nachrichten.

News aus der Community: Patch für GNOME 48

Beim Stöbern im Issue-Tracker der Erweiterung bin ich auf einen spannenden Hinweis gestoßen: Für GNOME 48 existieren bereits funktionierende Patches! Und noch besser – unter Arch Linux sind diese bereits in das offizielle Paket eingeflossen.

Wenn ihr also Arch oder ein Arch-Derivat wie EndeavourOS oder Manjaro verwendet, könnt ihr euch die aktualisierte Version der Erweiterung direkt über pacman holen:

$ sudo pacman -S gnome-shell-extension-appindicator

Nach der Installation müsst ihr die alte Version der Erweiterung im Erweiterungs-Manager deaktivieren, euch ab- und wieder anmelden. Danach sollte die gepatchte Version als Systemerweiterung auftauchen – und ihr könnt AppIndicators unter GNOME 48 wieder nutzen.

Zwischen Moderne und Kompatibilität

Ich persönlich vermeide Tray-Icons, wo es geht. Viele freie Anwendungen bieten inzwischen native GNOME-Integrationen oder verzichten ganz auf den Zwang zur Hintergrundpräsenz. Doch wenn ihr auf ein Tool angewiesen seid, das nicht auf moderne GNOME-Techniken setzen, kommt ihr um die AppIndicator-Erweiterung kaum herum. Dank der aktiven Community – und dem Patch-Einbau unter Arch – funktioniert sie jetzt auch unter GNOME 48.

Was ist WSL überhaupt?

Für alle unter euch, die mit WSL noch nicht viel zu tun hatten: Das Windows Subsystem for Linux erlaubt es, Linux-Tools und -Anwendungen direkt unter Windows auszuführen – ohne eine virtuelle Maschine aufsetzen oder einen Dual-Boot einrichten zu müssen. Microsoft verfolgt damit seit Windows 10 die Strategie, Entwicklern mehr Flexibilität zu geben, ohne dass sie sich komplett von Windows lösen müssen.

WSL basiert auf Virtualisierungstechniken, allerdings arbeitet es nicht mit vollwertigen VMs, sondern mit leichtgewichtigen Containern, die deutlich weniger Ressourcen fressen. Dadurch lässt sich etwa ein Terminal mit einem Linux-Shell schnell öffnen, Werkzeuge wie grep, sed, awk oder auch pacman lassen sich nativ nutzen – vorausgesetzt, die passende Distribution ist installiert.

Arch Linux für WSL: Jetzt ganz offiziell

Bisher war Arch Linux in WSL nur über Umwege verfügbar. Wer wollte, konnte sich ein inoffizielles Image holen oder mit etwas Aufwand selbst eines erzeugen. Das ändert sich nun: Seit dem 15. April ist Arch Linux ganz offiziell in Microsofts WSL-Verzeichnis gelistet. Der Befehl wsl.exe --list --online zeigt euch alle verfügbaren Distributionen – darunter nun auch „archlinux“. Mit wsl.exe --install -d archlinux könnt ihr euch die schlanke Distribution direkt aus dem Microsoft Store installieren.

Hinter dem offiziellen Image steckt übrigens eine Initiative aus der Community: Anfang des Jahres haben Arch-Entwickler darüber diskutiert, ob man ein offizielles Abbild für WSL bereitstellen sollte. Die Diskussion war schnell entschieden, das Gitlab-Repo eingerichtet und Microsoft ebenfalls mit an Bord. Einmal im Monat wird das Image nun automatisch aktualisiert.

Chance für Linux – aber mit Vorbehalt

Natürlich ist es schön zu sehen, dass Microsoft Linux heute nicht mehr als Feind, sondern als Werkzeug im eigenen Ökosystem betrachtet. Und gerade für Entwickler oder User, die aus beruflichen Gründen nicht vollständig auf Windows verzichten können, ist ein offizielles Arch-Image für WSL eine willkommene Nachricht.

Trotzdem sollten wir die Entwicklung mit einem kritischen Blick begleiten. WSL ist kein vollständiges Linux-System. Systemdienste wie Systemd fehlen oder laufen nur mit Workarounds, nicht alle Tools und Konfigurationen funktionieren wie gewohnt, und letztlich bleibt das Ganze eng an Microsofts Gnaden gekoppelt – inklusive aller Einschränkungen hinsichtlich Datenschutz, Telemetrie und proprietärer Kontrolle.

Update 24.04.25: Viele weitere Details und auch zahlreiche Tipps zu Arch Linux in der WSL findet ihr im Arch Wiki. Generell braucht es für Arch Linux auch die WSL2. Achtet daher darauf euer System entsprechend zu aktualisieren. Auf meinem Testrechner beispielsweise mit Windows 10, tauchte das Arch Linux-Image zuerst nicht auf.

Welche Pakete auf eurem System betroffen sind, ermittelt ihr über das Kommando pacman -Qoq /usr/lib/python3.9. Sollte das System hier ein oder mehrere Namen ausspucken, dann müsst ihr diese über euren AUR-Helper neu erstellen, um in Zukunft Fehler beim Ausführen der entsprechenden Anwendungen auszuschließen. Die schnellste und einfachste Methode dafür ist, die Liste an euren AUR-Helper zu übergeben. Beachtet dazu das zweite Kommando aus dem folgenden Listing. Tauscht den Aufruf des AUR-Helpers, hier paru, gegen das von euch genutzte Programm aus. Zur Kontrolle prüft ihr am Ende, ob es nun keine veralteten Programme mehr gibt.

$ pacman -Qoq /usr/lib/python3.9
chrome-gnome-shell
[...]
python-pympress
python-vlc
setzer
sunflower
$ pacman -Qoq /usr/lib/python3.9 | paru -S - --rebuild
$ pacman -Qoq /usr/lib/python3.9
Fehler: Kein Paket besitzt /usr/lib/python3.9

Die Aktion ist bei allen Systemen nötig, die auf Arch Linux aufsetzen und das AUR integrieren. Dazu gehören natürlich Arch Linux selbst sowie äußerst beliebte Derivate wie Manjaro, aber auch eher Exoten wie ArcoLinux, Chakra oder KaOS. Eine Liste der zahlreichen Arch-Linux-Derivate pflegt das Arch Wiki. Auch wird es nicht das letzte Mal sein, dass die Python-Anwendungen aus dem AUR neu gebaut werden müssen, da nächste Python-Update kommt bestimmt.

Sehr neue Entwicklungen und gerade frisch gestartete Software-Ideen müssen hingegen entweder von Hand oder über aus von den Projekten betrieben Paketquellen integriert werden — wenn es denn überhaupt welche gibt. Nur Arch Linux geht hier wieder einen komplett eigenen Weg, das Arch User Repository oder kurz AUR vereinfacht die Installation fremder Software ganz wesentlich. Wer Arch Linux oder eines seiner Derivate wie etwa Manjaro noch nicht kennt, dem sagt das AUR vielleicht noch nichts: Im Vergleich zu herkömmlichen Paketquellen pflegt das AUR keine Binärpakete, sondern lediglich eine Sammlung von Kochrezepten, die dem System per Skript erklären, wie sich eine Software optimal in das Arch-System integrieren lässt.

Das Arch User Repository

Die dafür notwendige PKGBUILD-Datei (hier am Beispiel von Spotify) enthält Informationen, woher die Anwendung herunterzuladen und wie sie zu installieren ist, inklusive einer Reihe von Anpassungen, plus die benötigten Abhängigkeiten aus der Paketverwaltung. So lässt sich so gut wie jedes Programm ohne große Komplikationen installieren, egal ob es die Entwickler nur in Form des Quellcodes, über DEB- oder RPM-Pakete oder statisch gebaute Binaries bereitstellen. Unter Arch lassen sich so sehr einfach proprietäre Anwendungen wie Chrome oder Spotify installieren oder eben auch ganz neue Entwicklungen. Es braucht nur eine Person, die sich mit dem Schreiben einer PKGBUILD-Datei auskennt — und davon gibt es in der Arch-Linux-Community so einige.

Allerdings braucht es wie immer bei Fremdpaketen einen Disclaimer: Die Hürden Änderungen in das AUR einzubringen oder gar AUR-Pakete zu betreuen, sind im Vergleich zu denen in der Karriere eines offiziellen Arch-Entwicklers geringer. Von daher ist es durchaus möglich, dass Menschen mit schlechten Absichten Manipulationen oder gar Malware in das AUR einbringen. 2018 ist das bereits passiert, damals gab es einen Angriff auf den AUR-Eintrag des Acrobat Readers und zweier weiterer PKGBUILDs. Das AUR ist allerdings auch kein wilder Spielplatz für Bastler und Hacker, eine Gruppe von Trusted Users überwacht das Geschehen im AUR, korrigiert Fehler und leitet neue Beitragende an. In der Praxis lässt sich das AUR daher gut nutzen, zur Sicherheit sollte man allerdings immer mal in die PKGBUILD-Dateien sehen und kontrollieren, ob die Software zum Beispiel von den offiziellen Seiten des entsprechenden Projekts geladen wird.

AUR-Helper helfen im Alltag

Nun zurück zum Thema: Das AUR ist wie angesprochen kein Selbstläufer. Es enthält selbst keine Software oder fertige Pakete, sondern lediglich Skripte zum Bauen von Arch-Paketen. Der offizielle Installationsweg führt somit über das Auschecken der PKGBUILD-Datei aus dem Github-Repository des AUR, danach kontrolliert ihr die PKGBUILD und baut im letzten Schritt letztlich mit makepkg -si das Paket. Der Schalter -i am Ende installiert das am Ende erstellte Paket, dabei werden automatisch die im PKGBUILD definierten Abhängigkeiten aus der Paketverwaltung nachgezogen. Alle während dieses Prozesses heruntergeladenen und gebauten Daten braucht ihr am Ende nicht mehr, daher führte ich diese Schritte gerne im Ordner /tmp des Systems aus. Es sei denn, ich möchte die Daten auf anderen System wiederverwenden.

$ pacman -S --needed base-devel git
$ git clone https://aur.archlinux.org/spotify.git
$ cd spotify
$ less PKGBUILD  ### Mit [Q] beenden
$ makepkg -si

Es gibt viele Arch Nutzer, die generell diesen Weg gehen, so behalten sie die volle Kontrolle über den Vorgang. Allerdings gibt es spätestens dann beim Bauen der AUR-Pakete Probleme, wenn diese selbst zusätzliche Pakete aus dem AUR benötigen. Benötigen diese zusätzlichen Pakete wieder andere Pakete aus dem AUR, wird es arg kompliziert. Aus diesem Grund gibt es eine Reihe von Programmen, AUR-Helper genannt, die den Nutzer bei der Installation von AUR-Paketen unterstützen. Sie automatisieren die oben genannten Schritte und lösen Abhängigkeiten automatisch auf, sodass sich die Installation von Paketen aus dem AUR oft nicht anders anfühlt, als die Installation von Software aus den offiziellen Paketquellen. In der Regel übernehmen die AUR-Helper sogar die Syntax des Arch-Linux-Paketmanagers Pacman.

### AUR-Helper wie Yay oder Pacaur erleichtern die Arbeit
### mit Software aus dem Arch User Repository:
$ yay -S spotify
$ pacaur -S spotify
$ paru -S spotify
### Beim Update kann man sich das 'pacman -Syu' sparen.
### Die AUR-Helper übernehmen die Syntax von Pacman und
### rufen neben den eigen Update auch die aus der Paket-
### verwaltung ab.
$ yay -Syu
$ pacaur -Syu
$ paru -Syu

In der Geschichte der AUR-Helper gibt es immer mal wieder ein hin und her. Bis vor ein paar Jahren war Yaourt (Yet another AUR Helper) das Maß aller Dinge: Das Programm war das einzige, das AUR-Abhängigkeiten automatisch auflöste und vor allen Dingen alle Interaktionen mit dem Nutzer vor dem Build-Vorgang klärte, sodass das eigentliche Bauen später ohne Unterbrechungen in einem Rutsch erfolgte. Eine große Erleichterung, da das Bauen manche Pakete durchaus längere Zeit in Anspruch nimmt, besonders wenn diese aus dem Quellcode kompiliert werden. Doch mit der Version 1.9 stellte der Yaourt-Entwickler seine Arbeit ein, wodurch Pacaur zum Liebling der Nutzer wurde. Bis auch hier wieder der Entwickler goodbye sagte und Yay der Quasi-Standard wurde, auch wenn Pacaur inzwischen einen neuen Betreuer gefunden hat. Aktuell liegt Paru in der Gunst der User am höchsten und liegt im AUR-Ranking ganz vorne.

Ein Mix an AUR-Helfern hilft

Was ist allerdings immer wieder merke: Kein AUR-Helper ist perfekt. Yay erhält zum Beispiel regelmäßig Updates (zuletzt erschien das Update auf Yay 11.0.2 Mitte Oktober 2021), doch ich stelle immer wieder fest, dass das Programm in bestimmten Situationen scheitert. Aktuell bricht Yay zum Beispiel das Bauen von Spotify ab, da Prüfsummen nicht stimmen würden. Von Hand oder mit Pacaur lässt sich das Spotify-Paket jedoch ohne Probleme erstellen. Zudem wird Yay in Go entwickelt, das auf der Festplatte bald 500 MByte belegt (Tipp: Yay über das Binary yay-bin installieren). Auf einem schlanken System würde ich daher eher zu Paru oder Pacaur greifen. Letzteres hat aber auch wieder den Nachteil, dass die Entwicklung trotz eines neuen Projektbetreuers eher still steht. Die letzte Version ist vor über zwei Jahren freigegeben worden.

$ yay -S spotify
[...]
grep: spotify-1.1.72.439-Release: No such file or directory
sha256sum: spotify-1.1.72.439-x86_64-Packages.sha256: no properly formatted checksum lines found
==> ERROR: A failure occurred in prepare().
    Aborting...
 -> error making: spotify

Ideal ist es daher in meinen Augen einen Mix an AUR-Helpern auf einem Arch-System bereitzuhalten und bei Fehlern im Build-Prozess erst einmal einen anderen AUR-Helfer zu testen, bevor man sich auf die Fehlersuche begibt oder gar einen Kommentar unter dem AUR-Eintrag im Repository hinterlässt. Bei mir hat schon mehrmals Yay einen Fehler ausgespuckt, während Pacaur ohne Problem das PKGBUILD abarbeitete und anders herum. Ich persönlich empfehle schon alleine aufgrund des schlankeren Unterbaus generell Paru und Pacaur, wobei Paru euer Hauptprogramm sein sollte — nicht ohne Grund ist Paru das am häufigsten installierte Paket aus dem AUR. Pacaur spielt bei mir die zweite Geige, ist aber immer ein gutes Backup. Yay versuche ich inzwischen zu vermeiden, auch wenn das Kommando yay -Syu bei mir im Gedächtnis eingebrannt ist.

### Installation von Paru
$ sudo pacman -S --needed base-devel
$ git clone https://aur.archlinux.org/paru.git
$ cd paru
$ makepkg -si

### Installation von Yay:
$ pacman -S --needed base-devel git
$ git clone https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg -si
### Alternativ Yay als Binary:
$ git clone https://aur.archlinux.org/yay-bin.git
$ cd yay-bin
$ makepkg -si

### Installation von Pacaur:
$ pacman -S --needed base-devel git
$ git clone https://aur.archlinux.org/pacaur.git
$ cd pacaur
$ makepkg -si

$ yay -Syu
[...]
:: PGP keys need importing:
 -> F9A211976ED662F00E59361E5E3C45D7B312C643, required by: spotify
==> Import? [Y/n] 
:: Importing keys with gpg...
gpg: Keine gültigen OpenPGP-Daten gefunden.
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 0
 -> problem importing keys

Um das Problem nun möglichst einfach zu lösen, macht ihr einfach ein Terminalfenster auf. Danach löscht ihr den obsoleten Schlüssel aus dem System und importiert den neuen GPG-Key der Entwickler von der Spotify-Webseite. Anschließend leert ihr den Cache des AUR-Helpers Yay (war zumindest bei mir nötig) und spielt dann alle anstehenden Updates ein. Diesmal sollte die Aktion ohne Fehler in einem Rutsch durchlaufen. Generell habe ich schon öfters festgestellt, dass Spotify gerne seine Schlüssel ändert, behaltet die Lösung daher also im Hinterkopf.

$ gpg --delete-key 8FD3D9A8D3800305A9FFF259D1742AD60D811D58
$ curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | gpg --import -
$ yay -Sc
$ yay -Syu

Überhaupt lohnt sich bei bockigen AUR-Paketen auch immer ein Blick auf die AUR-Seite des entsprechenden Pakets. Im Fall von Spotify wird die Lösung dort bereits ausführlich diskutiert. Schaut bei den Beiträgen auch immer auf das Datum des jeweiligen Kommentars: Oben unter „Pinned Comments“ sind immer wieder angestaubte Beiträge mit deutlich veralteten Informationen fixiert — je nach Engagement des Paketbetreuers. Erst unter den „Latest Comments“ findet ihr die neusten Kommentare mit aktuellen Hinweisen bei Problemen oder Schwierigkeiten.

Das eigentliche Ende kommt dann im November 2017: Ab diesem Zeitpunkt müssen Paketbetreuer keine 32-Bit-Versionen ihrer Pakete mehr erstellen. Der Schritt beinhaltet essentielle Tools wie etwa Packprogramme oder Werkzeuge zur Paketverwaltung (also bspw. tar und pacman), somit wird dann die i686-Architektur von Arch offiziell aufgegeben… Spätestens dann sollte man seinen Rechner mit einem 64-Bit-Arch neu installieren (wenn es geht), oder auf eine Distribution umsteigen, die noch 32-Bit-Rechner unterstützt.

Title: i686 is dead, long live i686

Due to the decreasing popularity of i686 among the developers and the community, we have decided to phase out the support of this architecture.

The decision means that February ISO will be the last that allows to install 32 bit Arch Linux. The next 9 months are deprecation period, during which i686 will be still receiving upgraded packages. Starting from November 2017, packaging and repository tools will no longer require that from maintainers, effectively making i686 unsupported.

However, as there is still some interest in keeping i686 alive, we would like to encourage the community to make it happen with our guidance. Depending on the demand, an official channel and mailing list will be created for second tier architectures.

Trotz des offiziellen Aus von Arch für 32-Bit-Rechner, wird es wohl aber dennoch noch einen 32-Bit-Zweig der Distribution geben: Die Unterstützung dessen soll die Community übernehmen. Eine entsprechende Mailingliste und einen IRC-Channel dazu gibt es bereits. Über diesen soll die Arbeit koordiniert werden. Als Anwender finde ich es dennoch ein bisschen Schade: Arch ist eine Distribution, die sich wunderbar schlank aufsetzen lässt, von daher ideal für ältere Rechner, bei denen man nicht auf ein „Alte-Rechner-Linux“ zurückgreifen möchte.

Die Seite listet zu jeder Version eines betroffenen Pakets die entsprechenden Meldungen mitsamt dem Gefährdungsgrad sowie dem aktuellen Status auf und zeigt, in welcher Version das Paket bereits gefixed wurde. Oft gibt es ein Arch Linux Security Advisory aka ASA mit zusätzlichen Informationen zur Sicherheitsschwachstelle in der Spalte ganz rechts. Sämtliche Meldungen sind miteinander verlinkt, sodass man sich schnell einen Überblick verschaffen kann.

Wer nun ein hochgefährdetes System betreibt (oder einfach so auf dem Laufenden bleiben möchte), sollte diese Meldungen fortlaufend im Auge behalten, allerdings gibt es noch keinen RSS-Feed der Seite — somit fällt es schwer neue Einträge zu verfolgen. Stattdessen kann man jedoch aber auch ein bestehendes System nach Paketen mit einer entsprechenden Warnung durchsuchen. Dazu dient arch-audit aus dem AUR, das ab der Version 0.1.6 auf die Einträge im Security Tracker zurückgreift.

$ pacaur -S arch-audit
$ arch-audit
Package lib32-libtiff is affected by ["CVE-2015-7554"]. VULNERABLE!
Package libusbmuxd is affected by ["CVE-2016-5104"]. VULNERABLE!
Package openssh is affected by ["CVE-2016-10012", "CVE-2016-10011", "CVE-2016-10010", "CVE-2016-10009"]. Update to 7.4p1-1!
Package php is affected by ["CVE-2016-9936", "CVE-2016-9934", "CVE-2016-9933"]. Update to 7.1.0-2!
Package libwmf is affected by ["CVE-2016-9011", "CVE-2015-4696", "CVE-2015-4695", "CVE-2015-4588", "CVE-2015-0848", "CVE-2009-3546", "CVE-2009-1364", "CVE-2007-3477", "CVE-2007-3473", "CVE-2007-3472", "CVE-2007-2756", "CVE-2007-0455", "CVE-2006-3376"]. VULNERABLE!
Package openjpeg2 is affected by ["CVE-2016-9118", "CVE-2016-9117", "CVE-2016-9116", "CVE-2016-9115", "CVE-2016-9114", "CVE-2016-9113"]. VULNERABLE!
Package libimobiledevice is affected by ["CVE-2016-5104"]. VULNERABLE!
Package openssl is affected by ["CVE-2016-7055"]. VULNERABLE!
Package bzip2 is affected by ["CVE-2016-3189"]. VULNERABLE!
Package lib32-openssl is affected by ["CVE-2016-7055"]. VULNERABLE!
Package libtiff is affected by ["CVE-2015-7554"]. VULNERABLE!
Package jasper is affected by ["CVE-2016-8886"]. VULNERABLE!
Package gst-plugins-bad is affected by ["CVE-2016-9447", "CVE-2016-9446", "CVE-2016-9445"]. VULNERABLE!
$ arch-audit --upgradable
Package php is affected by ["CVE-2016-9936", "CVE-2016-9934", "CVE-2016-9933"]. Update to 7.1.0-2!
Package openssh is affected by ["CVE-2016-10012", "CVE-2016-10011", "CVE-2016-10010", "CVE-2016-10009"]. Update to 7.4p1-1!

Das Ausführen von arch-audit ohne irgendwelche Schalter gibt sämtliche auf dem System Pakete aus, zu denen eine Sicherheitswarnung herausgegeben wurde. Mit dem Schalter --upgradable reduziert man die Ausgabe auf Pakete, zu denen es bereits ein Update in den Paketquellen von Arch Linux gibt. Ein pacman -Syu spielt diese Updates allerdings nicht zwangsläufig sofort ein, da frisch veröffentlichte Updates in der Regel erst einmal in den Testing-Quellen stecken und erst noch freigegeben werden müssen.

$ sudo pacman -Syu
[...]
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (43) archlinux-keyring-20161101-1  blender-17:2.78.a-2
            boost-libs-1.62.0-2  calibre-2.71.0-1  confuse-3.0-1
[...]
            source-highlight-3.1.8-10  ttf-dejavu-2.37-1  vim-8.0.0055-1
            vim-runtime-8.0.0055-1
[...]
(43/43) Prüfe auf Dateikonflikte                   [######################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans-mono.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-sans.conf existiert im Dateisystem
ttf-dejavu: /etc/fonts/conf.d/57-dejavu-serif.conf existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Der Grund für diese Fehler, findet sich in dieser kleinen Änderung am genannten Paket: Anstatt die aufgeführten Dateien physisch in /etc/fonts/conf.d abzulegen, setzt die Paketverwaltung in Zukunft nur noch einen Symlink nach  /etc/fonts/conf.avail. Pacman kann diese Änderung allerdings nicht automatisch umsetzen, man muss die Installation stattdessen erzwingen. Die englische Arch-Seite hat dazu einen kurzen Beitrag in ihren News, im deutschsprachige Pendant fehlt ein entsprechender Hinweis jedoch noch. Nach dem erzwungenen Update, kann man die Paketverwaltung dann wieder ganz normal verwenden.

$ sudo pacman -S --force ttf-dejavu
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (1) ttf-dejavu-2.37-1

Gesamtgröße der installierten Pakete:  9,75 MiB
Größendifferenz der Aktualisierung:  0,57 MiB

:: Installation fortsetzen? [J/n] j
(1/1) Prüfe Schlüssel im Schlüsselring             [######################] 100%
(1/1) Überprüfe Paket-Integrität                   [######################] 100%
(1/1) Lade Paket-Dateien                           [######################] 100%
(1/1) Prüfe auf Dateikonflikte                     [######################] 100%
(1/1) Überprüfe verfügbaren Festplattenspeicher    [######################] 100%
:: Verarbeite Paketänderungen...
(1/1) Aktualisiere ttf-dejavu                      [######################] 100%