https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption#With_suspend-t... On Sat, Jan 11, 2020 at 4:40 PM Paul Dann via arch-general wrote:

I'm having trouble getting hibernation to work on my new Dell Inspiron 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv), but resume fails, with the following left in the kernel logs:

--- PM: Image signature found, resuming PM: resume from hibernation Freezing user space processes ... (elapsed 0.001 seconds) done. OOM killer disabled. PM: Marking nosave pages: [mem 0x00000000-0x00000fff] PM: Marking nosave pages: [mem 0x0009e000-0x0009efff] PM: Marking nosave pages: [mem 0x000a0000-0x000fffff] PM: Marking nosave pages: [mem 0x40000000-0x403fffff] PM: Marking nosave pages: [mem 0x66797000-0x66798fff] PM: Marking nosave pages: [mem 0x761f7000-0x791fefff] PM: Marking nosave pages: [mem 0x79200000-0xffffffff] PM: Basic memory bitmaps created PM: Using 3 thread(s) for decompression PM: Loading and decompressing image data (1343374 pages)... PM: Image loading progress: 0% PM: Image loading progress: 10% PM: Image loading progress: 20% PM: Image loading progress: 30% PM: Image loading progress: 40% PM: Image loading progress: 50% PM: Image loading progress: 60% PM: Image loading progress: 70% PM: Image loading progress: 80% PM: Image loading progress: 90% PM: Invalid LZO compressed length PM: Read 5373496 kbytes in 6.35 seconds (846.21 MB/s) PM: Error -1 resuming PM: Failed to load hibernation image, recovering. PM: Basic memory bitmaps freed OOM killer enabled. Restarting tasks ... done. PM: resume from hibernation failed (-1) ---

And then the system boots fresh. An internet search revealed absolutely nothing about the "Invalid LZO compressed length", and I've no idea why the image would be corrupt. I'd appreciate any ideas.

Paul

Am 12.01.20 um 01:39 schrieb Paul Dann via arch-general:

I'm having trouble getting hibernation to work on my new Dell Inspiron 7590. It seems that the image is stored correctly (onto LUKS+LVM thin-lv),

I've noticed something similar on a similar setup. It looks like the kernel is taking some shortcuts when accessing the (swap-) space during hibernation, which are not compatible with dm-crypt. I'm using an AEAD cipher and the integrity data is wrong after resume. BR

On Sun, 12 Jan 2020 at 12:03, Justin Capella via arch-general < arch-general@archlinux.org> wrote:

Ah interesting. Do those memory regions match what is reported in proc/iomem prior to hibernating-- odd question but I recall someone on the irc encountering a difference.

Mmm that *is* interesting. The reserved sections are mostly a match, but not 100%: -- 00000000-00000fff 0009e000-0009efff 000a0000-000fffff 40000000-403fffff 66798000-66798fff 761f7000-7796efff 78361000-7901cfff 79200000-7f7fffff fec00000-fec00fff ff000000-ffffffff ---

I suggest hopping on the IRC if you're able, easier and quicker, probably not arch specific but feel free to start there or maybe the ##kernel channel

I'll give that a go; thanks. Paul

On Mon, 6 Apr 2020 at 17:37, Markus Schaaf via arch-general wrote:

What I have found: It is unlikely that hibernation is the cause to the problem I have encountered. It is just the trigger. Somehow dm-integrity or dm-crypt manages to fuck up it's on-disk meta-data. (Meanwhile the same happened to my work desktop, which had a similar setup, after suspend to RAM.) After I had determined the exact encryption algorithm and layout of my data, I was able to not only read all of it, but the on-disk integrity-tags matched 100%. Every single sector.

That's very interesting, and well done for figuring it out and saving the system. Strangely, my problem just went away: my laptop's been hibernating fine since about a week after I started the thread. I put it down to a kernel update. That being said, I don't hibernate regularly, so maybe I've just been lucky :p Paul