Arch Linux

Manchmal funktioniert der Resume nach Ruhezustand nicht

frankd

Ich schlage mich nun schon eine Weile mit einem Fehler in meiner Arch installation herum, bei dem ich einfach nicht weiter komme.
Wenn ich das System in den Ruhezustand versetze, funktioniert das aufwachen meistens, manchmal jedoch nicht.

Wenn es nicht funktioniert geht führt es beim Start ein Recovering Journal erfolgreich durch und startet dann normal, ohne den letzten Zustand wiederherzustellen. Einmal kam es schon vor, dass das System gar nicht mehr starten wollte und in der Notfallkonsole im Start hängen blieb und erst ein manuellem fsck das System wieder startfähig wurde.

Zum System:
Thinkpad x230, Coreboot Bios, Samsung SSD
Verschlüsseltes System mit dm-crypt und LVM erstellt nach Anleitung aus dem Wiki

Ich freue mich wirklich über jeden Tip. Das bemühen der Suchfunktion hat mir nicht weiter geholfen, falls ich etwas übersehen habe, seht es mir nach und stupst mich in die richtige Richtung.

Hier die Fehlerausgabe aus dmseg vom heutigen Morgen:
[ 16.532829] PM: Image signature found, resuming [ 16.532854] PM: hibernation: resume from hibernation [ 16.532865] random: crng reseeded on system resumption [ 16.533159] Freezing user space processes [ 16.534283] Freezing user space processes completed (elapsed 0.001 seconds) [ 16.534295] OOM killer disabled. [ 16.534298] Freezing remaining freezable tasks [ 16.535378] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 16.535615] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff] [ 16.535623] PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff] [ 16.535630] PM: hibernation: Marking nosave pages: [mem 0x7fefa000-0xffffffff] [ 16.544929] PM: hibernation: Basic memory bitmaps created [ 16.654423] PM: Using 3 thread(s) for lzo decompression [ 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. [ 16.655549] Restarting tasks ... done. [ 16.655630] video LNXVIDEO:00: Restoring backlight state [ 16.870614] PM: hibernation: resume failed (-1) [ 17.327534] EXT4-fs error (device dm-2): ext4_orphan_get:1414: comm mount: bad orphan inode 29491511 [ 17.327544] ext4_test_bit(bit=310, block=117964816) = 0 [ 17.327633] EXT4-fs error (device dm-2): ext4_orphan_get:1414: comm mount: bad orphan inode 35410389 [ 17.327637] ext4_test_bit(bit=4564, block=141557778) = 0 [ 17.327747] EXT4-fs error (device dm-2): ext4_orphan_get:1414: comm mount: bad orphan inode 35417627 [ 17.327751] ext4_test_bit(bit=3610, block=141557779) = 0 [ 17.327873] EXT4-fs error (device dm-2): ext4_orphan_get:1414: comm mount: bad orphan inode 29500245 [ 17.327876] ext4_test_bit(bit=852, block=117964817) = 0 [ 17.328192] EXT4-fs (dm-2): recovery complete [ 17.333669] EXT4-fs (dm-2): mounted filesystem d2d01a14-6d59-4610-bf3f-414586acd393 r/w with ordered data mode. Quota mode: none.

tuxnix

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

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)

Dirk

[ 16.655547] OOM killer enabled.

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

frankd

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

niemand

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.

brikler

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

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.

frostschutz

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

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!

Dirk

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

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

frankd

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.

niemand

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.

brikler

Dirk nach einem glücklichen aufwachen:

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

Dirk

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

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.

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

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.

brikler

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

Dirk

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

tuxnix

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

Nächste Seite »