Hey guys, do any of you guys have any idea about what to do when updating fedora? Currently on 5.13.5 and I tried updating to 5.13.6 from gnome software as well as from my terminal just for both to give me a boot error of “systelctl status initrd-switch-root.service” ( initrd-switch-root.service failing). I look up the issue online but there are different options to try and the two that I tried didnt work. Do you guys have any idea? It seems people have this issue with Fedora when updating. Currently, I’m back on my 5.13.5 install but my grub still has the two installs that don’t work.
I’m also having moments where I’ll restart my computer and use it for a while and then everything gets really slow, and when I’ll suspend my computer my closing the lid and then reopening it causing everything to be slow and it’ll say my CPU usage is high. Any ideas about that?
EDIT: Like right now after just browsing the internet, listening to Spotify, and in a call on discord, my OS just decides to slow down and all everything gets super slow. I’m not even doing anything super intensive, and I can’t even see what is using all of my CPU or whats causing me to throttle. I just restarted and after a couple of minutes of a slow install (which normally doesn’t happen) it went somewhat back to normal. A couple of animations are still slow and all.
Hi folks, I’m struggling to get the fingerprint reader working on Fedora 34. I got all hardware working 100% on Ubuntu 21.04 yesterday, but decided to switch to Fedora 34 due to the much better trackpad gesture support (3-finger desktop switching was a must for me!).
As recommended, I installed from the latest respin of Fedora 34. I’ve got libfprint-1.90.7-3.fc34.x86_64 installed, but every time I try to enroll a fingerprint, I immediately get an error and it gives up. Some reading on fprintd suggests this is usually a driver error. Here’s what the error looks like:
[sawaba@fedora ~]$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-unknown-error
Is that the right device?
I can’t find anything in /var/log that gives any more details and all my Googling hasn’t revealed anything useful. I also tried pulling from the Fedora 35 repo, but it just gives me the same version of libfprint that seems to be working for everyone else…
1 Like
There is Ubuntu thread, and others, suggesting that libfprint must be version 1.92 1 for the fingerprint sensor to work.
I haven’t managed to get a successful compile yet, always some package not found.
@Edward_Gray you shouldn’t need to compile, you can just install from rawhide: Community reviews - #9 by Michael_Lingelbach
1 Like
I’m currently running Fedora 34 on my Framework and fprintd worked out of the box.
Here is further information, if curious:
CPU: Quad Core 11th Gen Intel Core i7-1185G7 (-MT MCP-) speed/min/max: 1242/400/4800 MHz Kernel: 5.13.7-200.fc34.x86_64 x86_64
Up: 55m Mem: 4624.4/31880.5 MiB (14.5%) Storage: 3.64 TiB (19.4% used) Procs: 347 Shell: Zsh inxi: 3.3.06
It is suggested above to follow the procedure for Ubuntu (Ubuntu 21.04 on the Framework Laptop - #8 by jeshikat), but that says to run the command sudo update-grub, which doesn’t seem to exist in Fedora. This page, Equivalent of update-grub for RHEL/Fedora/CentOS systems? - Unix & Linux Stack Exchange, has an answer that says that the Fedora 33 guide says to run sudo grub2-mkconfig --output=/boot/grub2/grub.cfg. Does that seem right for Fedora 34? The current guide GRUB 2 - Fedora Project Wiki seems to confirm this, but I’m still a little confused.
And now that I look at that page more, I wonder if the correct advice might be to use grubby, per GRUB 2 - Fedora Project Wiki. However, looking at the grubby man page leaves me as confused as ever. Not being intimately familiar with the various parts of the Grub2 subsystem, I’m not clear what options in grubby would accomplish changing the setting.
I finally did the following, and it seems to have worked, as shown:
Before configuring /etc/default/grub to enable deep sleep:
[jeremy@fedora ~]$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
[jeremy@fedora ~]$
After configuring /etc/default/grub to enable deep sleep::
[jeremy@fedora ~]$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet mem_sleep_default=deep"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
[jeremy@fedora ~]$
Running the script to invoke the grub incantation:
[root@fwfedora ~]# cat /sys/power/mem_sleep
[s2idle] deep
[root@fwfedora ~]# cat doit.sh
grub2-mkconfig -o /etc/grub2.cfg
grub2-mkconfig -o /etc/grub2-efi.cfg
[root@fwfedora ~]# . doit.sh
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
[root@fwfedora ~]# ls -l /etc/grub2.cfg /etc/grub2-efi.cfg
lrwxrwxrwx. 1 root root 22 Jun 15 11:41 /etc/grub2.cfg -> ../boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 22 Jun 15 11:41 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg
[root@fwfedora ~]# diff /etc/grub2.cfg /etc/grub2-efi.cfg
[root@fwfedora ~]#
(reboot)
[root@fwfedora ~]# cat /sys/power/mem_sleep
s2idle [deep]
[root@fwfedora ~]#
6 Likes
@Jeremy_Schneider before you dive too deep into grub, if you haven’t checked to see whether you need to, you can run this command:
cat /sys/power/mem_sleep
If the result is [s2idle] deep, you don’t need to mess with grub to enable deep sleep, it’s already enabled.
I was deep into troubleshooting on my Fedora 34 system before realizing it was already enabled for me. Also worth mentioning - I installed Fedora 34 using the respin from August 2nd, which reportedly already had a lot of this stuff fixed.
2 Likes
@Alex_S The only difference here is that I’ve got the i7 chip just below yours - the i7-1165G7. I can’t imagine how that would make a difference though - the fingerprint reader isn’t part of the Intel chipset…
@Adrian_Sanabria Thank you. It is indeed already set. I used to be very grub-literate in my Gentoo days ;-).
[jeremy@fwfedora ~]$ cat /sys/power/mem_sleep
[s2idle] deep
[jeremy@fwfedora ~]$
Oh, by the way, I also installed from a respin – maybe that’s why I have it.
My battery seems to drain unreasonably fast when the machine is asleep – not like my Google Pixelbook – I can close it and return days later to a machine at practically the same charge level.
I’m looking forward to enhancements in the access to the firmware charging limits and other battery-related customizations.
@Jeremy_Schneider Same! I remember the days when I had the time and patience to do Stage 1 Gentoo installs 
Yes, one of the main reason to use the Fedora respins is that the Framework folks got them to include some of these fixes!
And I’m sure they’ll get us some good firmware updates that fix some of these issues, though overall, I’m pretty happy.
The output is saying that it’s not set. You want “deep” to be selected. But s2idle is.
1 Like
@Andrew_Gallant Thank you for that information! I saw the word “deep”, and was ignorant of the syntax…
@Adrian_Sanabria I am actually having the same problem. Regardless of what version I use, it seems to (sometimes) pass the first enroll stage but then quit with that same error. Journalctl says fprintd[11235]: Device reported an error during enroll: Finger is too similar to another, try use a different finger. According to fprintd, there are no enrolled fingerprints though…
The weird thing is that Gnome showed the fingerprint option when I first installed Fedora, but after running dnf upgrade it no longer does.
Update: After correctly setting the sleep mode as described in my post above, starting with 100% battery charge and closing the laptop, 10 hours later the charge was reported as 90%. That’s a big improvement over my initial observations.
4 Likes
Good news. The new libinput RPM package 1.18.1 to fix the Framework touchpad issue is available on Fedora 35. On Fedora 34, the libinput 1.18.1 RPM package is currently in testing status. It will be released around 1 week later. To install it earlier on Fedora 34, you can check this testing page. I also updated this thread’s wiki.
2 Likes
@Adrian_Sanabria @waocats I had similar errors after installing Windows to debug the trackpad issue. I was able to work around it by enabling the fingerprint login in Gnome (although I couldn’t enroll a fingerprint), then disabling fingerprint login and then reenabling it again. My guess is that since the fingerprint reader is a match on device chip there might have been some logic that needed to get reset after reinstalling an operating system. You might give that a try and see if that resolves your error.
Can anyone chime in on how long it takes their laptop to resume from S3/deep suspend?
For me on Fedora 34, kernel 5.13.8-200.fc34.x86_64:
Suspend: almost instant
Resume: around 13-15 seconds to resume (from S3/deep). This seems somewhat slow, is this in line with how long it should take?
I looked through some diagnostics with
https://github.com/intel/pm-graph and looked at dmesg/journal, but couldn’t find any culprits (yet), but I may be reading them incorrectly.
Semi side-note:
Fedora’s S2Idle resume is instant, but I think it’s using S1 sleep state. Tested in Windows and it’s instant also, but the modern standby feature I believe uses S0ix, not S1.
Linux should be able to S2Idle using S0ix to achieve discharge rates similar to Windows modern standby, if I’m gathering my info correctly, but support/implementation seems shoddy all around, and doesn’t seem to be working correctly on Framework yet (F34, 5.13), due the seemingly high discharge rates.
Saw that 5.14/5.15 are supposed to help, at least with AMD chips. Further insight would be appreciated!
2 Likes
I don’t have my Framework laptop yet, but resuming from deep suspend should be nearly instant. It might take another few seconds for WiFi to connect, but 13-15 seconds is definitely not normal. Or at least, shouldn’t be considered acceptable.
When I’ve had problems in the past, pm-graph is what has bailed me out. If that isn’t working for you, then I’m not quite sure where to go from there.
Here’s a guide from Intel that talks about debugging steps: http://web.archive.org/web/20210302014224/https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
1 Like