Dirk Das ist etwas, das du eigentlich nicht sehen willst.

Doch, in der Regel möchte man den beim Aufwachen wieder aktiviert sehen, wenn er beim Einschlafen abgeschaltet wurde:
[ 16.534295] OOM killer disabled.

Was man nicht sehen möchte, ist eher sowas wie

… invoked oom-killer
[…]
kernel: Out of memory: Killed process [PID] […]
systemd[1]: session-1.scope: A process of this unit has been killed by the OOM killer.

On-Topic: So Dateisystemfehler und die Sache mit dem korrupten Speicherabbild würden mich dazu bewegen, da mal sowas wie memtest86 drüberlaufen zu lassen. Wäre nicht das erste Mal, dass kaputter RAM solche Art Fehler verursacht. Über die SMART-Werte des genutzten Datenträgers würde ich in dem Zuge auch mal schauen.

  • Dirk und frankd haben auf diesen Beitrag geantwortet.

      frankd Kann ich ein swapoff und swapon im laufenden Betrieb machen?

      anders als bei laufendem system gehts eh nicht^^

      1) erst auschalten: swapoff /pfad/zum/swap
      2) dann wieder einschalten: swapon /pfad/zum/swap
      3) hibernate

      • frankd hat auf diesen Beitrag geantwortet.

          niemand Worauf ich hinaus wollte: Warum wird er überhaupt aktiv? Normal ist das nicht, oder?

          root ~ # dmesg  | grep -i oom
root ~ #

              Dirk Normal ist das nicht, oder?

              Ich interpretiere den geposteten Logschnipsel so, dass der oom-killer im Zuge des Einschlafens ordnungsgemäß beendet, und nach dem Starten wieder in Betrieb genommen wird.

              Mein System hat keinerlei Swap, sonst hätte ich selbst mal geschaut, ob das bei einem Hibernate generell so ist. Eine kurze Suche im Netz deutet jedoch darauf hin.

                Apropos Recherche: Es gibt noch diesen obskuren 8 Jahre alten Thread quasi das gleiche Beschreibt, Verschlüsselung und LVM und Hibernate geht nur manchmal.

                https://bbs.archlinux.org/viewtopic.php?id=221249

                @frankd eventuell das mal durchtesten? Vorher natürlich Backup machen, etc., gerade wegen der Module, und weil da die Reihenfolge relevant ist, und für die Verschlüsselung module an entsprechenden Stellen stehen müssen – könnte sonst in Arbeit ausarten.

                • frankd hat auf diesen Beitrag geantwortet.
                • frankd gefällt das.

                  Dirk nach einem glücklichen aufwachen:

                  tom@donar ~ # sudo dmesg | grep OOM
[ 3519.257695] OOM killer disabled.
[ 3532.364646] OOM killer enabled.

                    Ich würde, erst einmal schauen ob der Rechner aus dem Kurzschlaf korrekt aufwacht und danach erst den Tiefschlaf genauer unter die Lupe nehmen.
                    Die beiden Zustände unterscheiden sich im Grunde genommen nur dadurch, dass für den Tiefschlaf auch der RAM stromlos gemacht wird und sein Inhalt zuvor auf den permanenten Speicher auf der Swap abgelegt werden muss. Auf diese Weise hat man den Fehler schon mal eingegrenzt.

                    frankd Wenn ich das System in den Ruhezustand versetze, funktioniert das aufwachen meistens, manchmal jedoch nicht.

                    Eine einfache Ursache dafür könne eine zu klein gewählte Swap-Partiton sein.
                    Bei meinen 2GB RAM habe ich eine Swap-Partition von 8GiB angelegt.
                    Ich nutze den Swap quasie als RAM Ersatz und mit einer SSD funktioniert das auch im Gegensatz zu einer HD auch halbwegs komfortabel.

                    [matthias@leno1 ~]$ free
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:    1910396     1640804       94316      162780      504784      269592
Swap:        8388948     2871988     5516960

                    In den Anleitungen steht, man solle die Swap Partition etwas größer anlegen als den verbauten RAM-Speicher.
                    Ich hab aber wie man oben sieht, zusammen schon ca. 4.4GB im Betrieb geladen.
                    Hätte ich tatsächlich meine Swap-Partition nur mit 2GB angelegt dann könnte das mit dem Tiefschlaf niemals klappen weil im Swap dann viel zu wenig Platz für all das geladene vorhanden ist.
                    Und deshalb und weil ein paar Internetseiten im Browser mir den wenigen RAM schon alleine auffressen, habe ich die Swap-Partition mit 8GB angelegt. Und für den Tiefschlaf ist dann auch genug Platz zum Auslagern vorhanden.

                    Dass es bei dir nur manchmal nicht klappt, könnte daran liegen, dass die Summe des benutzten Speichers gelegentlich den Platz von Swap übersteigt.

                        brikler
                        Ich habe swapoff && swapon && hibernate getestet. Behebt den Fehler leider nicht.

                        tuxnix
                        Wie in Beitrag vier zu sehen, habe ich für 16GB RAM 32GB SWAP. Ich glaube also daran liegt es nicht. Trotzdem Danke für Deine Mühe.

                        frostschutz
                        Vielen Dank für den Tip. Da werde ich mich wohl etwas einlesen müssen, da ich bisher keine Ahnung habe was diese e820 Tabellen sind. Aber das sind genau die "Stupser" die ich gerade brauche, da mir die Ansatzpunkte für Websuchen ausgehen. Danke!

                        Dirk
                        Die verlinkte Beschreibung zu dem älteren Thread sieht interessant aus und wird noch getestet werden. Ich schreibe dann was dabei raus kam.

                        Bei diversen Neustarts heute, teils mit Hibernation, teils ganz normale Neustarts ist mir aufgefallen, dass es auch Fehlermeldungen bei einem ganz regulären Neustart mit der verschlüsselten root-partition gibt. Daher werde ich nun ersteinmal die komplexität reduzieren und hibernation auskonfigurieren. Wenn es dann mit dekativiertem resume hook und dektiviertem grub Kommandline Eintrag immernoch Journaling Probleme beim Start gibt, hat mein Problem vieleicht gar nichts mit dem Ruhezustand zu tun.

                        Auf jedenfall bin ich sehr dankbar für eure Zeit und Unterstützung. Es ist schon krass wieviel Unterstützung hier möglich ist, mehr als man jemals bei einem komerziellen Softwareprodukt bekommen kann. Dickes Dankeschön!

                                niemand
                                Die Test habe ich durchlaufen. Memtest ohne Fehler und SMART auch. Trotzdem Dank für den Stupser die Basics bei der Fehlersuche nicht außer Acht zu lassen.

                                  Erster Zwischenstand. Nach dem ausconfigurieren des Ruhezustandes gab es auch keine Fehler mehr bei normalen Startvorgängen, also denen nach sauberem herunterfahren.

                                  Also habe ich den resume in der mkinitcpio und und der default/grub wieder reaktiviert.

                                  Ich habe das gemacht, was in dieser alten Anleitung steht und fürs erste läuft mein System immer noch und bisher gab es auch keine Resumefehler mehr. Ich würde das nun eine Woche etwa testen, und falls alles gut läuft das Thema hier als solved markieren.

                                  • Dirk hat auf diesen Beitrag geantwortet.

                                      frankd Das Klingt doch gut! Daumen sind gedrückt!

                                        etwas OT:

                                        tuxnix Bei meinen 2GB RAM habe ich eine Swap-Partition von 8GiB angelegt.

                                        vielleicht schaust dir mal zswap an, das könnt eine gute ergänzung sein 🙂

                                        anmerkung: die kernel boot parameter funktionieren nicht mehr

                                        • tuxnix hat auf diesen Beitrag geantwortet.

                                            brikler
                                            Danke, zswap kannte ich noch gar nicht.
                                            Das kommt jetzt gleich auf meine nach unten offene TO DO Liste. 😉