Your submission was sent successfully! Close

You have successfully unsubscribed! Close


The set of snaps that make up a device, and govern its capabilities, are controlled by the model assertion, alongside the snap assertions in a given recovery system.

The model assertion contains:

  • Identification information, such as brand account id and model name.
  • Which essential snaps make up the device system, including the gadget snap, kernel snap and the boot base snap with the root filesystem.
  • Other required or optional snaps that implement the device functionality.
  • Additional options for the defined device, such as grade for a UC 20 device.

When one or more of the above elements change, the updated model assertion and its associated image are deployed to the device, authenticated and linked through its serial assertion, to the store. This process is called remodelling.

One example of remodelling is upgrading a UC20 device to UC22

Remodelling viability

Remodelling is the responsibility of the snap daemon (snapd) running on the device. It both mediates the update process and the re-registration of the device after the update (if required). But the complexity and viability of the remodelling process is dependent on several factors outside of snapd’s control.

At its simplest, a device can be successfully remodelled when using the same model name and the same dedicated Snap Store but with a new model revision where the only difference is an added or removed snap, or changed snap track or channel.

But if the dedicated Snap Store needs to change, even under the same brand scope, this requires the acquisition of a new serial assertion, and the success or failure of such a process will depend on the context.

With a dedicated Snap Store, the following types of remodelling contexts are possible:

  • same brand/model -> same dedicated Snap Store
    Works as a simple contextual carrier for the new model.
  • same brand/model -> different dedicated Snap Store
    Keeps access to the device state kept on the remodel change, creates a store that uses that state, and then refers to the new dedicated Snap Store.

Remodelling context validity

The below permutations of the remodelling contexts are all valid:

brand store model name + snaps - snaps
same same same yes yes
same same different yes yes
same different same yes yes
same different different yes yes
different different different yes yes

Remodelling between versions of Ubuntu Core

Migrating from one version of Ubuntu Core to another is a special case of remodelling due to the differing storage layouts and the differing implementation of full disk encryption in Ubuntu Core versions.

For this reason, it is generally not possible to migrate from Ubuntu Core 18 to Ubuntu Core 20 automatically. Migrating automatically between Ubuntu Core 20 and future versions of Ubuntu Core should be possible.

Last updated 5 months ago. Help improve this document in the forum.