DKMS Paket lässt sich nicht entrfernen mit zypper...?

Deutsch (German) Installation/Administration
#1

Merkwürdigerweise ist bei mir das Paket “amdgpu-dkms” in zwei Versionen installiert. Leider lässt sich keins der beiden Pakete deinstallieren.

zyyper remove amdgpu-dkms

ergibt folgenden Fehler:

Entfernen von (100)amdgpu-dkms-1:5.18.13.50400-1510348.noarch(@System) fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.

Wie kann ich die fehlerhaften Module wieder entfernen?

Weder in /usr/src/amdgpu noch in /var/lib/dkms finde ich Dateien.

Etwas ratlos, was kann ich tun?

Grüße,
jhhh

#2

Um zu zeigen was du hast:

zypper se -si amdgpu-dkms

Und bitte das Ganze (Kommando und Resultat) nicht unterbrechen mit Geschichtenerzälerei wie “ergibt folgende Fehler”. Wenn du das integral zeigst (auch die prompts!), können wir das schon interpretieren. Und vielleicht noch mehr wenn nichts ausgelassen wird.
Beispiel:

henk@boven:~> uname -r
5.14.21-150400.24.60-default
henk@boven:~>
#3

Da du dieses Paket aus unbekannten externen Quellen installiert hast ohne mitzuteilen wie/was/warum du getan hast, ist daran gar nichts merkwürdig.

Da es das Paket amdgpu-dkms in keinem openSUSE Repo gibt, wäre es auch äußerst hilfreich zu wissen was du getan hast:

  • von wo hast du dir das Paket besorgt?
  • wie hast du das Paket mit welchen Befehlen nach welcher Anleitung installiert?
  • Welches Betriebssystem verwendest du (solche Basisangaben sollten wir eigentlich gar nicht bei dir erfragen müssen…)
  • …
#4

Nicht entfernen lassen sich die beiden

amdgpu-dkms v5.18.13
amdgpu-dkms v6.0.5

TW:~> sudo zypper se -si amdgpu-dkms

Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                 | Type  | Version                 | Arch   | Repository
---+----------------------+-------+-------------------------+--------+---------------
i+ | amdgpu-dkms          | Paket | 1:5.18.13.50400-1510348 | noarch | (Systempakete)
i+ | amdgpu-dkms          | Paket | 1:6.0.5.50500-1581431   | noarch | AMD GPU
i+ | amdgpu-dkms-firmware | Paket | 1:6.0.5.50500-1581431   | noarch | AMD GPU
i+ | amdgpu-dkms-headers  | Paket | 1:6.0.5.50500-1581431   | noarch | AMD GPU

Eingerichtet habe ich die AMDGPU repositories und dann amdgpu installert.

#6

Leider hast du die Fragen nicht beantwortet. Wir wissen immer noch nicht welches Repo du eingebunden hast. Es gibt kein offizielles openSUSE amdgpu Repo.
Zeige wenigstens deine Repolist inklusive der URL damit wir erahnen können was du auf deinem System getrieben hast:

sudo zypper lr -d
#7

Hier ist das offizielle AMD Repo für SUSE, enthält “amdgpu”:

https://repo.radeon.com/amdgpu/latest/sle/15.4/main/x86_64

Ausserdem noch für ROCM:

https://repo.radeon.com/rocm/zyp/zypper/

Ausserdem verwende ich die Tumbleweed repositories und Packman.

Danke.

#8

Ich weiß nicht wie lange du schon hier beim Forum bist, aber so funktioniert das nicht. Wenn man nach

zypper lr -d

gefragt wird zeigt man das entweder wie du das oben auf

zypper se -si amdgpu-dkms

schon mal gemacht hast, oder du sagst das du das, warum denn auch, nich beantworten möchtest. Wie du das jetz machst, da gehen die Leute irgendwoanders hin.

#9

Du könntest versuchen zunächst mit

rpm --rebuilddb

die Paketdatenbank neu aufzubauen und anschließend

zyyper remove amdgpu-dkms

nochmals durchführen.

Das sind keine von openSUSE bereitgestellten (und gewarteten) Repositories.

Und falls Dir beim Einbinden dieser Repositories ein Tippfehler unterlaufen ist, kann man das anhand der von Dir gezeigten URLs nicht erkennen. Es ist also in Deinem Interesse das Ergebnis von

zypper lr -uEP

hier zu zeigen.

#10

Ok, wenn ihr das hier so macht, gern.

Es wäre aber auch schön, wenn die angeforderten Schritte kurz erläutert würden… - ich nutze ausschließlich Linux und Linux-Foren seit über 10 Jahren und meine Erfahrung ist, dass oft nach völlig irrelevanten Logs und System-Daten gefragt wird, bloß um danach dann doch dieselbe generische Antwort zu erhalten - meist der Verweis auf ein Readme, einen ähnlichen Foren-thread oder einen Bug-Tracker.

Schön, wenn das hier anders ist - hier (und bei openSUSE) bin ich erst seit ca. 2 Monaten. Also so gesehen neu hier.

Probleme mit “sticky” dkms Paketen lassen sich in anderen Distributionen normalerweise dadurch beheben, dass man die Modul-Quellen unter diesen drei Paden löscht und evtl. die Datenbank des Paketmanagers repariert:

/usr/src/[Modulname]
/var/lib/dkms/[Modulname]
/libe/modules/[Kernel-Version]/updates/[Modulname]

Den dritten Pfad finde ich in openSUSE nicht, wie ein Paket aus der Zypper-Liste entfernt manuell werden kann, sehe ich auch nicht.

Tumbleweed:~> zypper lr -d
#  | Alias                                | Name                              | Enabled   | GPG Check       | Refresh        | Priority  | Type   | URI                                                                                                   | Serv->
---+--------------------------------------+-----------------------------------+-----------+-----------------+----------------+-----------+--------+-------------------------------------------------------------------------------------------------------+-------
 1 | AMD_GPU                              | AMD GPU                           | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://repo.radeon.com/amdgpu/latest/sle/15.4/main/x86_64                                            | 
 2 | Google-Chrome                        | Google-Chrome                     | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://dl.google.com/linux/chrome/rpm/stable/x86_64                                                  | 
 3 | ROCm                                 | AMD ROCm                          | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://repo.radeon.com/rocm/zyp/zypper/                                                               
4 | brave-browser                        | Brave Browser                     | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://brave-browser-rpm-release.s3.brave.com/x86_64/                                                | 
5 | devel_tools_compiler                 | devel:tools:compiler              | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://download.opensuse.org/repositories/devel:/tools:/compiler/openSUSE_Factory/                   | 
6 | download.opensuse.org-oss            | Haupt-Repository (Quellen)        | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/source/tumbleweed/repo/oss/                                              | 
7 | download.opensuse.org-oss_1          | Haupt-Repository (OSS)            | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/                                                     | 
8 | download.opensuse.org-tumbleweed     | Hauptaktualisierungs-Repository   | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | http://download.opensuse.org/update/tumbleweed/                                                       | 
9 | ftp.gwdg.de-Essentials               | Packman Essentials Repository     | Ja        | (r ) Ja         | Ja             |   95      | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials                         | 
10 | ftp.gwdg.de-openSUSE_Tumbleweed      | Packman Repository                | Ja        | (r ) Ja         | Ja             |   97      | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/                                   | 
11 | games_tools                          | games:tools                       | Ja        | (r ) Ja         | Ja             |   88      | rpm-md | https://download.opensuse.org/repositories/games:/tools/openSUSE_Tumbleweed/                          | 
12 | microsoft-edge                       | Microsoft Edge                    | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://packages.microsoft.com/yumrepos/edge/                                                          
13 | snappy                               | snappy                            | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://download.opensuse.org/repositories/system:/snappy/openSUSE_Tumbleweed                         | 
14 | system_packagemanager                | system:packagemanager             | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://download.opensuse.org/repositories/system:/packagemanager/openSUSE_Tumbleweed/                | 
15 | vscodium                             | Visual Studio Codium              | Ja        | (r ) Ja         | Ja             |   99      | rpm-md | https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/rpms

Die meisten Repositorien, die nur ein, zwei Pakete für individuelle Dritt-Software zur Verfügung stellen (wie etwa das Teamviewer-Repo) habe ich der Übersichtlichkeit halber entfernt.

#11

Das ist gefährlich. Das benutzen von Linux kann man auf ganz verschieden Art und Weise machen. Ein wichtiger Bestandteil von Helfen ist das die Helfer versuchen so schnell möglich eine Idee zu bekommen wie das System mit dem Problem funkioniert und eingerichtet ist. Dabei helft herauslassen nach Sicht derjenige der das Peoblem hat nicht. Auch ist es bei viel Probleme so das diejenige die das Problem hat, schon Vieles ausprobiert hat und dabei oft sichselbst in eine bestimte Richtung gezwungen hat. Das Vorlegen des Problems an Andern hat als großes Vorteil das Andern frisch hereinschauen. Möglichts nich beinflußust von das was der Problemeigner alles schon gedacht hat.

Tatsächlich könnte man sagen: Hier glaubt keiner was du sagst, die glauben nur was das System sagt (und was du hier ungeändert zeigst).

#12

Ok. Das habe ich verstanden… diese Gefahr werde ich dann im Einzelfall abwägen… hierfür meine gesamte Softwarekonfiguration inklusive der Software zu posten, mit der ich Kundensysteme warte, tue ich nur ungern.

Aber sei’s drum - ich hoffe aber, Du hast ja jetzt einen besseren Überblick!

Was kann ich denn nun wegen der DKMS-Pakete machen?

#13

Deine Repository-Liste zeigt eine wilde Mischung aus

  • openSUSE Tumbleweed
  • openSUSE Factory
  • Dritt-Software (z.B. Google, Microsoft, …)

Das wird so nicht getestet (openQA) und daher kann auch niemand sagen, ob das so überhaupt funktioniert (Factory-Pakete können sich jederzeit ändern und nicht lauffähige Versionen werden von keinen automatisierten Tests erfasst oder gar zurückgehalten). Um eine solche Mischung ohne Probleme in Betrieb zu halten muss man schon sehr genau verstehen, welche Konsequenzen sich aus der Nutzung dieser Repositories ergeben können.

Aber Du bist noch nicht einmal bereit Fragen zu Deinem System vollständig zu beantworten und Informationen zu Deinem System unzensiert bereitzustellen.

Es tut mir leid aber unter diesen Voraussetzungen ist es mir zu riskant Dir weiter zu helfen.

#14

Ok, danke - Du must mir ja nicht helfen, wenn Du nicht willst.

Das hättest Du aber sicher auch nicht getan, wenn ich Dir die volle Repo-Liste mit etwa 10 weiteren Mini-Repos gepostet hätte, oder?

Die Verantwortung dafür, was kaputt gehen kann, liegt ja sowieso bei mir.
Müsste Dir demnach nicht “zu gefährlich” sein… - ich mache nicht gleich alles sofort nach, was ich in einem Forum empfohlen bekomme.

Mein Problem liegt nicht an den unterschiedlichen Repositories.

Ich habe penibel darauf geachtet, dass alles, was von den drei Standard Repos bereitgestellt wird, auch von dort verwendet wird. Der Rest ergänzt nur Pakete (z.B python36), die ich benötige.

Sich ändernde Factory Pakete teste ich grundsätzlich, indem ich vor der Aktualisierung eine Snapshot erstelle. Das funktioniert bisher gut.

Das System funktioniert so insgesamt hervorragend - das Repo-System inkl. der Möglichkeit Anbieter zu wechseln ist ja dazu auch gedacht und ich finde es sehr gut ausgefeilt. Einer meiner Gründe zu SUSE zu wechseln.

Meine Frage bleibt:

Wo im System findet DKMS die Vorgabe welche Module zu bauen sind?

Wie gesagt, in den Systemen, die ich kenne, liegen die Kernelsources inklusive der Module Sources in diesen drei Verzeichenissen:

/usr/src/[Modulname]
/var/lib/dkms/[Modulname]
/libe/modules/[Kernel-Version]/updates/[Modulname]

Wo liegen Sie in SUSE (der dritte Pfad existiert so nicht!

Da die Module für AMDGPU ohne Probleme funktionieren, habe ich sicher kein Problem inkompatibler Software. Ich arbeite gerade jetzt auf dem System. Ic kann auch weiterhin einzelne Pakete aktualisieren.

Nur der Versuch den Kernel zu aktualisieren scheitert daran, dass zwei unterschiedliche Modulversionen für AMDGPU zum Bauen gesucht werden…

Eine zweite Frage ist die, wie sich ein einzelner Eintrag aus der zapper Datenbank installierter Pakete manuell löschen lässt?

Meine Fragen haben m.E.n. nichts mit der Liste der Repositories zu tun.
Sondern mit mangelndem Verständnis darüber, wie Zypper genau mit RPM zusammenspielt und wie ich Zypper beibringen kann, dass ein Paket, dass ich vorher manuell entferne (zur Not jede Datei einzeln), aus der LIste installierter Pakete gelöscht werden muss.

Wenn mir hierbei jemand weiterhelfen kann, würde ich mich freuen.

Beste Grüße,
jhhh

#15

Da du absichtlich Daten verschweigst, wird dir hier keiner helfen können.

Dann wirst du dir auch selbst zu helfen wissen, wenn du die Ratschläge und Aufforderungen anderer Nutzer bewusst ignorierst.

Na dann…

Ein Snapshot ist kein Test. Da liegt ein grundlegendes Verständnisproblem vor…

Du hast dir die Datenbank selbst zerschossen. Wie du das geschafft hast weißt nur du.
Du hast es geschafft amdgpu-dkms-firmware-1:5.18.13.50400-1510348 und amdgpu-dkms-headers-1:5.18.13.50400-1510348 zu deinstallieren ohne das Hauptpaket amdgpu-dkms-1:5.18.13.50400-1510348 zu entfernen. Außerdem hast du die komplette 1:6.0.5.50500-1581431 Serie instralliert. damit hast du dir ein Abhängigkeitsproblem geschaffen, dass du lösen könntest indem du dir die beiden fehlenden firmware und header Pakete der 1:5.18.13.50400-1510348 Serie neu installierst und danach amdgpu-dkms-1:5.18.13.50400-1510348 forciert neu installierst. Den Pfad unter dem du die alte Serie auf dem AMD Mirror findest sollte für dich einfach zu finden sein.

Dateien händisch entfernen und sich danach wundern das die Paketdatenbank kaputt ist und sich einzelne Pakete nicht entfernen lassen? Wirklich?
Wie man die Datenbank neu baut wurde dir ja schon in diesem Thread mitgeteilt…

#16

Mein Problem liegt nicht an den unterschiedlichen Repositories.
Sehe ich anders…

Denn zum Bsp. das AMD Repo ist gegen Leap 15.4 (SLE) gebaut, die Patches sind für Leap 15.4 eingestellt usw.

Aber der Rest ist aus Tumbleweed.

Wobei sich mir die Frage stellt warum man das AMD Repo bei Tumbleweed denn unbedingt braucht.

#17

Danke für den Hinweis.

Sebstverständlich richte ich mir keine zusätzlichen Repos ein, bevor davon ich überzeugt bin, dass ich sie wirklich brauche.

Und um die Diskussion, wie jemand Anderes darüber denkt, was ich brauchen sollte, zu vermeiden.

In diesem Fall handelt es sich tatsächlich um die Leap Respositories, die sich aber, mangels Alternativen eben auch für TW eignen.

Wobei sich mir die Frage stellt warum man das AMD Repo bei Tumbleweed denn unbedingt braucht.

Wenn Du eine Alternative kennst, die AMD Treiber inklusive funktionierender ROCM (openCL) Unterstützung sauberer zu installieren, lass es mich gerne wissen - natürlich wäre mir das auch lieber.

(Um auch der Frage wiederum vorzubeugen:
Ja, ROCM inklusive unterschiedlicher Perl und Python Versionen brauche ich für KI-Generatoren, die ich auf meinem Rechner teste…)

Gruß,
jhhh

#18

Du hast es geschafft amdgpu-dkms-firmware-1:5.18.13.50400-1510348 und amdgpu-dkms-headers-1:5.18.13.50400-1510348 zu deinstallieren ohne das Hauptpaket amdgpu-dkms-1:5.18.13.50400-1510348 zu entfernen. Außerdem hast du die komplette 1:6.0.5.50500-1581431 Serie instralliert. damit hast du dir ein Abhängigkeitsproblem geschaffen, dass du lösen könntest indem du dir die beiden fehlenden firmware und header Pakete der 1:5.18.13.50400-1510348 Serie neu installierst und danach amdgpu-dkms-1:5.18.13.50400-1510348 forciert neu installierst. Den Pfad unter dem du die alte Serie auf dem AMD Mirror findest sollte für dich einfach zu finden sein.

Danke für den Hinweis - das war sehr hilfreich.

Tatsächlich werden die DKMS-Sources unter

/usr/src/admgpu-[Modulversion]

bei der Installation durch dkms mittles Symlink verlinkt nach

/var/lib/dkms/amdgpu/[Modulversion]/~source

Bei der Deinstallation erhalte ich einen Fehler, weil diese Modul-Sources nicht gefunden und somit nicht entfernt werden können.

Die Lösung war amdgpu-dkms-firmware, amdgpu-dkms-headers derseben Version zu installieren und dann mit

dkms add -m amdgpu -v [Modulversion] die dkms Struktur zu erzeugen.

Danach lässt mit mit Zypper diese Version gezielt entfernen.

Glücklicherweise musste ich gar nicht in alten Versionen auf den AMD-Servern rumwühlen. Ich habe das, wie gerade beschrieben, mit der aktuellsten Version gemacht.

Danach habe ich dasselbe nochmal gemacht, nur die aktuellen DKMS-Quellen im Filesystem umbenannt, sodass sie aussehen, wie die älteren Pakete. Dann wieder dkms add ...und remove mittles Zypper.

Danach konnte ich die AMDGPU Treiber vollständig de- und in der aktuellen Version wieder installieren. Zum Testen der einzelnen Schritte habe ich eine Reihe von Snapshots angelegt, sodass ein Rollback nach jedem Schritt möglich gewesen wäre.

War aber nicht nötig: Der neueste default Kernel 6.3.1, wie auch der ältere Fallback Kernel bauen die Module wieder anstandslos und die oben beschriebenen Dateien des DKMS-Trees liegen in einer (!), der aktuellen Version vor.

Die Pfade, nach denen ich hier gefragt habe, habe ich in der Datei
/etc/dkms/framework.conf gefunden.

Danke an alle, die mich in die richtige Richtung gewiesen haben.

Solved!
jhhh