Re: [arch-general] Hibernation Failure
Am 23.04.20 um 10:14 schrieb Paul Dann via arch-general: > it down to a kernel update. That being said, I don't hibernate > regularly, so maybe I've just been lucky :p Probably. I needed to read some of the code and it hasn't changed lately AFAIK. My guess is that the problem has something to do with the integrity journal. I had it disabled, but it's read on cryptsetup open anyway. After all I didn't like the (inflexible) data layout (which leads to write amplification), and the journal (and perhaps some of the code) of dm-integrity, so I've formatted all disks back to aes-xts. :-) And remember to print your backup keys on paper. BR
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
Am 12.01.20 um 12:19 schrieb Markus Schaaf via arch-general: > > > 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. I know it is terribly late, but for those curious: While investigating this I managed to make my laptop unbootable, because dm-crypt decided that every single sector on my encrypted partition had a bad AEAD tag and wouldn't let me read a single byte. That was exactly what had been happening to my swap-partition before, when I tried to resume from hibernation. But this time it had eaten my root-partition too. Of course I had backups, encrypted (of course), with a key I had changed recently ... that I knew I needed to save somewhere else, but somehow forgot to. I'm writing this on exactly that laptop, restored completely from the "unreadable" SSD. But it took me some time to read the relevant kernel code, develop and run some helpful tools to search and decrypt the data on said partition. 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. BR
Re: [arch-general] Hibernation Failure
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. 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 On Sun, Jan 12, 2020, 3:19 AM Markus Schaaf via arch-general < arch-general@archlinux.org> wrote: > > > 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 >
Re: [arch-general] Hibernation Failure
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
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
Re: [arch-general] Hibernation Failure
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption#With_suspend-to-disk_support 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 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
