Bug#749832: systemd: ignores /run/do-not-hibernate, hibernates after kernel update

[Ben Hutchings]

On Sat, 2018-07-21 at 00:33 +0200, Michael Biebl wrote:
> On Thu, 29 May 2014 19:11:25 -0700 Nikolaus Rath <Nikolaus at rath.org> wrote:
> > Package: systemd
> > Version: 204-8
> > Severity: grave
> > Justification: causes non-serious data loss
> > 
> > 'systemctl hibernate' (and probably other methods to hibernate when
> > systemd is installed, I tested only the command) hibernates the system
> > even if a new kernel package has been installed and /vmlinuz no longer
> > points to the currently running kernel.

A minor nitpick here: for the 99% of systems that boot using GRUB, it's
the GRUB default that matters, not /vmlinuz.  Installing a new kernel
version usually updates both, but not always.

In principle, part of the preparation for hibernation could involve
setting the GRUB default.

> > If this happens, and the system is booted again, the bootloader will
> > load the new kernel, and then try to resume using the image stored by
> > the old kernel. As far as I can tell, the system then marks the
> > hibernation image as broken,

This is the first thing that the resume process does after finding the
hibernation image header.  This is because (1) we want it to be usable
as a swap partition again (2) restoring twice from the same hibernation
image would likely cause much worse data loss.

> > reboots automatically

I think that this is actually a crash, because I can see nothing
specific in the hibernation code that would do that.

What surprised me, and in a reall scary way, is that there is
ABSOLUTELY NOTHING in there to verify that the kernel resuming the
hibernation image, matches the one that created it.  Not even a
comparison of release strings (which wouldn't be sufficient).

> > and, on the second
> > attempt, boots the system using the new kernel without resuming. At this
> > point, any data that was available in the hibernated session but not
> > written to disk is lost.
> > 
> > Prior to installing systemd, hibernating was not possible after a kernel
> > update. I believe the mechanism to prevent it was a
> > /run/do-not-hibernate file that is not used by systemd.
> 
> Is there a distro-agnostic way to determine whether it's safe to
> hibernate or not?

I don't think there's any reliable way to tell that, since the way that
kernels are installed and loaded is not only distribution-dependent but
potentially site-dependent.

In principle, you could implement a general test for "is the running
kernel the same as *that* installed kernel".  The ".notes" section of
the running kernel, which includes its build ID, can be read from
/sys/kernel/notes.  You can then unpack the installed kernel image and
compare with the build ID in that.  Unfortunately the "unpack" step is
dependent on architecture and boot loader, which I think makes this
impractical.

The best I can suggest at this point is that you completely disable
hibernation until we sort our shit out on the kernel side.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180721/052e72d6/attachment-0002.sig>