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

[Nikolaus Rath]

Hi Michael,

On 05/30/2014 06:06 AM, Michael Biebl wrote:
> Am 30.05.2014 04:11, schrieb Nikolaus Rath:
>> 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.
>>
>> 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, reboots automatically 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.
> 
> I downgraded the severity bug for two reasons:
> - if a kernel with a new ABI is installed, the old one is not removed
> automatically, so you can still boot/resume with that kernel
> - if a kernel is updated but the ABI is the same, resuming with the new
> kernel should work

Severity is of course up to you. But I'd like to point out that it does
not help at all that the old kernel is still installed: as soon as
you've tried booting the new kernel once, you cannot resume from the
hibernation image anymore, even when booting the old kernel.

I don't know much about the kernel ABIs, but I've now twice experienced
the following situation:

- new kernel is silently installed by unattended-upgrades (apparently
this happens even when the new package breaks the ABI) and becomes the
default to be loaded by the bootloader
- there's no visible indication that this happened, so I hibernate as usual
- when I reboot, I automatically end up with the new kernel (still
without me being aware of it)
- when the resume fails and the system reboots again, I realize that
there is a problem, but at that point it's too late. I can no longer
resume, and the hibernated system state is lost.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«