When `apt install firefox` actually installs a snap — purging snap for good and moving to Flatpak

Environment: Kubuntu 26.04 LTS · KDE Plasma 6 · apt / snapd / Flatpak

TL;DR

On Ubuntu and its official flavors, the stock firefox apt package isn't the browser — it's a transitional stub that pulls in snapd and the snap build of Firefox. So apt install firefox hands you a snap.

To rip snap out and move to Flatpak: (1) purge the snap packages, (2) pin snapd so it can't sneak back in as a dependency, (3) reinstall your apps from Flathub.

# 1) remove snap (the firefox snap + the transitional apt package)
sudo apt purge firefox snapd
# 2) block snapd from returning (pin priority -1)
#    put these 3 lines in /etc/apt/preferences.d/nosnap.pref
#    Package: snapd
#    Pin: release a=*
#    Pin-Priority: -1
# 3) Flatpak + Flathub
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.mozilla.firefox

The symptom

Fresh Kubuntu install, sudo apt install firefox to get a browser. It looked like an ordinary apt package went in, but what actually happened was snapd came up as a service and Firefox landed as a snap. All the usual snap friction showed up: slow cold starts, an isolated sandbox running separately from the system's apt, and an update schedule that runs on its own cycle rather than apt's.

The misdiagnosis: "just remove the snap and reinstall via apt"

There's an easy trap here. "The snap build is the problem, so remove that and reinstall via apt to get a proper deb." I reached for that first too — and it's wrong.

On Ubuntu and its official flavors, reinstalling the firefox apt package pulls snapd right back in as a dependency. That's precisely what the stub does, so removing the snap and reinstalling via apt just pulls back in what you removed a moment ago. Removing only the surface symptom (the snap instance) doesn't break the cycle.

Root cause

It comes down to what the firefox apt package actually is. It's not a package containing the browser — installing it installs snapd and pulls the snap build of Firefox. So:

apt install firefox → snapd installed + snap Firefox installed.
Remove only the snap Firefox → the apt stub is still there, and snapd can re-enter at any point through a reinstall or dependency resolution.

In other words, the assumption "it came from apt, so it isn't a snap" simply doesn't hold on Ubuntu and its official flavors. The fix isn't a surface removal (deleting the snap instance) — it has to go all the way to removing the stub and snapd itself and closing the re-entry path.

The fix

1) Remove snap completely

Purge the snap-related packages. After the user ran it, the snap command itself was gone and the snapd / snapd.socket / snapd.seeded services were all disabled.

sudo apt purge firefox snapd

2) Blocking re-entry is the real crux

Purging alone isn't enough — snapd can quietly reappear as another package's dependency. Pin snapd to priority -1 in /etc/apt/preferences.d/nosnap.pref (Linux Mint ships the same trick — it uses -10, but any negative priority blocks the install just the same).

Package: snapd
Pin: release a=*
Pin-Priority: -1

With this in place, apt refuses to install snapd even if some package later asks for it as a dependency.

3) Switch to Flatpak

Add Flathub, install the backend so Flatpak apps show up in KDE Discover (the software center), and reinstall what you need from verified publishers.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
sudo apt install plasma-discover-backend-flatpak
 
flatpak install flathub org.mozilla.firefox      # publisher: Mozilla
flatpak install flathub org.telegram.desktop     # publisher: Telegram FZ-LLC
flatpak install flathub md.obsidian.Obsidian     # publisher: Obsidian

Flatpak apps install either system-wide (/var/lib/flatpak/app/) or per-user (~/.local/share/flatpak/app/), launchers register automatically, and you update with flatpak update or Discover — no hand-managing folders like a tarball install.

Verifying

Rechecking the state as I write this:

The snap command is gone and snapd is disabled.
/etc/apt/preferences.d/nosnap.pref is still in place, and snap never reappeared afterward — i.e. it holds without re-entry.
flatpak list shows firefox, telegram, and obsidian all as Flatpaks.

Loose ends right after the switch

New K-menu icons didn't appear until a reboot/re-login — XDG_DATA_DIRS has to refresh for the new Flatpak launchers to register.
The freshly installed Flatpak Telegram needed a re-login (the old tar build's local session data had been deleted; the cloud messages themselves are unaffected).
fcitx5 / fcitx5-hangul (the Korean input method) was unrelated to all this — it had been a plain apt install from the start and wasn't affected.

Takeaways / checklist

What apt install firefox actually installs depends on the distro and version. If you suspect a snap, confirm with snap list.
Purging isn't enough to evict snap for good — pin it low with nosnap.pref to stop dependency re-entry (Mint already does this).
If new apps don't show in the K-menu after switching to Flatpak, check that a reboot/re-login has refreshed XDG_DATA_DIRS.

This came out of the first-boot setup right after installing Kubuntu 26.04 in a dual boot. One note: right after moving Firefox to Flatpak like this, a chain of problems followed — starting with Firefox crashing on its very first launch, then NVIDIA and DRM issues — each with its own cause. They're written up as separate posts, linked under "More in this series" below.