On Tue Mar08'22 02:04:50PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Tue, 8 Mar 2022 14:04:50 -0800 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: enabling hibernate on a new F35 installation
On 3/8/22 13:12, Ranjan Maitra wrote:
On Tue Mar08'22 11:26:12AM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Tue, 8 Mar 2022 11:26:12 -0800 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@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@colorremedies.com Date: Wed, 2 Mar 2022 17:46:28 -0700 To: Community support for Fedora users users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: enabling hibernate on a new F35 installation
On Wed, Mar 2, 2022 at 4:02 PM Samuel Sieb samuel@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.
Thank you for this. However, the prompt did eventually come back when I tried the first command, and then I hibernate and it works. Well, I guess till the next kernel upgrade.
Thanks again! I will update the bug report with the additional information.
Best wishes, Ranjan