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

[Lennart Poettering]

On Mon, 18.04.16 23:19, James Hogarth (james.hogarth at gmail.com) wrote:

> Hi all,
> 
> There's been some discussion today about the impact of
> https://bugzilla.redhat.com/show_bug.cgi?id=1206936 and where the problem
> actually lies.
> 
> The issue lies specifically with hibernate and affects all Fedora systems
> regardless of hardware (it's reproducible in a VM).
> 
> The hibernate image gets written to swap correctly
> but hibernate-resume-generator.c looks specifically for 'resume' in
> /proc/cmdline to determine a) if any check shoudl even happen and b) which
> block device to check.
> 
> When Fedora is installed anaconda does not write a resume= line
> to GRUB_CMDLINE_LINUX in /etc/default/grub or to the default kernel stanza
> for grubby to later duplicate.
> 
> Dracut cmdline module does produce a resume= line but it appears this
> occurs too late for the generator to pick up.
> 
> The end result is that without manual intervention to add an appropriate
> resume= line it's impossible to resume from hibernation on Fedora, and the
> critical battery behaviour (configured via /etc/Upower/Upower.conf and
> visible in upower -d) is to HybridSleep.
> 
> Is it feasible for systemd to have the generator pick a swap image
> regardless of resume being present or not? If so the dracut cmdline coming
> later than the hibernate generator wouldn't be a problem.

So what precisely are you proposing? That we actively search for the
swap partition in the hibernate-resume generator?

The general problem with that is that swap partitions are
traditionally hard to recognize, and I'd rather not try that on
classic MBR partition tables (the major issue is that swap partitions
originally had no recognizable disk magic, until one was added to the
end – not the beginning of the partitions, which turned out to collide
easily with data file systems which usually have magic at the
beginning and don't zero out the end, thus possibly causing data loss
when a swap partition is misrecognized).

I am pretty sure that for MBR the resume partition should be passed to
the initrd via the resume= line, the same way as this is done for the
root partition via root=.

That said, on top of that, I'd be willing to extend the logic so that
on GPT partition tables we'd start looking for an explicit partition
type for hibernation swap partitions. On GPT this is all much nicer,
since their GPT partition type logic is fine-grained and explicit
enough to avoid the problems with auto-detection mentioned above.

Of course, searching for the hibernation partition only on GPT would
probably not solve your issue, but I doubt that searching for swap
partitions elsewhere is really a safe and good thing to do.

Lennart

-- 
Lennart Poettering, Red Hat