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.
dracut handles telling the kernel to resume from hibernate.
(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.
Maybe we should disallow hibernate, if the current running kernel is not available anymore or not the default kernel in grub.
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.
(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.
maybe the kernel should also refuse to resume from a different version!!
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.