Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hybrid-sleep #5

Open
arvids opened this issue Oct 2, 2017 · 3 comments
Open

hybrid-sleep #5

arvids opened this issue Oct 2, 2017 · 3 comments

Comments

@arvids
Copy link

arvids commented Oct 2, 2017

Hello,
Does this work with hybrid-sleep as well?
Right now suspend and hibernate seem to work for me but hybrid-sleep does not ask for encryption key on wake-up.

@guns
Copy link
Owner

guns commented Oct 2, 2017

Hybrid-sleep has never been tested, but I'll take a look and add it in the next point release if it's easy to support.

@arvids
Copy link
Author

arvids commented Oct 3, 2017

The reason I am requesting hybrid-sleep is for the goal to be able to hibernate from sleep either after a certain period of time to save battery or because the battery has reached a threshold.
It seems that hybrid-sleep is only helpful for saving everything and not for preserving battery.
So maybe there is a better approach?

Without trying this systemd approach my guess is it would not work since go-luks-suspend would require my password when waking up from suspend to execute hibernate, right?

@matrss
Copy link

matrss commented Nov 28, 2017

I'd love to see such a feature supported aswell, but we should make clear what exactly we want.
AFAIK hybrid-sleep writes to swap as if you were to hibernate, but then instead goes into the suspend state. What the approach you linked does is, it goes into the suspend state and later wakes up to hibernate.
In the first approach the system would actually stay in suspend until your battery runs out of power, the second approach starts hibernate after a certain amount of time.
That said, I think (correct me if I'm wrong) it's impossible to suspend and later wake up to hibernate as the root partition would still be inaccessible. Hybrid-sleep on the other hand would slow down the whole suspend process, as it writes to swap right at the beginning.
My Idea would be to go with the hybrid-sleep approach, but maybe use the linked systemd approach to later wake up and then poweroff, I guess that should be possible and (again, correct me if I'm wrong) still preserve the state of the swap partition, to later resume from there.

Still, I seem to face the same problem you initially stated, if I resume from hybrid-sleep the system doesn't ask for a keyfile nor a password. I guess we should get that fixed first.

EDIT: According to the systemd hybrid-sleep service file it executes systemd-sleep hybrid-sleep which then probably uses standard suspend instead of this encrypted one. That should explain why hybrid-sleep doesn't ask for a keyfile on resume.

BTW here's another link for the delayed-hibernate feature, but in the ArchWiki; as this project (mostly) aims at Arch Linux, that one might be more applicable, also it should basically be the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants