hibernation should be disallowed from the desktop when the installed kernel does not match the running kernel

I think this safety check got lost in migrating to pm-utils, since it was part of powermanagement-interface. See bug 14908 (no, that's not a typo) for details of how it used to work.

Probably this needs to be ported over to pm-utils. I happened to be talking with Andy about this last week, so passing to him for further processing.

See bug 76424 for more history on this

Hmm. This sounds familiar...

This secret was in having a '/var/run/do-not-hibernate' various and having a pmi/acpi-support propagate up the lack of a hibernate via dbus/HAL to gnome-powermanager when the new kernel didn't match the booted kernel.

Fedora since have something similar (but a little more indepth IIRC) which may/may not already be included in pm-utils. If it is, it may only need grub parsing fixing.

In the original form this check simply prevented hibernate from working, this would have pretty much been silent with no user feedback given on failure. I am going to propose that for Jaunty we simply reinstate that level of fix, silently preventing hibernate. For Karmic we should probabally can use the notification systems to provide a reason to the user.

Ok here is the debdiff for Karmic to ensure we do not hibernate when there is an installed but un-booted kernel. This simply checks for the kernel flag file and inhibits the hibernate at the pm-hibernate level. This will not be reported directly, a later update for gnome-power-manager will fix that.

Here is the corresponding debdiff for Jaunty.

@main-sponsors -- looking to get sponsorship for this change to both karmic, and for sru for jaunty. debdiffs for both are includes in the preceeding comments.

This will not fix the lack of notification. That is triggered by what appears to be a bug in gnome-power-manager, and I will file a new bug with patches for that.

Filed bug #374919 to cover the lack of notification of the hibernate failure.

This bug was fixed in the package pm-utils - 1.2.5-2ubuntu3

---------------
pm-utils (1.2.5-2ubuntu3) karmic; urgency=low

  * debian/000record: add for the kernel to prevent hibernates if it has
    been upgraded. Else we will fail during resume and data may be lost.
    LP: #350491.

 -- Andy Whitcroft <email address hidden> Fri, 08 May 2009 16:50:17 +0100

Accepted pm-utils into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

The kernel is correctly generating the agreed upon flag file, therefore closing the kernel tasks invalid.

Anyone who could test the update in -proposed? It's sitting there for 4 months already.

I will remove this from -proposed soon if there is nobody interested in verifying this.

I have reproduced the behavior of allowing the user to hibernate their system after the kernel has been upgraded with the version of pm-utils in jaunty, 1.2.2.4-0ubuntu4, and can confirm that the version of pm-utils in jaunty-proposed, 1.2.2.4-0ubuntu5, does prevent hibernation from occurring, if without any explanation. I also verified that after a kernel upgrade, the version of pm-utils in jaunty-proposed continues to allow suspension to occur, and verified that hibernate and suspend continue to work when booted without an installed kernel update. (My system apparently doesn't support the suspend-hybrid option, so I could not test that it continued to function). I saw no regressions in behavior.

This bug was fixed in the package pm-utils - 1.2.2.4-0ubuntu5

---------------
pm-utils (1.2.2.4-0ubuntu5) jaunty-proposed; urgency=low

  * debian/000record: add for the kernel to prevent hibernates if it has
    been upgraded. Else we will fail during resume and data may be lost.
    LP: #350491.

 -- Andy Whitcroft <email address hidden> Fri, 08 May 2009 16:41:05 +0100

This still feels like the wrong solution. We have to have the currently running kernel available anyways, so why not just boot that on resume, and keep hibernation working? Configurations that have ubuntu hibernate on a critical battery shortage will suffer data loss right now anyways, even with the prevent-hibernation fix.

If you're going to hibernate, just fix grub's configuration so that it has to boot the correct kernel (or at least provides a warning message if the user tries to boot anything else). Everything just works right, the right kernel always loads, no data loss.

> Problem persists in intrepid. Seems to be the best of all possible options is:
> 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.

This also covers the case of hibernation being broken by a user-error of not understanding that selecting the wrong action in grub will result in data loss when there's an active hibernated session somewhere.

My comment was made quite a while ago, so a modification to work with grub2 would be required...

@Jeremy: I'd say that your proposal follows the KISS principle, which is good. However, there are many cases where people have two or more completely separated systems on their HDD. And in those cases, you don't want to prevent users to boot into another system. Especially when one system has been put on hold in order to use another one.

@Michael When a machine is hibernated, that swap partition can't be touched, or we lose everything. That can easily happen when the swap partition is used by another Linux. And http://www.faqs.org/docs/Linux-mini/Swap-Space.html describes a method to share the same swap with Windows and Linux, suggesting even booting Windows might not be reliable.

My suggestion is to treat hibernate as a suspend. Attempting to do anything other than resume the currently running kernel is a bad idea, and should be strongly cautioned against as a potential cause of data loss, especially where the machine hibernated automatically as a result of power loss.

BTW, upstream pm-utils says this is the distribution's responsibility to handle.

I'll reopen the pm-utils task. Disabling hibernate still results in data loss when the system is set up to hibernate in response to a failure in power or battery. Strictly speaking, the fix presented here solves the immediate problem, but it'll have to be undone to solve the other problem. If you really want, I'll open a separate task for it though.

@Jeremy, please open a separate bug (not a new task on this bug) for the issue with unclean shutdown when hibernation is disabled. Thank you.