Nach dem Update von 42.3 auf 15- Standby spinnnt

Hinweis: In dem Thema Nach dem Update von 42.3 auf 15- Standby spinnnt gibt es 39 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ich benutze gern den Suspend S3 mode, und das schon seit ewigkeiten.



    Aber der scheint nicht richtig wieder hochzukommen.




    Verhalten aus dem Standby:



    Ich sehe konsolentext für einige Sekunden. Zu schnell um das zu lesen.

    Zuerst beschwert sich Kwin, das über den Standby keine Info gekommen sei und Neu gestartet werden will



    Meine Hdds gehen nicht wieder in den Standby, die sollten eigentlich weiterschlafen.
    hdparm -S 12 /dev/sd[bcde] stellt das wieder her


    Fancontrol ist nicht aktiv, obwohl die statusabfrage was GANZ anderes behauptet. Stop und Start bringen ruhe.



    Im journal schreibt mir Qtpainter mehrere Hundert mal das gleiche.




    ich habe einen weiteren user angelegt, gleiches verhalten.




    Kalt und Warmstart:



    Standard Unser--- Es dauert lang bis der Desktop und die Systemleiste erscheint



    Test Unser ---- der Desktop ist sofort einsatzbereit.



    Qtpainter überschwämmt in beiden Fällen das log.



    Fancontrol und after.local werden korrekt ausgeführt.




    Das update habe ich nach der Anleitung im SDB eingerichtet und auf der Konsole ausgeführt.
    Danach aus dem Packmann Repo aktualisiert. Und das Nvidia repo eingebunden, nv und noveau raus und G5
    wiede istalliert.
    Kernel wird mit nomodeset acpi_enforce_resources=lax, lezteres benötigt der Fancontrol.



    mit der 42.3 version hatte ich keinen Grund die Logs zu lesen, der Standby ging hier ohne Wenn und Aber.



    'Wie kann ich das abstellen?????




    Freue mich auf Antworten und Vorschläge



    Ahoi von hier aus.

  • Das "nomodeset" willst du nicht. Entferne es.


    Du kannst auf das Laden des entsprechenden Sensor- Moduls (wie auch immer das bei dir heißen mag) verzichten und stattdessen die Werte schlicht aus /sys/class/thermal/* (mit einem homecrafted Script) lesen.

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 129623 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Der Parameter >nomodeset< macht in meinen Problemen tatsächlich keinen unterschied.


    Suspend arbeitet nicht ordentlich, und darauf kommt es mir an.


    Wie kann ich das Problem Lösen, oder so weit abschwächen das nach dem Aufwachen aus dem Suspend nicht alles Quer geht.



    Der Pfad den Du angibst, ist aus dem Sysguard bequem zu erreichen. Jedoch kann der nur das ausgeben was in den Dateien abgelegt ist. und da ist eben 0 oder 1. An oder aus.
    Tatsächliche Daten sind nur unter Harware-Sensoren / nct6776-isa-0290 zu bekommen. Ich beziehe mich hier auf den Sysguard.


    Ich habe es noch mal ausprobiert, wie sich die User verhalten beim anmelden.
    Mein Test-User ist SuSe Standard in der Gruppe user und video id 1001.


    Der geht zügig auf, aber beim herunterfahren hakt es schon sehr. kein Konsolenmodus wie gewohnt. Nur Reste vom Start zuvor. Im Journal finde ich dazu nichts.


    Mal sehen was wird.
    Für weitere Vorschläge bin ich gern zu haben



    Ahoi von hier aus

  • Der Parameter >nomodeset< macht in meinen Problemen tatsächlich keinen unterschied.

    Ich will nicht wissen, ob das einen Unterschied macht, sondern ob du das entfernt hast.
    Du brauchst das nicht und du willst das __garantiert__ nicht.

    Suspend arbeitet nicht ordentlich, und darauf kommt es mir an.


    Wie kann ich das Problem Lösen, oder so weit abschwächen das nach dem Aufwachen aus dem Suspend nicht alles Quer geht.

    Indem wir rausfinden, was da Sache ist.

    Der Pfad den Du angibst, ist aus dem Sysguard bequem zu erreichen. Jedoch kann der nur das ausgeben was in den Dateien abgelegt ist. und da ist eben 0 oder 1. An oder aus.
    Tatsächliche Daten sind nur unter Harware-Sensoren / nct6776-isa-0290 zu bekommen. Ich beziehe mich hier auf den Sysguard.

    Poste ein ls /sys/class/thermal und ein lsmod
    Was irgendein Sysgard sagt, oder nicht, interessiert nicht sonderlich.

    Ich habe es noch mal ausprobiert, wie sich die User verhalten beim anmelden.
    Mein Test-User ist SuSe Standard in der Gruppe user und video id 1001.

    Es ist keine gute Idee (wenn auch erlaubt und möglich) bei Usernamen Großbuchstaben zu verwenden.
    Wir schreiben die traditionell klein.


    Wie __genau__ hast du im Log nachgeguckt?
    Es ist wenig hilfreich, wenn du schreibst "ich finde nix". Hilfreich wäre uns das Log eingedampft auf relevante Zeilen hier zu posten.


    Das gilt generell für alle Posts hier. Nicht schreiben, "ich hab' da was gemacht",
    sondern stattdessen die Eingabe samt Ausgabe der Befehle hier zu posten.

    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 129632 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Also hier wie gewünscht:


    Wie __genau__ hast du im Log nachgeguckt?

    ich benutze das Programm Ksystemlog und in diesem Fall JournalCtl und lasse in eine txt Datei schreiben die ich dann mit Kate ansehe und auf meine weise filtern kann.


    Der einzelne Systemstart produziert dabei mehr als 100 MB an Textdaten! Das sind einige Tausend Zeilen. Und besteht in der Mehrzal aus :


    Qtpainter not aktive. Her mal ein Schnipsel davon:



    Wenn du willst, kann ich die hier hochladen, mach ich aber nur wenn Du das ausdrücklich anforderst.


    ich suche immer noch danach, warum der Standby nicht richtig wieder hochkommt und Fehler produziert.


    Also eben nicht an der Stelle weiter macht ---- Was das doch bewirken sollte.


    Ahoi von hier aus und bedanke mich höflich für deine Mühe

  • Hier wie gewünscht:



    Hoffe das hilft.


    Ahoi von hier aus

  • Also ich fasse hier noch mal zusammen.



    bis zum Dist-Upgrade ging diese Maschine einwandfrei.
    Den Beweis habe ich im Journal gefunden, das ja bekanntlich vom 1. Tag an geführt wurde.



    Logs begin at Sun 2018-01-07 14:32:58 CET, end at Sun 2019-02-24 22:29:52 CET



    Seit dem 14. Feb. 19, an dem Tag habe ich das Dist-Upgrade durchgeführt.



    Davor hatte ich Kaltstartzeiten von unter einer Minute!! Ab Grub bis zum sddm.
    Ich hatte weder den Willen noch eine Veranlassung mich mit dem Journal zu beschäftigen.




    SuSe geht einfach und macht keine Zicken.



    ich habe das unbestimmte Gefühl das einige Pakete beim Update liegengelassen worden sind.



    Her mal die Liste was ich gefunden habe:






    Mir kommt es sehr seltsam vor, das die libsensors5 nicht benutzt wird! Ohne diese bekomme ich keine Sensordaten! Also Gar keine!



    SAUERLAND gibt ja nicht umsonst hinweise darauf und macht sich die Mühe.




    Ich suche hier nach einer möglichkeit diese vermeintlich obsoleten Pakete zu überprüfen.



    Es muss doch eine Verfahrensweise existieren mit Hilfe derer ich dem Problem auf die Spur kommen kann.



    Pakete in ihrer Konfiguration zu überprüfen. Zu wissen das alle Soft und Hard Links auch ein Ziel erfüllen.




    Ahoi von hier aus.