Nach dem Tausch von meiner Nvidia GTX 1050 Ti Grafikkarte zu einer AMD Radeon RX 7800 XT startet mein PC noch, aber ich lande immer im Terminal. Ich bin wie folgt vorgegangen:

  1. noch mit der Nvidia Grafikkarte, alles von Nvidia gelöscht:
    şudo pacman -Rscn nvidia
    sudo pacman -Rscn nvidia-settings
    sudo pacman -Rscn `nvidia-utils
    sudo  acman -Rscn opencl-nvidia
    sudo pacman -Rscn opencl-nvidia
    sudo pacman -Rscn libvdpau
  2. die neuen AMD Treiber geladen:
    sudo pacman -S xf86-video-amdgpu
    sudo pacman -S mesa lib32-vulkan-radeon libva-mesa-driver lib32-libva-mesa-driver
  3. Pc runter gefahren, Karten getauscht, neu gestartet und bin dann im Terminal gelandet , statt im Plasma Login.

Was ist da nur passiert? Laut dem pacman.log ist mit dem Löschen von libvdpau viele Plasma-Anwendungen gelöscht worden. Wenn gewünscht kann ich das Log auch posten.

Weil ich ein btrfs-Filesystem verwende und auch Timeshift aktiv bei mit ist, habe ich jetzt aktuell die alte Nvidia Grafikkarte eingebaut und einen Rollback auf dem Stand 1 Tag vor dem Grafikarten Tausch durchgeführt. Der Pc startet und ich kann dies hier auch gerade aktuell schreiben damit, aber ganz sauber scheint mir der PC trotzdem nicht zu sein. Denn mit pacman -Qs nvidiaoder auch mit pacman -Qs firefox wird mit nichts angezeigt, obwohl ich gerade Firefox nutze. Wie kann ich weiter Vorgehen?

Aktuell sehe ich da 3 Möglichkeiten:

  1. Es gibt eine einfache Möglichkeit, die fehlende Software schnell und einfach zu Installieren. Wie würde die aussehen?
  2. Wieder zurück rollen auf den letzten nicht funktionierenden Stand und alles was gelöscht worden ist wieder installieren.
  3. Eine neu Installation. Ist sicherlich die sauberste Sache, aber auch aufwendig.
  • GerBra hat auf diesen Beitrag geantwortet.

    Vorneweg:
    Die -c/--cascade Option von pacman bei -R ist "gefährlich / desktruktiv" und meist (bzw. speziell in deinem Fall auch nicht notwendig).

    -c, --cascade
    Remove all target packages, as well as all packages that depend on one or more target
    packages. This operation is recursive and must be used with care, since it can remove many
    potentially needed packages.

    Fansurfer Der Pc startet und ich kann dies hier auch gerade aktuell schreiben damit, aber ganz sauber scheint mir der PC trotzdem nicht zu sein. Denn mit pacman -Qs nvidiaoder auch mit pacman -Qs firefox wird mit nichts angezeigt, obwohl ich gerade Firefox nutze. Wie kann ich weiter Vorgehen?

    Wird durch dein BTRFS-Snapshooting auch die lokale pacman-Datenbank (Standard: /var/lib/pacman/local) gesichert bzw. wieder hergestellt? Falls Nein, dann ist das schlecht. Ich vermute, durch das --cascade wurden im ersten Versuch u.a. auch das Firefox-Paket entfernt (real und aus der lokalen Datenbank). Nach dem Wiederherstellen des Snapshots ist zwar das Binär-Programm /usr/bin/firefox) wieder vorhanden, aber der Eintrag als installiertes Paket in der DB fehlt. Das ist jetzt kein Beinbruch, erfordert aber später Nachinstallationen.
    Doch, ist ziemlich problematisch. Da du aktuell (Stand des wiederhersgestellten Snaphots) z.B. kein nvidia-* Paket mehr deinstallieren kannst mittels pacman (Da die lokale DB ja wohl nicht mehr mit den aktuellen Programmen auf der Festplatte übereinstimmt.)

    Das also bitte vorher mitteilen: Wird durch dein Timeshift-Snapshot auch /var/local/pacman/* und /var/log/pacman.log gesichert?

    Wenn nein, dann:
    a) Sichere dir die aktuelle /var/log/pacman.log (Änderungen deines obigen ersten Versuchs sind darin geloggt, brauchst du später)
    b) Könntest du z.B. per Snaphot auf den Zustand nach deinem ersten obigen Versuch zurückgehen? Bei dem also

    Fansurfer Nach dem Tausch von meiner Nvidia GTX 1050 Ti Grafikkarte zu einer AMD Radeon RX 7800 XT startet mein PC noch, aber ich lande immer im Terminal.

    das gilt? In dem Zustand sind halt System und lokale DB synchron.

    Teile uns das am besten vorab mit.
    Sinnvoll wäre auch den Teil der pacman.log zu posten ab dem du deine obigen Befehle angefangen hast. Damit man mal sieht was alles deinstalliert wurde.

    Wie gesagt: Ich würde aktuell nichts verändern aus dem wiederhergestellten (grafischen) System. Sondern erstmal die Fragen beantworten. Danach wäre zu entscheiden ob es sinnvoller ist:
    a) mit einem laufenden System, aber "kaputter" lokalen Paketdatenbank oder
    b) mit einem "nur" bis zum Terminal startenden, aber synchroner DB
    weiterzumachen.
    Erstmal nur das.

    Das schrieb ich auch noch, ist aber aktuell nur zu Info:

    Zum ursprünglichen Problem/Vorgehen:
    Das Wechseln von Grafikkarten ist kein Problem, auch im laufenden Betrieb. Es darf halt lediglich nicht versucht werden eine grafische Umgebung zu booten in der noch Verweise/Konfig der alten Hardware aktiv sind.
    Was du ggf. vergessen hast ist das oftmals Grafiktreiber auch im initramfs geladen werden (KMS/EarlyKMS).
    Du solltest vor dem Wechseln dringend nochmal deine /etc/mkinitcpio.conf überprüfen, ob dort noch nvidia-Module zum Laden eingetragen sind. Das korrigieren und ebenfalls dran denken das initramfs neu zu erstellen. Gerade bei jedem Hardware-Wechsel ist das sowieso anzuraten.

    //Edit heute
    Da du dich nicht meldest und ich heute keine Zeit mehr haben würde kurz ein paar Gedanken meinerseits. Aber evtl. hast bzw. wirst du ja neuinstallieren.

    Fansurfer Aktuell sehe ich da 3 Möglichkeiten:

    Ich würde bei deinem Punkt 2) ansetzen., also

    Fansurfer Wieder zurück rollen auf den letzten nicht funktionierenden Stand und alles was gelöscht worden ist wieder installieren.

    Warum? Weil dieser Zustand das Gesamtsystem vom Paketmanager aus gesehen am Besten widerspiegelt.
    Also dieses System (mit AMD GPU) bootet (OK), startet aber kein grafisches Target (sddm/Plasma), aber du landest am TTY-Login und kannst dich einloggen (Oder bootete dieses System nur bis zu einer Rescue/Ermergency-Shell wo ein Root-Login aerforderlich ist?)
    Grund für kein sddm/Plasma können nun sein:
    a) Der Wechsel vom Treiber/Kernel-Modul nvidia zu amdgpu wurde nicht sauber vollzogen, evtl. wie ich schrieb da das initramfs noch alten nvidia-Kram beinhaltet. Oder die Kernel-Commandline noch nvidia-Kram versucht zu setzten.
    Beides sollte durch Analysieren vom System-Journal und/Oder XOrg.<ZAHL>.log herausfindbar sein.
    b) sddm bzw. wichtige Teile von Plasma fehlen aufgrund der "Löschorgie" bei deinem Versuch nvidia zu entfernen. Auch das sollte im Systemlog bzw. XOrg.log rauslesbar sein.
    Wenn dir selbst in dem Moment die Analyse nicht möglich ist kannst du beide Logfiles auch auf einen Pastebin-Server stellen vom TTY-Terminal aus (Ich gehe davon aus daß du Internet-Zuzgamg hast in dem Moment, ping archlinux.de). Eine Möglichkeit ist:
    (Systemlog vom Boot):
    journalctl --system -b | curl -F 'file=@-' 0x0.st
    (XOrg Log findet sich entweder in /var/log/ oder im User-Verzeichnis $HOME/.local/share/xorg/ Schau dir ggf. jeweils mit
    ls -l /obige Pfade) den Datumsstempel an um das Log vom aktuellen Boot zu erwischen. Das dann posten)
    curl -F 'file=@-' 0x0.st < /pfad/zum/richtigen/XOrg.<ZAHL>.log
    Beide Befehle stellen die Ausgabe nach 0x0.st und zu erhältst einen Link. Diesen Link dann hier posten. Setzt natürlich voraus, daß du ein weiteres Gerät hast mit dem du das Forum hier bedienen kannst.

    Fehlende Pakete:

    Im aktuell laufenden System (wiederhergestellter Snapshot) solltest du dir vor weiteren/späteren pacman-Aktionen das Log sichern, z.B. nach /root. Das brauchst du um eine Liste der gelöschten Pakete zu erhalten.

    Da in diesem Zustand ja mehr Programme installiert sind als die (alte) lokale pacman-DB widerspiegelt bietet sich als Hilfe auch noch eine Liste von Programmen an die installiert sind (binär in /usr/bin), zu denen es aber keine Infos in der ("kaputten") pacman-DB mehr gibt. Das könntest du so erhalten (Beide Befehle funktionieren auch als Normaluser):

    LANG=C find /usr/bin -exec pacman -Qo '{}' \; 2>&1 | grep "error:" > $HOME/not_owned_bins.txt
    (Das schreibt eine Liste von Dateien aus /usr/bin nach $HOME/not_owned_bins.txt die zu keinem installierten Paket (aus der "kaputten" DB) gehören)

    sudo pacman -Sy
    cut -d ' ' -f 5 <  $HOME/not_owned_bins.txt | LANG=C pacman -F - | cut -d ' ' -f 5 | sort -u > $HOME/missing_packages.txt

    (Das erneuert die Sync-Datenbank und prüft dann für jedes im ersten Befehl gefundene Datei zu welchem Paket dieses gehören würde. Dieses Paket fehlt dann. Diese Liste wird nach $HOME/missing_packages.txt geschrieben).

    In der Liste wird nicht unterschieden zwischen explizit installierten (also von dir angefordert z.B. Firefox) und Abhängigkeiten. Die meisten wirst du wohl anhand des Paketnamens identifizieren können ob explizit oder als Abhängigkeit (letztere braucht du dann eigentlich nicht extra zu installieren). Oder du suchst das erste Auftreten im pacman.log, da solltest du sehen ob du das betreffende Paket explizit (also mittel -S <paketname>) installiert hast oder ob es als Abhängigkeit nachgezogen wurde. Z.B. mittels:
    grep -m 1 '\<paketname\>' /var/log/pacman.log
    (Also z.B. grep -m 1 '\<firefox\>' /var/log/pacman.log zeigt dir sicher daß du firefox mittels -S installiert hast; -m begrenzt die Trefferausgabe auf das erste Auftreten. Während z.B. das Paket nss (eine Abhängigkeit u.a. von firefox) lediglich als installed gefunden wird, ohne explizit mittels -S)

    System mit AMD GPU

    Im Terminal mit der AMD Karte:
    Prüfe deine /etc/mkinitcpio.conf auf etwaige nvidia-Einträge, z.B. bei MODULES=
    Entferne diese und trage ggf. das amdgpu Modul ein für EarlyKMS (siehe z.B.
    https://wiki.archlinux.org/title/Kernel_mode_setting#Early_KMS_start)
    Erstelle (als root) das initramfs neu.
    https://wiki.archlinux.org/title/Regenerate_the_initramfs

    Prüfe deine Kernel-Kommandozeile auf etwaige nvidia-Anweisungen:
    cat /proc/cmdline
    Wenn nötig editiere diese bei deiner Bootloader Konfiguration, für Grub z.B. in /etc/default/grub und erstelle dir eine neue Boot-Configdatei
    https://wiki.archlinux.org/title/GRUB#Generated_grub.cfg

    Stelle sicher, daß:
    ls /etc/X11/xorg.conf.d/
    keine Datei xx-nvidia.conf (xx ist eine Zahl, 20 wahrscheinlich) mehr enthält.

      Schon mal Danke für die ausführliche Antwort.

      GerBra Wird durch dein BTRFS-Snapshooting auch die lokale pacman-Datenbank (Standard: /var/lib/pacman/local) gesichert bzw. wieder hergestellt?

      Zu meinem entsetzen wird das Verzeichnis /var nicht mit gesichert durch Timeshift und kann so mit auch nicht wieder hergestellt werden. Das Verzeichnis /var ist komplett leer in den Snapshots.

      GerBra a) Sichere dir die aktuelle /var/log/pacman.log (Änderungen deines obigen ersten Versuchs sind darin geloggt, brauchst du später)

      Die pacman.log habe ich in mein Homeverzeichnis kopiert.

      GerBra b) Könntest du z.B. per Snaphot auf den Zustand nach deinem ersten obigen Versuch zurückgehen?

      Ja, Timeshift hat einen entsprechenden Snapshot angelegt.

      Die pacman.log geht nur über den Link, ist sonst zu groß.

      Ich halt erst mal die Füsse still.

      GerBra Du solltest vor dem Wechseln dringend nochmal deine /etc/mkinitcpio.conf überprüfen, ob dort noch nvidia-Module zum Laden eingetragen sind.

      Es sind keine nvidia-Module eingtragen.

      GerBra Ich würde bei deinem Punkt 2) ansetzen.

      Werde Morgen auf den letzten Stand zurück rollen und die AMD Grafikkarte wieder einbauen.

      Ich schaue dann mal ob ich mich als Root oder normaler Benutzer einloggen kann.

      Also ich müsste meinen Display- und Login-Manager (sddm) über einen Grafikkartentausch informieren, denn sonst wüsste der nicht, wie er sich verhalten sollte. Ist das bei Euch anders?

      LG

      Erst einmal, Ich kann mich als normalerBenutzer einloggen.

      Im Systemlog vom Boot finde ich keine Einträge von nvidia, dafür aber von amdgpu.
      Im Xrog.0.log sind die Einträge von nvidia noch vorhanden, dafür keine von amdgpu. Das muss jetzt wohl erst einmal korrigiert werden.

      Also, erstmal die gute Nachricht...
      Das System bootet ordnungsgemaß mit der amdgpu bis hin zum Target "Graphical Interface". Das sieht alles gut aus.

      Warum nun kein XOrg.log? Warum nun kein sddm? Warum kein Plasma?
      Warum? Warum?

      Schlicht - die schlechte Nachricht - ...
      Du hast alles deinstalliert.
      Hast du dir die pacman.log mal angeschaut? Durch das vermaledeite -c/--cascade wurde xorg-server, sddm, das gesamte KDE/Plasma entfernt.

      Der xorg-server ist mittlerweile zwar wieder installiert ([2023-11-02T23:22:22+0100]), aber da ist halt einfach nicht weiter was ein normales grafisches Anmelden und Desktop sein könnte.

      Wieder ne gute Nachricht:
      Ein wieder "laufendes" System kriegst du recht einfach.

      • Installiere Plasma + SDDM neu gemäß Wikis (du hattest plasma-meta installiert)
      • Installiere Firefox + Language
      • Installiere Steam (wieder wenn nötig)
        An weiteren ANwendungen, die du selbst explizit installiert haben könntest würde ich in dem pacman-Log Auszug ggf. identifizieren:
      • darktable
      • vlc
      • kodi-dev
        Sound (pulseaudio, etc.) dürfte wohl von irgendwas oben als Abhängigkeit nachgezogen werden.
        Gehe am besten später das Log selbst nochmal durch ob du noch ein Paket/Anwendung entdeckst, die du explizit installiert hast.

      Danach (nicht vergessen den sddm.service wieder zu enablen mit systemctl!) sollte auch eine Anmeldung per DisplayManager wieder möglich sein und Plasma starten.

      Hand aufs Herz: Ist dir bei den nvidia-Remove Aktionen nicht irgendwie schlecht geworden was da alles entfernt werden sollte? Ich meine, pacman fragt ja dann extra nochmal: Proceed with transaction (oder so...) ????

      Auf jedenfall haben wir einen guten Beispiel-Thread, warum man -c/--cascade nicht gedankenlos verwenden sollte (BOOKMARKED!) ;-)

      Ich habe beim deinstallieren dummerweise nicht genau hin geschaut was alles gelöscht werden soll. `pacman -Rscn ' habe ich bisher häufig benutzt, zukünftig wohl nicht mehr. Hinzu kommt noch meine falsche btrfs Konfiguration mit den Subvolume. Damit ist kein Rollback möglich. Von Subvolume wie @var werden keine snapshots gemacht und das dort doch wichtige Daten liegen habe ich schmerzlich gelernt.
      So, habe jetzt fast alle Programme nach installiert. Stream weigert sich noch. Zum Schluss habe ich auch systemctl enable sddm.service durchgeführt. Der Service ist auch korrekt eingetragen worden. Der Pc hängt sich aber beim Starten jetzt auf. In der fstab habe ich eine Cloud über webdave eingehangen und dabei hängt der Start.

      • GerBra hat auf diesen Beitrag geantwortet.

        Fansurfer So, habe jetzt fast alle Programme nach installiert.

        Stelle am besten nochmal ein aktuelles Journal-Log auf einen Pastebin-Service
        (journalctl -b --system --no-pager)

        Fansurfer Stream weigert sich noch.

        Vielleicht am besten einen eigenen Thread aufmachen, bitte mit den Befehlen/Anwendung die du starten willst bei steam und Fehlermeldungen. Du kannst eigentlich jedes Spiel und die Runtime selbst aus einem Terminal raus starten.

        Fansurfer um Schluss habe ich auch systemctl enable sddm.service durchgeführt. Der Service ist auch korrekt eingetragen worden. Der Pc hängt sich aber beim Starten jetzt auf. In der fstab habe ich eine Cloud über webdave eingehangen und dabei hängt der Start.

        Das ist mir jetzt unklar. Hängt sich der PC auf nach dem Enablen von sddm oder weil der webdsv-Mount eingetragen ist. Oder anderst: Startet sddm und drüber dein Plasma wenn du den webdav-mount in der fstab nicht aktiv hast?
        Nach dem "Aufhängen" (und Reboot): Poste auch bitte ein Journal vom "aufgehängten" Bootversuch, also:
        journalctl -b -1 --system --no-pager

        Meine Gedanken zu Timeshift oder einer anderen Lösung:
        Kann man Timeshift nicht sagen, daß du einer "Sicherung" neben @ auch andere Subvolumes gehören? Ich kenne weder Timeshift noch Snapper praktisch, bei Timeshift auf der Projektseite ist zumindest erwähnt daß eigene Verzeichnisse zur Sicherung hinzugefügt werden können. Evtl. geht sowas ja auch für andere BTRFS-Subvolumes, was in dem Fall wohl @var wäre.

        Bei meinen BTRFS-Systemen ist /var kein eigenes Subvolume, wird also durch den Snapshot von / eingeschlossen. In /var habe ich allerdings dann weitere Subvolumes (nested oder explizit) um eben z.B. nicht /var/cache, /var/run, etc. im "System"-Snaphot drinzuhaben. Für mich ist sowas auch die einzig sinnvolle Definition für BTRFS-Subvolumes: über die Ebenen bestimmte Bereiche von bestimmten Snapshots auszuschließen.
        Bei System-Snapshots (ich nenne es gerne auch Abbild, "Image" des Systems an einem bestimmten Zeitpunkt) lege ich halt persönlich wert drauf, das ein Image vom z.B. 6.11. um 14:50 beim Wiederherstellen mir genau das System auf diesen Stand zurückbringt. Speziell bei Archlinux bedeutet daß für mich:

        • Kernel (/boot, Bootloader)
        • Root-Dateisystem (/)
        • die pacman sync + lokale DB vom Zeitpunkt der Sicherung, ich will z.B. ein fehlgeschlagenes pacman -Syu genau ggf. nochmal reproduzieren können. Was eben nur geht, wenn die Datenbanken synchron zur Sicherung sind.
        • Logfiles lege ich auch großen Wert darauf, ich möchte nach dem Wiederherstellen meine Logs auch wieder auf dem Stand von 6.11. 14:50 haben.

        D.h. meine Logs, mein System soll nach einer Wiederherstellung sauber sein von jeglichen "Aktionen" die ich später ggf. ausgeführt habe, die aber ja augenscheinlich die Ursache waren warum ich den Snapshot überhaupt wiederherstelle. Logs/Fehler etc. aus dem Lauf nach dem Snapshot hätte ich mir schon seperat gesichert.

        Wenn die gewählte Snaphot-Lösung (weil sie "einfach" sein will) keine diffizile Konfiguration zuläßt, gibt es ggf. auch eine andere Möglichkeit sowas zu "überlisten".
        Für den Paketmanager (pacman) wäre es z.B. möglich, daß Datenbank-Verzeichnis anders als (default) /var/lib/pacman zu legen. Nämlich z.B. in deinem Fall in ein eigenes Unterverzeichnis deines Root(@)-Subvolumes. Dann wären sowohl sync als auch die DB der lokal installierten Pakete ja in der Timeshift-Sicherung drin. (Option DBPath in /etc/pacman.conf). Ebenso daß Logfile könntest du von /var/log an einen anderen Ort legen (Option LogFile).
        Z.B. ein Verzeichnis
        /arch (wäre im @-Volume)
        DBPath z.B. /arch/lib/pacman
        LogFile z.B. /arch/log/pacman.log
        Das hätte dich zumindest im aktuellen Fall vor dem Dilemma Restore-Snapshot vs. nicht passendem Versions-/Installations-Umfang von Paketen bewahrt.

        Mein PC läuft jetzt wieder, mit einer neuen Installation. Die ich über kurz oder lang sowieso durch geführt hätte, aufgrund des Durcheinanders mit der Paketdatenbank und der nicht sauberen Wiederherstellungsmöglichkeit.

        Es gibt jetzt kein extra Subvolume für /var sonder nur noch für /var/cache, /var/spool und /var/tmp. Damit sollte sich der PC auch wieder herstellen lassen. Ob ich dafür Snapper oder Timeshift verwende ist noch nicht sicher.

        @ GerBa
        Für deine ausführlich Unterstützung möchte ich mich noch mal bedanken.