Beiträge von Welm

    ...obwohl keine Programme (Office, Firefox, ...) geöffnet waren...

    Ein mögliches Problem könntest Du schonmal ausschließen:

    Programme, die beim Ausloggen liefen, werden z.B. vom KDE automatisch beim nächsten Einloggen wieder gestartet. Wenn die aus irgendwelchen Gründen kein Fenster haben, können sich Dutzende von denen ansammeln und unbemerkt laufen. Im KDE kann man das Nachstarten unter "Systemeinstellungen" -> "Arbeitsbereich" -> "Starten und Beenden" -> "Arbeitsflächensitzung": "Mit leerer Sitzung starten" abschalten. Wenn's beim nächsten Einloggen besser ist, dann war es das.

    Das dort genannte plasma-pk-update gibt es bei mir in keinem Repository.

    Such nach "plasma5-pk-updates".


    ...ist da Leap besser...

    Ich habe keine dicken Probleme mit den halbautomatischen Updates in Leap 15.5. Ich kann aber nicht mit Tumbleweed vergleichen -- hab ich nicht. Wenn mal ein Problem gemeldet wird und nicht am nächsten Tag weg ist, dann nehme ich den Online-Update im Yast, da dort Meldungen und Maßnahmen wesentlich besser angezeigt werden.

    (dabei bin ich schon seit Diskettenzeiten mit Suse unterwegs ,,,,)

    Willkommen im Club. :) Mein erstes Suse war "SuSE April 95" (damals gabs keine Nummern)

    Die Maus wird also vom System wohl nur als "irgendeine Maus" erkannt.


    Das liegt vermutlich daran, dass der USB-Stick nicht extra für diese Maus ist wie meinen Logitech-Mäusen sondern nach dem "Logitech Unifying"-System arbeitet. Der USB-Stick ist dabei für mehrere Logitech-Geräte gleichzeitig zuständig, die ganz unterschiedlich sein können. Ich weiß, dass es da Probleme in Linux gab und keine Unterstützung von Logitech. Es gab auch zusätzliche Pakete zur Konfiguration des USB-Sticks. Aber ich kenne mich damit und mit dem aktuellen Stand der Dinge nicht aus.

    Falls Du doch noch weiter machen willst probier mal

    Code
    xev|grep button

    Betätigt man mit der Maus im aufgetauchten Fenster z.B. nacheinander linke, mittlere, rechte Maustaste und dann Vorwärts- und Rückwärtsscrollen sollte sowas wie hier erscheinen:

    Code
        state 0x10, button 1, same_screen YES
        state 0x110, button 1, same_screen YES
        state 0x10, button 2, same_screen YES
        state 0x210, button 2, same_screen YES
        state 0x10, button 3, same_screen YES
        state 0x410, button 3, same_screen YES
        state 0x10, button 4, same_screen YES
        state 0x810, button 4, same_screen YES
        state 0x10, button 5, same_screen YES
        state 0x1010, button 5, same_screen YES

    Man sieht dabei grob gesagt die Dinge am Eingang der graphischen Oberfläche. Wenn das Scrollen da schon nicht auftaucht, dann steckt das Problem wohl tiefer im System und nicht in der Konfiguration von X, KDE, ...

    Gibt es BIOS Updates für dein Board?

    Für das PRIME A520M-K gibt es ein BIOS vom 29.9.2023 (Ver. 3402).


    Das ASUS-Board A520M-K hat m.W. das EZ-Flash-3 im BIOS. D.h. das BIOS kann den BIOS-Update selbst machen -- es wird kein Betriebssystem benötigt oder benutzt. Man bringt das ausgepackte zip auf einen USB-Stick, steckt ihn in den extra dafür vorgesehenen USB-Anschluss und kann im BIOS den Update machen. Evtl. muss man hinterher ein paar andere Einstellungen wieder auf den alten Wert setzen. Bei mir war es Sprache und SVM-Modus(=Virtualisierung). Fotos der alten Einstellungen sind da hilfreich...

    Bei mir läuft ein 15.5 mit 5600G und Defaultkernel.


    Im Detail:

    Code
    PRETTY_NAME="openSUSE Leap 15.5"
    model name      : AMD Ryzen 5 5600G with Radeon Graphics
    Linux macbeth 5.14.21-150500.55.31-default #1 SMP PREEMPT_DYNAMIC Wed Oct 4 16:52:05 UTC 2023 (5dc23e0) x86_64 x86_64 x86_64 GNU/Linux

    Ist meines Wissens OK.


    Einige Programme werden früh beim Booten gebraucht - noch bevor das System an die Platte kommt. "dracut" kopiert diese Programme deshalb vorher ins initramfs.


    "dracut" hat aber nur eine Liste von zu erledigenden Themen. Die geht er durch und wenn es ein Script mit dem Themennamen gibt, dann wird es aufgerufen und macht die Arbeit. Es ist aber normal, dass viele dieser Scripte bei der Distri oder bei der Hardware oder bei der Systemkonfiguration gar nicht gebraucht werden und deshalb fehlen. Der Vollständigkeit halber schreit dracut dann im Log "beim Thema xy war nichts zu tun".

    Vermutlich beseitigt der gestern rausgekommene Kernel das Problem.


    Ich hatte mit einem HP-AMD-Laptop auch Bootabstürze mit dem Kernel 5.14.21-150500.55.7. Direkt nach kurzer Anzeige des graphischen Loginbildschirms wurde der Bildschirm schwarz und nichts ging mehr. Der Vorgängerkernel lief. Kopieren des amdgpu-Kernelmoduls in den kaputten Kernel beseitigte das Problem. Es lag also wohl am amdgpu-Modul. Der gestern reingekommene neue Kernel 5.14.21-150500.55.12 mit neuem amdgpu-Modul geht einwandfrei. (vgl. https://bugzilla.opensuse.org/show_bug.cgi?id=1213569)



    Nach 3 Tagen, Softwareaktualisieren war der 150400 verschwunden und es ging nichts mehr.

    ...

    Nun habe ich Sorge, dass bei der nächsten Aktualisierung wieder nichts geht.

    In solchen Fällen kannst Du eingreifen und beim Hochfahren einen funktionierenden Kernel behalten. Das automatische Löschen von Kernels wird durch Einträge in /etc/zypp/zypp.conf gesteuert. Da gibt es eine Zeile

    multiversion.kernels=latest,latest-1,running

    Es werden also gewöhnlich zwei Kernels zum Booten bereitgestellt: der neueste und der davor. Der "running" ist ja meist einer der beiden.


    In dieser Zeile kannst Du weitere Kernels eintragen, die Du nicht verlieren willst. Z.B.

    multiversion.kernels=latest,latest-1,running,oldest

    (oder z.B. "latest-2")


    Gewöhnlich ist in /boot genug Platz für ein paar weitere Kernels ... aber wenn /boot in einer eigenen Partition liegt sollte man lieber erstmal nachprüfen ...

    Ich bin mir nicht sicher, ob die Interpretation von "Energy-Full" hier so ganz richtig ist. Ich hab mal gelesen, dass der Wert nur bei einer Veränderung von "Voll" auf "Leer" ohne zwischenzeitliches Laden geändert wird ... denn dann hat man die dafür nötigen Daten.


    In dem Fall wäre es sinnvoll, ein- oder zweimal im Jahr ganz voll zu laden und danach bis zum automatischen Abschalten zu entladen. Erst das würde wieder zu realistischen "energy-full"- und Prozentzahlen führen.