Installing COSMIC on Fedora means picking one of three routes to the same System76 desktop. You can use the COSMIC spin, the image-based COSMIC Atomic, or a dnf group install on top of the Fedora Workstation you already run. They look identical once you’re logged in, but they differ in how updates reach you, how much disk they take and how easily you can back out. By the end of this guide you’ll have COSMIC running from the route that suits your machine.
Each route got its own VM (4 vCPU, 4 GB of RAM, 40 GB disk) with SELinux enforcing, and each one was measured with the same scripts: packages, disk, boot time and memory at the login screen. You’ll also meet the one login bug that turned up on two of the three, along with its fix. I tested all three routes on Fedora 45 in October 2026, and every step below still holds.
Choose the route that fits your machine
The quickest way to decide is to ask what you want the machine to be once COSMIC is on it. Tick the line that sounds like you:
- You want a fresh install with COSMIC as the only desktop, and you’re happy managing software with plain
dnf: install the spin. - You want an operating system you can roll back as a whole after a bad update, with apps coming from Flatpak: install COSMIC Atomic.
- You already run Fedora Workstation and want to try COSMIC without reinstalling or losing GNOME: add the
cosmic-desktopgroup.
If you’re torn between the first two, the Atomic model is the same one Silverblue uses, and the trade-offs in our Silverblue vs Workstation comparison carry straight over. If you’re still deciding between desktops altogether, our desktop environment RAM usage comparison measures GNOME, KDE Plasma, Xfce and four other desktops in a logged-in session, which is a different moment from the login-screen figures below.
The table below shows what each route left behind. Boot time is the graphical.target figure from systemd-analyze, and memory is RAM in use at the login screen 90 seconds after SSH answered, both as the range over three reboots. The spin was measured after its first upgrade, Atomic as installed, and Workstation with cosmic-greeter as its login screen.
| Measured | COSMIC spin | COSMIC Atomic | Workstation + group |
|---|---|---|---|
| Packages after install | 1,680 RPMs | 1,457 RPMs | 1,856 + 107 RPMs |
| Disk used | 4,318 MiB, 4,904 MiB after the first upgrade | 6,184 MiB | 3,850 MiB, then 4,621 MiB |
| Login screen | cosmic-greeter | cosmic-greeter | GDM until you switch |
| Desktop sessions offered | COSMIC | COSMIC | COSMIC, GNOME, GNOME Classic |
| Software tool | dnf, COSMIC Store | rpm-ostree, COSMIC Store, Flatpak | dnf, GNOME Software, COSMIC Store |
| Boot to graphical.target | 6.5 to 6.8 s | 14.2 to 15.2 s | 8.1 to 9.0 s |
| Memory at the login screen | 841 to 851 MiB | 1,072 to 1,078 MiB | 847 to 852 MiB |
| Hit the tty1 login bug | Yes, until the first upgrade | Yes, until an image with the fixed greeter | No |
Atomic has the fewest packages yet the largest disk figure. That comes from how it stores the system, not from extra apps. The whole OS sits as content-addressed objects under /sysroot/ostree, and its btrfs mounts carry no compression option. Workstation mounts btrfs with zstd compression, which is why the 107 new packages, reported by dnf as 1 GiB, grew disk use by only 771 MiB.
Install the COSMIC spin
The COSMIC spin is a live image. Download the COSMIC live ISO from the Fedora COSMIC spin page, write it to a USB stick, boot it, and start the installer from the live desktop. If you’d rather install over the network, the Everything netinstall image gets you the same desktop: choose COSMIC Desktop under Software Selection. That installs the cosmic-desktop-environment group, which bundles COSMIC with Firefox, LibreOffice, printing, multimedia and the other desktop basics. The test machine took the netinstall route, driven by a kickstart file so the run could be repeated.
Check these on a fresh install. They tell you straight away that everything landed:
- You log in through cosmic-greeter, and COSMIC is the only session it offers.
- You manage software with
dnf, and the COSMIC Store runs on top of PackageKit for RPMs plus Flatpak for anything from a remote you add. - You have Firefox, LibreOffice and Thunderbird, plus a few GNOME utilities such as Calculator, Disks and System Monitor, but no GNOME Software.
- You can browse the COSMIC Store right away, because its PackageKit backend reads Fedora’s own app listings.
The Store’s Explore page on the spin fills straight from Fedora’s RPM catalogue, so Firefox, Virtual Machine Manager and Lutris show up without any extra setup. Add Flathub the same way as on Atomic below if you want its much larger catalogue next to those.
Update the system before you do anything else. An installer can only install what its repositories carry when you run it, and the mirror the test install drew from was behind: it landed an older COSMIC release and an older kernel than Fedora’s repositories already offered:
sudo dnf upgrade --refreshThat first upgrade replaced 237 packages and added 7, a 1 GiB download that took just under 9 minutes. It’s the step that matters most on the spin, because it also replaces the greeter build carrying the tty1 bug described further down, so you’ll want it done before you set up autologin. Check that the new greeter unit names the right kmscon service:
grep -E "^(After|Conflicts)=" /usr/lib/systemd/system/cosmic-greeter.serviceBoth kmscon references should read [email protected]:
After=systemd-user-sessions.service plymouth-quit-wait.service cosmic-greeter-daemon.service
After=[email protected] [email protected]
Conflicts=[email protected] [email protected]Reboot into the new kernel, because the upgrade installs it next to the old one and the running system keeps using the old kernel until you do. From then on the spin was the quickest of the three routes on identical hardware, reaching graphical.target in 6.5 to 6.8 seconds and using 841 to 851 MiB at the login screen.
Install COSMIC Atomic
COSMIC Atomic ships as its own installer ISO from the Fedora COSMIC Atomic download page. The installer image is about 2.8 GiB and carries the whole OS image inside it, so the install deploys that image from the ISO’s own ostree repository rather than downloading a package list. I drove it with a kickstart file to keep the runs repeatable, but the graphical installer lands you in the same place. Once you’ve logged in, open a terminal from the dock and look at the deployment you booted:
rpm-ostree statusYou should see a single deployment of the cosmic-atomic image with a valid Fedora signature:
State: idle
Deployments:
● fedora:fedora/45/x86_64/cosmic-atomic
Version: 45.1.1 (2026-10-17T16:48:45Z)
Commit: 2f226fe0a04251da12bbd327c0a911353e9e829736a4de4b8a04060d4e0af8f0
GPGSignature: Valid signature by 4F50A6114CD5C6976A7F1179655A4B02F577861EA fresh COSMIC Atomic install works differently from the spin in a few ways you’ll notice in your first hour, because the OS is one signed image rather than a set of packages you manage yourself:
- You won’t find
dnf; you manage the system withrpm-ostree, and run mutable work in Toolbx. - You get all 26
cosmic-*packages baked into the image, so there is nothing to add before the desktop is complete. - You start with no Flatpak apps installed and only Fedora’s OCI registry configured as a remote.
- You decide when updates happen, because both
rpm-ostreed-automatic.timerandbootc-fetch-apply-updates.timership disabled.
The third point matters straight away, because it decides what the COSMIC Store can show you. Atomic has no PackageKit, so the Store can only list apps from Flatpak remotes. With nothing readable configured, the first thing you’d want to do on a new desktop, installing apps, looks broken until you add a remote.
Add Flathub so the Store has apps
The part that trips people up on a fresh COSMIC Atomic install is the COSMIC Store opening to a blank Explore page. That’s normal. The only Flatpak remote configured is Fedora’s OCI registry, and on the test machine the Store found nothing in it to list. Add Flathub as a system remote:
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepoOn the test machine the Explore page was still blank after adding the remote and reopening the Store, and it only filled once the app listings had been downloaded. Fetch them now:
sudo flatpak update --appstreamClose the Store and open it again from the launcher. The Explore page now fills with Flathub’s Editor’s choice picks, and you can install apps from it with one click. Our Flatpak and Flathub guide for Fedora covers the command-line side, including user installs and permission overrides.
Apps you install this way land under /var/lib/flatpak and do not touch the OS image, so they survive every system update and rollback. That’s the split Atomic is built around: the image carries the desktop and its core apps, and everything you add yourself sits outside it, so a rollback never takes your apps with it.
Update the system from the Store
The Store also handles operating system updates on Atomic. It drives rpm-ostree itself, so a new image shows up under Updates as a single System Upgrade entry rather than a list of packages.
Clicking Update ran an rpm-ostree Upgrade transaction that finished in 63 seconds and left the new image as a pending deployment next to the running one. Nothing changes until you reboot, and the old deployment stays in the boot menu if the new one misbehaves. If you prefer the terminal, rpm-ostree upgrade does the same job, and the rest of the rpm-ostree workflow (layering, rollback, pinning a deployment) works exactly as it does in our guide to managing packages on Fedora Silverblue. Over SSH, prefix it with sudo. Without it you’ll get error: rpmostreed OS operation AutomaticUpdateTrigger not allowed for user. The polkit rules only allow unprivileged updates from an active local session.
Add COSMIC to Fedora Workstation
If you already run Fedora Workstation, you do not have to reinstall to try COSMIC. Fedora ships it as a regular package group, and it installs next to GNOME without replacing anything. Check what the group contains first:
dnf group info cosmic-desktopThe mandatory packages are the session and the core apps, and the defaults add the welcome wizard, a media player and printer setup:
Id : cosmic-desktop
Name : COSMIC Desktop
Mandatory packages : cosmic-edit
: cosmic-files
: cosmic-session
: cosmic-store
: cosmic-term
Default packages : cosmic-initial-setup
: cosmic-player
: flatpak
: pam_oo7
: system-config-printer
: toolboxUse the group ID, cosmic-desktop, rather than its display name. Both the group and the cosmic-desktop-environment environment are called “COSMIC Desktop”, so the name is ambiguous while the ID is not (the DNF5 cheat sheet lists the other group commands). The environment is the full spin package set with LibreOffice, Firefox and the rest, which you already have on Workstation. Install the group:
sudo dnf group install cosmic-desktopOn the test machine this pulled 107 packages, a 345 MiB download, and finished in 1 minute 21 seconds. Near the end you’ll see a scriptlet message from the greeter package. It looks like an error, but it’s only telling you GDM stays in charge of the login screen:
>>> Running %post scriptlet: cosmic-greeter-0:1.10.0-4.fc45.x86_64
>>> Finished %post scriptlet: cosmic-greeter-0:1.10.0-4.fc45.x86_64
>>> Scriptlet output:
>>> Failed to preset unit: File '/etc/systemd/system/display-manager.service' already exists and is a symlink to /usr/lib/systemd/system/gdm.serviceLog out and click your user on the GDM screen. A gear icon appears in the bottom right corner once the password field shows, and its Session Type menu now lists COSMIC next to GNOME and GNOME Classic.
Pick COSMIC, then type your password. GDM remembers your last pick for your account, so COSMIC stays selected at the next login until you choose GNOME again from the same menu. You can try COSMIC for a day and switch back the next morning without reinstalling anything.
Your first COSMIC login opens the COSMIC welcome wizard, even on an account you’ve used with GNOME for years. The first page covers the screen reader, magnifier and display scaling, and Next takes you through the rest. That’s expected: the group pulls in cosmic-initial-setup, which starts from /etc/xdg/autostart when a COSMIC session opens. COSMIC keeps its settings in ~/.config/cosmic, separate from GNOME’s.
The two desktops share one set of desktop portals without fighting over them. The group adds xdg-desktop-portal-cosmic next to the GNOME portal, and /usr/share/xdg-desktop-portal/cosmic-portals.conf tells the portal service to prefer the COSMIC backend, then GTK, whenever the session reports XDG_CURRENT_DESKTOP=COSMIC. Secret requests go to oo7-portal first, with GNOME Keyring as the fallback, and oo7-portal was the portal process running in the COSMIC session on the test machine.
Use the COSMIC login screen instead of GDM
You can stop here if GDM’s session menu is all you need. If you’d rather boot straight to COSMIC’s own login screen, point the display manager at it. A plain systemctl enable refuses because GDM already holds the display-manager.service alias, so add --force:
sudo systemctl enable --force cosmic-greeter.servicesystemd swaps the alias from GDM to the COSMIC greeter:
Removed '/etc/systemd/system/display-manager.service'.
Created symlink '/etc/systemd/system/display-manager.service' → '/usr/lib/systemd/system/cosmic-greeter.service'.Reboot and you’ll land on cosmic-greeter. Its Session button, the gear in the row under the clock, lists the GNOME sessions too, so you can still log into GNOME from it.
With cosmic-greeter as the login screen, this Workstation VM reached graphical.target in 8.1 to 9.0 seconds across three reboots and sat at 847 to 852 MiB of memory in use at the greeter. The group only adds packages, so GNOME, GNOME Software and your files stay as they were, and the last section shows how to take it all back out.
Fix a COSMIC session that won’t start
Fedora now runs kmscon as the virtual console instead of the classic getty, and the COSMIC greeter starts on the same tty1. Its unit file is meant to stop kmscon first, but the greeter builds on the COSMIC Atomic image and on a freshly installed spin misspell the kmscon unit name. Both start together, kmscon grabs the graphics device, and the greeter’s compositor gives up. With a password login you may not notice, because systemd restarts the greeter a second later and the second attempt works.
Autologin is where it hurts. On COSMIC you turn it on by adding an [initial_session] block to the end of /etc/greetd/cosmic-greeter.toml, naming the user and the COSMIC session to start. Put your own login name in place of lorna, and run the checks below before you enable it on the spin or Atomic:
[initial_session]
command = "start-cosmic"
user = "lorna"greetd runs that session on its very first start. That’s exactly the attempt kmscon spoils. The compositor exits and cosmic-session stays running without it. Since the session never ends, greetd never brings the greeter back. On the affected Atomic VM the reboot ended on kmscon’s text login prompt. If you’re already stuck there, log in at that prompt and apply the fix below from the text console:
Three quick checks tell you whether your greeter build is the culprit: its version, the ordering lines in its unit file, and how many times systemd had to restart it this boot:
rpm -q cosmic-greeter
grep -E "^(After|Conflicts)=" /usr/lib/systemd/system/cosmic-greeter.service
systemctl show cosmic-greeter.service -p NRestartsOn an affected build the unit names ksmcon@tty1 and kmscon@tty1. Neither exists, because the real unit is kmsconvt@tty1, and a counter of 1 right after boot means the greeter lost its first round. This is the affected Atomic VM with password login:
With autologin configured the counter stays at 0 even on an affected build, because greetd hands tty1 to your session instead of failing and restarting. Rely on the unit lines and the journal in that case. The journal names the cause: the compositor cannot open the graphics device because kmscon is holding it, and greetd reports that the greeter quit:
sudo journalctl -b -t cosmic-comp -t greetd --no-pager | grep -E "busy|without"These lines are the signature to search for. The first one starts with blank space because it’s the continuation of a longer cosmic-comp error about /dev/dri/card1, and with autologin the greetd line is missing because greetd never sees the session fail:
Failed to open device: Device or resource busy (os error 16)
Oct 21 15:48:35 lorna-laptop cosmic-comp[1058]: Error occured in main(): Backend initialized without output
Oct 21 15:48:36 lorna-laptop greetd[970]: error: check_children: greeter exited without creating a sessionUpdate first, because the packagers have already fixed the typo in cosmic-greeter (Bodhi update FEDORA-2026-8e765073e8). On the spin, the first sudo dnf upgrade from the install section brought in the corrected build. On Atomic it arrives with a later image, so run sudo rpm-ostree upgrade, reboot, and repeat the grep check. If the unit still names ksmcon@tty1, a small systemd drop-in that names the right unit fixes it in the meantime. /etc stays writable on an atomic system, and rpm-ostree merges your local /etc changes into each new deployment, so the drop-in keeps working across updates. Create the drop-in directory:
sudo mkdir -p /etc/systemd/system/cosmic-greeter.service.dOpen a new file in it with nano, the default editor on both images (the spin and COSMIC Atomic both ship vi and nano, but not vim):
sudo nano /etc/systemd/system/cosmic-greeter.service.d/kmscon.confAdd these lines, which tell systemd to stop kmscon on tty1 before the greeter starts:
[Unit]
Conflicts=[email protected]
After=[email protected]Reload systemd and reboot:
sudo systemctl daemon-reload
sudo systemctl rebootAfter the reboot, systemctl show cosmic-greeter.service -p NRestarts reads NRestarts=0 and [email protected] stays inactive, and with the autologin block in place the test VM went straight to the COSMIC desktop. The other text consoles still use kmscon: Ctrl+Alt+F3 opened one on tty3. Once the grep check shows [email protected] after a later update, the drop-in is redundant and you can delete kmscon.conf.
Switch back to GDM or remove COSMIC
If you added COSMIC to Workstation and want your old setup back, hand the login screen back to GDM first, because removing the group takes cosmic-greeter with it:
sudo systemctl enable --force gdm.serviceThe alias flips back the same way it moved:
Removed '/etc/systemd/system/display-manager.service'.
Created symlink '/etc/systemd/system/display-manager.service' → '/usr/lib/systemd/system/gdm.service'.Now remove the group. On the test machine this removed 97 packages and freed 839 MiB:
sudo dnf group remove cosmic-desktopFour COSMIC packages survive the group removal: cosmic-files, cosmic-term, cosmic-icon-theme and cosmic-initial-setup. dnf only changes their install reason, so they’re picked up by the next cleanup:
sudo dnf autoremoveThat pass removed the last 10 packages and another 187 MiB, which put the package count back to exactly where the fresh Workstation started, plus the Fedora signing key dnf imported during the first install. The cosmic.desktop session file goes with it, leaving GNOME and GNOME Classic as the only sessions in /usr/share/wayland-sessions. The one thing left behind is your COSMIC configuration in ~/.config/cosmic. It is harmless, and you can delete the folder if you want a completely clean home directory.
