pmi should deny hibernate if the running kernel will not be used at next boot

Bug #36577 reported by Paul Sladen
Affects Status Importance Assigned to Milestone
powermanagement-interface (Ubuntu)
Fix Released
Paul Sladen

Bug Description

pmi is an interface between user programs wanting a power-related action and handling the actions themselves.

An example of this is that during a developement solution it can be useful to hibernate and then unhibernate to test a new version of 'sysvinit' or 'usplash'. However if the 'linux-image' version has changed then the unhibernate will fail and all the work will be lost.

There isn't a good solution to /knowing/ which kernel the user is likely to use at next boot as they may technically choose to edit the boot-loader command line.

A solution that works 98% of the time (on default installs and in normal use) is maybe to:

  test -f /boot/grub/menu.lst && grep -q "^default[$(echo -ne '\t ')]*0\$" /boot/grub/menu.lst && ! grep -qm 1 '^kernel.*'`uname -r` /boot/grub/menu.lst && echo no you can\'t have a pony.

Revision history for this message
Paul Sladen (sladen) wrote :

See the other duplicate for an earlier recording of the same issue.

I've modified 'pmi' so that its 'query' and 'capabilities' methods check the bootloader configuration to see if the currently running kernel is also the default for the next boot.

However, these don't seem to be [re-?]queried by 'gnome-power-manager' as AFAICT the only connection from g-p-m's CanSuspend D-Bus method are via, passively:


which updates:


by grepping '/sys/power/state' for 'disk'. And, actively by calling the


which does:

  /usr/sbin/pmi action hibernate force

Now, what would be the best way of dynamically conveying when hibernation isn't available (either lack of available swap compare to current memory usage, or lack of swap, or lack of matching kernel) up through the D-Bus stack so that g-p-m, gdm and the GNOME logout window all acknowledge it?

Changed in powermanagement-interface:
assignee: nobody → sladen
status: Unconfirmed → In Progress
Revision history for this message
Daniel Silverstone (dsilvers) wrote :

I don't think g-p-m monitors the power_management.can_suspend_to_disk value so changing that will not solve the problem alone.

It is possible that you can return an error string up the stack from the hal-system-power-hibernate helper script somehow.

I imagine Martin Pitt will know more.

Revision history for this message
Paul Sladen (sladen) wrote :

Pitti, Kinnison reckons you might have input on the above^^.

Yes, I can make pmi do a query on itself and then fail, however I'm wondering if this conflicts the point of 'force' ... which hal also calls it with anyway.

If I make 'pmi' fail (which is very easy, the least-intrusive and simplist option) the it would go like this:

  G-P-M -> Hibernate
  pmi Fail
  -> G-P-M displaying an error but with no reason.

However this is still probably better that letting the user loose their data.

Paul Sladen (sladen)
Changed in powermanagement-interface:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.