On 30 April 2016 at 02:44, Chris Murphy <li...@colorremedies.com> wrote:
> On Thu, Apr 28, 2016 at 1:13 AM, James Hogarth <james.hoga...@gmail.com> > wrote: > > > > On 28 Apr 2016 2:37 a.m., "Chris Murphy" <li...@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? ;)
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: http://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org 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
