43 to 44 Upgrade Error because of PowerProfiles.service, tuned-ppd, tlp

PowerProfiles.service collides while trying to install tuned-ppd and tlp and results in 4 error messages.

The messages are unfortunately in german but I think it could be understandable.

How can I resolve this issue ?


Fehler beim Ausführen der Transaktion:
Datei /usr/share/dbus-1/system-services/net.hadess.PowerProfiles.service kollidiert zwischen den versuchten Installationen von tuned-ppd-2.27.0-1.fc44.noarch und tlp-1.9.0-7.fc44.noarch

Datei /usr/share/dbus-1/system-services/org.freedesktop.UPower.PowerProfiles.service kollidiert zwischen den versuchten Installationen von tuned-ppd-2.27.0-1.fc44.noarch und tlp-1.9.0-7.fc44.noarch

Datei /usr/share/dbus-1/system.d/net.hadess.PowerProfiles.conf kollidiert zwischen den versuchten Installationen von tuned-ppd-2.27.0-1.fc44.noarch und tlp-1.9.0-7.fc44.noarch

Datei /usr/share/dbus-1/system.d/org.freedesktop.UPower.PowerProfiles.conf kollidiert zwischen den versuchten Installationen von tuned-ppd-2.27.0-1.fc44.noarch und tlp-1.9.0-7.fc44.noarch


I found a solution by shortening my search-criteria:

What's New in Fedora Workstation 44 - Fedora Magazine

So it is solved ! :smiling_face_with_sunglasses:

Welcome to fedora @der-michel

Thanks to make this request. I got the same when updating my system from F43 to F44.

However I am not sure if this is a official change and if it has been announced.

This is a known design conflict. tuned-ppd is intended as a direct replacement of power-profiles-daemon[1], and it works by registering and listening on the same DBUS events the power-profiles-daemon does, so it can serve the same DBUS services (power profiles) which are already in use and offered by KDE and GNOME control centers or other UI[2]. TLP ships those same interface files (because TLP “stands in” for PPD on systems that use it), so they collide.

I installed F43 newly on the Disk I made the update from F43 > F44. This means every F43 new installation would get this error, right? I take the solution tick you made away, so we can continue discussing and find out if we should report this as a known issue.

This link did lead to a solution. On my regular machine I had no problem, but on a USB portable system I had this conflict. I removed ‘tuned-ppd’, and the GUI upgrade went smoothly. Der-Michel’s link I mean…

Please include the actual information / solution in posts rather than links which can disappear.

In any case, thanks for posting, as this is relevant to many users. I’ve have tlp installed and configured for a long time.

Fedora upgrades are getting concerning with amount of hidden issues or changes. Who is going to read the comments of a blog post to know about this before upgrading?

Anyway, here is the relevant comment from the link:


Fedora 43 → 44 upgrade conflict:

tuned-ppd

vs

tlp

What’s happening

The upgrade is trying to install

tuned-ppd

alongside your existing

tlp

package. Both packages ship the same D‑Bus service files for the

PowerProfiles

interface (

net.hadess.PowerProfiles

and

org.freedesktop.UPower.PowerProfiles

), which is why DNF/RPM aborts the transaction — RPM refuses to let two packages own the same files.

This is a known design conflict. tuned-ppd is intended as a direct replacement of power-profiles-daemon[1], and it works by registering and listening on the same DBUS events the power-profiles-daemon does, so it can serve the same DBUS services (power profiles) which are already in use and offered by KDE and GNOME control centers or other UI[2]. TLP ships those same interface files (because TLP “stands in” for PPD on systems that use it), so they collide.

Note also that the service unit

power-profiles-daemon.service

declares a conflict with

tlp.service

, causing

tlp.service

to be effectively disabled[3] — the same applies to

tuned-ppd

. So even if you forced both to coexist, only one would actually run.

You need to pick one of these tools. Two clean options:

Option A — Keep TLP, skip

tuned-ppd

(recommended if TLP is working for you)

Tell the system upgrade to exclude

tuned-ppd

:

sudo dnf system-upgrade download --releasever=44 --exclude=tuned-ppd
sudo dnf system-upgrade reboot

If you launched the upgrade from GNOME Software / Discover, drop to a terminal and use the

dnf

command above instead — the GUI doesn’t give you an exclude option.

If

dnf

complains that

tuned-ppd

is being pulled in by another package (e.g., a desktop meta-package), you can also try:

sudo dnf system-upgrade download --releasever=44 --allowerasing --exclude=tuned-ppd

After the upgrade, verify TLP is active and PPD/tuned-ppd are not:

systemctl status tlp
systemctl status tuned-ppd power-profiles-daemon 2>/dev/null
sudo tlp-stat -s

Option B — Switch to

tuned-ppd

(the new Fedora default)

If you’d rather adopt the Fedora default power management stack, remove TLP first, then run the upgrade:

sudo systemctl stop tlp
sudo systemctl disable tlp
sudo dnf remove tlp tlp-rdw
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot

After reboot,

tuned

and

tuned-ppd

will provide the Power Profile slider in GNOME/KDE.

Which should you choose?

TLP generally tunes more knobs out of the box. Anecdotally, when using tlp, powertop usually shows that every tunable is good, while with ppd or tuned-ppd the result is different — tlp may be more efficient in some areas[4].
tuned-ppd integrates natively with the GNOME/KDE Power Profile selector and is what Fedora ships by default going forward, and tuned allows configuring various aspects of the sys/hw and not just the cpu states[5].

If you’ve intentionally installed TLP and tuned it, go with Option A. If you don’t remember why TLP is installed and you just want the stock Fedora experience, go with Option B.

Why

--skip-broken

/

--best=false

won’t help here

This is a file conflict at the RPM level (two packages claiming the same path), not a dependency-resolution problem. So flags like

--skip-broken

,

--nobest

, or

--allowerasing

alone won’t bypass it unless they actually result in one of the two packages being removed from the transaction. You must explicitly exclude or remove one side.

I tried to copy and paste, however it looked horrible. Then it is from the Fedora Magazine, which we do have a own category now. I would find it great if we could at least the F44 related topics, transfer into it already and redirect from the Magazine to discussion.

@glb is there a way to transform WP content/comments into markdown so that we could move for the stable versions content from F44 into discussion?

Thx @fasulia that you took the time to move it over.

Fedora Magazine comments on all future articles should automatically get redirected here, so:

  • they will no longer close automatically
  • TL1+ users should be able to edit their comments after posting them
  • Discourse’s code formatting functions will work in the comments
  • moderators should be able to bump questions from the Fedora Magazine comment section over to Ask Fedora when appropriate rather than having to ask the user to repost their question in the right place
  • a Fedora Account will be required to comment, so CoC rules will apply to comments
  • there is a larger moderation team here on Discourse to help with managing the comments

I think there is a way to do that, but it isn’t something that I was planning to do and I certainly haven’t tested it. How badly do you want this done? I could attempt it, but my preference would be not to experiment with that.

Not badly, If I can do it I will.

After further research I see that I should have kept tuned, and deleted the tlp. On the day I couldn’t find any clear reason for one over the other. I wonder if the upgrade re installed the tuned package :thinking:

So Fedora still has not updated the F44 installation pack??
it seams like listen to my gut feeling and Odin was wise, i thought it could be wise to wait with F44 this upgrade.. So its the 30th of May 2026, is this fixed?

i use F43 on both my Gaming PC and my Work Laptop, and use both for work then i work from home some days and weekends (working for a Swedish Hosting company) so i dont dare do a upgrade that might brick my work PC. (yes we are mostly a Linux OS using company, Domain, servers and clients.)

Niclas, if I were in your situation I would run a few DNF list commands to figure out which of the two is installed. I don’t think it’s a flaw of the updater, rather the age of the original install, or the frequency of the updates on the system.

I ran into the problem on a USB system that I maintain as a lifeboat. It only gets booted up to update a few times a year. My daily driver updated seamlessly because… daily driver with all the updates.

Hope this helps.

The reference to the article above is very helpful for deciding which one to keep. They can easily be removed and replaced without system instability. Just install the replacement before restarting.

ah thank you. :sign_of_the_horns:

My work PC is a fresh F43 installation cuz i did get a new PC in April.
my “Gaming PC” got a fresh install with F42 and upgraded to F43 and seams to be clean after running

XXXX@fedora:/$ sudo dnf check
XXXX@fedora:/$
XXXX@fedora:/$ grep -rE “baseurl|metalink” /etc/yum.repos.d/

long list without any broken stuff..

Me to, on a installation I updated since F33 or F34, I just removed TLP before installation and the messages not appeared.

I even found the change description, it was made for F35; time pasts so fast:

And TLP is:

Description    : TLP is a feature-rich command-line utility, saving laptop battery power
               : without the need to delve deeper into technical details.

I checked on a new install, TLP is not installed by default. So the packages which are conflicting is just on Laptops which installed the cmd utility to save battery power.

I not have a Laptop but I just installed it to learn about.

Which is the newer package?

Tuned-ppd is the “new” one.

But before you just go with that; please read the article 'Michael :slight_smile: der-michel posted way up there ^^^. It explains why and the reasoning behind keeping either option. Heck. I’ll just repost it here too.

The Article that explains this problem.

Does this also apply to KDE? I recently purged all of Gnome and switched to KDE.

According to that article on the topic gnome and KDE share this package.