Fedora 41 released, so far so good

In my case I updated to Fedora 40. I’m running Bluefin:gts and it was updated this morning from Fedora 39 to 40. In the case of bluefin the updates are slightly different, but I did not notice “anything broken”.

I almost (almost) miss the times when a new release of your favourite distro implied some fixes (well, tbh, I do not miss those time, hahaha)

TL;DR It just worked, only took ~10-15min.

I saw the update notice early this morning, and in a tremendous leap of early adopter faith, I went for it. Adding to my anxiety I did it on battery power with 70% charge remaining. Even more anxiety, I hadn’t done any recent backups. (Most of my stuff is in a cloud somewhere, so no biggie). And if that wasn’t enough my system is configured to run dual boot Win11/Fedora 40 (now 41).

The upgrade went smooth, the download took only a few minutes (thank you 1Gb internet service :slight_smile:) The update process went smooth ~10min. At around the halfway point it slowed to a crawl (almost thought it hung) but in a minute or so picked up. When complete it rebooted back into Fedora no issues. Networking came up & VPN connected just fine. Firefox stared up, no issues accessing websites or playing YouTube videos.

Rebooted the machine into Windows 11 no problem. Lightroom ran as expected (accessing my photos in Adobe cloud), and Firefox ran as expected just as in Fedora. Rebooted back to Fedora NTF.

IMHO go for it realizing that all things considered YMMV…

Config here: FW13 Intel® Core™ Ultra 5 125H , 32Gb RAM, 1Gb SSD. Dual boot Win11/Fedora (primary OS).

P.S. Also checked camera in Fedora 41, worked fine.

Rod

1 Like

Does it sleep well on the 11th Gen? (Deep sleep)

I think you can forget that. This is a BIOS issue on the 11th gen and completely independent of the distribution or kernel versions being used. I will do a reinstall with preparations for hibernation since that’s going to be the only way for 11thgen to save some battery.

I’m curious as to how the battery life will be on AMD boards since the release notes state that they moved away from Power Profiles Daemon and have Tuned as default now

I upgraded my os from Fedora 40 to 41 as well, and it is running well so far.
Mine is workstation version (the one with GNOME 47) and I’m using AMD 13 model.
I did not erase everything. I just used dnf for my upgrade.
Whenever I face some issues, I will share those!

cheers! :smile:

Yeah, you’re right. Looks like it’s s2idle and modern standby going forward.

#CannotRollbackBIOSFrom3.20

since doing the update, my battery percentage display has been stuck at 98%, i hope it’s a software/firmware problem and that it’s not my battery, FW16

EDIT: nevermind, i guess the battery drain is much smaller now? weird

I get constant crashes, mainly on firefox and chromiumbut I also had a few wide system freezes.

Im on (Intel® Core™ Ultra Series 1) fedora 41 on the sway spin and tested the two recent kernels - with the most recent being: 6.11.5-300.fc41.x86_64,

https://retrace.fedoraproject.org/faf/reports/1059646/

Specifically on firefox: sometimes the tab fails and I restart it, sometimes the whole browser and most of the times the whole system so I have to force shut it down.

last updated packages:

Packages altered:
  Action   Package                                        Reason          Repository
  Upgrade  glibc-0:2.40-9.fc41.x86_64                     Group           updates
  Upgrade  glibc-common-0:2.40-9.fc41.x86_64              Dependency      updates
  Upgrade  glibc-all-langpacks-0:2.40-9.fc41.x86_64       Group           updates
  Upgrade  glibc-gconv-extra-0:2.40-9.fc41.x86_64         Dependency      updates
  Upgrade  glibc-devel-0:2.40-9.fc41.x86_64               Dependency      updates
  Upgrade  javascriptcoregtk4.1-0:2.46.3-1.fc41.x86_64    Dependency      updates
  Upgrade  webkit2gtk4.1-0:2.46.3-1.fc41.x86_64           Dependency      updates
  Upgrade  jxl-pixbuf-loader-1:0.10.3-5.fc41.x86_64       Weak Dependency updates
  Upgrade  krb5-libs-0:1.21.3-3.fc41.x86_64               Dependency      updates
  Upgrade  libjxl-1:0.10.3-5.fc41.x86_64                  Dependency      updates
  Upgrade  libnl3-0:3.11.0-1.fc41.x86_64                  Dependency      updates
  Upgrade  libnl3-cli-0:3.11.0-1.fc41.x86_64              Dependency      updates
  Upgrade  libusb1-0:1.0.27-4.fc41.x86_64                 Dependency      updates
  Upgrade  libvdpau-0:1.5-8.fc41.x86_64                   Dependency      updates
  Upgrade  polkit-0:125-1.fc41.1.x86_64                   Group           updates
  Upgrade  polkit-libs-0:125-1.fc41.1.x86_64              Dependency      updates
  Upgrade  tigervnc-license-0:1.14.1-2.fc41.noarch        Dependency      updates
  Upgrade  tigervnc-server-minimal-0:1.14.1-2.fc41.x86_64 Dependency      updates
  Replaced glibc-0:2.40-3.fc41.x86_64                     Group           @System
  Replaced glibc-all-langpacks-0:2.40-3.fc41.x86_64       Group           @System
  Replaced glibc-common-0:2.40-3.fc41.x86_64              Dependency      @System
  Replaced glibc-devel-0:2.40-3.fc41.x86_64               Dependency      @System
  Replaced glibc-gconv-extra-0:2.40-3.fc41.x86_64         Dependency      @System
  Replaced glibc-headers-x86-0:2.40-3.fc41.noarch         Dependency      @System
  Replaced javascriptcoregtk4.1-0:2.46.1-1.fc41.x86_64    Dependency      @System
  Replaced jxl-pixbuf-loader-1:0.10.3-4.fc41.x86_64       Weak Dependency @System
  Replaced krb5-libs-0:1.21.3-2.fc41.x86_64               Dependency      @System
  Replaced libjxl-1:0.10.3-4.fc41.x86_64                  Dependency      @System
  Replaced libnl3-0:3.10.0-1.fc41.x86_64                  Dependency      @System
  Replaced libnl3-cli-0:3.10.0-1.fc41.x86_64              Dependency      @System
  Replaced libusb1-0:1.0.27-3.fc41.x86_64                 Dependency      @System
  Replaced libvdpau-0:1.5-7.fc41.x86_64                   Dependency      @System
  Replaced polkit-0:125-1.fc41.x86_64                     Group           @System
  Replaced polkit-libs-0:125-1.fc41.x86_64                Dependency      @System
  Replaced tigervnc-license-0:1.14.1-1.fc41.noarch        Dependency      @System
  Replaced tigervnc-server-minimal-0:1.14.1-1.fc41.x86_64 Dependency      @System
  Replaced webkit2gtk4.1-0:2.46.1-1.fc41.x86_64           Dependency      

Im disabling hardware acceleration on firefox to see if it changes anything.

Update: hardware acceleration seemed to solve the issue for firefox

I upgraded yesterday on my FW 13 Core Ultra 155h. Everything seems to work except I have troubles running steam on wayland on my second screen. For whatever reason, even if my second screen is set as primary (I’m using gnome) and has 100% scaling, steam is scaling to integrated screen scaling settings (200%). I did not have this behaviour on Fedora 40.

The only way for me to play my steam games right now is to set integrated screen scaling to 100% temporarly or to run on xorg (but it ruins my screen configs when I come back to wayland)

I updated on the day F41 was released, and everything went smoothly. No issues, nothing broke – running on Framework 13 with 12th-gen Intel.

The main change I noticed is the switch to “tuned” for battery and system optimization, replacing power-profiles-daemon. From a fresh installation standpoint, tuned seems more effective than power-profiles-daemon, but I’m not completely satisfied with it. I used TLP before, which handles around 95% of tuned’s tasks but is far more user-friendly to configure. The documentation for tuned is scattered and often requires diving into the source code just to find tuning parameters, their names, and possible values. In comparison, TLP lacks profile support (limited to AC and DC profiles, that are selected automatically) and doesn’t provide a gnome-shell interface to switch profiles.

I tried setting up tuned profiles for different workloads and verified them using tlp-stat and powertop. By default, tuned (with its default profiles) only activates about half the settings that TLP recognizes. Editing those profiles took me a minimum of six hours (due to bad documentation), and even with identical settings enabled, my idle power consumption wouldn’t go below 3.3W with tuned, compared to TLP’s 2.3W. While idle consumption isn’t an ideal comparison metric, I don’t have a standardized runtime test available at the moment.

See Tuned configuration, resembling a tuned TLP profile for Framework 13 12th-gen Intel · GitHub

@Kieran_Levin these profiles and my comment above might be of interest to you

For the AMD boards, power-profiles-daemon may be slightly better than Tuned: [TRACKING] PPD v TLP for AMD Ryzen 7040 - #270 by Mario_Limonciello .

There was an issue with installing PPD on Fedora 41, but that should be resolved now. If you want to revert back to PPD:

sudo dnf swap tuned-ppd power-profiles-daemon

If you don’t need it, you can remove tuned entirely:

sudo dnf swap tuned power-profiles-daemon

General PSA: Friendly reminder for our officially supported distros, we’re recommending your defaults. Newer configurations will be moving to tuneD.

Fedora 41 for example, used ppd-tuned. Provides a gui of PPD for your performance settings.

TLP as always, AMD does not recommend and for Intel, advanced users only…but not officially recommended.

Custom tuneD profiles can accommodate any custom cpu and performance considerations for advanced users.

(Edited and corrected tuned-pdd) If you are set on using TLP, that’s fine, but you need to disable ppd or tuneD or tuned-pdd.

In my testing, per Mario’s recommended checking, I found that tuneD with the default ppd-tuned was close in some soft daily testing to ppd. Did not see a dip in battery life.

2 Likes

*ppd-tuned → tuned-ppd :wink:

And I agree, the defaults are fine for most people, my post wasn’t formulated that well.

Ha! Yeah, I was on my phone and I caught this as well. lol

This thing :slight_smile: tuned-ppd - Fedora Packages

does anyone know how to make sure that all the drivers required from Framework Laptop 13 (Intel® Core™ Ultra Series 1) are there and intact after the update? The freezes Im getting seem to be related with the graphics.

I did not know 11th gen has a bios issue with sleep. I was wondering why after years of updates it still has problems waking from sleep. Do you have more information about it?

I’m having issues upgrading from Fedora Silverblue 40 → 41. I’m getting the following error:

$ rpm-ostree rebase fedora:fedora/41/x86_64/silverblue

error: Could not depsolve transaction; 1 problem detected:
 Problem: conflicting requests
  - package tuned-ppd-2.24.0-6.fc41.noarch from @System conflicts with ppd-service provided by power-profiles-daemon-0.23-2.fc41.x86_64 from updates
  - package power-profiles-daemon-0.23-2.fc41.x86_64 from updates conflicts with ppd-service provided by tuned-ppd-2.24.0-6.fc41.noarch from @System
  - package tuned-ppd-2.24.0-6.fc41.noarch from @System conflicts with ppd-service provided by power-profiles-daemon-0.23-1.fc41.x86_64 from fedora
  - package power-profiles-daemon-0.23-1.fc41.x86_64 from fedora conflicts with ppd-service provided by tuned-ppd-2.24.0-6.fc41.noarch from @System
  - installed package tuned-ppd-2.24.0-6.fc41.noarch obsoletes power-profiles-daemon < 0.23-2 provided by power-profiles-daemon-0.23-1.fc41.x86_64 from fedora
  - package tuned-ppd-2.24.0-6.fc41.noarch from @System conflicts with ppd-service provided by power-profiles-daemon-0.23-2.fc41.x86_64 from updates-archive
  - package power-profiles-daemon-0.23-2.fc41.x86_64 from updates-archive conflicts with ppd-service provided by tuned-ppd-2.24.0-6.fc41.noarch from @System

It seems that the transition from PPD to Tuned-PPD isn’t going smoothly. I have tried waiting a while to see if this might have been a bug in the update process but it doesn’t seem to change. I don’t see an obvious issue with my layered packages:

LayeredPackages: bridge-utils langpacks-en_GB libvirt libvirt-daemon-config-network libvirt-daemon-kvm nmap qemu qemu-kvm virt-install virt-manager virt-viewer

Does anyone have a clue what’s up here?

In general with the Atomic variants, if you have layered packages, the updates might not work.

You would need to reset your layers (removes all the layered packages) with rpm-ostree reset and then upgrade

I had a look at best practices for upgrades on Silverblue and you might be right, that’s something to look into. However, during my research I ran into rpm-ostree status -v and it signalled me the following:

InactiveRequests: power-profiles-daemon

I had been playing around with updating PPD manually some months ago for better battery life but I initially didn’t see it in my layered packages, as was expected because I removed it again. But apparently it was stored as an inactive request.

Removing it with rpm-ostree uninstall power-profiles-daemon cleared the way for the upgrade to work! Thanks for the nudge in the right direction :slight_smile:

1 Like