On Sat, 2018-07-21 at 00:33 +0200, Michael Biebl wrote: > On Thu, 29 May 2014 19:11:25 -0700 Nikolaus Rath <nikol...@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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers