use 'do-not-hibernate' NOT 'do-not-suspend' to prevent hibernate following kernel upgrade

The system should refuse to hibernate in this case, though it's somewhat tricky
to do that robustly.

However, kernel upgrades are not (nor have they ever been) automatic; no
packages are upgraded except when the user explicitly requests it.

Matthew, Thom: is there anything quick, dirty and safe we can do to catch the
most common cases for Hoary?

I can't think of one that isn't (at least) moderately fragile. Thom?

Not that I can think of. However, when we upgrade the kernel, should we register
a reboot event with upgrade-manager? This would at least mitigate the problem
somewhat.

On kernel upgrades, we probably need to drop something that'll disable
hibernate. Matt, what's the best way to deal with this?

(In reply to comment #4)
> On kernel upgrades, we probably need to drop something that'll disable
> hibernate. Matt, what's the best way to deal with this?

I mailed you a script which tries to heuristically determine if we'll be using a
different kernel on the next boot. Your sentence above gave me an idea for how
to improve it even further:

Kernel upgrades already drop a file in /var/lib/update-notifier/user.d to
indicate to the user that they should reboot. Unfortunately, I think it's dated
based on the timestamp in the .deb, and not when it is installed, but perhaps it
could still be useful

I've encountered two different (but similar) problems on my Thinkpad T43p.

With the vanilla ubuntu install, I was getting the occasional "swsusp: Resume
mismatch: version" on restarting, and it would start from scratch.

I installed the linux-686 module to get the full benefit of my memory (the
default kernel only sees 1GB, while I have 2GB total) and my CPU. Then swsusp
stopped working at all - it wouldn't even shut down cleanly, I had to hard-shutdown.

I'm also seeing swsusp "lose" the ipw2200 module on resume. I'll file a
separate bug on that.

Hi,

At first glance I added this to the top of /etc/acpi/hibernate.sh.

grubkern=`awk 'BEGIN { kern=0 } {if ( $1 == "default" ) f=$2; if ( $1 == "kernel" ) if ( f == kern ) { gsub(".*z-","",$2 ) ;print $2 ; ( kern = kern + 1 ) } }' /boot/grub/menu.lst`

if [ $grubkern != `uname -r` ] ; then exit 1 ; fi

It just checks the default kernel is the same as the running one. Pretty hacky but it works! Might be nice if it could return a messages to the user somehow rather than just quitting.

In the end I thought that maybe grub-update should perhaps write out a file when it notices a change in default kernel.

On Mon, Apr 10, 2006 at 01:35:30PM -0000, John Cooper wrote:
> At first glance I added this to the top of /etc/acpi/hibernate.sh.
>
> grubkern=`awk 'BEGIN { kern=0 } {if ( $1 == "default" ) f=$2; if ( $1 == "kernel" ) if ( f == kern ) { gsub(".*z-","",$2 ) ;print $2 ; ( kern = kern + 1 ) } }' /boot/grub/menu.lst`
>
> if [ $grubkern != `uname -r` ] ; then exit 1 ; fi
>
> It just checks the default kernel is the same as the running one. Pretty hacky but it works! Might be nice if it could return a messages to the user somehow rather than just quitting.
>
> In the end I thought that maybe grub-update should perhaps write out a file when it notices a change in default kernel.

That looks like it would only work in the case of a kernel ABI change, since
the filename doesn't change otherwise (though hibernation resume would still
fail).

Perhaps we should arrange for newly-installed kernels to always drop/touch a
file, and on reboot, remove it. That would provide a reliable test.
Matthew, what do you think?

--
 - mdz

Yes, that sounds practical.

--
Matthew Garrett | <email address hidden>

Hi,

in order not to slow down the everyday boot process, I would suggest not to touch a file, but to drop a short shellscript together with a link to the /etc/rc init script system (or "upstart"-system), which deletes itself after the first successful reboot.

Otherwise, one would have to always check for this file during the start of the system.

Ben, please arrange for future kernels to drop a file or such so that we can test its timestamp against the uptime of the system to determine whether the kernel has been upgraded since the last reboot (and refuse to hibernate in this case).

On Sat, 2006-10-21 at 00:07 +0000, Matt Zimmerman wrote:
> Ben, please arrange for future kernels to drop a file or such so that we
> can test its timestamp against the uptime of the system to determine
> whether the kernel has been upgraded since the last reboot (and refuse
> to hibernate in this case).

I thought we had setup the /proc/version_signature file for this very
reason?

Also, it's very easy to test for /var/run/reboot-required, which shows
that some update of the system is requiring a reboot. The largest user
of this file is the kernel. I would be willing to bet that other users
would also be grounds for not hibernating.

So if the hibernation scripts test for /var/run/reboot-required, they
could use this as a means for deciding not to hibernate.

This is related to bug #36577, worth dup'ing it? That bug is that 'pmi' should deny hibernation is the same kernel will not be used on next boot.

Done. If consensus is that the acpi-support task here should be powermanagement-interface instead, please change it.

On Fri, Oct 20, 2006 at 08:57:21PM -0400, Ben Collins wrote:
> On Sat, 2006-10-21 at 00:07 +0000, Matt Zimmerman wrote:
> > Ben, please arrange for future kernels to drop a file or such so that we
> > can test its timestamp against the uptime of the system to determine
> > whether the kernel has been upgraded since the last reboot (and refuse
> > to hibernate in this case).
>
> I thought we had setup the /proc/version_signature file for this very
> reason?

I don't think that's quite enough, since it's non-trivial to query for the
version of the kernel which will be used on the next boot in order to
compare with this. The test which I think gives us the best combination of
accuracy and simplicity is "has a new kernel been installed since the last
boot?". That will only be wrong under special and unusual circumstances
(user installing a new non-default kernel).

> Also, it's very easy to test for /var/run/reboot-required, which shows
> that some update of the system is requiring a reboot. The largest user
> of this file is the kernel. I would be willing to bet that other users
> would also be grounds for not hibernating.
>
> So if the hibernation scripts test for /var/run/reboot-required, they
> could use this as a means for deciding not to hibernate.

Unfortunately, several other components use this as well. initscripts,
udev, dbus, hal, etc., and we don't want to disable hibernation
unnecessarily in those cases (especially for users of the development
branch where those may change often).

--
 - mdz

The old kernel isn't automatically uninstalled, is it? Would a better approach be to make hibernation somehow trigger the use of the old kernel?

Just a thought, I don't really have any solid idea of how one would implement it beyond hacking up '/boot/grub/menu.lst'.

Ben, please arrange to have the kernels touch a file or otherwise record this information in a form which is easy to test for.

Ideally we should display some sort of notification if we decide not to hibernate, but we don't do that if there isn't swap available etc., so at least logging it and not blowing up would be an improvement.

Wouldn't this also be fixed if you guys used pm-utils? mjg59 - I thought you guys were going to think about switching to pm-utils in feisty - so we can get this sort of thing common upstream. mdz - have you looked at the HAL suspend and hibernate failure reporting code from davidz?

The postinst now touches: /var/run/do-not-suspend

So anything that needs to know should fail to suspend when this file exists.

Shouldn't this be do-not-hibernate, or do-not-suspend-to-disk? suspending to RAM is perfectly OK in this scenario, isn't it?

mdz: yes, that is correct, 'do-not-hibernate' is the issue, suspending is fine. There are other cases where 'suspend' does not work, but hibernate does.

I'd like to get this fixed to 'do-not-hibernate' before feisty leaves the door, otherwise we'll be carrying (totally broken) compatibility code for forever after.

 kernel-package (10.065ubuntu5) feisty; urgency=low
 .
   * Touch '/var/run/do-not-hibernate' instead of '/var/run/do-not-suspend'
     to indicate to the power-management layer that the kernel that is likely
     to be used following a hibernate/resume-from-hibernate cycle has changed.
     Re-closes: (Launchpad: #14908)

Changes:
 powermanagement-interface (0.3.13) feisty; urgency=low
 .
   * Make 'pmi.acpi' check for '/var/run/do-not-hibernate' and deny
     hibernation if the file exists (from an upgrade of the default
     kernel which would cause a failure on resume-from-hibernate).
     (Closes: Launchpad #14908).

Gutsy Beta, KDE:

The problem is still there, at least in KDE (no blocking of hibernation after kernel update). Should I reopen the bug or make it somehow more visible to KDE development?