Offline do-release-upgrades from xenial to bionic introducing snap pkgs

It has been brought to my attention by someone using offline deployment of Ubuntu Xenial Desktops:
Intends to perform a full offline do-release-upgrade, all testing currently working without issue except for the introduction of snap packages as part of the upgrade.

They would need a offline solution to resolve snap dependencies for release upgrade.

Any recommendation ?

Here’s more context about the snap package being part of the upgrade:

It seems like do-release-upgrade has a deb2snap mechanism to migrate some of the deb to snaps and/or install new snap package, like if it was a fresh new install.



commit f57a65f69e47e55a5490104cca81e2ec88b5d075

  • Add in a quirk for upgrading to Cosmic that will
    check if the system has connectivity to the snap store and replace some
    desktop packages with snaps to ensure the system is similar to a fresh

Assuming one does a offline upgrade using a local repository (landscape or else) and considering this deb2snap approach during the upgrade, then this will break the snap portion of the upgrade, since there would be no access to the snap store.

How snap can be taking care of if no direct access to the snap store ?

Hi again!

If snapd is unable to contact the store, there’s nothing that can be done store-side to help with this issue.

I checked with the snap core team and was told that simply installing snapd (e.g. from a deb) doesn’t cause it to automatically install seeded snaps; so the request to install those snaps (and the failure to do so) comes from somewhere else, and means it’s also not behavior that can be altered in snapd itself.

Snap core team also helped pinpoint the source: it’s do-release-upgrade (actually the python3-distupgrade package) that does this. It contains a DistUpgrade.DistUpgradeQuirks module that has a _replaceDebsWithSnaps method, it’s the one that actually does snap install foo:

Trivially, making the “snaps” list in that method empty would cause not to install anything. However, I notice the code is supposed to not exit with a failure code when it fails to install a snap (see how it catches CalledProcessError and just logs the problem and continues ). So it probably needs more thorough analysis to see if it’s failing at another point, and either fixing this upstream in python3-distupgrade or crafting a fixed, custom version and distributing that to the systems you want to upgrade in a disconnected environment.

  • Daniel

In the event that the release upgrade process is unable to connect to the snapcraft store a dialog is presented indicating this and asking if you want to continue the upgrade. So there should be no need for an “offline solution”.

If somebody discovers this is not the case then a bug report should be opened about ubuntu-release-upgrader using ubuntu-bug so that details regarding the system are gathered.