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.
Many thanks and best wishes, Ranjan
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.
Check the logs both for the shutdown and for the bootup to see what's happening. You might find the reason there. Do you have secure boot enabled? I thought hibernation was disabled in that case.
On Wed Mar02'22 02:08:13PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Wed, 2 Mar 2022 14:08:13 -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/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.
Check the logs both for the shutdown and for the bootup to see what's happening. You might find the reason there. Do you have secure boot enabled? I thought hibernation was disabled in that case.
Sorry, I have secure boot disabled. So, hibernate should work out of the box now? I must have misread what I was reading about hibernation and F34+. I read that ZDRAM or whatever makes it have different hoops to jump.
OK, I will check the logs to see if I can find anything, thanks!
Best wishes, Ranjan
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.
There appears to be a systemd hibernate resume generator, but it doesn't seem to be working. Maybe that is what was supposed to handle the resume, but it doesn't.
zram and zswap don't make any difference, other than a swap partition is not necessarily created now for an install. Hibernation will use the physical swap partition that has enough space.
Thanks for this!
On Wed Mar02'22 03:01:44PM, Samuel Sieb wrote:
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?
Yes, I had this same experience and thought. Where should a bug report be filed in this case? Funny if no one else has reported this yet.
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.
How do I add a dracut config file?
There appears to be a systemd hibernate resume generator, but it doesn't seem to be working. Maybe that is what was supposed to handle the resume, but it doesn't.
zram and zswap don't make any difference, other than a swap partition is not necessarily created now for an install. Hibernation will use the physical swap partition that has enough space.
I see, thanks!
Best wishes, Ranjan
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.
On 3/2/22 16:46, Chris Murphy wrote:
On Wed, Mar 2, 2022 at 4:02 PM Samuel Sieb samuel@sieb.net wrote:
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.
Maybe that would work on a subsequent kernel install, but I didn't think to try that. It just wasn't there for the initial OS install and I also didn't try regenerating the initramfs without adding the module.
On Wed Mar02'22 05:08:28PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Wed, 2 Mar 2022 17:08:28 -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/2/22 16:46, Chris Murphy wrote:
On Wed, Mar 2, 2022 at 4:02 PM Samuel Sieb samuel@sieb.net wrote:
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.
Maybe that would work on a subsequent kernel install, but I didn't think to try that. It just wasn't there for the initial OS install and I also didn't try regenerating the initramfs without adding the module.
Interesting, looks like a similar issue may also have showed up in Fedora 28 earlier:
https://bugzilla.redhat.com/show_bug.cgi?id=1206936
Ranjan
On Wed Mar02'22 05:08:28PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Wed, 2 Mar 2022 17:08:28 -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/2/22 16:46, Chris Murphy wrote:
On Wed, Mar 2, 2022 at 4:02 PM Samuel Sieb samuel@sieb.net wrote:
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.
Maybe that would work on a subsequent kernel install, but I didn't think to try that. It just wasn't there for the initial OS install and I also didn't try regenerating the initramfs without adding the module. _______________________________________________
Filed the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2060501
I wonder if it should also be filed under anaconda?
Thanks, Ranjan
On Thu Mar03'22 04:18:52PM, Ranjan Maitra wrote:
From: Ranjan Maitra mlmaitra@gmx.com Date: Thu, 3 Mar 2022 16:18:52 -0600 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 Mar02'22 05:08:28PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Wed, 2 Mar 2022 17:08:28 -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/2/22 16:46, Chris Murphy wrote:
On Wed, Mar 2, 2022 at 4:02 PM Samuel Sieb samuel@sieb.net wrote:
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.
Maybe that would work on a subsequent kernel install, but I didn't think to try that. It just wasn't there for the initial OS install and I also didn't try regenerating the initramfs without adding the module. _______________________________________________
Filed the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2060501
I wonder if it should also be filed under anaconda?
Is it possible to file also under anaconda, or would that be a separate bug report?
Thanks, Ranjan
On 3/4/22 09:52, Ranjan Maitra wrote:
On Thu Mar03'22 04:18:52PM, Ranjan Maitra wrote:
From: Ranjan Maitra mlmaitra@gmx.com Filed the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2060501
I wonder if it should also be filed under anaconda?
Is it possible to file also under anaconda, or would that be a separate bug report?
I don't think it's an anaconda issue. See what happens where it is.
On Fri Mar04'22 10:53:00AM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Fri, 4 Mar 2022 10:53:00 -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/4/22 09:52, Ranjan Maitra wrote:
On Thu Mar03'22 04:18:52PM, Ranjan Maitra wrote:
From: Ranjan Maitra mlmaitra@gmx.com Filed the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=2060501
I wonder if it should also be filed under anaconda?
Is it possible to file also under anaconda, or would that be a separate bug report?
I don't think it's an anaconda issue. See what happens where it is.
Thanks, it has not been picked up yet. The reason I wondered if it was anaconda was because it only happened with new installs, and also because a similar bug in F28 was filed under anaconda.
https://bugzilla.redhat.com/show_bug.cgi?id=1206936
Best wishes, Ranjan
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?
Many thanks and best wishes, Ranjan
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.
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.
Thank you. I will try this.
I did file the bug a week ago, but it has not been picked up yet. I guess I could write a script which would run dracut -f if the kernel gets upgraded (till such time as the bug gets taken care of, if it does).
Best wishes, Ranjan
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.
Thanks, Ranjan
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.
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
-
Chris Murphy -
Ranjan Maitra -
Samuel Sieb