Re-exec mid-install

Imagine a user who downloads the ISO of their favorite distro. They’ve heard that all the cool kids are installing snaps, and post-install start to install something like snap install squidge9000. That would result in the following:-

  1. Under snapd shipped on the iso, get and install core
  2. Under snapd shipped on the iso, get and install squidge9000

Sometimes we add features that the latest build of squidge9000 needs, into snapd. Typically a user might get that new feature in snapd via their package manager or more commonly via re-exec into the snapd in the core snap.

However, for this new user, they have no snaps (not even core) installed, but they do have an old version of snapd which was baked into the iso they downloaded.

Would it therefore make sense on the first snap install to do the following:-

  1. Under snapd shipped on the iso, get and install core
  2. Re-exec into the new snapd in core
  3. Under snapd from core, continue with install of squidge9000

The reason I ask is because we have exactly this issue right now. Steps to reproduce.

  1. Download 16.04.0* from old-releases.ubuntu.com and install it
  2. Boot the newly installed LTS install
  3. snap install skype (note no mention of --classic)

This will install core using snapd 2.0.2 which shipped in 16.04.0. This will then install skype, but that will result in a broken installation because skype is a classic snap and snapd 2.0.2 is from the stone age before classic was a thing.

  • Yes, 16.04.0 is old, but it’s also baked into some OEM images shipped to users. So this is a real thing that happens. Yes, we’re talking to said OEM to get their images updated if they can.

However this is a bigger issue. Going forward the same problem could occur on systems where snapd is pre-installed, but no snaps (i.e. no core, no auto-update, no re-exec) are pre-installed.

Should we re-exec between core and the next snap to be installed?

IIRC, @mwhudson has a counterpoint on why re-exec is not always desirable. @mwhudson, can you comment?

I disabled it in the live-server image because of reasons I don’t entirely remember but may actually be fixed with 2.32 and I had it disabled in Debian for a while because of apparmor fun and games but they were fixed a while ago. I’m not sure either of those apply here :slight_smile:

If the snap depends on features present from a certain snapd on, it should have an assumes entry in its meta/snap.yaml that stated as much; otherwise the snap is broken.

Today I Learned: “Assumes”. I googled for it and found this documentation which is somewhat lacking detail. Can someone who knows how this works please document it fully.

3 Likes