Raising this question here since it impacts other issues, particularly around swap. Some related discussion/information:
On the UX side, we haven't exposed a user-visible hibernate option for some time. The main reason for this is the profusion of end session options (log out, switch user, hibernate, suspend, power off) and the similarity of hibernate and suspend. This still feels like the correct decision.
We did recently have a very brief discussion about using hibernate in place of power off, and this is something I'm interested in as a way to improve the overall end/restart session experience. However, it's still not clear exactly how feasible this would be or what would be involved.
I think it's just not feasible, not unless we can convince the kernel developers to support hibernation on arbitrary hardware. They're not going to want to do that, and it would probably be expensive to do.
OTOH, this is a bit of a PulseAudio chicken/egg situation, in which hibernation is never going to work reliably until some desktop decides to replace power off with hibernate. Then, suddenly people will hopefully be more interested in ensuring it works reliably.
Don't we currently automatically hibernate when the user runs out of battery?
Yeah but if it fails, that's effectively the same as running out of battery and having a power off.
Maybe for systems where kernel lockdown doesn't apply it's writing out a hibernation image; but otherwise it's just a power off. I'm not sure how to estimate what percent of the user base is using a system with Secure Boot enabled, but as it's the default configuration on x86_64 for a long time now, it must be at least 1/2?
If only about half of people have working runs-out-of-battery that seems to me like a big issue. You don't want to loose your work.
What about replacing hibernation by suspend. Couldn't that be used to save your data? I know it will still consume battery but it shouldn't be that much.
From a UX perspective, it would be good to have working hibernation: it's good to have when someone runs out of battery, and could be really interesting to have for user-initiated power off and restore, too.
That said, if hibernation isn't going to work in many cases, and if it's not getting adequately tested/supported, then we do have to ask the question of whether it's a good idea to try and use it.
It seems that the critical power behaviour is configured by upower. I see this in my UPower.conf file:
UPower.conf
# The action to take when "TimeAction" or "PercentageAction" above has been # reached for the batteries (UPS or laptop batteries) supplying the computer # # Possible values are: # PowerOff # Hibernate # HybridSleep # # If HybridSleep isn't available, Hibernate will be used # If Hibernate isn't available, PowerOff will be used CriticalPowerAction=HybridSleep
I hadn't considered hybrid sleep when I created this issue, and it would be good to know how it compares to hibernation.
I think hybrid sleep is like normal suspend and hibernation simultaneously. If your laptop still has battery life left when you open it back up, then you get a fast path resume from RAM like normal suspend. But if it has run out of power, then after you've plugged in you can resume from disk like after a hibernation.
So the defaults make sense, sans hardware-specific bugs.
I'm guessing upower calls the proper systemctl suspend/hibernate/hybrid-sleep command, and that triggers the proper systemd target. There's one that upower doesn't seem to know about.
systemctl suspend/hibernate/hybrid-sleep
systemd-hybrid-sleep writes out a hibernate file, then suspends. Writing out the hibernate image can involve a long delay on systems with a lot of memory.
systemd-suspend-then-hibernate suspends to RAM, wakes up later to write out the hibernate file and then hibernates.
More in man systemd-sleep.conf
man systemd-sleep.conf
But until there's hibernation image signing supported in the mainline kernel, it's subject to lockdown on Secure Boot enabled systems. I think SUSE has patches for this (?) but I have no idea how it works, where the signing key is escrowed. It may be supportable only with a TPM.
Is it possible to change the policy to "if hibernate isn't available, then suspend" ?
So again, from a UX perspective, I think the question is: can we hope to offer a good hibernation experience? If we can't, we might want to disable it, and that might have some implications for swap.
My preference is to have hibernation, but only if it's good and working.
Also note the recent discussion with Lennart about this here and the open TODO in systemd. The idea would be to 1) do suspend if hibernate is not supported, 2) otherwise do suspend and then hibernate if the battery gets empty. If hibernate were to fail (kernel bug or something) this is no worse than actually using your data because the computer ran out of battery.
There are enough "hardware and kernel claim it'll work" cases where the failure happens on resume, and it's not knowable in advance. Failures can be consistent or transient. That suggests conditional handling to make it good.
Is resume time related to good? Based on anecdotes, it takes ~0.75s per 1G of RAM resumed (this assumes NVMe and compressed images). That's 6s for a system with 8G RAM, and 24s for 32G RAM. This excludes firmware, kernel, initramfs time - because Linux hibernation is kernel supported, not bootloader supported. Is it faster to just cold boot? To contend with this, and also address limited storage for large hibernation files, Windows does "fast startup" which logs out of the user session before creating the hibernation image.
I'm still not convinced that we really should concentrate on hibernation. Wouldn't it be better to use sleep as default and opt-in for users to switch to hibernation?
Do someone here knows how long will sleeping PC hold the data before it runs out of battery for let's say 5% of battery? I know there are too many variables but it would be nice to know if it could be days or hours at least.
Is resume time related to good?
From a UX perspective, absolutely. Sub-30 seconds might be OK though, assuming the user is given accurate feedback about what's happening.
One key concern regarding "good" is whether hibernation is adequately tested or not. If secure boot does result in hibernation being disabled on a large proportion of systems, that would be a serious issue in this respect.
Is anyone able to clarify the impact that secure boot has an hibernation?
I've mentioned this in the past, but it bears repeating that the infrastructure for hibernation is not fit for purpose. Hibernation uses swap partitions, which means that we'd need a 32GB swap partition to support hibernating a computer with 32GB of memory, and, fingers crossed, none of those 32GB end up being used to something else. This dual use means that it's a poor choice. When firmware support exists, a special partition is usually set aside (see "Intel Fast Start").
Even if hibernation could resume, the hibernation process is a gamble, and not one we should be taking. Until that's fixed, it also goes against: https://pagure.io/fedora-workstation/issue/120
Having a separate storage was an item in the "kernel wishlist", which has gone mostly unanswered by kernel developers: https://wiki.gnome.org/BastienNocera/KernelWishlist
@hadess All fair points for consideration. @aday For sure, when Secure Boot is enabled, kernel lockdown policy is in place and it disallows hibernation.
Jan 13 13:55:16 flap.local kernel: Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7 Jan 13 13:55:28 flap.local kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
What's the point in considering anything that doesn't work under Secure Boot? This is 2020; we should assume most users have Secure Boot when picking defaults.
A dynamically created swapfile only used on-demand for hibernation, solves everyone's problems :D @jkonecny swap partitioning can be entirely removed from the installer @aday one less puzzle piece in the WGs partitioning jigsaw @catanzaro if upstream kernel devs accept SUSE's hibernation image signing patches (or something like it), Fedora can use it even if we stop making swap partitions and use swap on ZRAM instead @hadess no more massive swap partitions, which could be sized wrong anyway
I know, I know. This doesn't exist yet. But that's the only impediment. It's not kernel hacking. And overall it's a lot more reliable. A systemd generator could do this, triggered by hibernate.target, create exactly the correct size swapfile for current system state, and leverage existing systemd units to mkswap, swapon. Fits all the use cases discussed.
Original question restated: can/should we support hibernation, if so how?
Related question: are we willing to make hibernation not possible out of the box, due to default partitioning creating an insufficiently sized swap? Or must a 'create swapfiles dynamically' feature be delivered?
Metadata Update from @chrismurphy: - Issue unmarked as blocking: #120
Metadata Update from @chrismurphy: - Issue marked as blocking: #120
A dynamically created swapfile only used on-demand for hibernation, solves everyone's problems :D
Could we guarantee that there's always space for that swap file? I'm assuming that that's an advantage of a dedicated partition.
We can't guarantee that swap have available space for hibernation so this does not change from the current solution AFAIK.
Could we guarantee that there's always space for that swap file?
Guarantee is a strong word, that to me suggests 100% of the time with all edge cases covered. :D But yeah, short version is, almost guarantee is possible: Once the swapfile is created, don't delete it.
Could sysroot become full before the swapfile is created? Yes. Is it likely? No. Should it be accounted for? I think not.
But if I'm wrong, and it's yes, anaconda or g-i-s can create it. OK now we're pretty close to just having a swap partition created by the installer. But which is easier for "default partitioning users"? Deleting a swapfile to recover otherwise wasted space? Or partition ninja to recover space used by a swap partition? And this also suggests documenting how to do that in either case, which thwarts the effectiveness of coming up with sane defaults in the first place. The ideal scenario of good defaults is no documentation required, right?
Metadata Update from @chrismurphy: - Issue tagged with: meeting
Even if a swap file or partition of sufficient size is available, the fact that this swap space serves a dual purpose means that it's impossible to be sure that it will be available. When you also take into account that: - it's impossible/racy to enable a new swap space when needed (eg. when hibernation is requested), - that having large amounts of swap space is a good recipe for runaway processes and lack of interactivity (as yet), - and that a number of subsystems/drivers have problems with the way hibernation is implemented.
I'd strongly advise the WG to say they won't support hibernation, and look into (u)swsusp support instead. It doesn't have any of the limitations mentioned above, and just lacks integration in our user-space.
It seems unreasonable to default to a feature that requires enhancing applications to support over a feature that most things don't need to write code to support.
I'd strongly advise the WG to say they won't support hibernation, and look into (u)swsusp support instead. It doesn't have any of the limitations mentioned above, and just lacks integration in our user-space. It seems unreasonable to default to a feature that requires enhancing applications to support over a feature that most things don't need to write code to support.
I'm not sure I'd consider logind to be an "application", but it's certainly better having to modify logind than offering up functionality that can fail (and is known to fail) in any number of ways and shrugging when it does so.
What additional preparation is needed to discuss this on 11 Feb?
If the swap partition is no longer created, it definitely means taking away any chance of hibernation out of the box, even if it could work for some people. Are we ready to commit to that path? Or is compromise in order?
(Multiple swaps can exist. It's possible to do swap-on-ZRAM with a higher priority than swap on a partition.)
I'd say we're looking pretty strongly towards dropping swap partition for F33.
INFO for issue watchers who aren't watching desktop@ list: Support for hibernation 1/2: background and summary Support for hibernation 2/2: questions
My opinion on this is the same as hadess: hibernation that may or may not work, depending on your hw, system configuration, kernel build and phase of the moon is worse than no hibernation.
Lets not make promises we can't keep
Summary of top concerns that make this untenable, presently.
Hibernation is subject to kernel lockdown when UEFI Secure Boot is enabled. Will a Secure Boot compatible hibernation implementation ever exist on linux and what's a plausible time frame for it?
Hibernation (apparently) can silently fail if > 50% of RAM is used. https://marc.info/?l=linux-kernel&m=157177497015315 Fedora QA can trivially reproduce this. Use case is, user closes laptop lid, puts laptop in a bag. What happens? Dead laptop battery and data loss?
If improvement can't be made in both, development efforts need to be made elsewhere (e.g. application level) to reliably save user data and properly power off the computer.
While I'm personally very much in favour of this kind of behaviour, I am sceptical about what can be achieved here, particularly in the short term. To cite one example: we've been pushing for autosave in gedit for over 7 years and haven't seen any progress, and that's a relatively simple core application.
Use case is, user closes laptop lid, puts laptop in a bag. What happens? Dead laptop battery and data loss?
Just to clarify - closing the lid seems currently hardcoded to suspend in GNOME and can't be changed from settings. Hibernation needs to be activated manually (either through a command, using a hibernate button enabled from a gnome-shell extension, or setting it as an action for power button event (that can be done from gnome-control-center) and then pressing the power button). In all these cases it's obvious nothing happened, i.e. hibernation didn't work, so data loss should not be a concern.
That said, those aforementioned problems probably prevent Workstation from using hybrid sleep by default, unless the hybrid sleep implementation gets smart enough and in case the later hibernation fails, it suspends again instead (so instead suspend -> wait -> hibernate -> fails -> running -> out of battery, it is suspend -> wait -> hibernate -> fails -> suspend).
I've heard back from Matt Garrett, who gave me a hint where to look. I discovered current versions of SLES/openSUSE also disable hibernation when Secure Boot is enabled. I found SUSE's 2015 patches to sign hibernation images, and contacted the author, who replied that this is the latest status.
Summary: it encrypts and signs the hibernation image, and the key must be sealed by the TPM; this is a work in progress, but there's no completion estimate for the next version. For sure we can't count on it in the near term, and it's indeterminate beyond that.
Power management policies today:
GNOME Shell (Fedora Workstation 32) by default will automatically suspend (S3) when on battery power following 20 minutes of inactivity. Power button action is set to suspend (S3).
GNOME Shell will poweroff when the battery reaches a certain minimal point. I'm not sure what the trigger is.
Proposals.
A. Could GNOME Shell attempt suspend (S3) upon minimal battery trigger, instead of power off? This gives at least a chance of saving the user's data.
B. Implement swap-on-ZRAM, #127
C. Drop the creation of a swap partition at install time. Solves #120, but means hibernation is not possible out of the box for anyone who does an automatic/default installation. Should this be mitigated by documentation?
D. Pursue on-demand activation of swapfile. Also solves #120, and means hibernation could be opt in. There are gotchas with doing hibernation with swapfiles:
I'm pretty sure valid positions include each proposal as stand alone (you agree with only one), and in any combination, and most any order.
"A and B then C optionally D" means A and B should be implementable (no major issues) before proceeding with C, and D is nice to have but not required.
"A and B and D then C" means A, B, D should be implementable (no major issues) then proceed with C.
Power management policies today: GNOME Shell (Fedora Workstation 32) by default will automatically suspend (S3) when on battery power following 20 minutes of inactivity. Power button action is set to suspend (S3).
Note that the delay is user configurable from the power settings.
Doesn't that contradict what I found above?
Also note that we currently allow the user to configure what the power button does. The current options are: suspend, power off, hibernate, nothing.
GNOME Shell will poweroff when the battery reaches a certain minimal point. I'm not sure what the trigger is. Doesn't that contradict what I found above?
No, it will power off as the last resort, as the last 2 lines of the comment explain. That's what it does when no other action is available.
Got it the wrong way around. All the dirty IO buffers might not be sync()'ed to disk on suspend, whereas they would be on power off. That codepath in systemd would need to be changed if we wanted to change that, but then again it would still allow waking up from suspend with that super-low battery.
That's just not possible to implement in a way that won't fail too often. Enabling the swap on the fly would require some way to make sure that the swap is only ever used for hibernation, but there's no mechanism for that.
On my laptop, it hibernates instead. I guess you have secure boot enabled? Hibernate is definitely preferred to power off, if available. And we already saw above that Allan's laptop performs hybrid sleep, which is best of both worlds. Power off is the last resort if neither hybrid sleep nor hibernate is available.
Premises:
Conclusion: Hibernation can't be considered a generic solution for preserving user data in a minimal power scenario. It's either not reliably available or it's not reliable.
S3 (suspend-to-RAM) is a bit more complicated. I can't estimate its failure rates or causes. It's very reliable on Windows and macOS, but it may be there are common bugs that Windows somehow works around, and such work arounds aren't in the linux kernel.
From my narrow hardware experience? My HP Spectre used to S3 suspend reliably 3 years ago. Then a kernel update broke it. I bisected and proved to upstream what broke it. They had me do a bunch of ACPI debugging, and then somewhat convincingly said it was a firmware/ACPI bug, and weren't going to provide an in-kernel work around.
One of my laptops has Secure Boot enabled, the other lacks a swap partition. Hence suspend and power off are the only options, and GNOME's Power panel preferences reflects this, the Power Button Action does not offer a hibernation option on either computer. I think this is good because it can't work anyway. I also think it's a typical case.
In the idealized case of qemu-kvm, hibernation fails about half the time (a larger sample size might determine it fails somewhere between 1/3 and 2/3rds the time), for reasons not even upstream kernel developers agree upon. The less idealized case of baremetal (without Secure Boot), necessarily fares worse than the idealized case due to variable firmware and ACPI bugs.
I can only speak from my experience with a limited selection of bare metal machines, but the hibernation success rate has always been well above 90% for me. Which might be similar to suspend-to-ram success rate. There is something very wrong with hibernating/suspending VMs and I noticed that as well. But I wouldn't draw generic conclusions from the VM issues. (I'm not disputing your other claims, just trying to clarify this one.)
UEFI Secure Boot is enabled on the vast majority of x86_64 hardware since circa 2012. There's no time estimate when there will be a Secure Boot compatible hibernation implementation in the kernel.
Honestly this is all that really matters IMO. We should assume that the vast majority of our users have secure boot enabled. Given this, I'm uncertain why we're spending so much time discussing hibernation.
WG agrees in principle that supporting hibernation is desirable but difficult, due to the various liabilities discussed in this issue, #98, #120, on the desktop@ list, and on the kernel@ list [1],[2]. WG will keep an eye on future developments, but in the meantime won't let hibernation hold up progress in other areas.
WG and Anaconda agree that the installer will support the use case, in custom partitioning mode, of manually creating a swap partition, and automatically adding its resume=<UUID> boot parameter.
resume=<UUID>
I would personally like the working group to advertise its interest in having a working hibernation solution, and document our research so far. Let's not simply wash our hands of it.
What documentation form and scope do you propose? Who are the target audience? And will they read it?
I wish hibernation were viable and working, by default, out of the box. It's an area of interest of mine, but only insofar as it relates to resource management, partitioning and file systems. The latter I think are much more interesting.
Also, I make no assumption whether hibernation is interesting or relevant to the working group, until such time as there's something viable to implement. A minimally viable hibernation function suggests a Secure Boot compatible implementation is a top priority. And yet even that has no testable code in five years, and the discussions go back farther than that. I'd characterize upstream kernel development on hibernation as stopping just short of washing their hands, putting it in de facto maintenance mode. It certainly isn't advancing, instead it has regressed compared to other platforms. In that context, I think the working group would be entirely rational to wash its hands of this subject.
Is this better brought before FESCo? Ask them to decide, perhaps create a Fedora subgroup akin to the minimization effort, comprised of people who are interested in and dedicated to the subject?
We're going in circles here.
Our designers, represented by Allan, want hibernation. It'd be nice if we could get it to work.
Technically, the WG has determined it is not anywhere close to being in a satisfactory state. We haven't decided that we don't want a theoretical future good hibernation. We just don't want what's available today, because it is not good. It'd be nice if that would change. Allan's proposal seems uncontroversial to me:
I don't think we need to ask FESCo to set product direction for Workstation.
A mail to the desktop and devel lists might be a good start. Just something to explain what we're doing and encourage developers to take on the work that's needed.
Something like:
Metadata Update from @chrismurphy: - Issue untagged with: meeting
I'll gather tha various references I have that relate to this. I think it's useful to show our work, and point to external resources.
Working title is: Supporting hibernation in Workstation ed., draft 1 As there are substantive changes, I'll just update the number and repost. I figure it's always going to be a draft. There's no final story or conclusion, we're always doing the best we can currently, and the plan is to make improvements as we can. Please suggest changes, and I'll incorporate. The full email will include the (below) synopsis at the start, followed by factual findings, including the 'viable approach', and references. It won't be huge, I want it to actually be consumable, actionable, and referable.
Synopsis: The Workstation WG recognizes hibernation can be useful, but due to impediments it's not currently practical to support it. This is a recognition of the current state of affairs. The WG wishes hibernation could be relied upon, and thinks there is a viable approach for at least limited support of hibernation in Fedora in the future. The WG encourages interested parties to pursue needed improvements. In the meantime, however, Workstation Edition won't be constrained by the current status. There are desired enhancements to performance and security that are hindered by the status quo. The WG will re-evaluate when the significant impediments have been adequately addressed.
Further, the WG is committed to continuing to make it possible to enable hibernation, at install time, via Custom Partitioning. For each existing partition scheme preset, when the user selects "Click here to create them automatically", the installer will create the necessary real swap partition, and include the resume=UUID kernel parameter hint so that the kernel can find the hibernation image.
Synopsis: The Fedora Workstation working group recognizes hibernation can be useful, but due to impediments it's not currently practical to support it. This is a recognition of the current state of affairs, but the working group wishes hibernation could be relied upon, and thinks there is a viable approach for limited support of hibernation in the future. We encourage interested parties to pursue the needed improvements. In the meantime, Workstation Edition won't be constrained by the current status. There are desired enhancements to performance and security that are hindered by the status quo. The working group will re-evaluate when the significant impediments have been adequately addressed.
We would like to see an install time means of enabling hibernation retained via Custom partitioning. If the user chooses to create a swap partition, the installer will include a resume=UUID kernel parameter hint so that the kernel can find the hibernation image.
Why? Historically, Custom Partitioning -> "click here to create them automatically" does the same thing as our default automatic partitioning... why would we want this to be different?
@jkonecny @vponcova Yep, good question. What do Anaconda folks think? My recollection of the group meeting conversation is in this issue above and I say something similar. It could be a misunderstanding on my part.
I figure there'd be a new preset set as default, for now call it default_scheme = PLAINNOSWAP which would also appear in the Custom>Scheme drop-down menu, leaving all the others intact, rather than changing all presets to not create swap.
default_scheme = PLAINNOSWAP
Also, Custom partitioning sets a warning flag, when swap isn't created, to remind the user they might want to create one. This can be bypassed. But it's a little odd to me if the Custom+preset+automatic choice were to use a layout resulting in a warning, and also recommends to do something else. Should that flag go away? And only on Workstation edition? Sounds like such changes might quickly get tricky.
My thinking was that the default/automatic path would be the only exception, and everything else would stay the same as it is. Least possible change.
Thanks for working on this, @chrismurphy ! I think that it would be good to include a few specifics, so people know what the blockers are to getting hiberation working, and so we can point them in the direction of how we think the situation can be improved.
@aday Yes, the above synopsis is about 15% of what I have, and is the messaging part with prose. The rest is just the facts and specifics.
I was planning to post the whole thing to desktop@. But I just now had a thought: workstation pagure. Just add it as a single file. That's easier to reference and update, it's designed for it. I can also use markdown. The drag with email is the MUA reformats it, and if anyone wants to copy it and do a draft 2, it'd involve some trouble.
https://pagure.io/fedora-workstation/tree/master
What do you think? Once it's done (today? I hope) I can also post it to desktop@ or even crosspost to devel@ so it gets visibility.
OK here is draft 1. https://pagure.io/fork/chrismurphy/fedora-workstation/blob/master/f/hibernationstatus.md
Idea for the next steps:
This looks great, @chrismurphy ! Some minor suggestions:
In the meantime, Workstation Edition won't be constrained by the current status.
This seems like the key point in the piece, and it could therefore help to spell it out. A suggestion:
"In the meantime, given that hiberation isn't viable at the moment, the workstation WG has decided that technical decisions will not be constrained by it. This means that decisions about how workstation is configured out of the box may conflict with the requirements of hibernation."
We would like to see an install time means of enabling hibernation retained via Custom partitioning.
I think we can make a slightly stronger statement here, maybe "we will support" rather than "we would like to see".
Anaconda history states the reason for the current swap partition size is to accommodate hibernation
It might be nice to mention the actual size of swap:
"Anaconda history states the reason for the current 8 GB swap partition size is to accommodate hibernation"
large swap partition exacerbates performance problems in swap heavy workloads.
"the current large swap partition"? Just to clarify that this is an issue right now.
It might be nice to mention the actual size of swap: "Anaconda history states the reason for the current 8 GB swap partition size is to accommodate hibernation"
Current default swap partition size matches available RAM. It's not hardcoded 8 GB. For me it's 64 GB.
I'm confused by the code: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/core/storage.py#L299
Looks like the code says 'swap = mem / 2' for most cases; if hibernation then it's 'swap = mem + swap' which would make it 150% RAM, which I've literally never seen.
But yeah in practice, it's always been 1:1.
I'll point out the 1:1 ratio with 64G cap in a footnote. And I've made the other modifications Allan suggested. And I've pushed it to:
https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md
Typos and format changes don't result in incrementing the draft number or date. Substantive changes or additions probably should.
I'm working on the change proposal for #127, and in that I'll need to reference this hibernation document, which I expect to do by URL so that the proposal is always pointing to the current draft.
Are there any suggestions for wider circulation of the hibernation doc? desktop@ or devel@ or both?
I would send it to devel@ since that gets the widest amount of feedback.
Whoops, guess I should have done an interactive rebase to collapse all those formatting commits? Blek!
So, can this be closed now...? Or is there another planned action item?
I am not sure I understand the question. Anyway, I can confirm that the option "Automatic" in the screen Installation Destination creates the same partitioning as the button "Click here to create them automatically" in the screen Manual Partitioning with the default partitioning scheme in the combo box.
The logic that includes the resume= option is not bind to a specific partitioning method (automatic, custom, kickstarted, ...). If we are on the X86 architecture and there is a swap device on the installed system, we will add the resume= option for the largest one.
If Fedora Workstation removes swap from the default partitioning layout, then users should go to the Manual Partitioning screen and manually add swap to enable hibernation.
Anaconda's schemes are closely coupled to Blivet's constants. The scheme specifies what kind of a back end will be used to create the default partitions. The default partitions are defined by the default_partitioning option in the Anaconda configuration file.
If the goal is to simplify the workflow for users who want to use hibernation on Fedora Workstation, I suggest to add a new checkbox to the Manual Partitioning screen under the combo box for the partitioning scheme. The checkbox could indicate the interest in the hibernation and Anaconda can use it to add swap back to the default partitioning layout. It shouldn't be too difficult to implement it.
The warning can be disabled with the swap_is_recommended option in the Anaconda configuration file.
The change in the default partitioning will affect all paths that use default partitioning (the option "Automatic", the button "Click here...", the kickstart command "autopart").
@vponcova Thanks for the responses.
I think simpler and more consistent is better. And that means no swap by default in autopartitioning, or the custom partitioning preset schemes. i.e. depend on the user manually adding a swap partition specifically to opt into hibernation.
And also disable swap_is_recommended. An alternative I thought of, tweaking the language to make it a reminder or hint for hibernation, is possibly misleading. If UEFI Secure Boot state can be checked by Anaconda, and the warning made conditional, then it wouldn't be misleading. But I'm not certain if that's worth the effort.
Note that the change proposal is Fedora wide, not only Workstation. It might be only Fedora CoreOS that will opt out.
It's reasonable to close this now. Please feel free to reopen if new information is discovered, in particular as it affects updates to Supporting hibernation in Workstation ed., draft 2, 2020-05-31
In the short term, most related issues will be part of Changes/SwapOnZRAM.
Metadata Update from @chrismurphy: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @chrismurphy: - Issue set to the milestone: Fedora 33
Metadata Update from @ngompa: - Issue set to the milestone: None (was: Fedora 33) - Issue status updated to: Open (was: Closed)
There is a patch set by @mjg59 that may allow us to revisit this and support it with Secure Boot: https://lore.kernel.org/lkml/20210220013255.1083202-1-matthewgarrett@google.com/T/#u
Metadata Update from @ngompa: - Issue set to the milestone: Future Release
Hi Neal, were these patches accepted upstream?
The patch set is on v5 now, driven by Evan Green on the ChromeOS team: https://lore.kernel.org/lkml/20221111231636.3748636-1-evgreen@chromium.org/
If this patchset were to land, then what would we need to do to support hibernation?
Is it possible to create a swap partition while ensuring it will not actually get used as a swap device? Swap on disk is extremely slow, so we don't want it to be actually used except for hibernation.
Hm, this issue is pretty old. I'm thinking it probably does not make sense to track hibernation status here unless somebody is really actively working on it.
Can you provide another status update on this?
If this patchset were to land, then what would we need to do to support hibernation? Is it possible to create a swap partition while ensuring it will not actually get used as a swap device? Swap on disk is extremely slow, so we don't want it to be actually used except for hibernation.
Hi @ngompa, can you answer these questions please?
I will see if I can find any answers about this... I'm at Linux Plumbers Conference and I might be able to find someone who knows what's going on.
The patch set is abandoned and being completely rewritten. I am in contact with the folks working on it and will put an update once I have something.
Let's close this for now. Feel free to reopen when it's time to revisit this issue.
Metadata Update from @catanzaro: - Issue close_status updated to: Can't fix - Issue status updated to: Closed (was: Open)
Well, sure secure boot is a problem, but the lack of hibernation in general is a huge black eye for fedora. Literally every other laptop/desktop OS (windows/mac/etc) use hibernation to avoid entirely draining the battery. And being able to resume after the battery is 100% drained isn't a solution either (and doesn't work if the swap/hibernate partion isn't setup).
And <sigh> its one of those "do I want to wade into it battles" on LKML where "times have changed" because while AMD is shipping encryted ram machines, they are rarer than OPAL disks, where the kernel isn't even 100% aware if the underlying disk is encrypted.
And frankly for motivated users (myself) its is possible to hibernate a fedora install, it just takes anywhere from 30 seconds, to a couple hours (btrfs!!!) to get it working properly. Just add the resume modules to dracut, uinstall the zram, add add the resume= option to the grub/bls config. Of course this is all easier if a custom swap partition was put on LUKS encrypted volume during setup, or the machine has a TCG OPAL disk unlocked with a firmware pin, etc. But then the only remaining choice is does one want to disable secure boot, or enroll a MOK key and resign the kernel after "fixing" it.
Maybe its worthwhile opening this in bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=2263936
Login to comment on this ticket.