Install Pantheon Desktop on Fedora 44 / 45: COPR Guide and Fixes

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, one PAM edit that LightDM now needs before it will open a Wayland session, and the gaps you have to fill by hand afterwards. It covers what Fedora still ships from the old Pantheon group, why Fedora 45 is a different story (the COPR installs there, but its window manager will not start against the newer mutter, so you land on a text console), and how to strip the whole thing back out if you decide Pantheon is not for you. The install, login and Fedora 45 steps below were rerun on fresh Fedora 44 and Fedora 45 machines in October 2026 with SELinux enforcing; the settings, AppCenter and removal sections are from the August Fedora 44 walkthrough and still apply there.

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 at its last revision, 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 does not fail. Run the two checks people usually reach for:

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

The first prints nothing, because no group carries either name. The second says so in words and still exits 0, so a script that only checks the exit code reads it as success:

Updating and loading repositories:
Repositories loaded.
No matches found.

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 second wave has now reached a stable release. Fedora 44 still carries the applications that survived the first cut, and Fedora 45 does not: the window manager, the panel, the applications, the indicators and the notification server are all gone from its repositories, so the table in the next section is a Fedora 44 picture.

What Fedora still ships from the old Pantheon group

On Fedora 44, more than you would expect and less than you need. Of the 52 packages the old group pulled in, 16 are still in its repositories. The applications survived and the shell did not:

Still in the Fedora 44 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 none of them made it into Fedora 45. 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.

Fedora 45 answers that query the same way, and its leftovers are thinner again. Ask its repositories for every name the old group used:

dnf repoquery --qf '%{name} %{version}-%{release} %{repoid}\n' 'elementary-*' 'pantheon-*' 'switchboard*' 'wingpanel*' gala plank 'io.elementary*' contractor granite granite-7 | sort -u

Icon themes, the GTK3 granite library and plank are all that is left. The Xfce icon theme shows up twice only because our machine also had a newer build waiting in updates-testing:

elementary-icon-theme 8.1.0-5.fc45 fedora
elementary-icon-theme-gimp-palette 8.1.0-5.fc45 fedora
elementary-icon-theme-inkscape-palette 8.1.0-5.fc45 fedora
elementary-xfce-icon-theme 0.22-3.fc45 fedora
elementary-xfce-icon-theme 0.23-1.fc45 updates-testing
granite 6.2.0-13.fc45 fedora
plank 0.11.89-21.20210202.git013d051.fc45 fedora

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

Fedora 44’s own wingpanel package cannot be installed 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. The two --repo options keep any third-party repository you have already enabled out of the answer, so you read Fedora’s metadata rather than a rebuild’s:

dnf repoquery --repo=fedora --repo=updates --provides mutter | grep '^libmutter'
dnf repoquery --repo=fedora --repo=updates --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.

Fedora 45 never gets as far as a dependency error. Both packages are simply gone, so the same install stops at the name, and the same answer comes back for gala:

Failed to resolve the transaction:
No match for argument: wingpanel
You can try to add to command line:
  --skip-unavailable to skip unavailable packages

Its mutter has also moved on to the GNOME 51 sonames, libmutter-51.so.0 and friends. Keep that number in mind, because it is the reason the COPR build of gala fails on 45 further down.

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 x86_64 and aarch64 on Fedora 43, 44, 45 and rawhide, and both the 44 and 45 trees are complete, at 80 installable package names each on our machines. Completeness is not the same as working, though. The newest build in the project when this was written was the gala rebuild from early September, and that build is what breaks the 45 session, which the Fedora 45 section walks through. Treat this as a Fedora 44 proposition until gala is rebuilt.

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 both releases, 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:       503 packages

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

That summary comes from a fresh Fedora 44 Cloud Base clone with no desktop on it, so read 2 GiB as the ceiling. A machine that already runs GNOME shares most of the stack: on a Fedora 45 Workstation install the same metapackage came to 71 packages and 169 MiB. There is a second cost on Fedora 44 that 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 on Fedora 44 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 38 packages on Fedora 44 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.

Error: “Failed to open PAM session: Cannot make/remove an entry for the specified session”

This is where Fedora 44 now trips. The greeter accepts your password, the screen blanks for a moment, and you are back at the same login card with no message at all. LightDM’s session never started, and the reason is in the journal, not on screen. Switch to a text console with Ctrl+Alt+F3 (or SSH in) and ask for it:

sudo journalctl -b -o cat | grep -E 'pam_selinux\(lightdm|Failed to open PAM session' | sort -u

However many attempts you made, sort -u folds them into two lines, and the second one is the cause:

Failed to open PAM session: Cannot make/remove an entry for the specified session
pam_selinux(lightdm:session): Failed to get current context for /dev/tty/1: Not a directory

LightDM hands PAM the session’s terminal as tty/1, and logind records the same name. pam_selinux treats a terminal name that does not start with /dev/ as a path under it, so it goes looking for /dev/tty/1 to relabel. That path cannot exist, because /dev/tty is itself a device node rather than a directory, hence “Not a directory”. The pam_selinux.so open line in LightDM’s PAM stack is marked required, so with SELinux enforcing the whole session is refused before gnome-session gets to run.

Do not reach for setenforce 0. We tried it, and permissive mode turns the refusal into a crash: the LightDM session child segfaulted inside pam_selinux while relabelling the same terminal, and you land back at the greeter just the same. The core dump says exactly where:

sudo coredumpctl info --no-pager lightdm | grep -m1 -A7 'Stack trace of thread'

The top frames are pam_selinux calling setfilecon on a terminal context it never managed to read:

                Stack trace of thread 8868:
                #0  0x00007ff8afbfe29c __strlen_evex (libc.so.6 + 0x15d29c)
                #1  0x00007ff8afa022bc setfilecon_raw (libselinux.so.1 + 0x212bc)
                #2  0x00007ff8afa023a3 setfilecon (libselinux.so.1 + 0x213a3)
                #3  0x00007ff8af689fb3 set_file_context (pam_selinux.so + 0xfb3)
                #4  0x00007ff8af68a1cc set_context (pam_selinux.so + 0x11cc)
                #5  0x00007ff8afcce00f _pam_dispatch (libpam.so.0 + 0x700f)
                #6  0x000055583c85cb3a session_child_run (lightdm + 0x24b3a)

The fix is a single option. nottys tells pam_selinux to leave the terminal’s label alone while still giving the session its SELinux context, which is the part that matters. Add it to both pam_selinux session lines in LightDM’s own PAM file, which is not managed by authselect:

sudo sed -i 's/^\(session *required *pam_selinux.so \(close\|open\)\)$/\1 nottys/' /etc/pam.d/lightdm
grep pam_selinux /etc/pam.d/lightdm

The two session lines should now end in nottys. The auth line is a different module and stays as it is:

auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
session    required    pam_selinux.so close nottys
session    required    pam_selinux.so open nottys

Restart LightDM from the console with sudo systemctl restart lightdm, log in again, and the session opens with SELinux still enforcing. The Fedora package ships /etc/pam.d/lightdm as %config(noreplace), so a later LightDM update keeps your edit and drops any new upstream copy beside it as lightdm.rpmnew. This did not happen when this guide was first written in August, and Fedora 44 received a new LightDM release shortly afterwards, so a future update may make the edit unnecessary. The edit is harmless either way.

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 with a handful of application tiles and nothing pinned by you yet. Open the elementary Terminal from the Applications menu and confirm you are in the session you think you are in, rather than in a GNOME fallback wearing an elementary theme. The loginctl line asks logind for its record of your graphical session; it looks the session up through your user because a terminal started from the menu does not carry XDG_SESSION_ID:

echo $XDG_CURRENT_DESKTOP $XDG_SESSION_TYPE
loginctl show-session "$(loginctl show-user "$USER" -p Display --value)" -p Type -p Desktop -p Class -p TTY
rpm -q gala wingpanel elementary-dock elementary-settings
getenforce

Pantheon on Wayland, a logind user session on tty/1 (the terminal name behind the PAM failure above), and SELinux still enforcing. 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.

Fedora 45: the COPR installs, but gala will not start

Everything up to the reboot goes through on Fedora 45 without a single complaint. The COPR’s 45 tree resolves, the shell metapackage installs, the applications metapackage adds 21 more packages, the session file lands in /usr/share/wayland-sessions/, and LightDM takes over display-manager.service. Then the machine boots to a text login prompt where the greeter should be.

Error: “undefined symbol: clutter_get_default_backend”

The elementary greeter is gala running in greeter mode, so when gala cannot load, there is no login screen to show. Log in on the console and start it by hand to see why:

gala --version

It never gets as far as printing a version. The dynamic linker stops it first:

gala: symbol lookup error: /lib64/libgala.so.0: undefined symbol: clutter_get_default_backend

LightDM’s greeter log carries the identical line, and systemd has given up on the unit, which confirms this is the failure behind the missing login screen rather than a second problem:

systemctl is-failed lightdm
sudo grep -m1 'undefined symbol' /var/log/lightdm/seat0-greeter.log

Both answers point at the same symbol:

failed
gala: symbol lookup error: /lib64/libgala.so.0: undefined symbol: clutter_get_default_backend

The COPR’s 45 build of gala links the libmutter-51 sonames, so the dependency check passes and dnf installs it happily, but the code still calls a Clutter function that the mutter Fedora 45 ships no longer exports. A reinstall or a dnf distro-sync will not change that. The COPR build already carries upstream’s open mutter 51 port: its mutter51.patch is the same five-commit series as gala pull request 2866, plus one extra file. Upstream has since merged a separate fix for that one removed call (pull request 2942), so we rebuilt the source package on Fedora 45 with both applied. The build still fails, because this mutter also dropped background API that gala depends on:

../src/WindowManager.vala:142:2: error: implicit declaration of function ‘meta_background_refresh_all’; did you mean ‘meta_background_group_new’? [-Wimplicit-function-declaration]
src/gala.p/Background/Background.c:23:10: fatal error: meta/meta-background-image.h: No such file or directory

So there is no local patch to apply yet. Pantheon on Fedora 45 waits on the mutter 51 port in upstream gala being finished and on the COPR shipping a build of it. If you run Pantheon on Fedora 44 today, that is also the reason to hold off on the upgrade to 45: the COPR’s 45 tree carries this same gala build, and an upgraded machine has no reason to end up anywhere other than the same text console. If you upgrade anyway, install and enable GDM (or another display manager) first, so the upgraded machine has a login screen that does not depend on gala.

Get a graphical login back on Fedora 45

GDM is still installed on a Workstation machine, so recovery is two unit changes from the console:

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

The symlink moves back to GDM’s unit:

Removed '/etc/systemd/system/display-manager.service'.
Created symlink '/etc/systemd/system/display-manager.service' → '/usr/lib/systemd/system/gdm.service'.
/usr/lib/systemd/system/gdm.service

Reboot and the GNOME login screen is back. The Pantheon packages can stay installed while you wait, or come out with the removal steps at the end of this guide. To find out whether a usable gala has landed, check what the COPR is serving and whether the binary loads, from any terminal:

dnf repoquery --refresh --repo='copr:copr.fedorainfracloud.org:garaevdi:pantheon-rpm' gala
sudo dnf upgrade --refresh gala
gala --version

While the last command still prints the symbol lookup error, stay on GDM. Once it prints a version, switch back to LightDM the same way as in the display manager section above.

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. If you added nottys earlier, rpm keeps the edited PAM file as /etc/pam.d/lightdm.rpmsave when the package goes, and you can delete it.

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. On Fedora 44, 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 has fallen out of Fedora in much the same way, if you want to compare how far the two community rebuilds have got. Readers coming from the other direction can find the same stack packaged properly in the Pantheon on Ubuntu guide.