Bug 1842279
| Summary: | Fresh Fedora 32 installation can't hibernate (when using LUKS + LVM) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | davidgf <david> |
| Component: | dracut | Assignee: | dracut-maint-list |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 32 | CC: | dracut-maint-list, dtardon, jonathan, norbert.jurkeit, taocrismon, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-04-13 08:55:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I also wondered why hibernate fails with my F32 installation and got it working thanks to above instructions (with appropriate major:minor device number of course). With F31 hibernate worked out of the box for me, probably because it was shipped initially with an earlier dracut version which used a different check in module-setup.sh Jeez. I got this as well, please fix it. I think this bug should get more visibility since it is clearly a problem. I'm not confident enough to fix it by myself but I'll try to escalate it to the right person. I filed a bug to the relevant component, but seems it is not getting any traction, can you please chime in if this affected you? Link: https://github.com/dracutdevs/dracut/issues/924 Thanks! Issue persists with Fedora33. IMHO hibernation is still a useful feature, especially for laptops on battery, and it shouldn't be too difficult to get it working. According to my experience systemctl as well as desktop environment (Xfce used here) offer the hibernate option if and only if Secure Boot is disabled and an appropriate swap device (no zram) is active. It would be reasonable if dracut used the same criteria to decide about inclusion of resume support. Did you install Fedora 33 fresh and still happens? (In reply to davidgf from comment #6) > Did you install Fedora 33 fresh and still happens? Yes, fresh install in blivet mode re-using existing logical volumes. Again I had to set /sys/power/resume to major:minor device number of the swap volume and rebuild the initramfs to make resume work. *** This bug has been marked as a duplicate of bug 1795422 *** |
Hello there! I installed a fresh fedora 32 on my laptop. It has the following devices (lsblk): NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 500M 0 part /boot/efi ├─nvme0n1p2 259:2 0 953M 0 part /boot └─nvme0n1p3 259:3 0 237.1G 0 part └─luks-8903647f-d968-453a-80df-b1043fcc026e 253:0 0 237G 0 crypt ├─fedoravol-root 253:1 0 230G 0 lvm / └─fedoravol-swap 253:2 0 7G 0 lvm [SWAP] After a successful hibernation (the logs indicate the image is written to the swap partition) the kernel cannot resume correctly. Given the logs at boot my suspicion was that: either the swap is not available at that time, or the boot process does not attempt to use it. I checked my initramfs and noticed that under "dracut modules" there's no "resume" module, but "crypt" and "lvm" are. Debugging I got to the following file: /usr/lib/dracut/modules.d/95resume/module-setup.sh Which seems to have a check() like "$(cat /sys/power/resume)" == "0:0" So I essentially realized that my /sys/power/resume file has a 0:0 content in it, meaning the kernel does not know how to resume it and dracut uses such input to determine whether the resume module should be included in it. Is this a bug? After running: echo 253:2 > /sys/power/resume dracut -f The initrd now has the resume module, and I can hibernate my laptop. I'm no expert but I question that check() is correct. If I ever boot my kernel with resume disabled that means that if I rebuild my initramfs (or upgrade the kernel via yum) the support for resume will be disabled. Is this what we really want? And how does this work during the initial install? I'm assuming there's no swap so the generation of the initramfs during a fresh install has to be somehow different right? Thanks a lot for your work!