ich nehme mal an, daß dies der grund für dein problem ist:

[   16.654431] PM: Loading and decompressing image data (1389438 pages)...
 [   16.654436] Hibernate inconsistent memory map detected!
[ 16.654437] PM: hibernation: Image mismatch: architecture specific data
[ 16.654439] PM: hibernation: Read 5557752 kbytes in 0.01 seconds (555775.20 MB/s)
[ 16.655282] PM: Error -1 resuming
[ 16.655286] PM: hibernation: Failed to load image, recovering.
[ 16.655477] PM: hibernation: Basic memory bitmaps freed
[ 16.655547] OOM killer enabled.

ein gedanke: swap beobachten, wenn dus system aufweckst, bleibt jedes mal was im swap zurück, das könnte mal zu viel sein, wenn das zuträfe, wäre ein neustart, bzw swapoff+swapon die lösung

  • frankd hat auf diesen Beitrag geantwortet.
    [ 16.655547] OOM killer enabled.

    Das ist etwas, das du eigentlich nicht sehen willst. Wie viel RAM hast du? Wie groß ist dein Swap?

      Dirk

      MiB Spch: 15949,7 total, 419,9 free, 3604,4 used, 13116,2 buff/cache
      MiB Swap: 32768,0 total, 31908,9 free, 859,1 used. 12345,4 avail Spch

        brikler
        Kann ich ein swapoff und swapon im laufenden Betrieb machen? Dann wäre das vielleicht eine Idee meinem System bei zu bringen, das nach einem Resume zu machen. (Auch wenn ich noch keine Ahnung habe wie ich das anstelle)

        • brikler hat auf diesen Beitrag geantwortet.

            Vielleicht bin ich aber auch total auf dem Holzweg. Beim Durchstöbern meiner Logfiles ist mir aufgefallen, dass es scheinbar bei jedem Systemstart Probleme mit der verschlüsselten root Partition gibt.

            ------------ Sun Dec 29 10:16:53 CET 2024 ------------
            /dev/mapper/main-root: recovering journal
            /dev/mapper/main-root contains a file system with errors, check forced.
            Inode 46007984 extent tree (at level 1) could be narrower. IGNORED.
            /dev/mapper/main-root: Orphan file (inode 12) block 13 is not clean.
            CLEARED.
            /dev/mapper/main-root: 632546/60350464 files (0.8% non-contiguous), 132898286/241395712 blocks

            ------------ Sun Dec 29 07:00:29 CET 2024 ------------
            /dev/mapper/main-root: recovering journal
            /dev/mapper/main-root: Clearing orphaned inode 29491511 (uid=1000, gid=984, mode=0100644, size=16875624)
            /dev/mapper/main-root: Clearing orphaned inode 35410389 (uid=0, gid=0, mode=0100644, size=170748)
            /dev/mapper/main-root: Clearing orphaned inode 35417627 (uid=0, gid=0, mode=0100644, size=11328)
            /dev/mapper/main-root: Clearing orphaned inode 29500245 (uid=1000, gid=984, mode=0100644, size=544727)
            /dev/mapper/main-root: clean, 630528/60350464 files, 132134723/241395712 blocks

            ------------ Fri Dec 27 17:50:56 CET 2024 ------------
            /dev/mapper/main-root: recovering journal
            /dev/mapper/main-root contains a file system with errors, check forced.
            Deleted inode 29491291 has zero dtime. FIXED.
            Inode 46007984 extent tree (at level 1) could be narrower. IGNORED.
            /dev/mapper/main-root: Orphan file (inode 12) block 0 is not clean.
            CLEARED.
            /dev/mapper/main-root: 628932/60350464 files (0.8% non-contiguous), 132130111/241395712 blocks

            Leider reichen meine Linuxkenntnisse nicht aus, um auch nur eine Idee zu haben, wonach ich nun im Netz suchen kann, um eine Lösung zu finden.

            Bei "Hibernate inconsistent memory map detected!" geht es um die e820 Tabelle.

                    if (rdr->e820_checksum != compute_e820_crc32(e820_table_firmware)) {
                pr_crit("Hibernate inconsistent memory map detected!\n");
                return -ENODEV;
        }

            Hierbei wird nur die Prüfsumme verglichen. Daher bleibt die Fehlermeldung den konkreten Unterschied schuldig. Vielleicht in deinen diversen Bootlogs mal ein Blick auf die e820 Meldungen werfen, ob hier Abweichungen auffällig sind.

            Wenn du Pech hast, macht dein BIOS irgendwas komisches, was dem Linux Kernel nicht gefällt. (Oder du hast manuell im Bios was geändert oder Geräte hinzugefügt/entfernt?)

            Generell ist Hibernate leider eine sehr wackelige Geschichte. Und jedesmal wenn es schief geht, setzt man sein Dateisystem aufs Spiel. Ich verzichte darauf komplett...

            • frankd hat auf diesen Beitrag geantwortet.

              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. 😉