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-based distros, 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 update timing that marches to its own drum instead of 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-based distros, 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 re-summons what you evicted a moment ago. Peeling off the surface (the snap instance) doesn't break the loop.

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-based distros. 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 (the same trick Linux Mint uses by default).

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

What the user confirmed afterward:

The snap command was gone and snapd was disabled.
/etc/apt/preferences.d/nosnap.pref was still in place, and snap never reappeared afterward — i.e. it holds without re-entry.
flatpak list showed 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.