Hallo,
ich habe hier einen älteren Rechner, der mit Kernel 6.11 Probleme macht. Er fängt an zu booten, es werden noch 3 Zeilen angezeigt, allerdings so kurz, dass ich es nicht lesen kann und dann ist der Bildschirm dunkel. Auch die Tastatur scheint tot zu sein. Ich kann also nicht sagen, ob er bootet. Mit 6.10 läuft die Kiste einwandfrei. Auf zwei neueren Rechnern läuft 6.11 problemlos.
Hier mal die Daten des Rechners:
System:
Host: master Kernel: 6.10.12-1-siduction-amd64 arch: x86_64 bits: 64
compiler: gcc v: 14.2.0
Desktop: Xfce v: 4.18.1 Distro: siduction - xfce base: Debian GNU/Linux
trixie/sid
Machine:
Type: Desktop Mobo: Gigabyte model: P55-UD3 v: x.x
serial: <superuser required> BIOS: Award v: F3 date: 07/31/2009
CPU:
Info: quad core model: Intel Core i7 860 bits: 64 type: MT MCP arch: Nehalem
rev: 5 cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
Speed (MHz): avg: 1798 high: 2798 min/max: N/A cores: 1: 1199 2: 1199
3: 2798 4: 1199 5: 2798 6: 1199 7: 2798 8: 1199 bogomips: 44768
Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Advanced Micro Devices [AMD/ATI] Oland PRO [Radeon R7 240/340 /
Radeon 520] vendor: Micro-Star MSI driver: amdgpu v: kernel arch: GCN-1
bus-ID: 01:00.0 temp: 38.0 C
Display: x11 server: X.Org v: 21.1.13 with: Xwayland v: 24.1.3 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu
resolution: 1920x1080~60Hz
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.2.4-1 glx-v: 1.4
direct-render: yes renderer: AMD Radeon Graphics (radeonsi oland LLVM
19.1.1 DRM 3.57 6.10.12-1-siduction-amd64)
Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: Gigabyte driver: r8169 v: kernel port: de00 bus-ID: 03:00.0
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 00:24:1d:dc:ab:74
Drives:
Local Storage: total: 3.19 TiB used: 678.56 GiB (20.8%)
Info:
Memory: total: 8 GiB available: 7.76 GiB used: 2.23 GiB (28.7%)
Processes: 328 Uptime: 1m Init: systemd target: graphical (5)
Packages: 3438 Compilers: gcc: 14.2.0 Shell: Bash v: 5.2.32 inxi: 3.3.36
Begib Dich unmittelbar nach dem Start des Rechners in das Grub Auswahlmenü und wähle mit den Cursor Tasten
den Eintrag mit dem 6.11 Kernel aus, den Du booten möchtest. Drücke anschließend die Taste "e", um die Anweisungen
in diesem Menu zu sehen und zu editieren. Wähle hier mit den Cursor Tasten die Zeile beginnend mit "linux ..." aus und entferne dahinter die Option "quiet". Am Ende dieser Befehlszeile fügst Du die Option "break=top" ein und startest das Laden des Kernels mit der Tastenkombination "Ctrl-x". Entweder bricht der Vorgang wärend des Startens des Kernels ab, dann siehst Du die letzten
Meldungen des Kernels. Oder der Kernel setzt Dich nach dem Start in der "Initial Ramdisk" ab. Welche Möglichkeit tritt ein?
Falls Du eine Shell mit dem Prompt (initrd) siehst, kannst Du den regulären Bootvorgang mit "ctrl-d" fortsetzen und auf die weiteren Meldungen achten. Berichte vielleicht zunächst, wie weit Du damit kommst, anschließend analysieren wir weiter...
Ich lande in (initramfs), dort startet dann nach kurzer Zeit kallsyms_selftest und endet mit finish.
Wenn ich dann mit ctl-d den Bootvorgang fortsetze rauschen noch etliche Befehle durch, allerdings in einer Geschwindigkeit, dass ich nichts erkennen kann und endet dann in einem schwarzen Bildschirm.
Kannst du auf eine tty wechseln (also wenn du Strg+Alt+F6 drückst, landest du dann in einer Konsole wo du dich anmelden kannst)?
Oder passiert da gar nichts?
Falls da gar nichts passiert, könnten wir noch versuchen einzugrenzen ob du eine Kernel-Panik hast sobald init den X-Server startet. Um das auszuschließen würde ich Vorschlagen das wir den Kernel 30 s nach einer Kernel-Panik rebooten lassen und dann einfach mal schauen, ob der Laptop sich innerhalb der nächsten 3 min von alleine neustartet.
Das ganze machst du so:
Quote from: Teriarch on 2024/10/22, 21:42:39
Begib Dich unmittelbar nach dem Start des Rechners in das Grub Auswahlmenü und wähle mit den Cursor Tasten
den Eintrag mit dem 6.11 Kernel aus, den Du booten möchtest. Drücke anschließend die Taste "e", um die Anweisungen
in diesem Menu zu sehen und zu editieren. Wähle hier mit den Cursor Tasten die Zeile beginnend mit "linux ..." aus und entferne dahinter die Option "quiet".
dann fügst du noch
panic=30 hinzu und
Quote from: Teriarch on 2024/10/22, 21:42:39
startest das Laden des Kernels mit der Tastenkombination "Ctrl-x".
Wenn sich dein PC dann irgendwann innerhalb von ca. 3 min neustartet, hast du eine Kernel-Panik dann ist bei diesem Kernel irgendwas im argen.
@harley-peter:
Gut. Am kernel selbst liegt's also nicht. Jetzt kannst Du schrittweise die breakpoints der initialramdisk durchgehen,
also der Reihe nach: break=top, break=premount, break=mount, break=modules, break=init.
Du kannst Dir dazu im (initrd) prompt mit
(initrd) less init
das ganze init script anschauen, welches vom kernel als erster Prozess im User Space nach der Initialisierung und Rückkehr vom iKernel Space gestartet wird. Das ist ein einfaches Shell script und Du kannst den Ablauf des Vorgangs sehr gut verfolgen.
Wenn der Bildschirm nach Laden der Kernel module (also nach break=modules) schwarz wird, dann werden die Treiber der
Graphikkarte (beim kms (kernel mode set)) verantwortlich sein. Dann gib in der Grub Zeile "linux ..." die Kerneloption "nomodeset" ein, und schau, ob das weiterhilft. Wenn Du bis "break=init" kommst, kannst Du die "linux ..." Zeile mit "emergency" bzw. "rescue" beenden und sehen, ob das weiterhilft, und ob es man mounten des real root FS liegt.
Also zusammnegefasst: Du solltest den Fehler eingrenzen, damit zunächst die exakte Stelle seines Auftretens identifiziert werden kann.
@Mister00X:
Rechner startet nicht neu und auf eine Konsole kann ich auch nicht wechseln, die Tastatur schein tot zu sein.
@Teriarch:
Bildschirm endet bei allen break Varianten im Dunkeln und es hilft nur ein harter Reset. Wenn ich allerdings nomodeset in die linux Zeile einfüge dann startet nach einer endlos langen Meldungsausgabe das Gerät ganz normal und ich kann arbeiten ohne Probleme.
Edit:
Ich habe mal ein wenig im Netz geschmökert und da gab es wohl etliche Neuerungen und Updates für AMD im Kernel 6.11 und eines davon mag wohl der Treiber für meine Karte nicht. Nur - wie kann ich das beheben?
Quote from: harley-peter on 2024/10/27, 16:36:18
Edit:
Ich habe mal ein wenig im Netz geschmökert und da gab es wohl etliche Neuerungen und Updates für AMD im Kernel 6.11 und eines davon mag wohl der Treiber für meine Karte nicht. Nur - wie kann ich das beheben?
vielleicht würde ich auf den 6.10 zurückkehren ..
@harley-peter
Du schriebst (für break=top):
> ich lande in (initramfs), dort startet dann nach kurzer Zeit kallsyms_selftest und endet mit finish.
> Wenn ich dann mit ctl-d den Bootvorgang fortsetze [...]
Im nächsten Post aber:
> Bildschirm endet bei allen break Varianten im Dunkeln und es hilft nur ein harter Reset.
Kann ich daraus schließen, dass ausschließlich bei "break=top" der Bildschirm hell bleibt?
Die Graphikkarten wurde früher hauptsächlich im Userspace verwaltet. Das führte zu langen Latenzzeiten,
und deswegen übernehmen heutzutage Treiber im Kernel die Verwaltung (Kernel Mode Set, KMS).
Für AMD Graphik radeon.ko, Intel i915.ko und für Nvidia nouveau.ko. Um herauszufinden, ob es an einem dieser
Treibern liegt, kannst Du mit
$ sudo mv /usr/lib/modules/6.11.5-1-siduction-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko\
/usr/lib/modules/6.11.5-1-siduction-amd64/kernel/drivers/gpu/drm/radeon/radeon.org
den Treiber (in Deinem Fall radeon für AMD) kurz umbenennen und die Initialramdisk mit
$ sudo update-initramfs -u -k all
neu bauen, damit die Treiber in die initrd übernommen werden. Ersetze dann in der linux boot Zeile
"nomodeset" durch "emergency" und beobachte, ob Du jetzt weiter im Ladevorgang kommst.
Sorry, dass ich mich etwas unklar ausgedrückt habe. Einzig bei top=break lande ich in der (initramfs) Konsole, bei allen anderen Varianten in einem dunklen Bildschirm.
Ich habe den Treiber umbenannt und die Initialramdisks neu gebaut sowie emergency eingefügt wie du es vorgeschlagen hast aber es hat sich nichts geändert, der Bootvorgang endet in einem schwarzen Bildschirm.
Zu meinem Verständnis: welchen Treiber nimmt der Kernel dann wenn ich den Treiber umbenenne?
Kann ich irgend etwas von Kernel 6.10 (wo es ja funktioniert) testhalber in Kernel 6.11 ausprobieren?
@harley-peter
o.k. Dann kannst Du Dich zunächst mit "linux ... break=top" in der initrd absetzen lassen.
Mit
$ lsmod
stellst Du zunächst fest, welche Treiber geladen sind (i.d.R. gerade die usb und xhci Treiber, die
für die Konsoleneingabe verantwortlich sind). Jetzt lädst Du die video Treiber manuell der Reihe nach,
bis der Bildschirm schwarz wird:
$ modprobe radeon
$ modprobe i915
$ modprobe nouveau
$ modprobe nvidia
Wenn einer dabei nicht gefunden wird, kann es an dem auch nicht liegen.
Sobald Du ihn identifiziert hast, können wir in den Kernel Sourcen oder den Treiber Parametern
nachschauen, was sich geändert hat.
> Zu meinem Verständnis: welchen Treiber nimmt der Kernel dann wenn ich den Treiber umbenenne?
Keinen (allerdings bin ich mir nicht sicher ob das -u (für update) in "$ sudo update-initramfs -u -k all" den
alten Treiber nicht dort belässt). Ohne Treiber verbleibt der Video mode so, wie er vom grub Bootloader
gesetzt wurde. Allerdings haben (wie bei "nomodeset") der X server bzw. kwayland anschließend keine
Möglichkeit, den Modus zu ändern (da ja alles über den Kernel läuft) und geben auf. Wir befinden uns
bei all diesen Versuchen noch bei der Diagnose des Problems, ohne welche eine übereilte Therapie
sinnlos ist.
Nimm diesen Fehler als willkommene Gelegenheit, die Zusammenhänge der Abläufe besser zu verstehen,
sozusagen als Paradebeispiel analytischer Denkweise.
> Kann ich irgend etwas von Kernel 6.10 (wo es ja funktioniert) testhalber in Kernel 6.11 ausprobieren?
Die Kernelmodule sind versioniert, und der 6.11 Kernel weigert sich, 6.10 Module zu laden (aus gutem Grund!).
Du kannst die Sourcen des alten Moduls mit den Header files des neuen Kernels übersetzen, aber davon würde ich
abraten, denn wenn es gelingt, wirst Du es bei jedem Kernelupdate wieder tun müssen. Lass uns lieber den Grund
herausfinden, weswegen es schief geht.
@Teriarch:
Ein lsmod in der initramfs Konsole ergibt folgende geladenen Treiber: hid_generic, xhci_pci, xhci_pci_renesas, xhci_hcd, ohci_pci, ohci_hcd, ehci_pci und ihci_hcd.
Ein modprobe xxx und anschließendes booten mit ctl-d endet bei allen Eingaben mit einem schwarzen Bildschirm. Bei modprobe radeon kommt noch folgende Meldung:
[drm] radeon kernel modesetting enabled
radeon 0000:01:00.0: SI support disabled by module param
Edit:
Ich habe es noch mit modprobe amdgpu versucht nach return setzt das System sofort den Bootvorgang fort, ohne ctl-d, endet aber ebenfalls in einem dunklen Bildschirm.
@harley-peter
O.K. Wir wissen, dass der Fehler sich bereits in der initialen Bootphase zeigt und zwar
zwischen den breaks "top" und "modules" (Da ja, wie Du schreibst alle anderen (außer "top")
und insbesondere "modules" zum Fehler führen). Du brauchst also mit ctrl-d den Bootvorgang
nicht fortsetzen, da dies in jedem Fall zum Fehler führt. Die Frage ist:
Was passiert zwischen break=top und break=modules? Um das herauszufinden, starte das
System mit "linux ... break=top,modules". Jetzt wirst Du zunächst bei "top" abgesetzt und ein
weiteres ctrl-d setzt Dich bei "modules" ab. Wir erwarten, dass der Bildschirm nach dem ctrl-d
schwarz wird. Wenn das passiert, kannst Du den Rechner immer bedenkenlos ausschalten und
neustarten, da noch keine realen Filesysteme gemountet sind.
Verfolgt man die Skripte der Initialen Ramdisk, dann werden zwischen diesen Breaks weitere
Module vom inzwischen gestarteten udev daemon über kernel events geladen. Einer von diesen
ist für den Fehler verantwortlich. Dummerweise wissen wir noch nicht, welcher das ist, da ja
der Bildschirm ausfällt (ganz nebenbei kannst Du vor und nach dem ctrl-d die Num Taste
betätigen, um zu sehen, ob der ganze Kernel abstürzt oder nur ein Treiber scheitert).
Führe die ganze Aktion also mit dem 6.10 Kernel durch:
- Füge "linux ... break=top,modules" ein. Starte den Kernel
- Abgesetzt beim ersten break gib lsmod ein und liste die geladenen module
- Lass Dich mit ctrl-d beim nächsten break absetzen und finde die hinzugekommenen
Module mit lsmod heraus (Der Bildschirm bleibt ja hell, da es sich um den 6.10 Kernel handelt.
Jetzt führst Du den Vorgang mit Kernel 6.11 durch (aber natürlich ohne ctrl-d) und lädst
per Hand (also mit modprobe xxx) die für 6.10 hinzugekommenen Module in derselben Reihenfolge
nach. Wir erwarten beim Laden einer dieser Module einen schwarzen Bildschirm und das ist unser
Kandidat. Berichte dann über den Ausgang des Experimentes.
Bereits nach dem ersten
modprobe amdgpu
wird der Bildschirm dunkel. Ich habe amdgpu mal ausgelassen und einige der anderen geladen, wobei nichts passiert außer vielleicht ein paar Meldungen. Es scheint also das Modul amdgpu zu sein.
Was ich mal so zwischendurch erwähnen wollte:
Ganz herzlichen Dank für deine super Hilfe und deine Erklärungen. :D
Edit:
Nach dieser Erkenntnis habe ich dann analog deiner früheren Anweisung die Datei /usr/lib/modules/6.11..../kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko umbenannt und anschließend die Initramdisk neu gebaut und gestartet und siehe da, der Bildschirm wird nicht mehr dunkel und ich lande in einer Konsole. Nach Anmeldung als root kann ich sogar X starten (nicht als user).
@harley-peter
> Was ich mal so zwischendurch erwähnen wollte:
> Ganz herzlichen Dank für deine super Hilfe und deine Erklärungen.
Kein Problem, dafür ist dieses Forum ja eingerichtet worden.
Nach <https://linux-hardware.org/?id=pci:1002-6613-1458-22b0> wird
Deine Karte auch von radeon.ko unterstützt. Wenn Du also wie bereits erfolgt
amdgpu.ko umbenennst, sollte der Rechner mit dem radeon Treiber doch durchstarten(?)
Nach meiner Recherche ist das Problem mit amdgpu wohl bekannt und man arbeitet daran.
Ich würde an Deiner Stelle also ein wenig warten. Klappt es denn mit dem radeon Treiber?
@Teriarch:
Wenn ich amdgpu.ko umbenenne, dann lande ich in einer Konsole. Dort kann ich allerdings nur als root X starten, als user funktioniert das nicht.
Auf Grund deines Hinweises mit radeon bin ich dann mit "e" in das Bootscript von Kernel 6.11 rein und habe in der Zeile linux....die Anweisungen "amdgpu.si_support=1 radeon.si_support=0 amdgpu.dc=1" in "amdgpu.si_support=0 radeon.si_support=1 amdgpu.dc=0" geändert, worauf der Rechner direkt in die grafische Oberfläche gestartet ist, so wie es sein sollte.
Dazu jetzt eine paar Fragen:
Die Anweisung ...support kann ich noch nachvollziehen aber was besagt die Anweisung amdgpu.dc? Ich sehe keinen Unterschied zwischen amdgpu.dc=1 und amdgpu.dc=0.
Dann habe ich festgestellt, dass diese Anweisungen in /boot/grub/grub.cfg enthalten sind aber dort steht, dass man diese Datei nicht ändern soll. Also habe ich weiter gesucht und die Anweisungen auch in /etc/default/grub und /etc/default/grub.ucf-dist gefunden. Soll/kann ich die Anweisungen dort ändern und ein update-grub machen? Wenn ja, in beiden Dateien oder nur in einer?
Quote from: harley-peter on 2024/10/30, 10:47:05
Anweisungen
"amdgpu.si_support=1 radeon.si_support=0 amdgpu.dc=1" in
"amdgpu.si_support=0 radeon.si_support=1 amdgpu.dc=0" geändert, worauf der Rechner direkt in die grafische Oberfläche gestartet ist, so wie es sein sollte.
/etc/default/grub ist die Standard Konfigurationsdatei für GRUB.
Weitere Konfigurationsdateien gehören eigentlich in das Verzeichnis
/etc/default/grub.d .
Die dort abgelegten Dateien überschreiben die Standardkonfiguration. Schau auch einmal dort nach, ob zu deinen Optionen Änderungen enthalten sind.
Die unterschiedlichen Werte befinden sich vermutlich im Schlüssel GRUB_CMDLINE_LINUX .
Ein Vorschlag zur Arbeitweise:
Als erstes einmal ein diff von den beiden Dateien
/etc/default/grub und
/etc/default/grub.ucf-dist machen und schauen welche Einstellungen unterschiedlich sind.
Dann die funktionsfähige
/boot/grub/grub.cfg sichern und testweise die
grub.ucf-dist an einen gänzlich anderen Ort verschieben,
update-grub ausführen und die
/boot/grub/grub.cfg prüfen/vergleichen.
Die Datei "/etc/default/grub.ucf-dist" taucht bei der Recherche nur in uralten Ubuntu Foreneinträgen auf. Dort geht es um eine von dpkg abweichende Handhabung bei geänderten Konfigurationsdateien während ihrer Aktualisierung.
Ich vermute mal du hast eine separate boot Partition und eventuell Teile von Ubuntu darin??
Oder diesbezügliche zusätzliche Paketquellen??
In siduction habe ich diese Datei noch nicht gesehen.
Wenn sich deine Frage ausschließlich auf siduction bezieht, dann mal ohne diese Datei testen.
Anmerkung: ...ucf-dist-Dateien sind eine grundsätzlich "Debian-Eigenschaft". So wie .dpkg-new oder ...-dist, je nachdem ob man bei Konfigurationsdateien die neue ablehnt (dann heißt die neue -new) oder annimmt (dann heißt die alte -dist). Als ".ucf"-Dateien werden sie benannt, wenn die Konfiguration mittels "Update Configuration File" (ucf) Programm vorgenommen wird. Auf diese Weise kann man sich sowohl "später" entscheiden, als auch (nachträglich) die Unterschiede feststellen. Nach "Bereinigung" empfiehlt es sich oft aufzuräumen und die Datei mit der Extension zu löschen.
Dies alles passiert natürlich nur, falls eine Konfigurationsdatei (vom alten Standard) abweicht, also Änderungen vorgenommen wurden. Sonst wird die alte einfach von der neuen Datei überschrieben
[Ubuntu löscht seit "geraumer Zeit" (14.04 LTS ???) solche Dateien automatisch und ohne nachzufragen. Das empfand ich nie als angenehm. Allerdings "sammelt sich so bei 'Normalnutzern' nichts an".]
@ro_sid Danke für die Erklärungen. Da lag ich meilenweit daneben.
Das würde in dem Fall von harley-peter bedeuten, dass bei der Aktualisierung von GRUB die Nachfrage, ob die bestehende, geänderte Konfigdatei behalten werden soll verneint wurde. In der Folge enthält die grub.ucf-dist die funktionsfähigen Kerneloptionen, vorausgesetzt das Datum passt.
@scholle1:
Auf diesem Rechner war nie ein Ubuntu installiert und habe bewusst auch keine Paketquellen davon eingebunden.
Ich habe die Datei /etc/default/grub angepasst und anschließend ein update-grub durchgeführt, die Datei grub.ucf.dist habe ich entsorgt. Die Kiste läuft wieder wie gewohnt.
Ich danke allen, insbesondere Teriarch für die tolle Unterstützung, alleine hätte ich das nie geschafft. :)
@harley-peter
Freut mich zu hören, dass es geklappt hat. Die Lösung mit den Kerneloptionen zum Wechsel
des Treibers hast Du ja auch selbst gefunden (with a little help from your friends ;-)). Das Wichtigste
ist aber, dass Du eine ganze Menge dabei gelernt hast und mit dem Erfolg am Ende für all die Mühen
belohnt wurdest. Es gibt keine größere innere Befriedigung als diese!
Allerdings, gelernt habe ich eine ganze Menge! :)
Nicht nur du. Solange alles ,,out of the box## funktioniert, setzt man sich ja kaum mit solchen Fragen auseinander.
Deswegen finde ich es immer toll, wenn Fehlersuche und Lösung eines Problems hier öffentlich kommuniziert werden.
edlin