Thanks for sharing it. It looks great result!
Today I experimented just keeping closing my Framework Laptop for 3 hours. The result was the battery was reduced from 100% to 90% during the 3 hours. The
tlp daemons are enabled. But no hibernate. Just using s2idle maybe. My BIOS version is 3.02. Hmm huge difference from you.
Yes, s2idle will drain down the battery quickly. Did you set up hibernate yet? Does
systemctl hibernate work for you? You should see no battery drain from just kicking off hibernate and powering on later, since it’s being written to disk.
By default Fedora 35 prohibits hibernation. Check your dmesg output for the line:
Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Also, I believe hibernation and zram can present challenges, as zram puts swap in a RAM disk, so…
Yeah, I wanted to measure the battery life before changing the setting from s2idle to hibernate. I didn’t set up the hibernate yet. In my current Framework Laptop, memory is 32 GB, and swap is 8.0 GB, I have to expand the swap size to more than 32 GB. The situation is like you. I am investigating the steps and other things such as what s2idle and hibernate are, referring your blog now.
Reading the following Fedora workstation group (?)'s document about hibernation, it seems that Fedora doesn’t support hibernation by the following concerns.
hibernation is less power consumption than S0 or S3;
Note 2: There is a pernicious problem with laptop batteries. As they age, they often won’t tolerate load very well, leading to rapid discharge and very short or no notice before a compulsory power off. In such cases, even when the system is hibernation capable, hibernation can fail. Power can be lost during hibernation entry. There isn’t much software can do to second guess the commonly confused state of aged batteries.
Current significant impediments:
- UEFI Secure Boot is overwhelmingly present and enabled by default on new computers;
- kernel lockdown policy inhibits hibernation when Secure Boot is enabled ;
- ACPI bugs can be transient and difficult to fix or work around; hibernation can mean data loss due to failed entry or exit;
- resource requirements for the permanent swap partition can be excessive, Anaconda history states the reason for the current swap partition size  is to accommodate hibernation;
- large swap partition exacerbates performance problems in swap heavy workloads.
Reddit: Fedora 34 Hibernation: https://www.reddit.com/r/Fedora/comments/mw4ee9/fedora_34_hibernation/
I am investigating about the system sleep and ACPI mainly reading kernel document now. Here is just my memo. I will add more contents there when I find something new.
Just note yesterday I updated the wiki updating Sleep / Suspend and adding Reporting upstream or Fedora project section.
Installed Fedora Linux 35 following the guide. Removed all partitions and restarted.
Computer fails to boot. Stuck on and will not power down.
text on black screen reads:
Answered my own question (shown below).
To restart the Framework, hold down the power key for more than 10 seconds (13?)
Computer booted into Fedora 35 after that.
On to the next challenge!
[FAILED] Failed to start Show Plymouth Reboot Screen
[FAILED] Failed deactivating swap Compressed Swap on /dev/zram0
[ 766.994700] watchdog0: watchdog did not stop!
If you know how to force the Framework to shutdown, please let me know.
I am sure I did something wrong but I don’t know what.
Caution: people who are using Fedora 35 and wants to use s2idle as a sleep state, Fedora 35 kernel 5.16.5 s2idle and maybe wifi issues . There is a regression bug about s2idle on kernel 5.16.5 on Fedora 35. So, don’t upgrade the kernel or use “deep” instead of s2idle. See the context here.
Anyone know where we could report the grub2 bug exactly? Not on framework hardware (yet), but I had the same issue on a ThinkPad T14, which was also solved by running
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
@jorp Did you check “Reporting to upstream project or Fedora” section on the 1st wiki comment on this thread?
Check possible packages related to grub2.
$ rpm -qa | grep grub grubby-8.40-55.fc35.x86_64 grub2-common-2.06-10.fc35.noarch grub2-tools-minimal-2.06-10.fc35.x86_64 grub2-tools-2.06-10.fc35.x86_64 grub2-pc-modules-2.06-10.fc35.noarch grub2-pc-2.06-10.fc35.x86_64 grub2-efi-ia32-2.06-10.fc35.x86_64 grub2-efi-x64-2.06-10.fc35.x86_64 grub2-tools-extra-2.06-10.fc35.x86_64 grub2-efi-ia32-cdboot-2.06-10.fc35.x86_64 grub2-efi-x64-cdboot-2.06-10.fc35.x86_64 grub2-tools-efi-2.06-10.fc35.x86_64
$ rpm -qi grub2-common | grep URL URL : http://www.gnu.org/software/grub/ Bug URL : https://bugz.fedoraproject.org/grub2
Oops! I actually missed that… thanks for the info @junaruga!
Thanks for reporting!
Relating this graphical issue I am seeing on a fresh install of Fedora 35: Fedora 35 graphical issues
When I move my mouse to the left of the screen it glitches out, I’ve gotten rainbow snow, hangs, and black screens since the update.
Updated the sleep / suspend section on this thread’s wiki, adding content about sleep mode deep & hibernation. I wrote a step by step page about changing the sleep mode from s2idle to deep, and change back.
I renamed this thread title from “Fedora Linux 35 on the Framework Laptop” to “Fedora Linux 35 (Fedora 35) on the Framework Laptop”, because I noticed this thread can not be found when searching by “Fedora 35” using this forum’s search area on the top of the page.
I understand “Fedora Linux” is the official name of Fedora distribution. That’s why the title was using “Fedora Linux 35” rather than “Fedora 35”.
But I assume the current situation is why a user who don’t know this thread might create a new thread about Fedora 35. I know the title is a kind of redundancy. But I could not find any better way to solve this situation.
Hello, I tried to install Fedora 35 following the official guide, but it doesn’t work. During boot (I hink) there are a bunch of repeated log lines like this:
[ 349.288629] dracut-initqueue: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-label\x2fFEDORA-WS-L.sh: [...] [ 349.291731] dracut-initqueue: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: "[ -e "/dev/root" ]" [ 349.294809] dracut-initqueue: Warning: dracut-initqueue: starting timeout scripts
And then finishes with:
[ 349.297570] dracut-initqueue: Warning: Could not boot. Warning: /dev/disk/by-label/FEDORA-WS-L does not exist Warning: /dev/root does not exist
And then allowing to enter an emergency mode with a shell or continue (which doesn’t work).
A Google search lead to some forums with people reporting this, but not with a comprehensive / easy guide to follow to fix this.
Besides the official guide for the installation I also tried with a USB drive prepared with Rufus, as well as with Ventoy (one time with GPT and Secure Boot enabled in Ventoy and Framework BIOS, another time with MBR and Secure Boot disabled in both Ventoy and BIOS).
Is it an issue with the Fedora image? Or with the USB drive? Or the laptop?