hibernation redux, possible blocker bug

[Chris Murphy]

Another hibernation bug came up for blocker review today.

systemd-logind does not verify if system has resume device defined
when checking if can.hibernate or can.hybridsleep
https://bugzilla.redhat.com/show_bug.cgi?id=1332266#c6

Converse to the description, the most compelling aspect is the
screenshot in comment 6, in which GNOME shell puts up a notification
stating that the system will hibernate soon. But of course that can't
work on Fedora right now because the required command line
"resume=<swap>" does not exist.

QA is right on the fence whether this behavior is sufficiently
misleading and bad as to violate the data corruption/loss release
criterion. In reality the system will merely be shutdown, so why not
just say that?

https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Data_corrupt...

Question for the WG is, is is possible to change
/etc/UPower/UPower.conf such that
- CriticalPowerAction=HybridSleep
+ CriticalPowerAction=PowerOff

That way the misleading message shouldn't happen?

[Bastien Nocera]

----- Original Message -----
> Another hibernation bug came up for blocker review today.
>
> systemd-logind does not verify if system has resume device defined
> when checking if can.hibernate or can.hybridsleep
> https://bugzilla.redhat.com/show_bug.cgi?id=1332266#c6
>
> Converse to the description, the most compelling aspect is the
> screenshot in comment 6, in which GNOME shell puts up a notification
> stating that the system will hibernate soon. But of course that can't
> work on Fedora right now because the required command line
> "resume=<swap>" does not exist.
>
> QA is right on the fence whether this behavior is sufficiently
> misleading and bad as to violate the data corruption/loss release
> criterion. In reality the system will merely be shutdown, so why not
> just say that?
>
> https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Data_corrupt...
>
> Question for the WG is, is is possible to change
> /etc/UPower/UPower.conf such that
> CriticalPowerAction=HybridSleep
> CriticalPowerAction=PowerOff
>
> That way the misleading message shouldn't happen?

Just papering over logind returning incorrect information? No.
And that breaks HybridSleep as well.

[Chris Murphy]

On Tue, May 17, 2016 at 4:45 AM, Bastien Nocera  wrote:
> ----- Original Message -----
> > Another hibernation bug came up for blocker review today.
> >
> > systemd-logind does not verify if system has resume device defined
> > when checking if can.hibernate or can.hybridsleep
> > https://bugzilla.redhat.com/show_bug.cgi?id=1332266#c6
> >
> > Converse to the description, the most compelling aspect is the
> > screenshot in comment 6, in which GNOME shell puts up a notification
> > stating that the system will hibernate soon. But of course that can't
> > work on Fedora right now because the required command line
> > "resume=<swap>" does not exist.
> >
> > QA is right on the fence whether this behavior is sufficiently
> > misleading and bad as to violate the data corruption/loss release
> > criterion. In reality the system will merely be shutdown, so why not
> > just say that?
> >
> > https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Data_corrupt...
> >
> > Question for the WG is, is is possible to change
> > /etc/UPower/UPower.conf such that
> > CriticalPowerAction=HybridSleep
> > CriticalPowerAction=PowerOff
> >
> > That way the misleading message shouldn't happen?
>
> Just papering over logind returning incorrect information? No.
> And that breaks HybridSleep as well.

systemd-logind returning incomplete information is a bug, but is it
really a blocker? And on what basis does something suddenly become a
blocker when it's been this way for multiple releases?

If it's appropriate to block on what amounts to an enhancement
request, then why is it inappropriate to block on bug 1206936 which is
also an enhancement request, to add resume= to the kernel command
line? Hybridsleep is already broken without that.