Hi,
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?
Hi,
@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
...
snaps:
- name: my-gadget
type: gadget
- name: my-kernel
type: kernel
- name: only-in-run-mode
modes:
- run
- name: only-in-recover-mode
modes:
- 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:
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.
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.
@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.