Bug 843014 - RFE: the kernel used during hibernating should be marked and used when resuming
Summary: RFE: the kernel used during hibernating should be marked and used when resuming
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-07-25 10:17 UTC by hramrach
Modified: 2019-03-15 06:39 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2019-03-15 06:39:11 UTC

Attachments (Terms of Use)

Description hramrach 2012-07-25 10:17:29 UTC
Description of problem:

when kernel is updated the old kernel is not kept around so that it can be used to resume the system.

Version-Release number of selected component (if applicable):

fedora 17

How reproducible:

whenever new kernel is released

Steps to Reproduce:
1. yum update
2. pm-hibernate
3. power on
Actual results:

system fails to resume and boots normally thrashing any data that was present in running processes

Expected results:

system resumes as normal

Additional info:

this would require that the old kernel is kept around and it is made the default choice in grub on suspend.

It seems that I have old kernels still installed so the problem is only in booting the correct kernel.

Also the boot process could be more conservative when resume fails so that the old kernel can be selected manually.

Comment 1 Bill Nottingham 2012-07-25 20:04:46 UTC
dracut handles telling the kernel to resume from hibernate.

Comment 2 Harald Hoyer 2012-07-26 07:30:24 UTC
(In reply to comment #1)
> dracut handles telling the kernel to resume from hibernate.

err.. Bill, how can dracut know, that it has a different kernel than the one, which was used to resume?

Also dracut cannot influence grub. This has to be done in another component.

Comment 3 Harald Hoyer 2012-07-26 07:31:54 UTC
Maybe we should disallow hibernate, if the current running kernel is not available anymore or not the default kernel in grub.

Comment 4 hramrach 2012-07-26 07:35:09 UTC
dracut does tell the kernel to resume but the resume fails because the kernel version is not compatible. I am not sure if it can tell the reason for which resume failed.

Comment 5 Harald Hoyer 2012-07-26 07:37:53 UTC
(In reply to comment #0)
> Description of problem:
> when kernel is updated the old kernel is not kept around so that it can be
> used to resume the system.

Btw, a normal "yum update" preserves the current running kernel.

Comment 6 Harald Hoyer 2012-07-26 07:38:40 UTC
maybe the kernel should also refuse to resume from a different version!!

Comment 7 hramrach 2012-07-26 07:43:49 UTC
yum update either installs a new revision of the running kernel or installs an additional newer kernel (which is then the default)

kernel performs some internal check when asked to resume to determine the compatibility of the current kernel (the one running dracut) with the saved image and refuses to resume if it finds the image incompatible

When that happens is a mystery. Sometimes a different kernel version would resume just fine, sometimes just a package revision number bump causes incompatibility.

Comment 8 Harald Hoyer 2012-07-26 08:15:47 UTC
We should prohibit hibernate after a "yum update" or "rpm" operation. For this to work, systemd has to have a mechanism to let something inhibit the hibernate.

Comment 9 hramrach 2012-07-26 08:51:45 UTC
That should probably happen only if the operation involved a kernel.

Updating some random libraries has no effect on the ability to resume the system and is quite common case. Otherwise updates are rendered very impractical.

Also I am not sure how systemd is involved here. Does pm-hibernate call into systemd to perform the suspend to disk?

There is a systemd hibernate target but it is not quite obvious if/when it is reached.

Comment 10 Bill Nottingham 2012-07-26 16:26:24 UTC
I suspect the right thing to do is to have pm-hibernate modify the boot loader to explicitly do a one-time selection of the current kernel, even if it's not the default.

Comment 11 Fedora End Of Life 2013-07-04 06:32:45 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Adam Pribyl 2013-07-11 11:45:35 UTC
In my opinion, yum never uninstalls the running kernel, therefore any update can not break it. I regulary start from grub a different kernel than the one that is hibernated and so far it works.

Comment 13 hramrach 2013-07-11 18:39:32 UTC
It works until it breaks.

AFAICT there is no guarantee that a kernel is able to resuma the suspend image of an earlier kernel. It just hapens to work most of the time.

The running kernel is overwritten when the update is a package revision rather than a new package. Even when it is kept around the new kernel is the default.

why is this resolved as notabug?

Is that by design that Fedora trashes your data when you suspend?

Comment 14 Fedora End Of Life 2013-08-01 18:08:00 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 15 Zbigniew Jędrzejewski-Szmek 2013-12-23 04:45:46 UTC
Actually this is not tied to new kernels being installed. If we hibernate, we should get the same kernel by default when resuming. This is probably too much for grub, but maybe gummiboot could support this.

Comment 16 Zbigniew Jędrzejewski-Szmek 2019-03-15 06:39:11 UTC
We went through an attempt to disallow hibernation in the previous Fedora cycle, and it way causing way more problems then it was solving. So that at least is certainly not the way to go.

The kernel explicitly supports resuming into a different kernel after hibernation. And it seems to generally just work. So let's resolve this by saying that this is supported by the kernel, and should work, and if the resume fails, then this is a kernel bug.

Note You need to log in before you can comment on or make changes to this bug.