Tumbleweed startet nach Update auf Kernel 6.3.1-2-default nicht und friert mit Grub-Auswahlmenü ein - Probleme mit Radeon-Grafik?

Hinweis: In dem Thema Tumbleweed startet nach Update auf Kernel 6.3.1-2-default nicht und friert mit Grub-Auswahlmenü ein - Probleme mit Radeon-Grafik? gibt es 26 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hallo miteinander,


    habe mich in diesem Forum angemeldet, da ich wohl mehr oder weniger die gleichen Probleme wie der Ersteller eines ähnlichen Threads RE: OpenSUSE Tumbleweed startet nach Update auf Kernel 6.3.1 nicht mehr, 'Paprikate', habe.


    Auch bei uns ist ein alter Laptop "Compaq - CQ58", den wir schon lange mit Tumbleweed nutzen, seit neuestem nicht mehr in der Lage, mit dem aktuellen Kernel 6.3.1-2-default zu starten. Die beiden älteren Kernel 6.2.9-1 -default und 6.2.10-1 -default starten problemlos. Auch ein Win10 (das eigentlich nie genutzt wird) startet.


    Daher gehe ich schon davon aus, dass es an einer Änderung im neuen Kernel liegt, der sich aber mit der zugrundeliegenden Hardware nicht mehr verträgt.

    Auf meinem Haupt-PC, den ich fast überwiegend nutze (auch mit dem aktuellen Kernel 6.3.1-2 -default, allerdings mit derWayland-, statt der X-11-Grafikplattform), gibt es keine Bootprobleme. Ebenso nicht bei meiner Mutter (sie nutzt auf beiden den X11-Fenstermanager); weder auf einem (neueren) Laptop, noch auf ihrem PC; beide Systeme nutzen das aktuellste Tumbleweed ...


    Übrigens nutzt auch unser Compaq-Laptop eine Radeon-Grafikkarte (wie in oben aufgeführtem Thread von 'Paprikate', nämlich die AMD Wrestler [Radeon HD 7310].


    Nachstehend die technischen Daten mittels Konsolenabfrage "inxi -Fz" - ich musste dazu den Laptop mit altem Treiber starten:

    XXXXX@localhost:~> sudo inxi -Fz

    System:

    Kernel: 6.2.9-1-default arch: x86_64 bits: 64 Console: pty pts/1 Distro: openSUSE Tumbleweed

    20230511

    Machine:

    Type: Laptop System: Hewlett-Packard product: Compaq CQ58 Notebook PC

    v: 0892120000304010002620100 serial: <filter>

    Mobo: Hewlett-Packard model: 1885 v: 66.34 serial: <filter> UEFI-[Legacy]: Insyde v: F.27

    date: 09/17/2013

    Battery:

    ID-1: BAT0 charge: 30.0 Wh (100.0%) condition: 30.0/30.0 Wh (100.0%)

    CPU:

    Info: dual core model: AMD E1-1200 APU with Radeon HD Graphics bits: 64 type: MCP cache:

    L2: 1024 KiB

    Speed (MHz): avg: 971 min/max: 777/1400 cores: 1: 777 2: 1166

    Graphics:

    Device-1: AMD Wrestler [Radeon HD 7310] driver: radeon v: kernel

    Device-2: Chicony HP Truevision HD type: USB driver: uvcvideo

    Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 23.1.1 driver: X: loaded: modesetting

    unloaded: fbdev,vesa dri: r600 gpu: radeon tty: 191x46 resolution: 1366x768

    API: OpenGL Message: GL data unavailable in console for root.

    Audio:

    Device-1: AMD Wrestler HDMI Audio driver: snd_hda_intel

    Device-2: AMD FCH Azalia driver: snd_hda_intel

    Sound API: ALSA v: k6.2.9-1-default running: yes

    Sound Server-1: PipeWire v: 0.3.69 running: yes

    Network:

    Device-1: Realtek RTL810xE PCI Express Fast Ethernet driver: r8169

    IF: eno1 state: down mac: <filter>

    Device-2: Ralink RT5390R 802.11bgn PCIe Wireless Network Adapter driver: rt2800pci

    IF: wlo1 state: up mac: <filter>

    Drives:

    Local Storage: total: 931.51 GiB used: 47.74 GiB (5.1%)

    ID-1: /dev/sda vendor: Samsung model: SSD 870 EVO 1TB size: 931.51 GiB

    Partition:

    ID-1: / size: 783.03 GiB used: 47.74 GiB (6.1%) fs: btrfs dev: /dev/sda3

    ID-2: /home size: 783.03 GiB used: 47.74 GiB (6.1%) fs: btrfs dev: /dev/sda3

    ID-3: /opt size: 783.03 GiB used: 47.74 GiB (6.1%) fs: btrfs dev: /dev/sda3

    ID-4: /var size: 783.03 GiB used: 47.74 GiB (6.1%) fs: btrfs dev: /dev/sda3

    Swap:

    ID-1: swap-1 type: partition size: 2 GiB used: 0 KiB (0.0%) dev: /dev/sda4

    Sensors:

    System Temperatures: cpu: 51.1 C mobo: N/A gpu: radeon temp: 51.0 C

    Fan Speeds (RPM): N/A

    Info:

    Processes: 183 Uptime: 0h 6m Memory: 15.22 GiB used: 1.73 GiB (11.3%) Init: systemd Shell: Bash

    inxi: 3.3.23


    Eine Journalabfrage direkt vom neuen Kernel habe ich nicht hinbekommen. Auch komme mit Strg+Alt+F2 nicht in die Shell.
    Aber vielleicht hilft das nachstehende Journal ja, - ich habe erst einen Start mit dem neuen Kernel versucht, dann - nach Misslingen (der Bildschirm friert ein, ist größtenteils schwarz (nur rechts noch ein Teil des grünen Balkens vom Grub-Auswahlmenü sichtbar) PC kalt heruntergefahren, dann Neustart mit älterem Kernel und dann die Konsolenabfrage mittels sudo:


    XXXXX@localhost:~> sudo journalctl -b -1 -p err

    [sudo] Passwort für XXXXX:

    Mai 21 20:11:55 localhost kernel: __common_interrupt: 1.55 No irq handler for vector

    Mai 21 18:12:23 localhost tlp[489]: Error: tlp.service is not enabled, power saving will not apply on boot.

    Mai 21 18:12:23 localhost tlp[489]: >>> Invoke 'systemctl enable tlp.service' to correct this!

    Mai 21 18:13:03 localhost.localdomain systemd[1375]: Failed to start Powerdevil.

    Mai 21 18:13:08 localhost.localdomain systemd[1375]: Failed to start Powerdevil.

    Mai 21 18:13:36 localhost.localdomain konsole[2224]: kf.xmlgui: Shortcut for action "" "Schnellbefehle anzeigen" set with QAction::setShortcut()! Use KActionCollection::setDefa>

    Mai 21 18:13:36 localhost.localdomain konsole[2224]: kf.xmlgui: Shortcut for action "" "SSH-Verwaltung anzeigen" set with QAction::setShortcut()! Use KActionCollection::setDefa>

    Mai 21 18:15:51 localhost.localdomain akonadi_control[2046]: org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_ical_resource' crashed. No restart!


    Der erst Startversuch mit dem neuen, problematischen Kernel war um ziemlich genau 18.16.50 Uhr. Bis ich dann mit dem älteren Kernel gebootet und die Konsolenabfrage gestartet hatte, wohl gegen 18.18 Uhr oder etwas später.

    Aber das Journal scheint ja den Bootversuch mit dem neuen Kernel 6.3.10-1-default korrekt dokumentiert zu haben.

    Ich bin aber nur Nutzer und habe keine tiefen Konsolenkenntnisse, weiß auch nicht, was die Parameter im journalctl-Befehl bedeuten.

    Danke für Hilfe!


    Holger

  • Kommst du in den Runlevel3?

    Hast du es mal ohne wayland versucht?

    Hallo Sauerland,

    sorry, aber was ist der 'runlevel3'?

    Und den Wayland nutze ich auf dem Laptop gar nicht. Wollte nur klarmachen, dass das wohl ohne Bedeutung ist - auf meinem Haupt-PC läuft Wayland und es gibt keine Probleme. Ebenso nicht auf dem PC meiner Mutter oder dem Laptop meiner Mutter, die beide (wie auch unser Laptop) alle mit X-11 laufen.

  • Bitte nicht in ein Zitat antworten, sondern zitieren und darunter antworten.


    In den Runlevel 3 kommst du nach dieser Anleitung:

    Sauerland


    Statt nomodeset einfach eine 3 mit Leerzeichen zum davor liegenden Text eintragen und starten.

  • Bitte nicht in ein Zitat antworten, sondern zitieren und darunter antworten.


    In den Runlevel 3 kommst du nach dieser Anleitung:

    Sauerland


    Statt nomodeset einfach eine 3 mit Leerzeichen zum davor liegenden Text eintragen und starten.

    Hallo Sauerland :)

    Nun komme ich also in den Runlevel 3.
    Das sieht bei mir so aus, dass ich nun nach einem grafischen Start (mit Grub-Auswahlmenü) schließlich in der Konsole lande mit folgendem Text:


    [ 0.004839][ C11 __common_interrupt: 1.55 No irq handler for vector
    Welcome to openSUSE Tumblewed 20230520 - Kernel 6.3.2-1-default (tty1).

    eno1:
    wlo1:

    localhost login: (blinkender cursor)

    Klar, da kann ich mich jetzt einloggen, dann aber nur noch auf der Konsole arbeiten, oder?

    Die nachstehende "3" habe ich dummerweise fest im YaST (Bootoptionen) eingetragen, und nicht nur im Grub mit "e" editiert, da ich (falsch) vermutete, dass das das Problem beheben würde)

    Doch das starten im Runlevel 3 dienst wohl nur der Fehlersuche? Wenn ja, hier noch einmal die journalctl-Abfrage:
    XXXXX@localhost:~> sudo journalctl -b -1 -p err
    [sudo] Passwort für XXXXX:
    Mai 22 23:59:43 localhost kernel: ___common_interrupt: 1.55 No irq handler for vector --> Ich meine, diese Zeile würde bei jedem Start angezeigt werden; hatte aber noch nie ein Problem verursacht ...
    Mai 22 22:00:11 localhost tlp[512]:  Error: tlp.service is not enabled, power saving will not apply on boot.

    Mai 22 22:00:11 localhost tlp[512] >>> Invoke 'systemctl enable tlp.service' to correct this!
    XXXXX@localhost:~>


    Dachte, das Problem liegt wohl an diesem tlp-Service. Habe also, wie in der dritten Fehlermeldungszeile angefordert, den tlp-Service mit 'systemctl enable tlp.service' aktiviert. Falsch gedacht!

    Das hat wohl auch nichts geholfen, denn nach einem Neustart lande ich wieder in der Konsole (vielleicht ja nicht, wenn ich ohne das Editieren mit der nachgestellten "3" starte?). Nach erneuter journalctl-Abfrage bleibt der Fehler mit dem tlp-Service bestehen und ich habe die gleichen drei Zeilen, nur mit aktuelleren Uhrzeiten.

    Übrigens habe ich Deine Antwort zuerst nicht richtig gelesen und statt der Leerzeichen und "3" anfangs "nomodeset" eingetragen.
    Interessanterweise startete der Laptop daraufhin ohne Probleme oder Grafikeinbußen. Das war auch der Grund, warum ich fälschlicherweise ganz hoffnungsvoll die "3" im YaST fest eingetragen habe. ;(

    Nach Änderung von 'nomodeset" in "3" am Ende der Zeile, wie beschrieben der Textmodus ...

    Und nun habe ich mir wohl selber ein Tor geschossen, denn ich wollte die schon im YaST fest hinterlegte Änderung mit der nachgestellten "3" in den Bootparametern wieder austragen und stelle fest, dass ich aktuell keine drei Kernel, sondern nur noch zwei i- und zwar identische - Kerneleinträge (mit den Recovery-Modes vier Einträge) habe. Alle mit dem problematischen 6.3.1-2-default. Und natürlich startet keiner der Einträge und bleibt hängen (das Problem, weswegen dieser Tread geöffnet wurde).

    Jetzt sollte ich wissen, wie ich den Booteintrag im YaST über die Konsole korrigieren kann (vorläufig am besten mit "nomodeset", denn dann startet Tumbleweed grafisch). Danke!

  • Grundsätzlich:

    Bitte nur das machen, was angefragt wird........

    Den Runlevel hatte ich nur angefragt, um zu sehen, ob es ein graphisches Problem ist, was anscheinend der Fall ist.

    PS:

    Auch im Runlevel 3 kann man Yast benutzen, einloggen mit:

    Code
    root
    root-Passwort

    danach

    Code
    yast

    Bedienung mit Pfeiltasten, Leertaste, TAB Taste usw.


    Du kannst aber auch im Grub die 3 entfernen und nomodeset eintragen, geht genau nach der obigen Anleitung......


    Dann kannst du zumindest Graphisch wieder starten und posten:

    Code
    /sbin/lspci -nnk | grep -EiA3 'vga|3d|display'
  • Hallo Sauerland!

    Erst mal vielen Dank! Ja, dass man den Yast auch in der Konsole starten kann, hatte ich glatt vergessen.
    Und bezüglich meinem "Vorpreschen": Entschuldigung! Ich gelobe Besserung. :)
    Habe also den Eintrag "3" entfernt und (vorläufig) stattdessen "nomodeset" eingetragen.

    Hier die von Dir gewünschte Konsolenabfrage:


    XXXXX@linux-2:~> /sbin/lspci -nnk | grep -EiA3 'vga|3d|display'

    00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7310] [1002:9809]

            DeviceName: AMD Radeon HD 7310 Graphics

            Subsystem: Hewlett-Packard Company Device [103c:1885]

            Kernel driver in use: radeon


    Und hier noch (falls es hilft und nicht verwirrt) der Auszug der 'inxi'-Abfrage; nur die Grafik betreffend:

    Graphics:

    Device-1: AMD Wrestler [Radeon HD 7310] driver: radeon v: kernel

    Device-2: Chicony HP Truevision HD driver: uvcvideo type: USB

    Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.1 driver: X:

    loaded: modesetting unloaded: fbdev,vesa dri: r600 gpu: radeon

    resolution: 1280x720~60Hz

    API: OpenGL v: 4.5 Mesa 23.0.3 renderer: AMD PALM (DRM 2.50.0 /

        6.3.2-1-default LLVM 16.0.2)

  • Hallo miteinander,

    scheint gerade Urlaubszeit zu sein? ;)

    Eigentlich könnte ich den Thread auf "erledigt" setzen, denn seit dem Eintrag des "nomodeset" im Grub-Editionsmenü startet das Tumbleweed ja auch mit dem neuen Kernel wieder anstandslos. Ich wäre also eigentlich schon sehr zufrieden! Danke! :)

    Doch es würde mich schon interessieren, ob das Problem meiner (und auch von Paprikate's Hardware Paprikate) mit dem Kernel 6.3.1-2-default behoben werden kann.

    Was empfehlt Ihr, wie ich weiter vorgehen soll? Thread auf "erledigt" setzen, oder nicht?

    Macht es Sinn, das Problem an die Tumbleweed-Entwickler zu melden, oder ist das vielleicht schon geschehen und ich sollte einfach mal abwarten?