UEFI - Grafische Probleme und Boot-Probleme Linux

M

McMoneysack91

Gast
Liebe Freunde,

ich habe seit längerem Probleme mit UEFI bei einigen Linux Distros.

Insbesondere Debian, Ubuntu und Linux Mint sowie LMDE machen mir etwas zu schaffen im UEFI.

1. Grafische Probleme

Egal, ob ich Ubuntu, Xubuntu, Linux Mint, LMDE4 live starte, ich bekomme immer ein stark verzerrtes Bild (siehe Anhang 1) mit grafischen Unebenheiten. Ich musste es mit meinem Mobiltelefon aufnehmen, da ein Screenshot diesen Fehler nicht aufnimmt, sondern da auf dem Bild alles perfekt erscheint. Also irgendwie ein Darstellungsproblem. Einzig und allein bei Xubuntu konnte ich den Live Modus mit "safe Graphics" starten. Dieser ergab ein vernünftiges Bild. Sobald ich Xubuntu dann jedoch installiert habe, boote ich leider wieder in ein völlig verzerrtes Bild.

1.jpg




2. Gänzlich schwarzer Bildschirm

Bei Debian10 und LMDE4 ging die Sache noch einen Schritt weiter. Wenn ich im UEFI Modus das Live-Medium starten möchte (live session), dann wird gebootet und anschließend erscheint ein für immer währender schwarzer Bildschirm mit einem blinkenden Balken (wie im Terminal) oben links in der Ecke. Er reagiert auf nichts, außer ich drücke SUPER+F1 z.B: dann gelange ich in diese Willkommensnachricht im Textmodus (kein DE, kein Xorg, reiner command line). Oben steht dann LMDE4 Debbie mint tty1 durch diese ttys kann ich mich dann durchschalten mit den F-Tasten.

Gebe ich nun startx ein, kommt wieder eine Fehlermeldung und der Bildschirm ist verzerrt, sogar im commandline Modus.

2.jpg



Lösung des Ganzen wäre, einfach den CSM Legacy Modus statt UEFI zu benutzen. Das klappt auch bei den meisten Distros. Nur gefällt mir da nicht, dass beim Booten alle möglichen Gesichtsgrimmassen an Grafik"fehlern", Streifen, Pixelchaos etc durchlaufen wird, bevor in das System gebootet wird (was dann aber perfekt und flawlessly funktioniert). Es gibt einem irgendwie das Gefühl, da ist schon irgendwas verkorkst und nicht koscher. Und schließlich...meine Mainboard hat doch UEFI - also warum nicht davon Gebrauch machen?

Meine Specs:

Mainboard: MSI A320M A-Pro
CPU: AMD Athlon 3000G
RAM: 8GB DDR4 (2x4GB)

Hinweis: Unter openSUSE hatte ich im UEFI keinerlei Probleme. Es lief flüssig wie geschmiert durch und bootete ohne Probleme, ob in die Liveversion oder in die installierte.
 
Hallo,

liegt vielleicht an der verwendeten Hardwareunterstützung der Grafik beim Booten.
Ich hatte da mal einige Änderungen im Grub2 vorgenommen und dann lief es besser.

Nach der Installation konnte ich irgendwann den HW-Support der GPU wieder aktivieren.
Weiß aber gerade nicht genau die Befehle, müsste ich mal suchen.

Welche UEFI-Version vom MSI A320M A-Pro ist denn momentan in Verwendung?
Welche Einstellungen wurden im UEFI vorgenommen?
Welchen Monitor (Hersteller, Modell) nutzt Du? Edit: offensichtlich irgendein Phillips ??* 200WS

P.S.
Du könntest die Bilder noch ensprechend um 90° drehen, sodass man sie besser anschauen kann.
Und wenn Du magst gern noch in Spoiler verpacken, dann lässt sich Dein Text besser zusammenhängend lesen.

Grüße
 
Zuletzt bearbeitet:
Mein UEFI sagt folgendes

CPUID/Mikrocode: 810F81/8108109
BIOS-Version: E7C51AMS.120
Erstellungsdatum: 09/26/2019

Ich schaue nach einem BIOS Update für meine Mainboard.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Wenn ich mich nicht täusche steht da Kernel 4.9.x auf dem zweiten Bild, wurde die APU da schon unterstützt?

Edit: openSUSE Leap ist bei Version 5.9 aktuell und nach kurzer Internetrecherche lief die APU wohl mit 4.12.x oder so. Aktuell ist 5.12.x bzw. 5.13.
Lösungsvorschläge; erstmal aktuellere .iso Dateien verwenden wenn du Debian, Mint, whatever nutzen willst. Oder eben Leap installieren 😀

Edit2: Mein altes UEFI ist Tumbleweed egal, B350 Chipset.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
@McMoneysack91
Vielleicht liegt's am Xorg selbst. Du hast ja mit "StartX" den X11-Server gestartet.
Da kam dann eine Fehlermeldung, dass keine ".Xauthority" existiert.

Bin jetzt kein Linux-Spezialist, aber vielleicht sollte man die Konfiguration dieser Datei mal vornehmen.
Sie ist dem Namen nach ja scheinbar für den X11-Server gedacht - vermutlich wer darauf zugreifen darf.

***

https://www.msi.com/Motherboard/support/A320M-A-PRO
Neuestes BIOS: https://download.msi.com/bos_exe/mb/7C51v14.zip

E7C51AMS.140.png


  • Update AMD ComboPI 1.0.0.4 Patch B (SMU v46.54)
  • Improved system boot up time
  • Improved PCI-E device compatibility
  • Update AMD ComboPI 1.0.0.6 (SMU v46.62)
  • Support new audio chipset
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: McMoneysack91
McMoneysack91 schrieb:
SE. schrieb:
Kernel 4.9.x auf dem zweiten Bild, wurde die APU da schon unterstützt?
McMoneysack91 schrieb:
Debian10 und LMDE4
Diese Ryzen APU ("Picasso") kamen nach dem Debian Feature Freeze für 10 heraus.
Das steht auch in vielen Beiträgen im Forum usw.

https://wiki.debian.org/DebianBuster : 2019-07-06: Initial release: 10.0 (Juli!)
Ryzen 3000G Release im November 2019: computerbase-review (November!)

Lösung:
  • 5.x Backports Kernel nutzen (debian wiki) -- das ist dann der freie AMDGPU Treiber
  • den 4.19 Kernel behalten und AMDGPU-PRO Linuxtreiber von AMD Nutzen (siehe debian-wiki)

zu 1

Die grafischen Probleme mit OpenSuse oder mit einer Fedora Live Version getestet ?
Wenn das Grafikproblem nicht im "screenshot" auftritt - dann kann es am Monitor , Kombination Monitor/Grafikkarte(APU) liegen - oder ein Bug im Treiber (Kernelversionen / Grafik-UIs testen: Wayland vs. Xorg - KDE <-> Gnome.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
In der Tat habe ich heute auch noch mal schnell Fedora34 Live XFCE getestet. Keine grafischen Probleme.

Zusammenfassung
Boot im UEFI

Debian10: schwarzer Bildschirm mit Blinkbalken
*Ubuntu: Grafikfehler diagonal verzerrt
Linux Mint 20: Grafikfehler diagonal verzerrt
LMDE4: schwarzer Bildschirm mit Blinkbalken

openSUSE Leap 15.3: startet problemlos
Fedora34: startet problemlos
 
lokon schrieb:
Diese Ryzen APU ("Picasso") kamen nach dem Debian Feature Freeze für 10 heraus.
Mag so sein, aktuell ist auch hier scheinbar 10.10 – Link.

Die Probleme lagen wohl bei „Debian10“ und Linux Mint Debian Edition, openSUSE funktionierte.

Unabhängig davon fällt mir gerade auf wie befreiend der Verzicht auf diese numerischen Versionierungs-Systeme sein kann. Netzinstallationen sind ein Segen.
 
SE. schrieb:
Mag so sein, aktuell ist auch hier scheinbar 10.10 – Link.

Das Kernelpaket in Buster 10.10 ist 4.19 - siehe packages.debian.org
5.10 ist bei buster-backports - muss aber aktiviert werden.
Afaik macht Debian keine Backport im "Distro"-Kernel (das würde gegen "stable" Regeln verstoßen).

Bei anderen Distributionen mit mehr Backports ("kommerz-Kernel" afaik Redhat oder Oracle UKE) müssen meist mehr changelogs / git commits gelesen werden um diese Fragen zu beantworten.

Bsp: Redhat 8.x haben Kernel 4.18 lt. Wikipedia (src: en-wikipedia) wobei das Grafik-Subsystem auf 5.1 basiert lt. Redhat Releasenotes 8.1 .

edit: Bei Ubuntu Varianten gibt es zB mainline Kernel, linux-oem oder diverse "ppa" Kernel - bei Arch Linux/Manjaro kann auch zwischen vielen Kernelvarianten gewählt werden.
 
  • Gefällt mir
Reaktionen: sedot
Es fällt mir irgendwie schwer, mir vorzustellen, dass MEINE Hardware zu neu für ein OS ist. Meine, der ich dafür bekannt bin noch PCs von 1999 rauszukramen und da TinyCore Linux und son Kram draufzuspielen.

Ich mein, OK, Debian 10 Stable. Kann ich verstehen. Aber nach meiner Recherche ist auch Xubuntu 20.04 anscheinend vom Kernel noch nicht so weit, dass es meine Athlon 3000G APU voll unterstützt.

Nun, derzeit bin ich tatsächlich bei Fedora angekommen, was meinen Main Tower angeht. Fedora installiert und startet unter UEFI problemlos und es gibt keine lästigen Probleme mit Druckereinrichtung etc. Alles läuft out of the box und ich denke, ich werde bei Fedora bleiben, bis Debian mit dem Kernel aufschließt.
 
Zurück
Oben