Re: [arch-general] Hibernation Failure
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
Re: [arch-general] Hibernation Failure
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%: -- -0fff 0009e000-0009efff 000a-000f 4000-403f 66798000-66798fff 761f7000-7796efff 78361000-7901cfff 7920-7f7f fec0-fec00fff ff00- --- > 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
Re: [arch-general] Hibernation Failure
On Sun, 12 Jan 2020, 10:08 Justin Capella via arch-general, < arch-general@archlinux.org> wrote: > > https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption#With_suspend-to-disk_support Nope; if that was the problem then the kernel would not see the resume data at all, because the swap block device would not yet exist. As you can see from the log I posted, the kernel recognises the data and attempts to decompress it, so the issue is not so straightforward. Paul
[arch-general] Hibernation Failure
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 0x-0x0fff] PM: Marking nosave pages: [mem 0x0009e000-0x0009efff] PM: Marking nosave pages: [mem 0x000a-0x000f] PM: Marking nosave pages: [mem 0x4000-0x403f] PM: Marking nosave pages: [mem 0x66797000-0x66798fff] PM: Marking nosave pages: [mem 0x761f7000-0x791fefff] PM: Marking nosave pages: [mem 0x7920-0x] 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
