Ubuntu 20.04 und RX 6800 / 6900

SFFox schrieb:
@Logoo :
Die Grafikkarte ist, wie im ersten Post beschrieben, aufgerüstet. Da funktionierte also alles vorher mit einer AMD Vega 64, so dass sich die Installationsfrage gar nicht stellt. Für den AMD GPU Driver, der im Kernel von Linux steckt und nahezu alle AMD Karten unterstützt, liegt aber für jede dieser Karten ebenfalls die passende Firmware im Ordner, den Aki hier genannt hat, weil der Kerneltreiber zu jeder Karte eine Firmware braucht.
Da brauchst du also nicht zu spekulieren, denn der Fall ist ja eindeutig :)

Jetzt mal ganz langsam .. wenn ich das jetzt Richtig verstanden habe ,
du hattest dein Ubuntu installiert als noch die Alte Grafikkarte drin war Richtig ?
dann hast du eine Neue Grafikkarte verbaut und seit dem kommt kein Bild mehr richtig ?
ich vermute hier wie schon gesagt, das mit falschen Treiber zusammen hängen kann ,
auf die Frage ob nach dem Booten wenigstens noch das Shell Terminal kommt geht du leider nicht ein ? Darüber könnte man wohl möglich den falschen Treiber deinstallieren was kompliziert ist ,
so das nach dem Booten die HW der Karte Neu Erkannt wird ?
ich vermute deine Ubuntu Version die Neue HW nicht findet und stur den Alten falschen Treiber
immer noch hoch lädt daher kein Bild kommt .

Wie ich schon sagte, wenn mit der Live DVD ein Bild kommt dann liegt das wohl möglich
an deiner installierten Linux Version auf PC das da was hackt ,
ich würde Neu installieren versuchen ?
 
Zuletzt bearbeitet:
Logoo schrieb:
Regelt z.b. nicht runter und läuft auf voller Pulle, das hatte ich bei einem PC schon mal,
wo eine NV Karte verbaut ist ,
da musste ich die NV Treiber Extra installieren damit das ging .
Bei meinen Linux PC hier mit Alter HD ATI habe ich dieses Problem nicht .
Wer hätte das gedacht, damit Hardware funktioniert braucht man Treiber :D

Bei Nvidia Grafikkarten ist die Situation so: Du brauchst den Proprietären Treiber von Nvidia damit die mehr machen können als nur stumpf nen Bild auf den Bildschirm zu bringen, Nvidia verschlüsselt die Firmware und hält sie auch geheim, sowie liefert auch keine Variante an Linux abseits ihres eigenen Treibers.
Nur uralt Grafikkarten haben volle Funktionalität inklusive hoch takten weil "damals" die Firmware noch nicht versperrt wurde war ein entwickeln für die Karten möglich, das ist aber lange her. Also immer der Proprietäre Treiber ist zu nutzen oder man hat sozusagen was schlechteres als ne IGPU, im Grunde dann nur de Framebuffer 2d schubse :D

Bei AMD Grafikkarten ist es so, das AMD den Freien Treiber zu geschätzt 99% selbst entwickelt und als Open Source für den Kernel zur Verfügung stellt. Dabei ist zu bedenken, dass der radv - Vulkan Treiber der normalerweise immer für alles genutzt wird - auch zum zocken NICHT von Amd entwickelt wird :D es ist aber selbst für Spieleentwickler das to go Ziel, inklusive Patches einbringen. Zudem ist radv in der regel doch performanter als der von AMD offen gestellte vulkan treiber :-)

AMD tut viel für Linux so gesehen :-) .

Ebenso tut Intel viel für Linux, das soll nicht unterschlagen werden, all deren Grafikkarten haben offene von Intel entwickelte Treiber für Linux und das schon länger als AMD es so macht :-)


@Logoo es läuft doch schon bei ihm, er hat nur die Firmware die nötig ist und nicht vorhanden war manuell nachgereicht und dann lief es. Der Grund einfach, das die Pakete der Distribution und somit auch die in denen die Firmware mit drin sind noch nicht neu genug waren. Durch das manuelle reinschieben der Firmware in den Passenden Ordner hat der Kernel diese aber nun Finden können und die Karte läuft mit dem ansonsten schon installierten AMDGPU Treiber. Den Treiber müsste man auch höchstens erneuern/updaten. aber das ist schon der richtige auch für die neue Karte, die ja auch eine AMD Grafikkarte ist.
 
Zuletzt bearbeitet:
Alexander2 schrieb:
Wer hätte das gedacht, damit Hardware funktioniert braucht man Treiber :D

Bei Nvidia Grafikkarten ist die Situation so: Du brauchst den Proprietären Treiber von Nvidia damit die mehr machen können als nur stumpf nen Bild auf den Bildschirm zu bringen, Nvidia verschlüsselt die Firmware und hält sie auch geheim, sowie liefert auch keine Variante an Linux abseits ihres eigenen Treibers.

Das alles hat aber nichts mit seinem vermutlichen Play und Plug Problem zu tun , das kann
auch an Ubuntu liegen Play und Plug Bug.
Wenn mit der Live DVD Bootet und Bild kommt normal liegt es an der installation auf seiner HDD im PC .
 
@Logoo Das Problem ist doch schon längst gelöst, der Rechner läuft wieder, dank des Hinweises von Aki. Ich konnte in den Kernel Recovery Mode starten, also keine GUI, nur root Konsole und habe die benötigten Firmware Dateien für den Treiber installiert. Das habe ich für alle, die das Problem auch haben, auch noch mal in kurz im ersten Beitrag zusammen gefasst :)
Danke für deine Mühe :)
 
Zuletzt bearbeitet:
Hallo, leider muss ich den Thread noch mal beleben.
Bis vor kurzem hat das Kernel Update noch wie im Startbeitrage festgehalten, einwandfrei funktioniert.
Jetzt setzen die Mainline-Kernels allerdings "libc6" in einer neueren Version voraus, als Ubuntu 20.04 an Board hat.
Der "Bug" ist bereits gemeldet:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1926938
Als workaround hat der User "TuxInvader" eigene PPAs aufgesetzt, u.a. das hier für den 5.10.x-er Kernel:
https://launchpad.net/~tuxinvader/+archive/ubuntu/lts-mainline-longterm

Die Einbindung des PPAs hat geklappt, die installation von einer aktuellen 5.10.41 Version auch (header, image und modules), allerdings geht beim Booten jetzt wieder die Grafik flöten, als würde er die Firmware nicht finden.

Hat jemand einen guten Lösungsplan? :) Ich lerne ja gerne dazu.
 
Gibts eigentlich einen speziellen Grund an der alten Version 20.04 festzuhalten?
Falls nicht, würde ich erst gar nicht anfangen mit PPAs und ähnlichem herumzufrickeln, sondern gleich ein Update auf die 21.04 machen.
 
Neue Hardware mit alter Distro verträgt sich halt selten gut.
Würde eher in Richtung Arch, Manjaro, Opensuse Tumbleweed, Fedora schauen.
Vielleicht noch Ubuntu 21.04 oder wenn LTS sein soll PopOS 20.04 (hat Kernel 5.11)
Natürlich kann man es mit einem Ubuntu 20.04 auch hinbekommen, aber wie du ja auch selbst merkst ist das meistens der deutlich schwierigere Weg.
Und Kernel PPAs sind sowieso oft eine Katastrophe. Ich hab das damals vielleicht 10x versucht und davon hatte ich 9x Probleme.
 
andy_m4 schrieb:
Gibts eigentlich einen speziellen Grund an der alten Version 20.04 festzuhalten?
Der Grund ist relativ einfach. In das Ubuntu ist sehr viel Konfigurationsaufwand geflossen und hat auch schon den Sprung von 18.04 auf 20.04 hinter sich. Ich nutze Ubuntu rein für's Home Office und mit der Sicherung des Home Verzeichnis ist es sicherlich nicht getan, die Kiste wieder 1zu1 lauffähig zu machen.
Ich mache regelmäßig komplett-Backups der SSD, auf der Ubuntu läuft. Somit könnte ich ein weiteres Upgrade auf 21.04 mal testen. Eine Lösung unter dem sonst immer noch sehr stabil rennenden Ubuntu 20.04 einen aktuellen Kernel lauffähig zu halten wäre mir allerdings lieber :)
wjmw89 schrieb:
Neue Hardware mit alter Distro verträgt sich halt selten gut.
Das ist wahr 🤷‍♂️
wjmw89 schrieb:
Natürlich kann man es mit einem Ubuntu 20.04 auch hinbekommen, aber wie du ja auch selbst merkst ist das meistens der deutlich schwierigere Weg.
Naja so schwer war es ja nicht so lange die Mainline Kernel gut liefen und die sind schon eine ziemlich gute Quelle.
wjmw89 schrieb:
Und Kernel PPAs sind sowieso oft eine Katastrophe. Ich hab das damals vielleicht 10x versucht und davon hatte ich 9x Probleme.
Im Zusammenhang mit speziellen Anforderungen sind sie das immer (da können manche Docking Station Besitzer ein Leid von singen). Ein anderes OS installieren ist "leicht", das kriege ich als alternative Lösung auch selbst hin. Ich würde aber gerne verstehen, was hier schief läuft und das beheben.
 
Was sonst vielleicht funktionieren würde mal abgesehen von einem Upgrade zu 21.04, wäre ein "Upgrade" von Ubuntu 20.04 auf PopOS 20.04.
Immerhin haben die Standardmäßig aktuell Kernel 5.11 und generell was ich bemerkt habe besseren Treibersupport.
Jedoch ist das halt auch nicht ungefährlich. Und kann dein System zerschießen.
 
SFFox schrieb:
Hat jemand einen guten Lösungsplan?
Eventuell linux-oem

SFFox schrieb:
allerdings geht beim Booten jetzt wieder die Grafik flöten, als würde er die Firmware nicht finden.
Die Pakete in den Distributionen passen meist zueinander - für Mainline oder andere Kernels muss eventuell dann auch mainline oder sogar "Entwickler" Firmware genommen werden.
Manchmal wird die Firmware auch umbenannt oder die neue Version ist noch nicht hochgeladen oder überhaupt nicht verfügbar wegen Lizenzproblemen.

Das normale Linux-Firmware Repo kann einfach per git heruntergeladen und bei Bedarf das /lib/firmware lokal überschrieben werden

Kernel-Log nach Hinweisen durchsuchen ...

Eventuell ist es auch eine Regression - ein alter Bug ist wieder da (weil der Fix vlt. in Ubuntu-Patches ist und noch nicht zum Kernel weitergereicht wurde) .... oder der Entwickler sagt dann: "kompilier mal den aktuellen Entwicklerzweig und schau ob der Fehler noch da ist" :)
 
SFFox schrieb:
Der Grund ist relativ einfach. In das Ubuntu ist sehr viel Konfigurationsaufwand geflossen
Naja. Home sichern. /etc sichern.
Irgendwann muss man ja doch auf ne neue Version. Umso früher umso besser. Vor allem: Umso kleinteiliger die Schritte sind, umso weniger Probleme hat man. Wenn Du dann irgendwann mal in ein zwei Jahren updatetest, dann ist das gleich ein großer Schritt von potentiell noch mehr Probleme und Aufwand als jetzt.

Wie schon gesagt. Wenn die Hardware nicht von der Version unterstützt wird, ists immer ungünstig. Das ist dann gern mal eine Dauerbaustelle. Dann lieber jetzt migrieren als noch Monate oder Jahre mit dieser offenen Wunde herumlaufen. Vor allem, Deine Frickeleien jetzt machen ja künftige Upgrades nicht gerade einfacher/problemloser.


SFFox schrieb:
Ich mache regelmäßig komplett-Backups der SSD, auf der Ubuntu läuft. Somit könnte ich ein weiteres Upgrade auf 21.04 mal testen.
Genau.
Du kannst dadurch upgraden und wenn das smooth geht ohne das die Konfigurationen zerschossen werden, dann hast Du gleich ein aktuelles System. Wenns nicht klappt kannst Du Dir immer noch überlegen zur alten Version zurückzugehen.

SFFox schrieb:
Ich würde aber gerne verstehen, was hier schief läuft und das beheben.
Du könntest den Kernel selbst gegen Deine jetzige libc kompilieren. Das dürfte mit hoher Wahrscheinlichkeit das Problem fixen. Allerdings musst Du dann auch die Updates dann jedes Mal von Hand nachziehen. Da fänd' ich ein Upgrade auf 21.04 insgesamt und auf in Hinblick auf die Zukunft pflegeleichter
 
Am Ende war der Workaround einfacher als gedacht: Kernel 5.12.8 lässt sich wieder "normal" über das Mainline Updatescript installieren. Der läuft soweit auch stabil und wird aktuell gepflegt :)
 
SFFox schrieb:
Kernel 5.12.8 lässt sich wieder "normal" über das Mainline Updatescript installieren.
Was heißt denn wieder?
Hat das mit dem Bug zu tun den Du angesprochen hast und der jetzt gefixt ist? Oder hast Du zunächst das Update auf eine andere Art und Weise als über das (übliche) Skript gemacht?
 
andy_m4 schrieb:
Was heißt denn wieder?
Hat das mit dem Bug zu tun den Du angesprochen hast und der jetzt gefixt ist? Oder hast Du zunächst das Update auf eine andere Art und Weise als über das (übliche) Skript gemacht?
Ab einer 5.12er Subversion ist die Abhängigkeit von "libc6" nicht mehr an eine neuere Version gebunden, die unter Ubuntu 20.04 noch nicht verwendet wird. Ich nehme mal an hier kann man von Regression sprechen.
Das Update lief ganz normal über das vorher auch genutzt mainline-update-script. 👍
Vllt. wird das noch auf 5.11.x einen Backport erhalten, ist ja immerhin ein LTS Kernel.
 
Zurück
Oben