Torizon Core Builder scan for changes

Hello everyone,

I noticed some oddities when reading changes from the module using the torizoncore-builder isolate command.
I’m now wondering whether I’ve understood things correctly.
I make some necessary changes, e.g. change password, set up one or more services, add a binary file for the M4, …

If I do that in one session, everything is going well.

However, if I make the changes step by step, or continue to change a module with an already changed image, some changes are not recorded.

How does the isolate command recognize, what has been changed or added and what is it compared to?

I can’t say for sure anymore. In any case, the changes to a virgin BSP image are incomplete.
Is this ‘normal’ behavior?
Or shortly: Do I always have to make my changes completely within ‘one session’ from a unchanged original BSP?

Best regards

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello Gerald,

The torizoncore-builder isolate command captures changes by comparing the current state of the system on the module with a reference state, typically the original BSP (Board Support Package) image that was flashed onto the module before any modifications were made. This comparison allows the command to identify what has been added, modified, or removed.

When you make changes in one session and use the isolate command, it effectively captures all the differences from the reference state at that moment. If you then continue to make further changes in subsequent sessions without capturing the intermediate state, the isolate command might not accurately capture all incremental changes. This is because it compares the current state to the original reference state, not to the state after your last set of changes unless you’ve updated the reference state to include those changes.

The behavior you’re observing, where not all changes are recorded if you make them step by step across multiple sessions, can occur if the reference state used for comparison by the isolate command does not include your most recent changes. To ensure all changes are captured:

  1. After making a set of changes and capturing them with the isolate command, consider updating your reference state to include these changes. This can be done by using the captured changes to create a new image and using that image as the new reference state for future isolate operations.
  2. Try to group related changes together and capture them in one session whenever possible. This reduces the complexity of managing reference states and ensures that the isolate command captures all relevant changes.

It’s not strictly necessary to make all changes in one session from an unchanged original BSP, but managing the reference state effectively and understanding what state your current changes are being compared to is crucial for ensuring that all desired changes are captured accurately.

In summary, the isolate command compares the current state to a reference state, and its ability to capture changes accurately depends on how well the reference state reflects the desired baseline for comparison. Updating the reference state after capturing changes can help ensure that subsequent modifications are accurately recorded.

Best regards, Toradex AI Assistant

Please, also check if these links can help you solve your problem:

TorizonCore Builder Tool “build” command | Toradex Developer Center.

Greetings @gerko,

Could you explain what you mean by “if I make the changes step by step”. What is your exact process here?

How does the isolate command recognize, what has been changed or added and what is it compared to?

Basically TorizonCore Builder runs ostree admin config-diff: ostree-admin-config-diff(1) — ostree — Debian testing — Debian Manpages

It runs this command on the device which produces a diff of what changed in /etc versus the original default state of /etc. What is key here is that it compares to the default state of /etc for that current image.

For example let’s say you start with a base image and add /etc/foo. The isolate command would see that /etc/foo did not exist int he default state of /etc and capture this. Now you deploy your image that has /etc/foo. You then add /etc/bar to this image. If you run isolate on this image now it would only capture /etc/bar. This is because /etc/foo is in the default state of this custom image and is not considered a difference by ostree admin config-diff.

So if you’re doing something like this then that might explain what you are observing.

Best Regards,

Thank you @jeremias.tx ,

That’s what I wanted to know:


Perfect, glad I was able to help clarify.