On 15 May 2016 at 08:11, James Hogarth <james.hoga...@gmail.com> wrote:
> > On 15 May 2016 06:32, "Andrei Borzenkov" <arvidj...@gmail.com> wrote: > > > > 15.05.2016 06:36, Chris Murphy пишет: > > > On Thu, May 12, 2016 at 12:38 PM, James Hogarth < > james.hoga...@gmail.com> wrote: > > >> > > >> On 2 May 2016 18:58, "James Hogarth" <james.hoga...@gmail.com> wrote: > > >>> > > >>> > > >>> On 24 Apr 2016 21:31, "poma" <pomidorabelis...@gmail.com> wrote: > > >>>> > > >>>> On 20.04.2016 22:42, Chris Murphy wrote: > > >>>>> On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger > > >>>>> <tobias.hun...@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
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel