Skip to main content


Got the gnome-shell-extension-hibernate-status extension ready for Fedora 41, removed Hybrid Sleep as it will just lead to confusion.
This entry was edited (1 year ago)
in reply to Matt (It's really me) Hartley

I will be bundling these together, but yes, this works flawlessly as shown.

Controls for suspend, suspend then hibernate and lid behavior. Lid behaviors I am really bullish with is suspend to hibernate with lid close and straight hibernate with lid close.

Extension is a fork, with my custom changes for GNOME 47..
github.com/ctsdownloads/gnome-…

This entry was edited (1 year ago)
in reply to Matt (It's really me) Hartley

When things are ready, the instructions what partition structure to be used will be provided, run Anaconda.

Reboot, update, run hibernate-config script to setup hibernate with all the bells and whistles including SELinux tweaks while keeping things secure - never touch a conf file (although the manual instructions will be provided for those who wish it).

Everything will be live on the Framework github (private atm on my own github).

This entry was edited (1 year ago)
in reply to Matt (It's really me) Hartley

Matt, cannot even understate your impact here, this is wickedly cool and reaffirms my decision 1000x to buy a Framework computer.

Love it!

in reply to Moritz Heiber

@moritz I appreciate it! My goal is to continue to tool out tools to add value where possible.

A fair sized area of focus is a proper hibernate option. Suspend is fine for a short term, but when someone sticks a laptop in a backpack, it really should have its state saved and be properly off into a state of hibernate. :)

in reply to Matt (It's really me) Hartley

Absolutely.

I mean, my 2nd gen Framework loses battery even when completely turned off, but I’ll take any and all improvements any day 😄

in reply to Matt (It's really me) Hartley

That's great! Looking forward to the instructions as I'm on Ubuntu. Does suspend-then-hibernate work with the AMD systems?
in reply to benedolt

@benedolt It does. Tested on AMD Ryzen 7040 Series on the 13 inch model. 16 will behave similarly. Intel Core Ultra Series should as well (testing Monday)

LUKS passphrase bypass as an option (still encrypted) and Yubikey testing Monday as well.

in reply to Matt (It's really me) Hartley

dying for suspend-to-hibernate that Just Works. can’t express how much i’d love to see it happen.
in reply to Niklas Schmelzle

@nsmlzl Sadly no. But secure boot can be enabled or disabled as one chooses. Hibernate simply won't work when enabled.

For those folks, I will be offering a looser alternative with "non-secure boot TPM LUKS handling" and Yubikey LUKS handling. Still ironing out the flow.

Additionally, I do have secure boot working with a vanilla install using LUKS to bypass the passphrase (stored via TPM). But no hibernate for this one.

in reply to cameronbosch

@cameronbosch Yes. It's the issue with the keyboard wake up that inspired this. Need to triple check dgpu behavior (which should be fine). But yes, the 16 too.
in reply to Matt (It's really me) Hartley

that is great what you are doing here for the #linux #community Matt!
I followed instructions on @frameworkcomputer community forum and your suggestions as well, to set up manually hibernate on #Ubuntu2204LTS

But the lid , close, and some other bells are not there yet. I will gladly read your updates and test them, to share results 😋

My #framework13 Intel 12thgen battery will probably love that ✋

This entry was edited (1 year ago)

Tech Cyborg reshared this.

in reply to Hervé @ Puma - IT Services 🐧

@Puma_IT @frameworkcomputer Appreciate the feedback. :) Lid behavor should absolutely work OOTB on Ubuntu and Fedora. So on a default, unchanged installation, lid behavior should be suspend...unless changes were made to the conf or there is something interfering with the lid sensor.
in reply to Matt (It's really me) Hartley

You're telling me: while Windows had a complete shutdown dialog since NT, Fedora GNOME only now offers hibernation in its power off menu???
in reply to crafti

Heh, my brain immediately went to the meme associated with you're telling me. Lol

Kidding aside. This is not Fedora official.

This is me building something out that is badly needed.

Why is hibernate not a thing by default? Space and where it's hibernating to.

Generally for Linux, it means providing either a swap file (which is usually not that great) or a swap partition (works fine with modern nvme drives, thanks to speed).

The issue is in the setup. (cont)

This entry was edited (1 year ago)
in reply to Matt (It's really me) Hartley

(cont)

Linux needs dedicated space to make this happen. And that requires user choices. Not everyone wants hibernate in exchange for giving up some drive space.

Unlike suspend which just works out the box.

I'm playing devil's advocate here.

The same could be said for SAMBA sharing. It's weird. 🙃

This entry was edited (1 year ago)
in reply to Matt (It's really me) Hartley

@crafti The main reason this is not as good as it could be is because most distributions have the non-upstream LOCKDOWN patch that blocks hibernate for secure boot. As a consequence of most systems being SB-enabled by default (or by force) for the past decade, hibernate functionality has gone largely untested and unloved.

The Chrome OS folks were going to fix it some time ago, but that stalled out and now with CrOS rebasing on Android, there's no hope left unless someone funds it.

Unknown parent

mastodon - Link to source
Matt (It's really me) Hartley

Interesting, I'll absolutely take a look as another option to choose from. I like the approach. Different from previous approaches.

My long term goal is to offer both options. Partition has always been the most stable for me overall, but this differs some from other approaches I've used in the past.

Fedora will differ some as you indicated, but this has promise.

This entry was edited (1 year ago)
in reply to Matt (It's really me) Hartley

@nil @nsmlzl Would also be my question and really a requirement. (Also if it disables secure boot, you should really add a warning there…)

Some more background here: unix.stackexchange.com/questio…

It is said, LUKS-encrypting the swpa space would workaround the issue of the kernel not supporting signed kernel images… (and may anyway be a good idea?)