Ubuntu core 20 and recovery partition


I have few questions about recovery, I am referring https://ubuntu.com/tutorials/how-to-ubuntu-core-recovery-mode#1-overview to understand the mode.

Does Ubuntu core support multiple recovery images?

Currently, I can see one image as below, I guess by default one .

jithcr@ubuntu:~$ snap recovery
Label Brand Model Notes
20210721 jithcr imxm8-mini-uc current

There is one recovery system that you install from during the first boot. More recovery systems can be created during remodeling, since you effectively create a new seed which you kind of installed from.

It is possible to create new recovery systems via undocumented debug API, but it’s not very useful at this time. Aside from the recovery system being created, you will not be able to reboot into that system using snap reboot command.

Do you have a particular scenario in mind in which you would see need to add and use a new recovery system?


@mborzecki Thank you for your response.

I am trying to understand recovery images preparations background ,possibility customizing the recovery image and how can I get more control to recovery point… etc .

Whole point is that how can we create a recovery image which serves my snap/application/configuration needs.

As an initial thought/ example,
I need particular snaps in recovery mode and don’t want same snaps in run mode.
I was concentrating on mode : ephemeral model file and expectation was such snaps should not get added run mode and available only in recovery mode. I am testing this. I don’t have a proper result here.

Where can i check more on APIs which help me to do create the new recovery systems ?

I think I’m a bit confused here. Do you want to create that recovery with specific snaps at runtime or at build time?

Anyways, the API does not allow you to select snaps and modes in which they appear in. Everything is encoded in the model.

Looking for Runtime.

You can take a look at this test: https://github.com/snapcore/snapd/blob/master/tests/nested/core/core20-create-recovery/task.yaml As I mentioned before, this is a debug API and not intended for end user consumption at this point.

Okay, Thank you.

Sorry for looping the question again. I got confused by seeing your question.
Is it possible to create multiple recovery with different snaps at build time? My understanding is that it is not possible since snaps list are already mentioned in the model file. ubuntu-image utility places snaps and prepares the core img file with one recovery/reinstall(factory reset) point.

No, but if your primary goal is to have a different set of snaps in recovery and run modes, then you can list the modes of a given snap, eg:

type: model
model: foo-bar
  - name: my-gadget
    type: gadget
  - name: my-kernel
    type: kernel
  - name: only-in-run-mode
      - run
  - name: only-in-recover-mode
      - ephemeral

The end result should be that only-in-run-mode is not present in recovery, while only-in-recover-mode is. However, all those snaps will be present in the system seed. At runtime snaps will choose which snaps will be seeded. In particular, recover mode is gets ‘seeded’ each time it runs (even though the changes aren’t persistent) as the data partition is effectively a tmpfs. Is this what you are looking for?

@mborzecki Thank you for example, I will check more…

I am looking for two cases one is in recovery mode (same as you mentioned) and another one is in run-mode points.

But I am not sure that whether I can call it run mode or not .( run mode with 2 set of snaps/user data)

For example, Assuming that I am getting hardware loaded with Ubuntu Core from factory,But I need to use the same hardware for 2 different Applications use ( say for example medical and automation ). In this case, in run mode, I am expecting different snaps/data in hardware.

Problem is if the device is getting corrupted at end user/field, re-installation lead device to a run-mode which has no specific application snap.Since I installed the application snap manually. So In the filed, I am not able to provide the recovery point to the end user.

I am trying to understand what Ubuntu Cores existing features which help to solve this kind of issues in the actual field deployment.

Easiest method that I understood is prepare the 2 UC images with required snaps and use in hardware based on the use case , That will help me retain the application snaps after re-installation.

Looking for best methods to recover the device with required snaps and data. I am trying to understand what are the features available in UC which are help us use to meet this kind of requirements.

Sorry for the lengthy explanation. Hope you are clear.

Do you want to convert one device type to another? Eg. a device once shipped as a medical appliance becomes an automation one?

I think the canonical way to do it so to have separate models. One for each type of device. Aside from the usual gadget/kernel/base snaps, you also list application snaps that you specifically require, such that it will not be possible to remove those snaps. Since a given system seed contains the model, reinstallation from that system will make sure that the application snap is again present in run mode. You can also list specific mode for a given snap in the model (eg. it’s not useful to have an application snap be seeded in recover mode). Please take a look at the documentation on model assertions.

If you are using ubuntu-image, then you will need to build 2 separate images, since it can only build an image for a single model. There’s probably a way to hack together a single image with 2 different system seeds, but if you are shipping those devices commercially then I guess it’s safer to have separate images after all.

No conversion required… From factory,Device contains UC with minimum snaps(Model file contains gadget,kernel,base) … device with medical appliance snap has to serve only for medical application.

Assume, I added medical appliance snap on one device and added automation snap in another device. In recovery perspective, if I performed a recovery/reinstall, next boot in run mode , gadget,kernel,base will be retained. Its limiting me to use UC image for multiple use case, I may need to maintain multiple UC img for medical and automation.

The deployment method you are describing sounds an awful lot like one of our partners who sells “white box” devices to resellers, who then customize the device before selling it off again to a third party. In this setup, you have 3 models:

  1. the plain model with the gadget + kernel + other hw specific bits but no app snaps
  2. the medical reseller model that inherits everything from model 1 but adds some medical specific app snaps
  3. the automation reseller model that inherits everything from model 1 but adds some automation specific app snaps

In this setup, you build your device from the factory with model 1, and the medical reseller would then take the device, boot it up and perform a remodel to their model assertion (model 2), then power off the device and ship it off to their customers. Same for the automation reseller, etc. In this scenario, the end devices would have two possible recovery scenarios, they could re-remodel back to your model in which case they lose the app snaps from the medical or automation reseller (for example you might do this if a device is “broken” and returned to you but you are able to fix it and want to sell it again), or they can use the “reinstall” mode to reinstall from the reseller model, so if the end customer had any customizations or data on top of the reseller, they would lose that, but otherwise it would be just like they bought it originally from the reseller.

@ijohnson , Thank you for your response.

In build time modelling approach, We need to maintain 2 set of img file (output of ubuntu-image command) - One for medial reseller and second one for automation reseller.

Which is the best method we can conclude
1.Runtime remodeling : Do we have run time remodeling support in UC?
2.Build time modeling : Build separate img for medial reseller and automation seller and use in the device based on the shipment to reseller.

This is very close to being available, @mborzecki is working on it actively, it should be available in snapd 2.53 if I were to guess since we just started the release process for 2.52. Maybe available in 4-6 weeks on stable channel of snapd, sooner on edge.

Yeah if you don’t want the reseller to have to boot the image and trigger the remodel, and you also know ahead of time which devices are going to which reseller, then yes you can just build an image from the model for their device (i.e. model 2 or 3 in my example) and then flash that onto the image. This somewhat complicates the “return to original OEM” recovery story, since your original model 1 system was never installed, so you can’t just jump back to that version and you instead need to be able to login to the device to trigger the remodel from model 2/3 to model 1.
An alternative method for this which increases your factory time but eliminates needing to maintain multiple images would be to always flash the original image for model 1, then do the remodel yourself still in the factory so it leaves the factory having been remodelled to model 2/3, but that takes more time in the factory which folks usually don’t want, but you also get the ability to always go back to the original “white box” system without the customizations from model 2/3.

1 Like

Is this feature released?

This PR needs to land https://github.com/snapcore/snapd/pull/10534, which hopefully will happen this or the next week.

1 Like

@ijohnson, I am using snapd 2.55.3 version. Does this version support Runtime remodeling. If not, let me know the version which supports such feature.

Remodeling should be supported now. There are some limitations as to what is possible eg. cross brand isn’t, but cross store is, but you need to set up the mappings in the serial vault yourself. Given that it’s kind of complicated, it’s probably best if you play around and get in touch with the support if you run into problems.

@mborzecki Is there any documentation to try remodeling?