Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451266 - Allows hibernation after a kernel update which will fail to resume
Summary: Allows hibernation after a kernel update which will fail to resume
Alias: None
Product: Fedora
Classification: Fedora
Component: pm-utils
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-13 17:09 UTC by Daniel Berrange
Modified: 2010-10-21 08:27 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-10-21 08:27:00 UTC

Attachments (Terms of Use)
Log after a failed resume from hibernate due to mis-matched default kernel (deleted)
2008-07-03 09:20 UTC, Daniel Berrange
no flags Details

Description Daniel Berrange 2008-06-13 17:09:18 UTC
Description of problem:
I did a yum update which pulled in a new kernel for a security fix. This in turn
updated the default kernel entry in grub. I later hibernated, forgetting I had

Upon booting up later, it obviously failed to resume from hibernate since the
kernel had changed. I thus lost all my open work / sessions.

The g-p-m applet should at the very least warn if the kernel has changed before
letting you hibernate. Better though would be to re-configure grub so that it'll
automatically boot the required kernel for restoring from suspend, rather than
its 'default' entry.

The same problem applies to the 'Shutdown' entry in the desktop 'System' menu,
though I'm unclear if that's g-p-m's responsibility or not.

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

How reproducible:

Steps to Reproduce:
1. yum update to a new kernel
2. Select 'hibernate' from the g-p-m applet
3. Boot up again with default kernel
Actual results:
Fails to resume from hibernate

Expected results:
Resumes successfully, or prevents me from hibernating in first place

Additional info:

Comment 1 David Zeuthen 2008-06-13 17:48:04 UTC
This sounds like a pm-utils bug...

Comment 2 JanS 2008-06-16 12:09:39 UTC
This is very severe bug.

As one could lost all work done during one session from reboot to reboot, and
this are in many cases days or even weeks.

Today when suspend works really fine there in no reason to reboot a machine for
a long time. And also currently when there are so many updates every day (tens
of them!)
Kernel updates happen also really frequently.

Sometime when you leave computer for a day, you wish to hibernate instead of
suspend. And you don't remember that you have updated kernel 3 days ago or so.

I had lost my work because of this bug more than once.

Comment 3 JanS 2008-06-16 12:14:08 UTC
I don't think that "dissallowing to hibernate" will be a good solution to this

As many users of laptops have set hibernate as an action when batery level is
critical, blacking hiberation process will destroy their work !

Grub sould have set and kernel that had been hibernated from, as default.

This is a bigger problem. It needs kernel/grub/pm-utils to be solved.

Comment 4 Till Maas 2008-06-16 13:43:37 UTC
pm-utils should already set the default kernel entry in grub to the one that is
currently running (iirc), can you please run as root
after you hibernated and attach the output?

Comment 5 Daniel Berrange 2008-07-03 09:20:08 UTC
Created attachment 310903 [details]
Log after a failed resume from hibernate due to mis-matched default kernel

Comment 6 JanS 2008-07-03 15:56:15 UTC
Recently (~month) I was not able to reproduce this bug. I am trying every kernel
update to do so (three to date).

I think its because I update kernels frequently without huge steps.
grub has default kernel entry set not correctly!
After update and going into hibernation, default kernel in Grub is the newest
kernel, not the kernel I had hibernate from. It boots from new kernel and, I
think because kernels are close and simmilar, it is able to wakes up, but with
proper older kernel (the one I had hibernated from, not the one grub chose defautly)

To check this, make:
-yum update kernel
-go into hibernation state
-do not allow grub to skip menu, and choose some different OS to boot
-on next reboot Grub will advise to boot from wrong kernel (if kernels are
close, it could succeed)

Comment 7 Till Maas 2008-07-31 20:43:08 UTC
The problem here is, that you booted a different OS between hibernation and
thaw. Currently the best way to avoid issues in this case (more than one OS), is
to install grub several time, e.g.:

once in /dev/sda with Entries:
Fedora (which boots the grub in /dev/sda1)
Other OS (which boots the bootloader in /dev/sda2)
and use the grub in /dev/sda1 as the default grub for your Fedora installation.
Then the hibernation hook should only modify the grub in /dev/sda1 in this
example and once you boot Fedora, it should boot the kernel used for
hibernation. Otherwise it looks to me like it would require some changes in grub
to handle the case when the other OS is another Fedora installation and both get
hibernated. Can you maybe test the setup with two grubs?

Comment 8 JanS 2008-07-31 21:20:58 UTC
I think it is obvious use case of hibernation, when one need to reboot to
different OS without loss of all sesion data. Also hibernation is faster then
reboot, so many people would like to use it for switching OSes.
So probably it should be working by default.

I think the easiest workaround is to issue a warning when one is booting from
different kernel that karnel used before hibernation. eg:
"Warning: you have chosen to boot kernel-2.26.2 in GRUB, but you have hiberated
from kernel-2.26.1. [F]orce kernel 2.26.2 / [C]hange to 2.26.1"

Should it be difficult to do?

Actualy in my case, I am rebooting to Windows. When I want to switch back to
Fedora, GRUB advises me worng kernel. Newer kernel starts to load hibernation
image and if kernels aren't different a lot, it manages to do so and after full
thaw I am on old kernel. But if update was bigger or I have forgotten to update
for a longer while and kernels differs considerably, it can fail.

Comment 9 JanS 2009-02-17 10:53:04 UTC
I wonder if this bug is present in Fedora 10, or was fixed there.

Comment 10 Bug Zapper 2009-06-10 01:35:35 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here:

Comment 11 Bug Zapper 2009-07-14 16:11:02 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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 12 Milan Kerslager 2009-11-26 07:40:34 UTC
The grub config file should be modified in a way that after Fedora hibernates, Grub will stil alllow to boot into the Windows (my secondary OS).

Or at least some config file should be under /etc to be able to make a change. Changes in /usr/lib64/pm-utils/sleep.d/01grub are lost after pm-utils update.

Comment 13 Jaroslav Škarvada 2010-08-02 13:42:49 UTC
I do not recommend booting other OS than the one hibernated. Please note that it is really not safe practice - you can accidentally mount the hibernated filesystem RW and you are in trouble.

AFAIK the current functionality is performed by grub --once switch that directly modifies stage2. This is Fedora's specific grub hack. Warnings or specific prompts in grub would probably require more grub hacks. I do not recommend going this way.

I think that the current pm-utils behaviour is safe and correct and the subject of this bug report is fulfilled (at least during my tests). Making the changes permanent through second OS boot is out of grub --once possibilities. This would probably require changes to initscripts and complete rewrite of 01grub. It would probably also interfere with manual modifications of grub config. If you have patch implementing such a behaviour, please post it. Otherwise I am voting for closing this as "current release" (because the subject of this bugreport is fulfilled) or "wont fix" for requests in comments - the effort needed to implement requested feature much more overweight the benefits.

BTW: You can still boot other OS (if you need to, but I do not recommended it) by hitting ESC in early stage of boot and then selecting requested OS. Also please note that custom changes to pm-utils hooks can be preserved during pm-utils upgrade by copying them to /etc/pm/*.

Comment 14 Milan Kerslager 2010-10-19 11:34:45 UTC
Your opinions are not correct. There is no need to force new kernel to be booted after update as hibernated system will be restored to its original kernel no matter what kernel will be used for booting. And yes - when the system is hibernated, the filesystem is marked as dirty. So if one knows a little bit about what mens "dirty" he will not mount it from another booted system. Or the another system simply refuses to mount dirty partition and BFU will not know how to fix it. There is no need to worry about this.

The solution presented in corrent Fedora leads only to disallow hibernate Linux and restore another system (possibly hibernated too). So please rethink this overengineered scripts.

The last thing is that forcing to boot from new kernel is completly unsafe as old kernel is proven to boot, but the new kernel is not. So with every update this system leave unexperienced user with possibility to have unbootable system.

Comment 15 Jaroslav Škarvada 2010-10-19 12:46:12 UTC
>There is no need to force new kernel to be
>booted after update as hibernated system will be restored to its original
>kernel no matter what kernel will be used for booting.
The 01grub hook is not forcing you the new kernel, it tries to resume from the same kernel as used for hibernation, that is the most safe approach. Using other kernel is not guaranteed to be safe.

>The solution presented in corrent Fedora leads only to disallow hibernate Linux
>and restore another system (possibly hibernated too). So please rethink this
>overengineered scripts.
If you are experienced user and you are aware about "dirty", you can hit ESC and boot any OS you want. Other inexperienced users will be safe with default behaviour.

>The last thing is that forcing to boot from new kernel is completly unsafe as
>old kernel is proven to boot, but the new kernel is not.
This is completely unrelated to pm-utils. If you are not happy with this behaviour, you should address this to kernel.

>So with every update this system leave unexperienced user with possibility
>to have unbootable system.
If something goes wrong there is the ESC key, thus you can easily return to old kernel. But again this is not pm-utils related.

So, what do you want to do here? Remove 01grub? That was not point of this bug report, please see comment 0.

Comment 16 Jaroslav Škarvada 2010-10-21 08:27:00 UTC
I consider the subject of this bug report to be resolved.

If you dislike the behaviour of 01grub hook, you can disable it by creating any file in /etc/pm/config.d with following content:

Please note this hook was integrated by upstream. For distro specific removal, really good and objective args would be needed.

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