On 30 April 2016 at 02:44, Chris Murphy <lists@colorremedies.com> wrote:
On Thu, Apr 28, 2016 at 1:13 AM, James Hogarth <james.hogarth@gmail.com> wrote:
>
> On 28 Apr 2016 2:37 a.m., "Chris Murphy" <lists@colorremedies.com> 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 can we keep discussion of the bug itself to the bugzilla entry and not infiltrate a random user support thread? ;)