The docs here seem to hint at the ability to select between multiple recovery images to
I can’t find any docs that describe how to create and label recovery image. Can this be done via snapd API?
Sadly not yet. This is stil a work in progress item, and so far only some low level bits of the whole thing landed. It’s also a bit hard to give an ETA at this point as I’m progressing on this slower than I initially planned.
Thanks for response.
Looking forward to this feature - it will be a very powerful tool for servicing devices.
To add a bit more information, as @mborzecki mentioned we are actively working on this but there’s no exposed way to do this ATM.
The situations in which we envision new recovery systems to be created are the following so far:
- A remodel operation of a UC20 system on top of changing the run system will also create a new recovery system that matches the new model, so that recover, reinstall (and later factory reset) can be done with a recovery system that matches the running system
- There are updates to the bootloaders or bootloader assets and firmware, for example secure boot key revocations or listing specific binary hashes as disallowed and others, that make the current recovery system(s) unusable: in those scenarios we would create a new recovery system that can work with the updated state before proceeding with the update
- We can also support an API that take the current snaps at their revision in the run system and make a recovery system based on them (any snaps not mentioned by the model wouldn’t be captured this way though as the way recovery systems are securely processed depends on the list of snaps in their model)
We are interested in input on any further use cases in this area.
1 Like
Some projects want to decrease first boot time (and consequent reboots) due to snaps being refreshed (sometimes flashed images have been on the shelf for a long time). Might there be a way to update the seeded snaps on disk on first boot but before all snaps are refreshed from a (possibly signed by brand or delegated authority) USB drive, perhaps by creating a new recovery system using the same model as was previously flashed to disk, but also getting updated snaps & assertions from the inserted USB drive. Given slow network connectivity this might be useful in some cases, and it might aid bulk on-premise first boots without requiring new images to be built (although the USB content would of course need to be up to date or there is no point). It might also be helpful in deployments with no network. We did discuss this a bit internally and several people said building and flashing a new image was probably adequate, but I wanted to mention it as well, since building new images for every device bring up may be awkward to manage, and empowering field staff to reflash devices in the field may be overkill or present other security concerns.
Two use case for our application
- First boot occurs at factory. We inject some additional data to device at this time. Would like to be able to create a new recovery image that includes this injected data.
- Once device arrives in field and is setup/configured, we would like ability to create recovery image with this configuration.
In both cases recovery image could contain sensitive data, so it must be encrypted.
The factory update use case described by KyleN would also be useful to us.
Hi, is there a ticket in Launchpad to follow up the development? Thanks 