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

[Paul Sladen]

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.

[Paul Sladen (sladen)]

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:

  hald/linux2/osspec.c:

which updates:

  power_management.can_suspend_to_disk

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

  /usr/share/hal/scripts/hal-system-power-hibernate

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?

[Daniel Silverstone (dsilvers)]

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.

[Paul Sladen (sladen)]

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
  Hal
  pmi Fail
  Hal
  -> G-P-M displaying an error but with no reason.

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