On Mon, Aug 12, 2019 at 10:20 AM Lennart Poettering
On Mo, 12.08.19 09:40, Chris Murphy (lists(a)colorremedies.com) wrote:
> Right now the only lever to avoid swap, is to not create a swap
> partition at installation time. Or create a smaller one instead of 1:1
> ratio with RAM. Or use a 1/4 RAM sized swap on ZRAM. A consequence of
> each of these alternatives, is hibernation can't be used. Fedora
> already explicitly does not support hibernation, but strictly that
> means we don't block release on hibernation related bugs. Fedora does
> still create a swap that meets the minimum size for hibernation, and
> also inserts the required 'resume' kernel parameter to locate the
> hibernation image at the next boot. So we kinda sorta do support it.
We could add a mode to systemd's hibernation support to only "swapon"
a swap partition immediately before hibernating, and "swapoff" it
right after coming back. This has been proposed before, but noone so
far did the work on it. But quite frankly this feels just like taping
over the fact that the Linux kernel is rubbish when it comes to
I'm skeptical as well. But to further explore this:
1. Does the kernel know better than to write a hibernation image (all
or part) to a /dev/zram device? e.g. a system with: 8GiB RAM, 8GiB
swap on ZRAM, 8GiB swap partition. We can use swap priority to use the
ZRAM device first, and conventional swap partition second. If the
user, today, were to hibernate, what happens?
2. Are you suggesting it would be possible to build support for
multiple swaps and have them dynamically enabled/disabled? e.g. the
same system as above, but the 8GiB swap on disk is actually made
across two partitions. i.e. a 2GiB partition and 6GiB partition.
Normal operation would call for swapon for /dev/zram *and* the small
on-disk swap. Only for hibernation would swapon happen for the larger
on-disk swap partition (the 2GiB one always stays on).
That's... interesting. It sounds potentially complicated. I can't
estimate if it could be fragile.
Let's consider something else: Hibernation is subject to kernel
lockdown policy on UEFI Secure Boot enabled computers. What percentage
of Fedora users these days are likely subject to this lockdown? Are we
able to effectively support hibernation? On the one hand, Fedora does
not block on hibernation bugs (kernel or firmware), thus not
supported. But tacitly hibernation is supported because a bunch of
users pushed an effort with Anaconda folks to make sure the swap
device is set with "resume=" boot parameter with out of the box
Another complicating issue: the Workstation working group has an issue
to explore better protecting user data by encrypting /home by default.
Of course, user data absolutely can and does leak into swap. Therefore
I think we're obligated to consider encrypting swap too. And if swap
is encrypted, how does resume from hibernation work? I guess
kernel+initramfs load, and plymouth asks for passphrase which unlocks
encrypted swap, and the kernel knows to resume from that device-mapper
I'm really skeptical of pissing off users who want hibernation to
work. But I'm also very skeptical of compromising other priorities,
and diverting resources, just for hibernation.
If you wait long enough between replies, I will find another log to
throw on this fire, somewhere. :-D