Trying to enable user consent for offline updates

Technical Support
, ,
1

I am trying to disable automated install for offline updates and require user consent before proceeding with the update. From what I read in the documentation this should be achievable using the Consent API. However, I am not able to get it to work; the update continues to automatically install.

I am running Torizon OS 7.7.0 on a Verdin imx8m plus SOM. My eventual goal is to have a confirmation dialog popup for the user to confirm or cancel the update when a update USB is inserted into the system.

I’ve configured and provisioned my device for offline updates.

This is the contents of my /etc/sota/conf.d/99-offline-updates.toml file:

[uptane]
enable_offline_updates = true
enable_online_updates = false
offline_updates_source = “/media/lockbox”

I can confirm that offline updates are enabled because I can see “Offline Updates are enabled” in the logs.

I disabled the automatic installation by executing this command:

busctl set-property org.uptane.Aktualizr /org/uptane/aktualizr org.uptane.Aktualizr InstallUpdatesAutomatically i 1

I confirmed the parameter is getting set by executing this command:

busctl get-property org.uptane.Aktualizr /org/uptane/aktualizr org.uptane.Aktualizr InstallUpdatesAutomatically

I get “i 1” as the response.

I then insert a USB drive with my update package and monitor the status by looking at the logs.

When I execute “journalctl -f -u aktualizr*” I see the following:

Event: UpdateCheckComplete, Result - Updates available
Event: DownloadProgressReport, Progress at 100%
Event: DownloadTargetComplete, Result - Success
Event: AllDownloadsComplete, Result - Success
Event: InstallStarted

The update continues to install and complete successfully. My issue is that it’s not waiting for user consent. Does the consent feature work for offline updates? Am I configuring it incorrectly? Any help would be appreciated.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Based on the available sources, I found that Torizon OS 7.4.0 introduced a D-Bus interface for Aktualizr that enables granular control over updates, including the ability to gather end-user consent before proceeding with updates(1). This feature was specifically added to fulfill EU Cyber Resilience Act (CRA) requirements(1).

However, the sources provided do not contain specific documentation about:

  • The exact D-Bus API methods and properties for the consent feature
  • Configuration parameters for enabling consent mode
  • Whether the consent API works specifically with offline updates
  • The correct property value to disable automatic installation (you’re using i 1, but the correct value isn’t documented in these sources)

The issue you’re experiencing—where updates continue to install automatically despite attempting to disable InstallUpdatesAutomatically—suggests there may be additional configuration steps or specific API calls required that aren’t covered in the sources I have access to.

I recommend:

Check out these potentially useful sources:

You may also want to reach out on the Toradex Community or GitHub for specific guidance on implementing the consent API with offline updates.

**

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Greetings @srampersad,

I just tried this myself and was able to reproduce similar results as you have described. This appears to be a bug where the consent check is not being considered for offline updates.

I’ll report this issue for our team to investigate and fix. Thank you for bringing this to our attention.

For the time-being if you need this urgently you’ll need to create some kind of monitoring system to confirm/deny your offline updates.

For example, you could set offline_updates_source to some other location on the filesystem rather than where your USB will be. Then you can create a script or small app that monitors when a USB with a lockbox is available. If something is detected you can bring up a confirmation dialog for the user. if the user accepts your script/app can then copy the lockbox from your USB to whatever file path you have offline_updates_source set to. In this way you create a similar gating/consent mechanism for updates.

Best Regards,
Jeremias

5

Hi @srampersad,

While discussing this internally, we wondered why do you need to ask for consent given that someone has to physically plug the USB stick to the machine.

We could envision some use cases where it may be needed, but still those are just hypothesis, so I’d rather learn from you directly.

6

We’re watching this discussion with some interest now since for us, enforcing consent on offline updates would upset our current workflow we’ve implemented for those. I’d request that if the default does change that it be configurable - we’d keep it disabled since we already have an explicit consent mechanism built into our offline-update monitoring and install progress mechanism.

7

@bw908 You shouldn’t need to worry. The discussion here is about the recent Aktualizr consent feature: aktualizr/docs/markdown/dbus-api.md at toradex-master · toradex/aktualizr · GitHub

This is something that needs to be explicitly enabled by the user and does not do anything by default otherwise. Whatever fix our team does here will make it so that this consent check works with offline updates if enabled. It will not change the default of this feature.

This is generally our strategy with introducing anything that could change, or disrupt the default update behavior. We make it opt-in to keep compatibility with user’s previous workflows to avoid breaking things.

Best Regards,
Jeremias

8

Hi @leo.tx,

This is being used in a medical application. The reason for needing user consent is for safety reasons. We have to prohibit the user from initiating a software update while a therapy is active since this could potentially result in patient harm. It should also be noted that the USB is used to export therapy logs. The user could potentially insert a USB for the purpose of exporting those logs but inadvertently insert the wrong USB thus initiating a software update. In an ideal case the user wouldn’t be that careless, but being a medical application, we still have to mitigate the risk. By forcing the user to accept or decline that update provides the needed mitigation.

9

Thank you for the explanation @srampersad. It’s very helpful information for us in our internal discussion. We’ll get back to you once we have an update regarding this issue.

Best Regards,
Jeremias