when battery power is critical

[Bastien Nocera]

----- Original Message -----
> On Wed, Oct 7, 2015 at 2:49 AM, Bastien Nocera <bnocera at redhat.com> wrote:
> 
> >Chris Murphy wrote:
> >> I can, it's just that there's an incongruence among the default
> >> setting (off), the notification I get (it will hibernate), and what
> >> actually happens (sleep/suspend to RAM).
> >
> > Then there's a bug in UPower or systemd.
> 
> Any suggestion on isolating which one and then I can file a bug?

As root:
killall -9 upowerd
/usr/libexec/upowerd -v

and check the logs after reproducing the problem.

> >> For a 1% battery state to result in anything other than power off or
> >> hibernate (suspend to disk) seems like a bad idea.
> >
> > Hibernate is the default if it's supported. You can check with:
> > upower -d | grep critical-action
> 
> HybridSleep
> 
> Seems like hibernate by default isn't appropriate by default since the
> installer doesn't support setting up swap for hibernate.

Sorry, HybridSleep is the default, and we'll ask logind if it's supported, and
fallback. From /etc/UPower/UPower.conf:

# If HybridSleep isn't available, Hibernate will be used
# If Hibernate isn't available, PowerOff will be used
CriticalPowerAction=HybridSleep

> >> And then there are the IRST supporting laptops, and while there's some
> >> kernel support for this I don't know if systemd or GNOME will leverage
> >> it. The RAM to disk dump is definitely always unencrypted though.
> >
> > Nobody added support for IRST as a new kernel sleep state, so the support
> > in systemd isn't finished.
> 
> So this is insufficient?
> https://lkml.org/lkml/2013/7/2/544

This doesn't integrate in the power subsystem of the kernel. This was my attempt
to integrate it in systemd, but I was told it should be implemented in the kernel
proper:
http://lists.freedesktop.org/archives/systemd-devel/2013-October/013653.html

> > *BUT*. Suspending on a machine which supports that mode should be migrated
> > to disk by the firmware. Right now, given the kernel's support for IRST,
> > we can't show the difference between a firmware hibernation and suspend.
> 
> Or presumably configure whether to use it, although I don't really see
> much of a downside to just always using this feature if it's
> available. Maybe one is that it requires its own partition, with the
> IRST partition type GUID set. It can't use the Linux swap partition.
> So that means doubling up on extra partitions.

It will be used automatically *by the firmware* if you set it up that way.

Cheers