Forwarding from ubuntu: 1) Apply kernel update (but don't immediately reboot, as you're working) 2) have to move somewhere, hibernate laptop 3) power on laptop to restore from hibernate 4) since the hibernated image does not correspond to the current kernel version, the image will be discarded and a regular boot is done Result: All data that hasn't been saved is lost, filesystems can be corrupted and need fsck. In severity this corresponds to a hard system crash. proposed fix: boot old kernel if hibernate exists or prevent hibernation when a new kernel version has been installed.
My suggestion on ubuntu's side for dealing with this problem: 1) Whenever you hibernate, save a copy of the grub menu.lst to a backup location 2) Change menu.lst to boot the currently running kernel by default, with a label simply reading "Resume from Hibernation". 3) If possible, add a warning message to the grub menu that booting any other option will result in a loss of the hibernated state 4) On resume from hibernation, restore the backup menu.lst from step 1. In this way, no attempt to boot an incorrect kernel will be made until the user explicitly requests it, ie, as part of a manual reboot.
(In reply to comment #1) > My suggestion on ubuntu's side for dealing with this problem: > > 1) Whenever you hibernate, save a copy of the grub menu.lst to a backup > location > 2) Change menu.lst to boot the currently running kernel by default, with a > label simply reading "Resume from Hibernation". > 3) If possible, add a warning message to the grub menu that booting any other > option will result in a loss of the hibernated state > 4) On resume from hibernation, restore the backup menu.lst from step 1. > > In this way, no attempt to boot an incorrect kernel will be made until the user > explicitly requests it, ie, as part of a manual reboot. > I am running Arch and whenever there is a kernel upgrade, the menu.lst doesn't get changed. The entry is the same, but you would automatically boot the new kernel. I would suggest to make checks for installed and running kernel versions and if they do not match, simply do not allow to hibernate. This would be the safest solution upstream, because the menu.lst method may not work on some distros (like Arch) or there may not even be a menu.lst (like on Ubuntu 9.10 where the default loader is grub2, or any other distro using a loader other than grub-there are still some lilos I would guess). The should still be a configuration option to alllow for hibernation, even if the kernels do not match. If the distro developer would want to activate hibernation even after a kernel upgrade, he would have to find a solution compatible with his distro's boot system.
This is hard to fix upstream in pm-utils, since it requires interaction with the distribution's kernel package. In Ubuntu we solved that by installing /usr/lib/pm-utils/sleep.d/000record which aborts hibernation when /var/run/do-not-hibernate is set. Our kernel package's postinst creates that stamp file. I think this should be closed upstream as "NOTOURBUG".
Every distro has their own way of telling what the installed kernel is vs. what the running kernel is, tweaks to their bootloader configuration, and (depending on your architecture and/or personal preference) a variery of different bootloaders to choose from. It is up to the distributions to solve this, not pm-utils.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.