On 3/8/22 13:12, Ranjan Maitra wrote:
On Tue Mar08'22 11:26:12AM, Samuel Sieb wrote:
> From: Samuel Sieb <samuel(a)sieb.net>
> Date: Tue, 8 Mar 2022 11:26:12 -0800
> To: users(a)lists.fedoraproject.org
> Reply-To: Community support for Fedora users <users(a)lists.fedoraproject.org>
> Subject: Re: enabling hibernate on a new F35 installation
>
> On 3/8/22 08:38, Ranjan Maitra wrote:
>> On Wed Mar02'22 05:46:28PM, Chris Murphy wrote:
>>> From: Chris Murphy <lists(a)colorremedies.com>
>>> Date: Wed, 2 Mar 2022 17:46:28 -0700
>>> To: Community support for Fedora users <users(a)lists.fedoraproject.org>
>>> Reply-To: Community support for Fedora users
<users(a)lists.fedoraproject.org>
>>> Subject: Re: enabling hibernate on a new F35 installation
>>>
>>> On Wed, Mar 2, 2022 at 4:02 PM Samuel Sieb <samuel(a)sieb.net> wrote:
>>>>
>>>> On 3/2/22 13:56, Ranjan Maitra wrote:
>>>>> My approach to enabling hibernate on Fedora since F20 has been to
create a swap partition and then do the following:
>>>>>
>>>>> sudo vi /etc/default/grub
>>>>>
>>>>> add --> resume=UUID="****" <-- to the line
GRUB_CMDLINE_LINUX=
>>>>>
>>>>> where the uuid is obtained using blkid, and then for efi-based
systems do:
>>>>>
>>>>> sudo bash -x grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
>>>>>
>>>>> and then use:
>>>>>
>>>>> systemctl hibernate
>>>>>
>>>>> However, this approach no longer works for me. It goes down all
right, but comes back into a newly booted system.
>>>>>
>>>>> Reading up, it appears that things changed in F34, but I have been
caught napping since I have been upgrading from previous versions for a while (I guess
this was sort of grandfathered in).
>>>>>
>>>>> I tried a few things, but what do I do to get hibernate going on a
new (clean) F35 installation.
>>>>
>>>> I just tried this out in a VM. I did an install of F35 with a swap
>>>> partition and it setup everything for hibernating including the kernel
>>>> command line parameter. "systemctl hibernate" does the full
hibernating
>>>> process, but resuming doesn't work. This seems like a rather
>>>> unfortunate bug. Why set everything up so that you can hibernate, but
>>>> not resume?
>>>>
>>>> The fix is to run "dracut -a resume -f". This will update the
initramfs
>>>> to include the bits that let resume work. In order for this to continue
>>>> working with kernel updates, you need to add a dracut config file with
>>>> the module.
>>>
>>> Sounds like a dracut bug to me. It should see the resume parameter on
>>> the kernel command line and just add the resume dracut module to the
>>> initramfs without having to request it explicitly.
>>>
>>
>> How do I do this for my case?
>
> Unless you haven't upgraded the kernel since setting that parameter, it
> isn't working. You can try running "dracut -f" to regenerate the
initramfs
> and see if resume works. Otherwise, you've already filed the bug.
Btw, is this
"sudo dracut -a resume -f"
or
"sudo dracut -f"
I tried the first one, and it simply hangs. I did not think that this would take long but
perhaps I was mistaken.
It will take a while, depending on your computer. You could check top
to see what's happening. But I did mean the second one. This is to
test if dracut will automatically detect the resume option on the
command line.