[systemd-devel] systemd hibernator generator does not function on default Fedora install

[James Hogarth]

On 15 May 2016 at 08:11, James Hogarth <james.hogarth at gmail.com> wrote:

>
> On 15 May 2016 06:32, "Andrei Borzenkov" <arvidjaar at gmail.com> wrote:
> >
> > 15.05.2016 06:36, Chris Murphy пишет:
> > > On Thu, May 12, 2016 at 12:38 PM, James Hogarth <
> james.hogarth at gmail.com> wrote:
> > >>
> > >> On 2 May 2016 18:58, "James Hogarth" <james.hogarth at gmail.com> wrote:
> > >>>
> > >>>
> > >>> On 24 Apr 2016 21:31, "poma" <pomidorabelisima at gmail.com> wrote:
> > >>>>
> > >>>> On 20.04.2016 22:42, Chris Murphy wrote:
> > >>>>> On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger
> > >>>>> <tobias.hunger at gmail.com> wrote:
> > >>>>
> > >>>> [...]
> > >>>>
> > >>>>> Anyway, the most complete solution for BIOS, UEFI, and UEFI Secure
> > >>>>> Boot systems, is fast startups as possible (which helps all kinds
> of
> > >>>>> use cases not just desktops), and then encourage DE's and app
> makers
> > >>>>> to support apps that save their own state without users having to
> > >>>>> manually save files, and default to power off in low battery cases.
> > >>>>>
> > >>>>> I guess opensuse has some patches that aren't upstream yet that
> > >>>>> support signed hibernation images for UEFI Secure Boot?  Maybe
> there's
> > >>>>> a way forward at some point. But right now I'm just not seeing it.
> > >>>>> There's some kind of brick wall in every direction with
> hibernation.
> > >>>>>
> > >>>>
> > >>>> :)
> > >>>> "Lacus Hiemalis Edictum" patch-set actually existed for several
> years.
> > >>>>
> > >>>> ...
> > >>>
> > >>> <snip>
> > >>>
> > >>> There is something that can be done in systemd to avoid the data loss
> > >>> issue without having to add complexity to the generator.
> > >>>
> > >>> Add to the logind conditions for suspend-to-disk an additional one
> to the
> > >>> existing ones to ensure resume= is in the kernel cmdline.
> > >>>
> > >>> If it's not there refuse the hibernate and shutdown instead. At
> least then
> > >>> the processes would get shutdown properly with a TERM and not have a
> power
> > >>> cord pull situation (with sync) on them.
> > >>>
> > >>> That would be minimal change from present but avoid writing a resume
> image
> > >>> that will never be read.
> > >>
> > >> Since this seemed a nice solution to the problem, and it appeared to
> make
> > >> sense to validate the kernel argument would be there ready for the
> generator
> > >> for the resume before allowing the hibernate through logind there's
> patches
> > >> for Fedora and upstream systemd on this bug:
> > >>
> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1332266
> > >>
> > >> I've tested the F23 build with the patch on my laptop and it behaves
> as I'd
> > >> expect for an invalid resume=, no resume= and as valid resume=
> > >
> > > Seems like resume= should be checked to make sure the specified device
> > > exists/is-valid for holding a hibernation image; just as important as
> > > checking /sys/power/state and /sys/power/disk.
> > >
> >
> > Both dracut and initramfs-tools can embed resume device information into
> > initrd and do not require resume= on kernel command line. Refusing
> > hibernation in this case will break these configurations.
>
> Perhaps a configuration entry in logind.conf in the event the kernel docs
> of resume= aren't going to be used, such as in the dracut or
> initramfs-tools examples you give?
>
> Those who don't want to use the systemd hibernate generator to resume can
> disable the resume= check using that?
>
Okay following this line of thought there is now a pull request which
defaults to validating resume= (since it seems sane to assume a system
shipping systemd may use the systemd hibernation generator) but has
systemd-sleep.conf with a config option to disable this validation:

https://github.com/systemd/systemd/pull/3278
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160517/391ead51/attachment.html>