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

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.

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.

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

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