hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Der Fluch des Textforums. Du bootest das installierte System ohne nomodeset, damit in den Logs steht, wo es weh tut. Dann bootest du das Live-System mit nomodeset, sonst erhältst du ja keinen Desktop, und lutschst die Logs mit den Fehlermeldungen aus dem installiertem System. Die kann Letalis Sonus dann netterweise für dich auswerten. Natürlich kannst du auf das installierte System zugreifen. Der Witz sind die Fehlermeldungen beim Fehlstart ohne nomodeset.
|
HD5850_Fail
(Themenstarter)
Anmeldungsdatum: 20. Mai 2018
Beiträge: 52
|
Danke, ja jetzt macht es Sinn für mich. Werde es gleich posten. Danke für eure Geduld!
|
HD5850_Fail
(Themenstarter)
Anmeldungsdatum: 20. Mai 2018
Beiträge: 52
|
Tja.... es ist vertrackt.... also ich bin vorgegangen wie ihr mir gesagt habt. Habe das installierte System ohne nomodeset einmal booten lassen Dann Reboot erzwungen Habe dann das Live System booten wollen, also musste ich nomodeset setzen Dann habe ich "Try Kubuntu" ausgewählt Er meldet nur no UMS support
Wie sage ich ihm denn: Boote die Live Test Version auch nochmal im nomodeset - bzw. denkt ihr, dass ich dann das auch nochmal extra setzten muss? Viele Grüße (wenn ihr kein Bock mehr auf mich Noob habt, dann sagt es einfach - dann kaufe ich mir eine neue, ist ja auch alles echt grenzwertig mit meinem Problem... -.-)
|
Dogeater
Anmeldungsdatum: 16. Juni 2015
Beiträge: 3381
|
HD5850_Fail schrieb: Tja.... es ist vertrackt.... also ich bin vorgegangen wie ihr mir gesagt habt. Habe das installierte System ohne nomodeset einmal booten lassen Dann Reboot erzwungen Habe dann das Live System booten wollen, also musste ich nomodeset setzen Dann habe ich "Try Kubuntu" ausgewählt Er meldet nur no UMS support
Wie sage ich ihm denn: Boote die Live Test Version auch nochmal im nomodeset - bzw. denkt ihr, dass ich dann das auch nochmal extra setzten muss?
Du drückst die TAB-Taste, wenn auf deinem Ubuntu-Ladescreen das komische Männchen mit der komischen Tastatur erscheint. Aber ach, du kommst ja doch bis dahin, wo du auf "Kubuntu starten" kommst. Dort drückst du jetzt aber bitte ersteinmal die TAB-Taste und eine Kommandozeile mit Bootoptionen erscheint. Dort trägst du dein nomodeset ein und löschst das "quiet" bitte heraus. Meine Asus EAH 5770 musste ich leider auch immer nomodesetten, bis ich den fglrx installieren konnte.
|
HD5850_Fail
(Themenstarter)
Anmeldungsdatum: 20. Mai 2018
Beiträge: 52
|
@Dogeater Moin, ja vielen Dank. Jedoch bin ich bereits einen Schritt weiter. Ich habe bereits immer über dieses Menü
nomodeset gesetzt oder nicht. (Das für 18.04: http://linuxbsdos.com/wp-content/uploads/2011/05/Kinstall-600x450.png )
Jedoch bin ich (mit nomodeset) in diesem Menü gewesen:
https://www.kubuntuforums.net/attachment.php?s=b668a5175f7401c90b4f0bcf14a7a858&attachmentid=7240&stc=1&thumb=1&d=1511181804 Und wenn ich jetzt auf "Try Kubuntu" klicke - dann wird es wieder schwarz.
Deshalb die Frage: Wie boote die Live Test Version auch nochmal im nomodeset?
Also ich müsste davor irgendwie diesen Parameter setzten können. Ich hoffe Ihr versteht was ich meine. (Frage: quiet lässt ihn nur den ganzen Kernel Log anzeigen statt den Bildschirm schwarz zu lassen, oder?) VG
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
HD5850_Fail schrieb: Jedoch bin ich (mit nomodeset) in diesem Menü gewesen:
Zu diesem Zeitpunkt sollte er bereits mit nomodeset gebootet haben, du hast ja auch bereits eine richtige grafische Oberfläche und keinen einfach bemalten Framebuffer mehr. Da geht noch irgend etwas anderes beim Starten der Desktopumgebung schief... Hast du noch ein parallel installiertes Windows? Das Ext2Read Projekt wird zwar nicht mehr weiterentwickelt, hat aber einen immer noch funktionsfähigen Dateibrowser ohne Schreibrechte für ext4 Dateisysteme, damit kannst du die Logs auch ohne die Installation von irgendwelchen Treibern von Windows aus besorgen. HD5850_Fail schrieb: (Frage: quiet lässt ihn nur den ganzen Kernel Log anzeigen statt den Bildschirm schwarz zu lassen, oder?)
quiet unterdrückt die unwichtigen Kernel Meldungen, darunter kann sich aber die ein oder andere wichtige Meldung verstecken.
Hast du schon mal die Bootoption noplymouth ausprobiert? Plymouth kann in seltenen Fällen Probleme machen.
|
HD5850_Fail
(Themenstarter)
Anmeldungsdatum: 20. Mai 2018
Beiträge: 52
|
Hast du noch ein parallel installiertes Windows?
Ne, habe "zum Glück" Windows vor Jahren abgeschafft. Mein Way-To-Linux ist leider noch etwas holprig wie ihr seht^^ Muss mir was anderes überlegen. Vllt probiere ich es mit Ubuntu. Evtl wird dort die LIVE version geladen... noplymouth werde ich mal probieren
|
Dogeater
Anmeldungsdatum: 16. Juni 2015
Beiträge: 3381
|
Deshalb die Frage: Wie boote die Live Test Version auch nochmal im nomodeset?
Wie gesagt, mit der TAB-Taste oder schaue dir mal die Optionen F5 und F6 an.
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
HD5850_Fail schrieb: Vllt probiere ich es mit Ubuntu. Evtl wird dort die LIVE version geladen...
Da wirst du wohl mehr Glück mit Xubuntu oder Lubuntu haben, da deren grafische Oberfläche standardmäßig keine Hardware-Beschleunigung nutzen oder gar voraussetzen.
|
HD5850_Fail
(Themenstarter)
Anmeldungsdatum: 20. Mai 2018
Beiträge: 52
|
Hallo zusammen, ich bin wieder da ☺ Habe jetzt die Kernel und Xorg Logs wie beschrieben extrahiert. Xubuntu konnte sogar die volle Auflösung dabei anzeigen. was ein Segen. Ich wollte die logs nicht veröffentlichen und habe sie an euch per PM geschickt. Hoffe das ist okay. Wenn ihr mir sagt, dass dort nichts von Interesse drin ist, kann ich es auch gerne veröffentlichen, war mir da aber nicht sicher. Beste Grüße
|
HD5850_Fail
(Themenstarter)
Anmeldungsdatum: 20. Mai 2018
Beiträge: 52
|
Okay, ich habe jetzt einfach mal die Log gepostet. Sollte ein Admin das für eine schlechte Idee halten, bitte den Post löschen! Wenn niemand sonst weiter weiß, dann muss ich mir wohl ne neue Grafikkarte kaufen ☹ Viele Grüße
- Xorg.0.log.old (28.0 KiB)
- Download Xorg.0.log.old
- Xorg.0.log (29.5 KiB)
- Download Xorg.0.log
- kern.log.1 (723.5 KiB)
- Download kern.log.1
- kern.log (284.9 KiB)
- Download kern.log
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
Zumindest mit nomodeset findet sich in den Logs nichts außer ein paar ACPI Fehlern. Die können in seltenen Fällen durchaus derartige Probleme verursachen, nur kann man da auch selten etwas anderes gegen machen als ein BIOS Update zu fahren und zu hoffen dass der Hersteller das Problem bereits behoben hat. In den Logs befindet sich allerdings kein einziger Bootvorgang ohne nomodeset , und das sind nicht gerade wenige Bootvorgänge die darin enthalten sind. Es wäre äußerst unschön wenn das ganze ohne die Option bereits so früh abschmiert, dass es noch keine Gelegenheit gibt den Log auf die Platte zu schreiben...
|
mrkramps
Anmeldungsdatum: 10. Oktober 2006
Beiträge: 5523
Wohnort: south central EL
|
Letalis_Sonus schrieb: In den Logs befindet sich allerdings kein einziger Bootvorgang ohne nomodeset , und das sind nicht gerade wenige Bootvorgänge die darin enthalten sind. Es wäre äußerst unschön wenn das ganze ohne die Option bereits so früh abschmiert, dass es noch keine Gelegenheit gibt den Log auf die Platte zu schreiben...
Möglicherweise schmiert das System tatsächlich schon beim ersten Mode Switch ab. In Bugreport #105221 🇬🇧 beschreibt jemand das Problem mit einer Radeon HD 5850 unter Fedora 26 (sporadisch) und Fedora 27 (permanent) mit Kernel 4.15. Scheint schon länger bekannt zu sein und diverse Kernel-Versionen zu betreffen. Mehr dazu auch in Redhat-Bug #1474044 🇬🇧. Lösungsansätze findet man dazu leider nicht. Ich will mich nicht zu weit aus dem Fenster lehnen, aber in diesem Fall würde ich fast sagen, dass man sich eine Menge Stress sparen kann, wenn man die Grafikkarte tatsächlich einfach durch ein aktuelleres Modell ersetzt, das nicht auf dem Evergreen-Chipsatz basiert. Wenn man noch etwas weiter im Trüben fischen möchte: Was für ein Monitor wird verwendet (genaue Modellbezeichnung)? Wie ist der Monitor angeschlossen (VGA, DVI, HDMI, DP)? Was für ein Mainboard wird verwendet (genaue Modellbezeichnung)? Gibt es eine aktuellere Firmware für das Mainboard? Wenn ja, welche Änderungen listet der Hersteller im Changelog der Firmware? Bootet das System mit einem älteren Kernel (Ubuntu 14.04.2 oder Debian 9 (bspw. AntiX)?
|
Letalis_Sonus
Anmeldungsdatum: 13. April 2008
Beiträge: 12990
Wohnort: Oldenburg/Erlangen
|
mrkramps schrieb: Ich will mich nicht zu weit aus dem Fenster lehnen, aber in diesem Fall würde ich fast sagen, dass man sich eine Menge Stress sparen kann, wenn man die Grafikkarte tatsächlich einfach durch ein aktuelleres Modell ersetzt, das nicht auf dem Evergreen-Chipsatz basiert.
Das setzt allerdings voraus, dass das Problem tatsächlich auch beim Evergreen-spezifischen Treibercode sitzt - ich habe selbst noch einen Evergreen Chip im täglichen Einsatz und noch nie Probleme damit gehabt. Es besteht durchaus die Möglichkeit dass das Problem mit einer neueren Karte immer noch bestehen könnte, weil es gar nicht von der Grafikkarte selbst ausgeht sondern nur ein Folgeschaden ist. Wenn das Problem schon unter 16.04 bestand halte ich den Treiber als Ursache für ziemlich unwahrscheinlich, das ist schließlich kein Sondermodell sondern eines der Massenmodelle von der Stange schlechthin - da bleiben solche Probleme nicht einfach über Jahre bestehen, dafür wird der Treiber einfach zu gut gepflegt.
|
mrkramps
Anmeldungsdatum: 10. Oktober 2006
Beiträge: 5523
Wohnort: south central EL
|
Letalis_Sonus schrieb: Das setzt allerdings voraus, dass das Problem tatsächlich auch beim Evergreen-spezifischen Treibercode sitzt - ich habe selbst noch einen Evergreen Chip im täglichen Einsatz und noch nie Probleme damit gehabt. Es besteht durchaus die Möglichkeit dass das Problem mit einer neueren Karte immer noch bestehen könnte, weil es gar nicht von der Grafikkarte selbst ausgeht sondern nur ein Folgeschaden ist. Wenn das Problem schon unter 16.04 bestand halte ich den Treiber als Ursache für ziemlich unwahrscheinlich, das ist schließlich kein Sondermodell sondern eines der Massenmodelle von der Stange schlechthin - da bleiben solche Probleme nicht einfach über Jahre bestehen, dafür wird der Treiber einfach zu gut gepflegt.
Deswegen will ich mich auch nicht zu weit aus dem Fenster lehnen. Eine andere Grafikkarte könnte zumindest ein spezifisches Kompatiblitätsproblem zwischen bspw. Mainboard und Grafikkarte beheben. Das würde einem dann die Fehlersuche ersparen. Ich habe mit dem freien radeon-Treiber und verschiedenen Radeon-HD-Chipsätzen über Jahre nur gute Erfahrungen gemacht und selber habe ich ebenfalls noch eine Evergreen im Produktiveinsatz. Deswegen habe ich das Thema gestern nur überflogen und gleich wieder weggeklickt, weil ich Treiberprobleme mit den älteren Baureihen inzwischen fast kategorisch auschließen würde. Die verlinkten Bug Reports geben leider wenig verwertbare Informationen zu den sonst in den betroffenen Systemen verwendeten Harware um weitere Rückschlüsse zuzulassen. HD5850_Fail, in diesem Sinne wäre es hilfreich, wenn du auf die Fragen in meinem vorherigen Beitrag eingehen könntest. Möglicherweise lässt sich daraus noch etwas ableiten.
|