adding OSTree to a custom image

Technical Support
, , ,
1

Hello,

Currently I’m building a custom image, based off of the TDX Console image manifest with additional OE layers for extra software, and custom layers for my business logic and image recipes. I’m investigating adding OSTree to my build to facilitate custom field upgrades using ostree deploy.

I see three possible ways to add ostree support to my image and my build process. Based on experiences with other customers, is one of these methods recommended?

  1. Manually add the meta-updater layer to my manifest, and manually include/create everything required in my recipes.
  2. Switch to the Torizoncore manifest, including meta-toradex-torizon but append its recipes as necessary in my layer to re-configure specifics (default users, network config, etc).
  3. Switch to the Torizoncore manifest excluding meta-toradex-torizon layer, but fork that layer into my own version to adjust the OS to fit my requirements.

Each method has their drawbacks: option 1 seems complicated and error prone but is included for completeness; option 2 seems inefficient (having to rollback Torizon customizations in my layer, like conflicting NetworkManager configurations), and option 3 seems most appealing but potentially a maintenance burden to stay up to date.

In a parallel investigation, I’m looking at TorizonCore Builder, but want to understand this option as well.

Thanks,
Tyler

2

Greetings @tyler_,

I would personally recommend your option 2 approach. But I have some additional information. In the meta-toradex-torizon layer we actually have an image recipe here: meta-toradex-torizon/torizon-core-lite.bb at dunfell-5.x.y · toradex/meta-toradex-torizon · GitHub

“TorizonCore Lite” is basically Torizon without any of the container stuff. So it’s essentially the minimal image, OTA related components, and some other minor modifications. If you base your image off this it would reduce the amount of customizations you would need to rollback and modify. This is probably the most practical approach from both an initial upfront work/long-term maintenance stand-point. It’s also the approach some of our other customers with a similar use-case as yours have done.

Out of curiosity, is there a reason you don’t want to just use the stock TorizonCore image we provide? I assume it’s due to very particular needs for your image.

Best Regards,
Jeremias

3

Thanks, @jeremias.tx . I’ll take a look at the lite image as well. I do need Docker support in my image, but I’ll review all the Torizon images to see what makes the most sense to use.

I have been experimenting with using vanilla Torizon in parallel (as part of looking into TCB). My use case requires some in- and out-of-kernel modules, as well as some additional core software like a DHCP server. I’ve been able to get all this working on vanilla TorizonCore with services in Docker, but without using full OTA I don’t think there is a friendly system update path since I’d need to manually combine/synchronize ostree updates with deployment of a new Docker compose to get my core services running.

4

Is there a reason you won’t/can’t use our full OTA system?

Using OSTree by itself is possible but without something to manage the updates it can be difficult to leverage OSTree by itself in a production environment.

Best Regards,
Jeremias