[gelöst]Buster: System fährt in Textmodus (tty1)

[halo44]

Guten Abend miteinander,

nachdem ich inzwischen Buster auf meinem Notebook installiert habe und das OS sauber läuft (nur ein Problem mit Wine/Playonlinux, was aber ein anderes Thema ist), habe ich nun auch eine Installation auf meinem Desktoprechner vorgenommen.

Wenn ich Buster über den Bootloader der Stretch-Installation aufrufe, startet das OS kurz, fällt dann aber zurück in die Auswahl der installierten OS. Erst wenn ich die Bootoption "nomodeset" mitgebe startet das OS, allerdings im Textmodus und bietet mir dort den login an. Logge ich mich dort ein kann ich mit "startx" das System starten und ich erhalte die gewohnte KDE-Oberfläche.

Der Display-Manager verweist auf /usr/bin/sddm. In /etc/sddm findet sich das zugehörige Skript. Warum wird der Display-Manager nicht ausgeführt? Kann es sein, daß Buster und AMD sich nicht vertragen?

Ich vermute, daß die Ursache irgendwie mit der Grafikkarte zusammenhängt:

Code: Alles auswählen

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8570D] [1002:990e]

Meine Stretch-Installation startet ohne "nomodeset", Buster braucht sie aber anscheinend. Ich habe "nomodeset" deshalb versucht, weil auch meine Kanotix-Installation nur startet, wenn ich "nomodeset" verwende.

Sowohl bei Buster als auch Kanotix findet sich mittels "lsmod" kein radeon-Modul. Beide Installationen sind aber vollumfänglich nutzbar, wobei Kanotix brav den vorgesehenen Display-Manager "lightdm" aufruft, Buster aber nicht den vorgesehenen "sddm".

Kann mir vielleicht jemand behilflich? Hierfür schon vorab meinen Dank.

Ich schreibe übrigens hier schon aus dem Buster-OS. Weitere Infos stelle ich gerne zur Verfügung.

Gruss H.

[Blackbox]

Dazu solltest sich doch entweder etwas in /var/log/Xorg.[0,1].log, oder ~/.local/share/xorg/Xorg.[0,1].log finden lassen?
Zur Not wirfst du dein(e) Xorg Logfile(s) in ein NoPaste.

[towo]

Und AMD Grafik benötigt zwingend das Paket firmware-amd-graphics. Ohne selbiges wird das schonmal nix.

[halo44]

Und AMD Grafik benötigt zwingend das Paket firmware-amd-graphics. Ohne selbiges wird das schonmal nix.

Das Paket ist schon installiert, also von daher kein Handlungsbedarf (hierfür).

Gruss H.

[halo44]

Dazu solltest sich doch entweder etwas in /var/log/Xorg.[0,1].log, oder ~/.local/share/xorg/Xorg.[0,1].log finden lassen?
Zur Not wirfst du dein(e) Xorg Logfile(s) in ein NoPaste.

Ich habe inzwischen lightdm installiert und kann mich daher damit einloggen. Fragt sich aber immer noch, warum ist "nomodeset" erforderlich und warum kommt der Display-Manager "sddm" nicht hoch?

Die Xorg.0.log, die vor Installation "lightdm" aktuell war, habe ich aus der Sicherung, die ich vor der Installation von "lightdm" gemacht habe, kopiert und nach nopaste eingestellt: pastebin/?mode=view&s=40478

Gruss H.

[towo]

Ein Log mit nomodeset hilft genau Null, weil durch nomodeset die AMD Grafik abgedreht wird.

[halo44]

Ein Log mit nomodeset hilft genau Null, weil durch nomodeset die AMD Grafik abgedreht wird.

Das weiß ich, schrieb ich auch schon bei der Themeneröffnung

findet sich mittels "lsmod" kein radeon-Modul

Leider aber startet mein Buster ohne "nomodeset" nicht. Kannst Du mir eine alternative Bootoption empfehlen?

Gruss H.

[towo]

Vielleicht findet lsmod kein radeon Modul, weil das System amdgpu verwendet?
Ich würde das System mal mit dem Parameter amdgpu.blacklist=1 starten.

[halo44]

Vielleicht findet lsmod kein radeon Modul, weil das System amdgpu verwendet?
Ich würde das System mal mit dem Parameter amdgpu.blacklist=1 starten.

Volltreffer - jetzt fährt das System mit dem eingestellten Display-Manager (jetzt natürlich lightdm) hoch und lsmod findet auch das radeon-Modul.

Vielen Dank für Deine Hilfe.

Gruss H.

[halo44]

Ich muß das Thema leider nochmal öffnen, weil das Problem doch nicht gelöst scheint.

Mit der Bootoption amdgpu.blacklist=1 gelang der Start beim ersten Mal gleich nach Einrichtung. Darum auch meine Erfolgsmeldung. Beim nächsten Start gelang dies jedoch nicht. Der Bootloader zeigte erneut das Auswahlbild. Ich wählte erneut die Buster-Installation und der Start gelang doch.

Obwohl dies schon merkwürdig war, bin ich erstmal mit der weiteren Einrichtung fortgefahren. Ich habe danach das System runtergefahren, damit meine zeitgesteuerte Systemsicherung über Stretch laufen konnte.

Jetzt aber gelingt es mir nicht mehr auch mit einem Dutzend Versuche Buster zu starten. Kann ich noch irgendetwas unternehmen? Sollte der Bootvorgang vielleicht früher oder später das radeon-Modul laden? Kann man das überhaupt beeinflussen?

Gruss H.

[towo]

Nun willst Du das Ganze sicher aber noch permenent haben, oder?
Also

Code: Alles auswählen

echo blacklist amdgpu > /etc/modproble.d/amdgpu-blacklist.conf 
update-initramfs -u -k all

[halo44]

Da haben sich unsere Beiträge überschnitten. Ich werde jetzt den Versuch mit der initrd unternehmen.

Gruss H.

[halo44]

Leider fährt das System auch jetzt nicht hoch. Ist dieser Inhalt der /etc/modprobe.d/amdgpu-blacklist.conf so richtig:

Code: Alles auswählen

blacklist amdgpu

Beim updaten erhalte ich diese Meldung:

Code: Alles auswählen

root@dt-buster:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.18.0-2-amd64
cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries 
    nor crypto modules. If that's on purpose, you may want to uninstall the 
    'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs 
    integration and avoid this warning.
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
root@dt-buster:~# 

Gruss H.

[towo]

Also solange Du kein verschlüsseltes System einsetzt, dind diese Meldungen irrelevant.
Und kannst Du das System booten, wenn du beim Grub nochmal amdgpu.blacklist=1 setzt?
Wenn ja, dann trag das einfach in /etc/default/grub bei GRUB_CMDLINE_LINUX_DEFAULT ein und mach danach ein update-grub.

[halo44]

Also solange Du kein verschlüsseltes System einsetzt, dind diese Meldungen irrelevant.
Und kannst Du das System booten, wenn du beim Grub nochmal amdgpu.blacklist=1 setzt?
Wenn ja, dann trag das einfach in /etc/default/grub bei GRUB_CMDLINE_LINUX_DEFAULT ein und mach danach ein update-grub.

Nein, ich kann das System weder mit noch ohne

Code: Alles auswählen

amdgpu.blacklist=1

booten. Es geht wie zu Anfang nur mit "nomodeset".

Zu cryptsetup: meine verschlüsselten Partitionen habe ich in Buster noch nicht geöffnet, das kommt später. Allerdings kann ich in meiner Notebook-Installation von Buster mit cryptsetup arbeiten, obwohl auch dort beim Erstellen der initrd die Fehlermeldungen zu cryptsetup kamen.

Gruss H.

[towo]

Naja, ohne relevante Logfiles von einem Boot ohne nomodeset nin ich raus.
Am besten journald auf persistent konfigurieren, dann kommt man auch an alte logfiles.
Auch X übschreibt sein Log noich, sonden sichert das alte Log.
Da ich nicht an dem System sitze und nicht hellsehen kann, kann ich auch nichts weiter dazu sagen.

[halo44]

Gut, Logfiles sind schon persistent eingerichtet. Ich kann mal sehen, was ich da finde.

Gruss H.

[halo44]

Hier ein Log ohne nomodeset: pastebin/?mode=view&s=40481

Gruss H.

[towo]

Das Log sieht gut aus, radeon wird problemlos initialisiert. Nun wäre das X-Log von diesem Bootversuch interessant.

[halo44]

Hat leider etwas gedauert, weil ich einige Zeit nicht online war.

In /var/log finde ich zwei Log-Dateien: eine Xorg.0.log und eine Xorg.0.log.old. In beiden findet sich nur eine Bootzeile mit "nomodeset".

Vielleicht kam der Rechner garnicht dazu eine Log-Datei in der Variante mit "amdgpu.blacklist=1" zu erstellen. Ich werde jetzt mal mit einem erneuten Startversuch mit dieser Option eine Xorg.0.log zu gewinnen.

Gruss H.

[halo44]

Wie vermutet wird keine Xorg.0.log erstellt, wenn der Systemstart mit "amdgpu.blacklist=1" scheitert.

Wie ich ja gestern schrieb, gelang der Systemstart zweimal mit dieser Bootoption. Da ich anschließend erstmal mein System sicherte, kann ich eine Xorg.0.log von einem dieser erfolgreichen Systemstarts anbieten. Vielleicht ist diese ja auch interessant.

Hier die Daten pastebin/?mode=view&s=40482

Gruss H.

[towo]

Nuja, das log nützt nu gar nix, weil da hat es ja funktioniert.
Hast Du mal in ~/.local/share/xorg/ geschaut, ob das Logfile evtl. dort erzeugt wird?

[halo44]

Nein, dort wird kein log erzeugt. Kann es ja vermutlich deswegen schon nicht, weil das System ja garnicht bis zur Nutzeranmeldung gelangt. Auch unter /root/.local/share findet sich kein xorg.

Gruss H.

[towo]

Also wenn nirgends ein Xorg.0.log erstellt wird, versucht das System auch gar nicht, irgendwie einen X-Server zu starten.
Und bei solchen Problemen wäre echt ein 2. Rechner von Vorteil, wo man dann versuchen kann, per ssh auf diesen Rechner zu kommen, damit man ggfs. sieht, was auf der Kiste so los ist.

[halo44]

Der zweite Rechner ist vorhanden und mit ssh kann ich auch umgehen, aber ich habe keine Vorstellung davon, wie ich auf den nicht hochgefahrenen Rechner kommen soll. Da bin ich auf Hilfe angewiesen.

Gruss H.