Install Pantheon Desktop Environment on Fedora 44 / 43

There is exactly one way to install the Pantheon desktop on Fedora today, and it is not the dnf group that every older guide points at. That group was retired years ago, along with most of the packages behind it, so the command still circulating in forum answers now fails on a clean machine.

Original content from computingforgeeks.com - post 17405

What follows is the route that does work: a community COPR repository that carries the whole elementary stack, a display manager to launch it, and the gaps you have to fill by hand afterwards. It covers what Fedora still ships from the old Pantheon group, why the leftover shell package cannot even be installed on the current release, and how to strip the whole thing back out if you decide Pantheon is not for you. Every command below was run on Fedora 44 machines (kernel 7.1.8, dnf5, mutter 50.4) in August 2026. The Fedora 43 side was checked by installing the same transaction against that release’s repositories rather than by booting a session on it, and the one place the two releases genuinely diverge is called out where it matters.

Why the pantheon desktop group no longer resolves

Start with the command that used to work, because seeing it fail is the fastest way to understand what changed:

sudo dnf group install 'pantheon desktop'

dnf5 does not offer a suggestion or a near match. It resolves nothing and exits non-zero:

Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
No match for argument: pantheon desktop
You can try to add to command line:
  --skip-unavailable to skip unavailable packages

Error: “No match for argument: pantheon desktop”

The group does not exist. Fedora’s comps file defined a pantheon-desktop group from Fedora 30 through Fedora 36, 52 packages in its final release, and the group was dropped when Fedora 37 shipped. Nothing has replaced it since, so there is no group, no environment, and no spin to install.

There is a second trap worth knowing about, which is that a dnf5 group query for a name that does not exist prints nothing and exits 0, so an absent group reads exactly like an empty one:

sudo dnf group list --hidden | grep -i -e pantheon -e elementary
sudo dnf group info 'Pantheon Desktop'

The first command prints nothing at all. The second prints only its two repository-loading lines and then stops, which is the shape of a name dnf5 has never heard of rather than a group that happens to be empty.

Why the packages went away is recorded in Fedora’s own package repositories. The session definition, the settings app and the login greeter were all pulled with the same note in their retirement marker, which you can read on the session-settings dist-git page:

remove package (temporarily) due to unresolved issues with GNOME 43

GNOME 43 was the Fedora 37 desktop, which lines up exactly with the release where the group disappeared, and the word “temporarily” never came good.

A second and much later wave has since caught most of what survived that first cut. Fourteen of the old group’s packages now carry a blunter marker on Fedora’s development branch: the window manager, the panel, the file manager, six of the applications, the notification server, the contractor service and three of the panel indicators.

Orphaned for 6+ weeks

That matters for the table in the next section. Of the sixteen packages it lists as surviving, thirteen are already absent from rawhide, and only the icon theme, plank and gnome-session are still standing there. The applications survived the first cut on the releases this guide covers, and they did not survive the second one.

What Fedora still ships from the old Pantheon group

More than you would expect, and less than you need. Of the 52 packages the old group pulled in, 16 are still in the current release’s repositories, and 17 in the one before it, which kept the contractor service a cycle longer. On these two releases the applications survived and the shell did not.

Still in the Fedora repositories	Gone
Files, Code, Calendar, Music, Photos, Camera, Calculator	Terminal, Videos, Print, Sideload, Shortcut Overlay
gala (window manager), wingpanel (panel, see below)	pantheon-session-settings, elementary-greeter
elementary-icon-theme, elementary-notifications, plank	switchboard and every settings plug
Bluetooth, date/time and keyboard indicators	Network, power, sound, session and notification indicators
gnome-session, which the group leaned on to start	Applications menu, contractor, theme, wallpapers, sound theme

Fedora has also picked up a few elementary application packages since the group was dropped, including a settings daemon, a screenshot tool and a mail client, so the left column is not frozen in 2022. None of them is a shell or a session, and all of them carry the same orphan marker on the development branch, so they are on the same path out. The two entries that matter most are on the right. pantheon-session-settings is the package that installs the session definition, and elementary-greeter is the login screen. Without the first one there is nothing for a display manager to offer you, which you can prove in one query:

sudo dnf provides '/usr/share/wayland-sessions/pantheon*'

No package in Fedora owns that path:

Updating and loading repositories:
Repositories loaded.
No matches found. If searching for a file, try specifying the full path or using a wildcard prefix ("*/") at the beginning.

Install every surviving piece by hand and the session directories stay empty, so there is still no Pantheon entry at the login screen. That is the whole reason this guide needs a third-party repository.

Error: “nothing provides libmutter-17.so.0 needed by wingpanel”

Fedora’s own wingpanel package cannot be installed on the current release at all. The panel links against mutter, Fedora moved mutter to the GNOME 50 series, and the soname moved with it. Ask for the package and the resolver stops before it downloads anything:

sudo dnf install wingpanel

The build in the repository was compiled against the previous soname and never rebuilt:

Failed to resolve the transaction:
  - nothing provides libmutter-17.so.0 needed by wingpanel-8.0.4^20260127.gitcd4852e-1.fc44.i686 from fedora
  - nothing provides libmutter-clutter-17.so.0 needed by wingpanel-8.0.4^20260127.gitcd4852e-1.fc44.i686 from fedora
  - nothing provides libmutter-cogl-17.so.0 needed by wingpanel-8.0.4^20260127.gitcd4852e-1.fc44.i686 from fedora
  - nothing provides libmutter-17.so.0()(64bit) needed by wingpanel-8.0.4^20260127.gitcd4852e-1.fc44.x86_64 from fedora
  - nothing provides libmutter-clutter-17.so.0()(64bit) needed by wingpanel-8.0.4^20260127.gitcd4852e-1.fc44.x86_64 from fedora
  - nothing provides libmutter-cogl-17.so.0()(64bit) needed by wingpanel-8.0.4^20260127.gitcd4852e-1.fc44.x86_64 from fedora
You can try to add to command line:
  --skip-broken to skip uninstallable packages

gala escaped the same fate. The build sitting in the repository is newer and links the current soname, so the window manager installs cleanly while the panel next to it does not. That split is the single reason a third-party rebuild of the panel is unavoidable here, and it is worth confirming with your own eyes rather than taking on trust. Ask the repositories rather than the installed system, which also means you can run this before installing anything, and run it before you enable any third-party repository or you will be reading the rebuild’s metadata instead of Fedora’s:

dnf repoquery --provides mutter | grep '^libmutter'
dnf repoquery --requires gala | grep -i mutter

Both queries return the same eight lines, and that identity is the point: gala asks for precisely the four sonames mutter hands out. Each appears twice because Fedora ships an i686 build alongside the x86_64 one and RPM records the capability differently for each, which is also why the resolver error above named an .i686 candidate next to the .x86_64 one:

libmutter-18.so.0
libmutter-18.so.0()(64bit)
libmutter-clutter-18.so.0
libmutter-clutter-18.so.0()(64bit)
libmutter-cogl-18.so.0
libmutter-cogl-18.so.0()(64bit)
libmutter-mtk-18.so.0
libmutter-mtk-18.so.0()(64bit)

The panel is a number behind on three of those four. It asks for libmutter-17, libmutter-clutter-17 and libmutter-cogl-17, and never asks for the mtk one at all, which is why the failure further up lists three lines per architecture instead of four.

This is the one place where the two releases in the title behave differently. The previous Fedora release still carries the older mutter, so the Fedora-shipped panel’s dependencies resolve there and this error does not appear. It buys you nothing, because that release is missing the session definition and the greeter exactly as the current one is, but it does mean the broken-dependency wall above is specific to the newer release.

Enable the Pantheon COPR repository

The stack that works is garaevdi/pantheon-rpm, which the owner describes as “Experimental efforts of packaging pantheon desktop”. Take that at face value before you commit a daily driver to it. It carries 64 source packages, builds for both x86_64 and aarch64, and it is genuinely active, with builds landing through mid-August 2026 as this was written. Twenty of its 184 builds are recorded as failures, which sounds worse than it is: the window manager is one of them, and that build succeeded on all four Fedora 43 and 44 chroots while failing only on the two rawhide ones. A project-level state of “failed” can mean nothing more than that. Chroots exist for the next Fedora release too, but they are branch forks rather than finished work, and its x86_64 tree currently holds most of the panel indicators without the panel itself, so the metapackage cannot resolve there yet. Treat this as a 44 and 43 proposition.

The copr subcommand is not built into dnf5, and this is where a lot of copied-around instructions go wrong. It comes from dnf5-plugins, not from the dnf-plugins-core package that older guides name: that one carries the dnf4 plugin, pulls in the dnf4 Python stack behind it, and still leaves you without dnf copr. Ask the package manager rather than guessing:

sudo dnf provides 'dnf5-command(copr)'

Every line of the answer names dnf5-plugins. It is a default member of Fedora’s core group, so on Workstation and on Cloud Base it is already installed and the install below is a no-op. Run it anyway on a stripped-down system, then enable the repository:

sudo dnf install dnf5-plugins
sudo dnf copr enable garaevdi/pantheon-rpm

Answer y to the warning about COPR content not being held to Fedora’s quality or security standards, then confirm the repository is actually serving packages rather than a stale empty chroot:

dnf repoquery --repo='copr:copr.fedorainfracloud.org:garaevdi:pantheon-rpm' --qf '%{name}\n' \
  | grep -vE 'debuginfo|debugsource' | sort -u | wc -l

The filter matters: drop it and most of what you count is debug metadata rather than anything installable. Filtered, the answer was 80 distinct package names on the test machine, and the figure moves as builds land, so treat the order of magnitude as the signal. If it prints 0, the chroot for your release has not been built and you should stop here rather than fight it.

Install the Pantheon desktop on Fedora

The repository ships two metapackages, and the first one is the desktop itself:

sudo dnf install metapkg-pantheon-shell

It pulls ten direct dependencies, which is a useful list to know because it tells you exactly what “Pantheon” means as a package set: gala and gala-wayland for the window manager, wingpanel for the top bar, elementary-dock for the dock, elementary-settings and elementary-settings-daemon, elementary-greeter, elementary-wallpapers, pantheon-agent-polkit and xdg-desktop-portal-pantheon. It also carries two Suggests, for the screenshot tool and the sound theme, and dnf ignores Suggests by default, which is why a fresh Pantheon session has no screenshot tool in it. The screenshot tool is a near miss worth knowing about: it does not arrive, but the COPR’s build of it is newer than Fedora’s, so if you already had Fedora’s copy installed it gets pulled across on the next upgrade anyway. Everything else arrives as a transitive dependency, and there are a lot of those on a machine that has never had a desktop on it:

Transaction Summary:
 Installing:       502 packages

Total size of inbound packages is 484 MiB. Need to download 484 MiB.
After this operation, 2 GiB extra will be used (install 2 GiB, remove 0 B).

That summary was taken on a second, untouched Cloud Base clone with no desktop on it, which is why it is a clean figure rather than one polluted by the walkthrough. Read 2 GiB as the floor for the shell and expect a smaller transaction on a machine that already runs GNOME or KDE. There is a second cost the summary does not spell out. A number of these packages exist in Fedora’s repositories too, and where both sides ship one, dnf takes whichever build sorts newer. Epochs are 0 on both sides throughout this stack, so that comes down to comparing the version first and falling back to the release only to break a tie. That distinction matters here, because for most of them the COPR carries a higher version on a lower release number and still wins. Eleven arrive as newer COPR builds and displace Fedora’s: gala and gala-wayland, the panel, Files, Code, Calendar, Mail, Photos, the icon theme, the settings daemon and the onboarding tour. So this transaction quietly moves those eleven off Fedora’s builds, twelve if you also had Fedora’s screenshot tool installed, which is worth knowing before you run it rather than after.

The shell metapackage deliberately leaves out the applications, so the second one is what gives you a usable desktop rather than an empty panel:

sudo dnf install metapkg-elementary-apps

That one is a modest 40 packages and recommends thirteen applications: the elementary Terminal, AppCenter, Files, Code, Photos, Calendar, Mail, Sideload, the system monitor, the onboarding tour and the shortcut overlay. Two of the thirteen never arrive at all. Tasks is not built in this repository and Fedora retired it years ago, and a captive-portal helper is both misspelled in the spec and absent from the repository, so correcting the typo would not rescue it either. Its only two hard requirements are Switchboard and the Bluetooth daemon. Switchboard is the System Settings app, and the similarly named elementary-settings in the shell list above is only a bundle of polkit rules, gschema overrides and skeleton files, so the settings window arrives with the applications rather than with the shell. Skip this metapackage and you get a Pantheon desktop with no settings app in it at all.

Enable a display manager and find the session

LightDM comes in as a dependency of the greeter, so the only thing left is to make it the active display manager and to switch the machine to a graphical boot:

sudo systemctl set-default graphical.target
sudo systemctl enable lightdm

On a Workstation install that already boots into GDM, that second command refuses outright. Both units claim the same display-manager.service alias, and systemd will not overwrite an existing one:

Failed to enable unit: File '/etc/systemd/system/display-manager.service' already exists and is a symlink to /usr/lib/systemd/system/gdm.service

Retire the old one first and the symlink moves across cleanly:

sudo systemctl disable gdm
sudo systemctl enable lightdm
readlink -f /etc/systemd/system/display-manager.service

The last line should print the LightDM unit path. Keeping GDM instead is a defensible choice: the session file lands in the standard /usr/share/wayland-sessions/ directory that display managers read, and the elementary greeter is a cosmetic upgrade rather than a requirement. This walkthrough switches because the greeter arrives with the metapackage anyway. Reboot either way, since a running display manager will not pick up a session that appeared underneath it.

Now the part that catches people out. The session is not called Pantheon on the login screen. Read the file the session-settings package installed:

grep -E '^(Name|Comment|Exec|DesktopNames|Type)=' /usr/share/wayland-sessions/pantheon-wayland.desktop

The user-visible name is generic while the identity is buried in the comment and the desktop-names field:

Name=Secure Session
Comment=Pantheon on Wayland
Exec=gnome-session --session=pantheon-wayland
DesktopNames=Pantheon
Type=Application

So at the login screen you pick Secure Session, not Pantheon. There is no X11 session file in the package either, and that is the packager’s decision rather than a missing feature. Upstream still ships an X11 session file, and the release this COPR builds still defaults its x11 meson option to true, but the spec compiles it with -Dx11=false, so /usr/share/xsessions/ stays empty here. Rebuilding that one package with the option turned back on is the obvious escape hatch if you need an X session, though it is a pointer rather than a path this guide has walked. elementary OS itself still offers an X11 session, which it calls Classic Session, next to the Wayland one.

Reboot, and the elementary greeter replaces the plain LightDM login box:

The gear next to the password field is the session picker. On a box where Pantheon is the only session there is nothing else in that menu, so an empty-looking picker is not a broken greeter, and on a Workstation install the GNOME entry sits alongside it.

Verify the Pantheon session

Log in and you get the real thing: wingpanel across the top with the applications menu on the left and the indicators on the right, the elementary dock at the bottom, and elementary’s own wallpaper behind it.

The dock starts almost empty, with a single placeholder tile, because nothing has been pinned yet. Two environment variables confirm you are in the session you think you are in rather than in a GNOME fallback wearing an elementary theme:

echo $XDG_CURRENT_DESKTOP $XDG_SESSION_TYPE
rpm -q gala wingpanel elementary-dock elementary-settings

Run both from the elementary Terminal and the picture is complete. Note the release tag on the panel package: it ends in -2, which is the COPR rebuild against the current mutter, not the -1 build sitting broken in Fedora’s own repository.

If XDG_CURRENT_DESKTOP comes back empty or says GNOME, you logged into the wrong session and the greeter’s gear menu is where to fix it.

Fill the gaps the metapackage leaves

Two things are missing from a fresh install, and neither announces itself. Open System Settings and count the panels:

Sixteen panels, no Printers and no Sharing. Nothing is broken: the plugs are not dependencies of anything, they carry a Supplements: switchboard tag, so dnf pulls each one in on its own once Switchboard is present. The two missing ones supplement a pair of packages instead of one, (switchboard and cups) for Printers and (switchboard and rygel) for Sharing, so on a box with neither of those installed the condition never fires. Ask for them by name:

sudo dnf install switchboard-plug-printers switchboard-plug-sharing

That transaction is larger than it looks, 62 packages on a machine with no print stack, because the printers plug requires CUPS and the sharing plug requires rygel, which between them pull the whole printing and media-sharing chain behind them. The two panels appear the next time Settings starts.

Error: “Unable to get list of updatable flatpaks: The name is not activatable”

AppCenter is a Flatpak front end, so on a machine without Flatpak it starts and then does nothing useful. The failure only shows up in the journal:

journalctl --user -b | grep -i flatpak

The message repeats every time the app checks for updates:

io.elementary.appcenter[5363]: FlatpakBackend.vala:1991: Unable to get list of updatable flatpaks: The name is not activatable

Install Flatpak and point it at elementary’s own repository. Name the remote appcenter rather than elementary, because AppCenter decides which applications are curated by matching the origin string against that exact name, and the repository file itself is titled AppCenter. The COPR’s own quick-setup page names the remote elementary, which works for browsing but costs you that curated handling:

sudo dnf install flatpak
flatpak remote-add --if-not-exists --user appcenter https://flatpak.elementaryos.org/repo.flatpakrepo
flatpak remote-ls --user appcenter --app | wc -l

The remote answered with 158 applications on the test machine. Adding Flathub as well is a reasonable idea if you want a wider catalogue, and the Flatpak and Flathub setup on Fedora covers that side of it. Restart AppCenter afterwards and the categories populate:

One caveat worth setting expectations on: these packages are built from elementary’s git snapshots by a single maintainer, so the versions you get here move independently of an elementary OS release. Nothing about that breaks the desktop. It does mean that if the point of the exercise is elementary as its developers ship it, running elementary OS itself is the shorter path.

Remove Pantheon and get your old desktop back

Six hundred packages, once you count the shell, the applications and the printing stack, is a lot to leave behind on a machine you were only curious about, and the obvious removal does not go far enough, so start with the metapackages and keep going:

sudo dnf remove metapkg-pantheon-shell metapkg-elementary-apps

The session file goes with them, so the login screen stops offering Secure Session immediately. LightDM goes too, because the greeter hard-requires it, and that takes display-manager.service off the system entirely. Do not plan on running systemctl disable lightdm afterwards; there is no unit left to disable.

What survives this first pass is Switchboard and every one of its plugs. The two plugs you asked for by name are user-installed rather than dependencies, they require Switchboard, and Switchboard then keeps every plug that supplements it. Sweep the lot separately:

sudo dnf remove 'switchboard*' elementary-bluetooth-daemon
sudo dnf autoremove

Confirm that nothing is hiding behind a name you did not think of. Do not bother writing a glob for it, because the repository’s 80 packages include names like granite-7, appcenter, expandtheon and plymouth-theme-elementary that no sensible glob catches. Ask by origin instead:

dnf list --installed | grep pantheon-rpm | wc -l

Zero is the answer you want, unless you were already running some of these packages from Fedora before you enabled the COPR, in which case those stay and the count reflects them. Set expectations on the disk either way, because a clean removal is not a clean reversal. These figures come off the walkthrough machine rather than the clean clone, and GDM, Flatpak and the printing stack were all already on it when the first reading was taken. It went from 1,197 packages and 3,135 MiB used down to 1,000 packages and 2,850 MiB, so 285 MiB came back out of a desktop that cost 2 GiB to put on. Nothing was left dangling either: dnf repoquery --unneeded returned zero afterwards, so no package sat there orphaned by the removal. That is not the same as saying nothing could go, because the same box reported 82 user-installed packages, and the generic GTK, PipeWire, portal and font libraries those three pull between them are exactly what stays behind.

Deal with the repository next. Note that disable only sets enabled=0 and leaves the repo file in place; dnf copr remove is the one that deletes it. If you had been using any of the eleven displaced packages from Fedora before enabling the COPR, they are user-installed, the sweep above left them behind, and they are still sitting on the COPR build, so follow up with a sync to pull them back to Fedora’s versions:

sudo dnf copr remove garaevdi/pantheon-rpm
sudo dnf distro-sync

Then put a display manager back, unless you kept GDM earlier and it is still enabled, in which case there is nothing to do here. Otherwise there is none enabled at this point, so the graphical target reaches its end and hands you a text login on tty1 instead of a desktop, which is survivable but not what anyone wants on a machine they use with a mouse. Install the one you had, if it went with the sweep, and enable it:

sudo dnf install gdm
sudo systemctl enable gdm
systemctl is-enabled gdm

Substitute sddm if you came from KDE. Enabling a display manager does not start it, so reboot to get off tty1 and back to a graphical login. If Pantheon was not what you hoped for but you still want something lighter than GNOME on the same box, Budgie and Cinnamon are both real Fedora groups that install in one command, Xfce is the lightest of the three, and Deepin sits in much the same third-party situation as Pantheon if you want to compare the two rebuild efforts. Readers coming from the other direction can find the same stack packaged properly in the Pantheon on Ubuntu guide.