Remodelling
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.