openSUSE startet wieder nicht

Hinweis: In dem Thema openSUSE startet wieder nicht gibt es 55 Antworten auf 6 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Suelkun:

    Zur Info: Meine HD 7750 aus dem Jahr 2012, welche ja nur ein Jahr jünger ist als deine HD 6450,

    wird seit längerem bei jedem Kernel Update einwandfrei unterstützt. So auch dieses Mal. Zuvor

    (das letzte Mal im Dezember '21) erging es mir regelmäßig genauso wie Dir. Dann habe ich immer

    einen Bugreport auf Bugzilla geschrieben und es gesellten sich schnell weitere Betroffene dort hinzu.

    Mit solchen Hinweisen auf Fehler im System hilft man den SuSE Entwicklern und erhält i.d.R. auch recht

    schnell Rückmeldungen. Das ist das Einzige wozu ich Dir raten kann.

    Für den Inhalt des Beitrages 298385 haftet ausdrücklich der jeweilige Autor: Hidalgo

    Gefällt mir 1
    Zitat von Hidalgo

    ....Dann habe ich immer einen Bugreport auf Bugzilla geschrieben und es gesellten sich schnell weitere Betroffene dort hinzu.

    Mit solchen Hinweisen auf Fehler im System hilft man den SuSE Entwicklern und erhält i.d.R. auch recht schnell Rückmeldungen. Das ist das Einzige wozu ich Dir raten kann.

    Einen Bugreport habe ich für openSUSE noch nie geschrieben. Vielleicht sollte ich das künftig wirklich tun.

    Ob es in diesem Fall an meiner Graka liegt, weiß ich nicht. Ich kann nur beobachten, daß der Startprozess kurz nach Grub hängen bleibt.


    Nun gut, sobald openSUSE 15.4 rauskommt (und ich ein paar Tests gemacht habe, um mich davon zu überzeugen, daß alles läuft, was ich so brauche) fliegt meine Graka raus.. Ich habe einen Ryzen 5 5600G in Wartestellung. Den benutze ich momentan zu Testzwecken auf einem separaten Rechner unter openSUSE 15.4-Beta und das sieht gar nicht so schlecht aus.

    Für den Inhalt des Beitrages 298386 haftet ausdrücklich der jeweilige Autor: Suelkun

    Zitat von Alero

    Was ich auch faszinierend finde ...

    Linux-Kernel Archive: Linux 5.3.18

    Nur openSUSE Leap frickelt sich immer noch irgend etwas zurecht, um mit dem Kernel über die Runden zu kommen. Das mit mehr oder minder großem Erfolg. Somit bleiben solche Sachen wie oben angeführt natürlich nicht aus.

    Nicht openSUSE, SUSE.......


    Und da ist es egal, ob der Kernel aktiv von den Kernel-Entwicklern unterstützt wird.....

    Zitat von Alero

    Momentan stellt sich das so dar, das Tumbleweed, trotz Rolling Release, die stabile Distribution ist und Leap 15.x die Bastelbude. Faszinierend.

    Wenn man die Mailing Liste oder den bugzilla sich anschaut, ist es aber doch anders herum...............

    Für den Inhalt des Beitrages 298387 haftet ausdrücklich der jeweilige Autor: Sauerland

    Läuft auf dem Laptop:

    Code
    uname -a && lsb-release -id

Linux laptop 5.3.18-150300.59.60-default #1 SMP Fri Mar 18 18:37:08 UTC 2022 (79e1683) x86_64 x86_64 x86_64 GNU/Linux

Distributor ID: openSUSE
Description:    openSUSE Leap 15.3

    Für den Inhalt des Beitrages 298388 haftet ausdrücklich der jeweilige Autor: Sauerland

    Zitat von Suelkun

    Einen Bugreport habe ich für openSUSE noch nie geschrieben. Vielleicht sollte ich das künftig wirklich tun.

    Ob es in diesem Fall an meiner Graka liegt, weiß ich nicht. Ich kann nur beobachten, daß der Startprozess kurz nach Grub hängen bleibt.


    [snip]

    Bei einem Bugreport erwartet der jeweilige Kernel Entwickler weitere Hilfe

    durch den jeweiligen Ersteller und verlangt nach den Bootmeldungen des

    betreffenden Systems, um die Fehlermeldung verifizieren zu können.

    Diese erhält man durch die Eingabe von


    dmesg | less


    in der root-Konsole.

    (Die dmesg-Meldungen sind umfangreich, deshalb der Pipe-Zusatz less, dann

    kann man wunderbar mit der Leertaste in den Meldungen blättern).

    Ein kleines Problemchen muss man allerdings ausräumen! Die Bootmeldungen

    sind flüchtig und werden bei jedem Booten neu erstellt. Wenn der Rechner mit

    dem fehlerhaften Kernel nicht bootet, wird zwar die Protokolldatei erstellt

    aber man kommt nicht dran. Bootet man mit dem älteren funktionierenden

    Kernel, dann kommt man nur an dessen Bootmeldungen. Somit muss man

    sein Linux-System so konfigurieren, dass die vorherige Bootmeldung bestehen

    bleibt. Das geht ganz einfach, indem man durch


    vi /etc/systemd/journald.conf


    die entsprechende Konfigurationsdatei aufruft und das

    Kreuzchen vor


    #Storage=persistant


    entfernt und das Ganze dann abspeichert. Dann kommt man auch an die

    vorherigen Bootmeldungen und kann diese dann nach Bugzilla hochladen.

    Die entsprechende Datei befindet sich hier:


    /var/log/boot.log


    Man muss natürlich den entsprechenden Bootvorgang auswählen und nicht alles!


    Will man mal etwas auf die Schnelle für sich probieren und einen neuen Kernel

    zum Arbeiten bewegen, der von sich aus so nicht mit der betreffenden Grafikkarte

    zusammenarbeitet, dann kann man beim Starten unter den Boot-Optionen mal

    versuchen:


    nomodeset xforcevesa


    Wenn das System dann nämlich hochfährt kann man sicher sein, dass es tatsächlich

    die Grafikkarte ist, welche ohne die Parameter den "Black-Screen" erzeugt und kann

    i.d.R. etwas anderes ausschließen.


    Ich hoffe, ich habe hier keinen Fehler gemacht oder etwas übersehen!

    Für jede Korrektur bin ich dankbar. Da OpenSuSE Leap sich immer mehr

    an Enterprise lehnt, kann ich nicht ausschließen dass (m)ein Tipp überholt ist.

    Danke!

    Für den Inhalt des Beitrages 298389 haftet ausdrücklich der jeweilige Autor: Hidalgo

    Gefällt mir 1
    Zitat von Sauerland

    Läuft auf dem Laptop:

    Identisches Gerät wie beim TE?

    Ne, aber bei der Corona Impfung gibt es auch Komplikationen..........


    Daher stellt sich die Frage, ob an dem Gerät des TE etwas besonderes ist oder nicht?????????


    Es reicht schon ein "krummes" Hersteller-Bios.....

    Für den Inhalt des Beitrages 298391 haftet ausdrücklich der jeweilige Autor: Sauerland

    Also, erst mal der Reihe nach, ich habe gestern nicht ins Forum geschaut:

    Zitat von Sauerland

    Ne, aber bei der Corona Impfung gibt es auch Komplikationen..........

    Daher stellt sich die Frage, ob an dem Gerät des TE etwas besonderes ist oder nicht?????????

    Es reicht schon ein "krummes" Hersteller-Bios.....

    Ich gehe davon aus, daß mit "TE" ich gemeint bin:

    Es ist kein Laptop, sondern ein Desktop, den ich zusammengestellt habe:

    Mainboard Asus B550M, Prozessor Ryzen 5 3600, 32 GB memory zum Mainboard passenden Typs, 1 TB Samsung SSD 970 EVO Plus, Grafikkarte Radeon HD 6450 1GB DDR3, noch 2 über ATA angeschlossene SSDs auf denen Nutzerdaten liegen, sonst nichts. Der Rest (LAN-Schnittstelle, Sound,...) vom Mainboard.


    Reicht das?

    Zitat von Sauerland
    Code
    Läuft auf dem Laptop:
uname -a && lsb-release -id

    weiß nicht, ob ich mich klar genug ausgedrückt habe. Ich komme gar nicht so weit, daß ich ein Terminal-Fenster öffnen könnte.


    > uname -a && lsb-release -id

    Linux Mozart 5.3.18-150300.59.54-default #1 SMP Sat Mar 5 10:00:50 UTC 2022 (1d0fa95) x86_64 x86_64 x86_64 GNU/Linux

    Distributor ID: openSUSE

    Description: openSUSE Leap 15.3

    Für den Inhalt des Beitrages 298402 haftet ausdrücklich der jeweilige Autor: Suelkun

    Erst mal auf die Schnelle:


    Wenn ich diese Parameter in der Befehlszeile in Grub eingebe, dann kommt das System vmlinuz-5.3.18-150300.59.54-default hoch, Die Anmeldescreen ist zwar verzerrt, aber sie startet. Das System vmlinuz-5.3.18-150300.59.60-default kommt nicht hoch.

    Es ist auch nicht so (wie vor ein paar Monaten), das das System starten würde, nur halt mit einer black screen: Es ist so, daß das System gar nicht startet. Das mit den Boot-Meldungen muß ich ausprobieren. Das dauert ein bißchen.

    Für den Inhalt des Beitrages 298403 haftet ausdrücklich der jeweilige Autor: Suelkun

    Hast du irgendwelche Kernel Pakete (Treiber) selbst kompiliert oder irgendwelche kmps installiert?


    Code
    zypper se -si kmp
    Code
    zypper lr -d

    TE = Threadersteller

    Für den Inhalt des Beitrages 298404 haftet ausdrücklich der jeweilige Autor: Sauerland