On Thu, Apr 28, 2016 at 1:13 AM, James Hogarth <james.hogarth@xxxxxxxxx> wrote: > > On 28 Apr 2016 2:37 a.m., "Chris Murphy" <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> 1. >> Check these for incompatible values. The follow example is based on >> UEFI with Secure Boot enabled, so hibernation isn't possible with >> Fedora kernels. >> [root@f23s ~]# mokutil --sb-state >> SecureBoot enabled >> [root@f23s ~]# cat /sys/power/state >> freeze mem >> [root@f23s ~]# cat /sys/power/disk >> [disabled] >> >> 2. >> cat /proc/meminfo >> >> MemTotal < 0.98 * SwapFree = true >> >> So memory must be 98% or less than swap free, not swap partition size. >> >> 3. >> You're best off using UUID. It needs to be in /etc/fstab >> UUID=theuuidforswap swap swap 0 0 >> >> 4. >> In /etc/default/grub GRUB_CMDLINE_LINUX="resume=UUID=theuuidofswap" >> grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg ## for efi systems >> and just /boot/grub2/grub.cfg for BIOS >> > > Chris I'm pretty sure one of the initial things that came up with that bug > is that the systemd hibernate generator didn't work with UUID and the direct > path (via devmapper if required) was needed. No swap volume UUID definitely works in my case, it resolves it to the correct major:minor. It just fails validation for some reason. My understanding of systemd hibernate generator is it doesn't work with GPT partition type GUID for Linux swap, which is a fixed UUID, 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F. And the reason is they think it's unreliable to just assume that's where the hibernation image is, using the generic swap GUID rather than an actually unique one for the specific swap that should have the hibernation image. At least that's my understanding of the systemd list thread. They did say it would be reliable to use an attribute setting for the partition, which is part of the UEFI GPT spec. But parted doesn't support arbitrary attributes or GUIDs for that matter, so we're kinda stuck, and that solution doesn't work on MBR partition disks. Further, there's still the open question whether it's OK for the hibernation image to be on an LVM LV. If it should not be on an LVM LV, then that means a more substantial change to Anaconda to support it that results in only root fs on LVM, at which point the can of worms that's opened is, why not just drop LVM from Workstation? I think without a clear statement from Harold or the LVM folks about hibernation images on linear LVs, it's questionable whether it's really correct to add resume=/dev/mapper/fedora-swap for everyone. For all we know this causes at least as many problems, or even worse it might be silent problems that don't materialize until later on; where failure to hibernate/recover is brutal enough the user is going to quickly figure out it simply doesn't work. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: http://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
