Call for testing: chromium-browser deb to snap transition


(cross-posted on the Ubuntu Community Hub)

The chromium browser has been available as a deb package for all supported Ubuntu releases and as a snap since version 60, and the time has come to start transitioning away from the debs.

In a first step, the transition will be happening exclusively for Ubuntu 19.10 (Eoan Ermine) users, and once I’m confident it is rock-solid it will be rolled out to stable releases, starting with disco and then the LTSes.

How does that work? The deb packages have been updated in eoan to install the stable snap on upgrade or new install (credit for the original implementation goes to the LXC team). Special care has been taken to not break existing workflows and to make the transition seamless:

  • when running the snap for the first time, an existing chromium user profile in $HOME/.config/chromium will be imported (provided there is enough disk space)
  • the chromium-browser and chromedriver executables in /usr/bin/ are wrappers that call into the respective snap executables
  • chromedriver has been patched so that existing selenium scripts should keep working without modifications
  • if chromium was the default browser, the chromium-browser wrapper will take care of updating it to the chromium snap
  • similarly, existing pinned entries in desktop launchers will be updated to point to the snap version (implemented for GNOME Shell and Unity only for now, contributions welcome for other desktop environments)
  • the apport hook has been updated to include relevant information about the snap package and its dependencies

If you live on the edge and are running Ubuntu 19.10 already, I would appreciate your feedback on this transition. Please share it here, or file bugs with ubuntu-bug chromium-browser.


Request: auto-connection of removable-media for chromium

Well 32bit snap version is crashing for me.

But why deb is being replaced with snap in the main archive ? I use Pop_os/Ubuntu-Mate and it doesn’t even have snap. How do I continue using/testing chromium deb ? Can you provide a PPA ?


Can you provide details about that crash? Which version of Ubuntu, which channel of the chromium snap, what desktop environment, does it crash right away at startup or are there a specific set of actions/pages that trigger the crash?

Technically, chromium is in universe, not in main (see this documentation). The deb packages won’t disappear, but they are becoming transitional packages that install the snap when installing/upgrading.

I’m not sure about Pop!_OS, but I’m pretty sure Ubuntu Mate supports snaps as first-class citizens.

Once the transition is complete there won’t be a PPA maintained by the Ubuntu desktop team, because one of the goals of this transition is to relieve some of the packaging/maintenance work.


Ubuntu 18.04 install Unity 7 and i have some Apparmor denied (Core: 16-2.40~pre1):

[ 875.534615] audit: type=1400 audit(1562746633.595:185): apparmor=“DENIED” operation=“file_mmap” profile="/snap/core/7343/usr/lib/snapd/snap-confine" name="/usr/lib/x86_64-linux-gnu/" pid=5956 comm=“snap-confine” requested_mask=“m” denied_mask=“m” fsuid=0 ouid=0

[ 875.857780] audit: type=1107 audit(1562746633.919:186): pid=1109 uid=103 auid=4294967295 ses=4294967295 subj==unconfined msg='apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/" interface=“org.freedesktop.DBus.ObjectManager” member=“GetManagedObjects” mask=“send” name=“org.bluez” pid=5956 label=“snap.chromium.chromium”

All seems to work so far.


These denials should be harmless indeed.


@oSoMoN hi, the deb package source ~/.chromium-browser.init if available in order to pass additional chromium flags on startup without having to modify .desktop launcher. Could chromium snap introduce similar functionality? Of course ~/.chromium-browser.init should be sourced from snap specific home (inside ~/snap) in that case.


@Reynolds5 this is tracked by bug #1837746 and will be fixed in due course.


@oSoMoN I have another issue related to password store backend in chromium, similar to .

The test command you use to detect backend:

dbus-send --session --dest=org.freedesktop.secrets /org/freedesktop/secrets --print-reply org.freedesktop.DBus.Properties.GetAll string:'org.freedesktop.Secret.Service' >/dev/null 2>&1

fails o my system (Ubuntu 19.04 + KDE session + kwallet) saying that nothing provides org.freedesktop.Secret.Service and chromium fallbacks to plain backend (losing my passwords). When I add --password-store=kwallet to desktop file command it works correctly.

So current approach for backed detection is broken in my case (maybe in general for kwallet). Maybe it’s possible to test also kwallet equivalent of that command however I don’t know what i should be


Thank you for the report @Reynolds5. I filed bug #1847470 to track it.


@Reynolds5 this issue is fixed in the candidate channel. Would you mind testing it and reporting back?

snap refresh chromium --candidate


Snapped Chromium still has theming issues in Ubuntu 19.10 (and before).
The bug have been reported since last year:


@oSoMoN works, thank you very much.


Excellent, thanks for the confirmation. I have now promoted the snap from the candidate channel to stable, so you can switch channels again:

snap refresh chromium --stable


The issue is solved by updating the gtk-common-themes snap to candidate channel.


You are right, it appears the gtk-common-themes snap in the candidate channel fixes the theming problem. Well spotted!
I am now trying to bisect what change fixed the problem, and I will talk to the maintainers to have it promoted to stable.


@oSoMoN I noticed that kwallet detection still fails if kwalllet isn’t running before chromium starts. In that case the test call is blocked by apparmor:
dbus-daemon[1464]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/modules/kwalletd5" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.kde.kwalletd5" pid=2837 label="snap.chromium.chromium"

If I pass --password-store=kwallet then chromium triggers kwallet start automatically. Is it something fixable or should I force running kwallet before starting chromium?

On a side note I also see quite similar blocked call for bluez:
audit[1166]: USER_AVC pid=1166 uid=104 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=2719 label="snap.chromium.chromium"

I don’t use bluetooth so I don’t know what are the consequences of above.


@oSoMoN there is one more thing - from time to time chromium tries to write into /proc/PID/clear_refs which is blocked by apparmor.

After reading various sources:

it doesn’t seem to be security sensitive. Is it possible to allow this action by adding something like: owner @{PROC}/@{pid}/clear_refs w, to chromium apparmor profile?


You are right, and the problem is similar for org.freedesktop.secrets if gnome-keyring-daemon is not already running.
I would have expected D-Bus activation to work in this context.

However, in the context of a normal KDE session I would expect kwallet to be running already (and same for gnome-keyring-daemon in a GNOME session). Is this not a safe assumption?

D-Bus activation for snaps

The other denials (bluez and /proc/PID/clear_refs) should be harmless, so you can safely ignore them.


It depends on system settings. I didn’t added kwallet to autostart applications. I also have it set to exit on idle. That means on my system it’s very likely that it won’t be running at the time chromium is launched. I can change it if there is no other workaround however I believe there will be more people hitting this issue and complaining about it.

My concern isn’t about it being harmful but about endless syslog spam. I’m heavy apparmor user and I have set desktop notifications for all denials so this isn’t ok for me. We can forget about bluez but please either allow /proc/PID/clear_refs or deny it but not leave it as is.