|
Bugzilla – Full Text Bug Listing |
| Summary: | Problem with full disk encryption and hibernation | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Carlos Robinson <carlos.e.r> |
| Component: | Bootloader | Assignee: | Bootloader Maintainers <bootloader-maintainers> |
| Status: | NEW --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | antonio.feijoo, mchang |
| Version: | Leap 15.5 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
dmesg output on resume
journal of "before" session journal of "after" session |
||
|
Description
Carlos Robinson
2023-08-31 21:55:25 UTC
Created attachment 869189 [details]
dmesg output on resume
dmesg output on resume, which is actually a boot.
Created attachment 869190 [details]
journal of "before" session
journal of "before" session
It is the journal of the session where I issue the "systemctl hibernate" command as root.
Created attachment 869191 [details]
journal of "after" session
journal of "after" session
It is the journal of the session where it should restore from hibernation, but instead it boots fresh.
I think you are experiencing this issue: https://github.com/dracutdevs/dracut/issues/2128 dracut ignores the `x-initrd.attach` option in /etc/crypttab, but it understands it's own `force` option. (In reply to Carlos Robinson from comment #0) > +++··································· > dracut explicitly skips /etc/crypttab entries with valid third field (which > refers to the existing key file on disk). There is no explanation, why. So, > dracut does not find any swap device and skips "resume" module. > > Why it does it for swaps only I do not know. Otherwise it is happy to > actually unlock this device in initrd. > > So yes, it does sound like a bug. It should either completely skip this > device or fully configure it. > > -------------- > > dracut ignores swap on LUKS device with key file as resume device but > has no problems adding the same LUKS device if it has x-initrd.mount > option. This is inconsistent. > ···································++- The other specific issue of dracut skipping encrypted swaps with password files: https://github.com/dracutdevs/dracut/issues/2425 I'd suggest to force the addition of the `resume` module in this case via `add_dracutmodules+=" resume "`. It worked! Thanks. I'll add that information to the wiki. [...] Well, no, now there is a new problem: I get the prompt from grub for the password, goes through the motions to restore, but at some point, it powers off instead! I have to press the power button, enter the password a second time, and now it fully restores. I'm not sure it happens every time, but for sure happened twice. Nothing is displayed on the screen, and nothing can be in the logs, system is not "running" while this is going on. (In reply to Carlos Robinson from comment #6) > It worked! Thanks. > > I'll add that information to the wiki. > > [...] > > Well, no, now there is a new problem: > > I get the prompt from grub for the password, goes through the motions to > restore, but at some point, it powers off instead! > > I have to press the power button, enter the password a second time, and now > it fully restores. > > I'm not sure it happens every time, but for sure happened twice. > > Nothing is displayed on the screen, and nothing can be in the logs, system > is not "running" while this is going on. Does the system power off before or after displaying the GRUB menu? If the answer is after, check if your the kernel command line of the boot option contains `quiet` or `plymouth=whatever` and remove them. BTW, I don't think you need to mark with `x-initrd.mount` the encrypted partitions in /etc/fstab only to make resume from hibernation work (I don't know if you have other use case that needs these partitions mounted in the initrd). (In reply to Antonio Feijoo from comment #7) > (In reply to Carlos Robinson from comment #6) It happens, apparently, before the grub menu. However, it has only happened those two times, so I haven't been able to investigate more. Yes, I already did those things and I'm booting in verbose mode since I wrote the previous comment. So I'm happy that it works, but no idea why that error happened or if will repeat. > BTW, I don't think you need to mark with `x-initrd.mount` the encrypted > partitions in /etc/fstab only to make resume from hibernation work (I don't > know if you have other use case that needs these partitions mounted in the > initrd). Unless I write those options to fstab and crypttab, all the lines in crypttab and not written to the initrd archive, and thus, they are not decrypted using the key file, but instead the system asks me to type the password _again_. Once by grub, once by systemd. That's the problem, that some logic in dracut decides what lines to copy and which not, and does the decision wrongly. You can follow the problem tracking and why each option was added and the testing in the mail list thread I linked. (In reply to Carlos Robinson from comment #8) > (In reply to Antonio Feijoo from comment #7) > > (In reply to Carlos Robinson from comment #6) > > It happens, apparently, before the grub menu. > However, it has only happened those two times, so I haven't been able to > investigate more. Yes, I already did those things and I'm booting in verbose > mode since I wrote the previous comment. > > So I'm happy that it works, but no idea why that error happened or if will > repeat. Based on this, re-assigning to @bootloader-maintainers to check this remaining issue. See comment #6. > > BTW, I don't think you need to mark with `x-initrd.mount` the encrypted > > partitions in /etc/fstab only to make resume from hibernation work (I don't > > know if you have other use case that needs these partitions mounted in the > > initrd). > > Unless I write those options to fstab and crypttab, all the lines in > crypttab and not written to the initrd archive, and thus, they are not > decrypted using the key file, but instead the system asks me to type the > password _again_. Once by grub, once by systemd. > > That's the problem, that some logic in dracut decides what lines to copy and > which not, and does the decision wrongly. > > You can follow the problem tracking and why each option was added and the > testing in the mail list thread I linked. Yes, I followed that. If you want to ensure that a crypttab entry is added to the initrd crypttab, you just need to add the `force` option in the 4th column. (In reply to Carlos Robinson from comment #8) > (In reply to Antonio Feijoo from comment #7) > > (In reply to Carlos Robinson from comment #6) > > It happens, apparently, before the grub menu. > However, it has only happened those two times, so I haven't been able to > investigate more. Yes, I already did those things and I'm booting in verbose > mode since I wrote the previous comment. > > So I'm happy that it works, but no idea why that error happened or if will > repeat. Could the CPU overheats in the course of running PBKDF iteration ? The process costs a lot to grub in terms of CPU resource consumption because no CPU hardware acceleration (SSE/AVX and so on) enabled in the pre-boot environment to make the cryoto related calculations efficient, especially the hash algorithms that is heavily used by the KDF. If the cooling system is also somehow not in a good condition to process the heat, as a safe measure the CPU may power itself off. If it is the case, either to improve the cooling system by cleaning it's fan and outlet, or you can try to reduce the PBKDF iteration count which would also shorten the time in grub to unlock the volume, as an exchange that your password might be easier to crack. You can follow the link to do that: [1] https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Speeding_up_LUKS_decryption_in_GRUB Thanks. |