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 upgraded. 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): gnome-power-manager-2.22.1-1.fc9.i386 How reproducible: Always 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:
This sounds like a pm-utils bug...
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.
I don't think that "dissallowing to hibernate" will be a good solution to this problem. 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.
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 pm-utils-bugreport-info.sh after you hibernated and attach the output?
Created attachment 310903 [details] Log after a failed resume from hibernate due to mis-matched default kernel
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. But: 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)
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?
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.
I wonder if this bug is present in Fedora 10, or was fixed there.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
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.
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/*.
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.
>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.
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: HOOK_BLACKLIST="01grub" Please note this hook was integrated by upstream. For distro specific removal, really good and objective args would be needed.