Fehlerbehebung

Fedora Atomic Desktops verwenden eine neue Methode zur Bereitstellung und Verwaltung Ihres Desktop-Betriebssystems. Daher können im täglichen Gebrauch gelegentlich Probleme auftreten. Im Folgenden finden Sie einige der häufigsten Probleme und mögliche Lösungsansätze.

"Forbidden base package replacements"

Dies kann vorkommen, wenn ein hinzugefügtes Paket von einem Paket des Basisbetriebssystems abhängt. Im problematischen Fall benötigt das hinzugefügte Paket eine neuere Version des abhängigen Pakets, die im Basisbetriebssystem nicht verfügbar ist.

In den meisten Fällen behebt das Warten auf eine neuere OSTree-Compose-Datei dieses Problem. Das abhängige Paket wird in der Compose-Datei aktualisiert, und das einzubindende Paket kann anschließend erfolgreich verarbeitet werden.

Sollten Sie jedoch auch mit einer neueren Compose-Version weiterhin auf dieses Problem stoßen, können Sie versuchen, die Metadaten mit rpm-ostree cleanup -m zu bereinigen und anschließend rpm-ostree install erneut auszuführen.

Alternativ können Sie versuchen, nach der cleanup-Aktion auf eine beliebige updates-Referenz, wie zum Beispiel fedora/44/updates/x86_64, umzusteigen.

Weitere Informationen finden Sie unter rpm-ostree#415.

Installation von Paketen nach /opt oder /usr/local

Die Installation in /opt wurde häufig als Problem genannt, wenn Benutzer versuchten, Google Chrome zu installieren. Ein https://github.com/projectatomic/rpm-ostree/pull/1795[Teillösungsansatz ermöglicht es Benutzern, Google Chrome übereinander zu installieren. Dies ist jedoch keine vollständige Lösung für Anwendungen, die veränderliche Daten in /opt schreiben.

Dieses Problem wird unter rpm-ostree#233 verfolgt.

NVIDIA-Treiber verwenden

Das Projekt Universal Blue erstellt Betriebssystemabbilder mit integrierten NVIDIA-Treibern. Diese Abbilder basieren auf den Fedora Atomic Desktop-Abbildern und enthalten zusätzliche, vom Projektentwickler vorgenommene Änderungen. Die Universal Blue-Abbilder werden vom Fedora-Projekt nicht offiziell unterstützt. Die Verwendung erfolgt auf eigene Gefahr.

Sie können die offiziellen NVIDIA-Binärtreiber aus den RPM Fusion-Paketquellen installieren.

Die NVIDIA-Binärtreiber werden nicht vom Fedora-Projekt gepflegt und sind möglicherweise nicht immer für die in Fedora Atomic Desktops enthaltene Kernelversion verfügbar.
  1. Stellen Sie zunächst sicher, dass Ihr System vollständig aktualisiert ist, indem Sie sudo rpm-ostree upgrade ausführen und das System neu starten.

  2. Richten Sie anschließend die RPM Fusion-Paketquellen gemäß der Dokumentation ein, einschließlich der beiden Neustarts.

  3. Installieren Sie abschließend die Treiber:

    # rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
    # rpm-ostree kargs --append=rd.driver.blacklist=nouveau,nova-core \
        --append=modprobe.blacklist=nouveau,nova-core \
        --append=nvidia-drm.modeset=1 \
        --append=initcall_blacklist=simpledrm_platform_driver_init
    # systemctl reboot

Bei Verwendung von Secure Boot müssen die lokal installierten NVIDIA-Treiber mit einem lokalen Schlüssel signiert werden, der mit mokutil registriert wird. Weitere Informationen finden Sie in der Fehlermeldung fedora-silverblue#499.

Möglicherweise treten während der Installation auch die folgenden Probleme auf: #286, #331

Vielen Dank an Alex Larsson, der die notwendigen Änderungen an den Paketen akmods und kmodtools vorgenommen hat. Mehr über Alex' Arbeit erfahren Sie in seinem Blog.

Kernelmodule und Treiber außerhalb des Kernelbaums, die DKMS verwenden

Fedora Atomic Desktops unterstützen derzeit kein DKMS. Siehe das Upstream-Problem rpm-ostree#1091.

Stattdessen empfehlen wir, für externe Kernelmodule kmods-Pakete zu erstellen und diese in die RPM Fusion-Paketquellen einzureichen. Die Kmods-Pakete werden dann von akmods) verwendet, welches auf Fedora Atomic Desktops unterstützt wird.

Hinzufügen externer Paketquellen

Dieser Abschnitt behandelt Softwarequellen von Drittanbietern, die nicht offiziell mit dem Fedora-Projekt verbunden sind oder von diesem unterstützt werden. Die Verwendung erfolgt auf eigene Gefahr.

Wenn Sie RPM Fusion-Paketquellen verwenden möchten, folgen Sie bitte dem Abschnitt Aktivieren von RPM Fusion-Paketquellen.

Manche Software ist möglicherweise nur über eine externe Paketquelle verfügbar. Sie können eine externe Paketquelle unter Fedora Atomic Desktops manuell hinzufügen, indem Sie die Datei .repo in /etc/yum.repos.d/ und den GPG-Schlüssel in /etc/pki/rpm-gpg/ ablegen. Im Folgenden finden Sie ein vollständiges Beispiel für die Einrichtung der Taiscale-Paketquelle:

  1. Paketquellenkonfiguration abrufen und installieren:

    $ curl -O https://pkgs.tailscale.com/stable/fedora/tailscale.repo
    [tailscale-stable]
    name=Tailscale stable
    baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch
    enabled=1
    type=rpm
    repo_gpgcheck=1
    gpgcheck=0
    gpgkey=https://pkgs.tailscale.com/stable/fedora/repo.gpg
    $ sudo install -o 0 -g 0 -m644 tailscale.repo /etc/yum.repos.d/tailscale.repo
  2. GPG-Schlüssel abrufen und installieren:

    $ curl -O https://pkgs.tailscale.com/stable/fedora/repo.gpg
    $ sudo install -o 0 -g 0 -m644 repo.gpg /etc/pki/rpm-gpg/tailscale.gpg
  3. Ersetzen Sie die gpgkey=-URL in der Paketquellenkonfiguration durch den Pfad zu den GPG-Schlüsseln:

    $ sudoedit /etc/yum.repos.d/tailscale.repo
    $ cat /etc/yum.repos.d/tailscale.repo
    [tailscale-stable]
    name=Tailscale stable
    baseurl=https://pkgs.tailscale.com/stable/fedora/$basearch
    enabled=1
    type=rpm
    repo_gpgcheck=1
    gpgcheck=0
    ### Update this line
    gpgkey=file:///etc/pki/rpm-gpg/tailscale.gpg
    ###    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  4. Installieren Sie die neuen Pakete mit:

    $ rpm-ostree install tailscale

Eine bessere Unterstützung für diesen Anwendungsfall in rpm-ostree wird unter rpm-ostree#4014 verfolgt.

SELinux-Probleme

Da Benutzer von Fedora Atomic Desktops im täglichen Gebrauch häufig die Standard-SELinux-Richtlinie angepasst haben, um ein oder mehrere SELinux-bezogene Probleme zu umgehen, geschieht dies üblicherweise, wenn im Protokoll eine SELinux-Verweigerung angezeigt wird. Falls dies der Fall ist und Sie zur Standard-SELinux-Richtlinie zurückkehren möchten, können Sie die folgenden Schritte ausführen.

  1. Überprüfen Sie den Status der SELinux-Richtlinie

    $ sudo ostree admin config-diff | grep policy
    M    selinux/targeted/active/policy.linked
    M    selinux/targeted/active/policy.kern
    M    selinux/targeted/policy/policy.31
    A    selinux/targeted/policy/policy.30

    Wenn dieser Befehl eine Ausgabe liefert, wurde Ihre SELinux-Richtlinie gegenüber der Standardeinstellung geändert.

  2. Kopieren Sie die im OSTree-Compose-Paket enthaltene Standard-SELinux-Richtlinie

    $ sudo cp -al /etc/selinux{,.bak}
    $ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/

    Danach sollte die Ausgabe von ostree admin config-diff | grep policy nicht mehr anzeigen, dass die Richtlinie geändert wurde.

    Falls Ihre Richtlinie immer noch geändert zu sein scheint, können Sie versuchen, wie folgt vorzugehen.

  3. Entfernen Sie die SELinux-Richtlinie; kopieren Sie die Standardrichtlinie hinein

    $ sudo rm -rf /etc/selinux
    $ sudo cp -aT /usr/etc/selinux /etc/selinux

    Anschließend sollte der Befehl ostree admin config-diff | grep policy keine Änderungen zurückgeben.

Benutzer konnte nicht zur Gruppe hinzugefügt werden

Aufgrund der Art und Weise, wie rpm-ostree Benutzer- und Gruppeneinträge verarbeitet, ist es unter Umständen nicht möglich, einen Benutzer mit usermod -a -G erfolgreich zu einer Gruppe hinzuzufügen. Bis rpm-ostree auf systemd sysusers umstellt, müssen Benutzer die Datei /etc/group mit Daten aus der Datei /usr/lib/group füllen, bevor sie sich selbst einer Gruppe hinzufügen können.

Wenn Sie beispielsweise einen Benutzer zur Gruppe libvirt hinzufügen möchten:

$ grep -E '^libvirt:' /usr/lib/group | sudo tee -a /etc/group
$ sudo usermod -aG libvirt $USER
Sie müssen sich ab- und wieder anmelden, um diese Änderungen anzuwenden.

Dieses Problem wird unter rpm-ostree#29 und rpm-ostree#49 verfolgt.

ostree fsck meldet Dateibeschädigung

Es kann vorkommen, dass eine oder mehrere Dateien auf der Festplatte beschädigt werden oder fehlen. In diesem Fall meldet ostree fsck Fehler in bestimmten Commits. Eine Umgehungslösung besteht darin, den gesamten OSTree-Commit als teilweise abgerufen zu markieren und ihn anschließend erneut abzurufen.

Das schreibgeschützte Verzeichnis /boot/efi verhindert jegliche Aktualisierungen

Dieses Problem tritt am häufigsten auf, wenn Benutzer Fedora Atomic Desktops auf Apple-Hardware installiert haben. Die /boot/efi-Partition auf Apple-Hardware ist als HFS+ formatiert und daher nicht immer ausfallsicher gegenüber Stromausfällen oder anderen schwerwiegenden Ereignissen.

Da Fedora Atomic Desktops nun das Paket hfsplus-tools in der Basis-Compose-Datei enthält, ist es für Benutzer relativ einfach geworden, diese Art von Fehler zu umgehen.

# umount /boot/efi
# fsck.hfsplus /dev/sda1
# mount -o rw /boot/efi

Weitere Details finden Sie im GitHub-Issue-Ticket rpm-ostree#1380.

Fedora Atomic Desktop kann nicht auf EFI-Systemen installiert werden

Benutzer berichten, dass sie Fedora Atomic Desktop nicht auf einem EFI-basierten System installieren können, auf dem zuvor ein anderes Betriebssystem installiert war. Die häufig auftretende Fehlermeldung sieht folgendermaßen aus:

ostree ['admin', '--sysroot=/mnt/sysimage', 'deploy', '--os=fedora-workstation', 'fedora-workstation:fedora/28/x86_64/workstation'] wurde mit dem Code -6 beendet.

Es gibt ein paar mögliche Umgehungslösungen:

  • Wählen Sie während der Installation „Benutzerdefinierte Partitionierung“ und erstellen Sie eine zusätzliche EFI-Partition. Weisen Sie die neu erstellte EFI-Partition dem Verzeichnis /boot/efi zu. Anschließend können Sie die vorherigen Betriebssysteme parallel zu Ihrem Fedora Atomic Desktop starten. Sollte diese Vorgehensweise nicht funktionieren, befolgen Sie die unten stehenden Schritte.

  • Formatieren Sie die EFI-Partition auf dem Host während des Installationsvorgangs neu. Dies kann durch Auswahl von „Benutzerdefinierte Partitionierung“ und Aktivieren des Ankreuzfelds „Neu formatieren“ beim Erstellen der Partition /boot/efi erfolgen.

Das Neuformatieren von /boot/efi führt wahrscheinlich dazu, dass zuvor installierte Betriebssysteme nicht mehr starten können. Sichern Sie daher unbedingt alle wichtigen Daten, bevor Sie diese Vorgehensweise anwenden.

Dieses Problem wird unter Bugzilla#1575957 verfolgt.

Toolbox: Fehler beim Auflisten der Abbilder mit com.redhat.component=fedora-toolbox

Ab Version 1.4.0 von podman ist diese Umgehungslösung nicht mehr erforderlich. Stellen Sie sicher, dass podman auf dem neuesten Stand ist, indem Sie rpm-ostree upgrade ausführen, bevor Sie diese Umgehungslösung anwenden.

Bei der Ausführung des Befehls toolbox list erzeugen Systeme, die podman-Versionen neuer als 1.2.0 verwenden, die folgende Fehlermeldung:

toolbox: failed to list images with com.redhat.component=fedora-toolbox

Die folgende Problemumgehung könnte für andere toolbox-Fehler hilfreich sein, die durch podman-Versionen größer als 1.2.0 verursacht werden. Siehe toolbox#169.

Als Ausweichlösung können podman-Pakete ab Version 1.2.0 durch folgenden Befehl überschrieben werden:

$ rpm-ostree override --remove=podman-manpages \
    replace https://kojipkgs.fedoraproject.org//packages/podman/1.2.0/2.git3bd528e.fc30/x86_64/podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm

Starten Sie das System neu, um die Änderungen zu übernehmen.

Zur Information: Das Paket kann auch durch Befolgen der folgenden Schritte überschrieben werden:

  1. Laden Sie podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm von Koji herunter.

  2. Entfernen Sie podman-manpages durch Ausführen von: rpm-ostree override remove podman-manpages.

  3. Überschreiben Sie das aktuell installierte podman-Paket (mit dem Paket, das Sie im ersten Schritt heruntergeladen haben) wie folgt:

    $ rpm-ostree override replace podman-1.2.0-2.git3bd528e.fc30.x86_64.rpm

Sie können das System jetzt neu starten, damit die Änderung wirksam wird.

Um diese Umgehungslösung rückgängig zu machen, führen Sie die folgenden Befehle aus:

$ rpm-ostree override reset podman
$ rpm-ostree override reset podman-manpages

Aufgrund fehlender Berechtigungen konnte die Toolbox nicht aufgerufen werden

Bei bestimmten Versionen von podman führt der Versuch, eine Toolbox zu öffnen, zu Fehlern. Sie können dies beheben, indem Sie die Berechtigungen für die Overlay-Container mit folgendem Befehl zurücksetzen:

$ sudo chown -R $USER ~/.local/share/containers/storage/overlay-containers

Dadurch werden die Berechtigungen für Ihre Container zurückgesetzt und Sie können diese erneut betreten.

Siehe das Upstream-Podman-Problem: podman#3187.

Ausführen von restorecon

Sie sollten restorecon niemals auf einem Fedora Atomic Desktop-System ausführen. Weitere Informationen finden Sie im folgenden Fehlerbericht: Bugzilla#1259018

Sollte Ihnen dies jedoch passiert sein, ist eine Wiederherstellung möglich.

  1. Starten Sie den Kernel mit der Option enforcing=0 in der Kernel-Befehlszeile

  2. Erstellen Sie lokal einen neuen, „korrigierten“ Commit

  3. Stellen Sie den neuen, „korrigierten“ Commit bereit

  4. Führen Sie restorecon aus

  5. Neustart

  6. Aufräumen

$ rpm-ostree status -b | grep BaseCommit
              BaseCommit: 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee
### Falls der obige Befehl nichts ausgibt, versuchen Sie Folgendes:
$ rpm-ostree status -b | grep Commit
              Commit: 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee
$ sudo ostree checkout \
    -H 696991d589980aeaef5eda352dd7ad3d33c444c789c209f793a84bc6e7269aee \
    /ostree/repo/tmp/selinux-fix
$ sudo ostree fsck --delete
$ sudo ostree commit --consume \
    --link-checkout-speedup --orphan --selinux-policy=/ /ostree/repo/tmp/selinux-fix
$ sudo restorecon -Rv /var
$ sudo restorecon -Rv /etc
### Im nachfolgenden Befehl ersetzen Sie:
### - „x86_64“ durch Ihre tatsächliche CPU-Architektur
### - „silverblue“ durch den Name Ihrer Fedora Atomic Desktop-Variante
$ sudo ostree admin deploy fedora:fedora/44/x86_64/silverblue
$ sudo reboot

Der Haken an dieser Wiederherstellungsmethode ist, dass Ihre Layered-Pakete entfernt werden; Sie müssen sie nach der Wiederherstellung erneut einfügen.

Weitere Details finden Sie in diesem Upstream-Kommentar: ostree#1265.

Passwörter im Wiederherstellungsmodus zurücksetzen

Falls Sie Ihr Benutzerpasswort oder Root-Passwort vergessen haben, können Sie das Passwort mit den folgenden Schritten zurücksetzen:

  1. Unterbrechen Sie während des Systemstarts den Bootvorgang im GRUB2-Menü mit der Taste Esc.

  2. Wählen Sie mit den Pfeiltasten den Boot-Eintrag aus, den Sie bearbeiten möchten.

  3. Bearbeiten Sie den ausgewählten Eintrag mit der Taste e.

  4. Verwenden Sie die Pfeiltasten, um die Zeile auszuwählen, die mit linux, linux16 oder linuxefi beginnt.

  5. Gehen Sie zum Ende dieser Zeile (durch Drücken von Strg + e) und hängen Sie init=/bin/bash an.

  6. Drücken Sie Strg + x oder F10, um den Eintrag zu starten.

  7. Führen Sie an der daraufhin angezeigten bash-Eingabeaufforderung die folgenden Befehle aus:

# mount -t selinuxfs selinuxfs /sys/fs/selinux
# /sbin/load_policy
# passwd
# sync
# /sbin/reboot -ff

Wenn Sie das Passwort für ein Benutzerkonto ändern möchten, ersetzen Sie den Befehl passwd durch passwd <Benutzername>.

Nach dem Neustart des Systems sollten Sie sich mit dem Benutzernamen und dem neuen Passwort anmelden können.