Possibility to interact with running 'aktualizr' service

Technical Support
,
1

Hello,

I’m currently evaluating the possibilities of Torizon as OS for our new hardware platform, especially the update system. As I have seen, there are two ways to update the system: OTA (cloud) and local (USB). In our use case (device with display and touchscreen) the user of our device always has to be informed and must confirm updates through local user interface.

Is there a possibility to interact with running ‘aktualizr’ service (IPC interface)? An interface to get progress status or an “update exist” event so that our software is able to inform the user and at the time the user confirms update installation, the service is triggered to download and install the update? Or is the only way to do that writing our own ‘uptane’ client, e.g. by using ‘libaktualizr’?

Thanks in advance!

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Based on the provided context, there is a potential for interaction with the aktualizr service through an IPC (Inter-Process Communication) interface, which may allow your software to obtain progress status updates and receive notifications for events such as “update exists.” However, the specifics of this IPC interface and its functionalities are not clearly defined in the available data.

If the existing aktualizr service does not provide the necessary IPC interface for your requirements, you may need to consider writing your own ‘uptane’ client using ‘libaktualizr.’ This approach would give you greater control over the update process and allow for custom handling of user notifications and confirmations, ensuring that the user is informed and can confirm updates before they are applied.

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

Offline updates - best way to apply pending changes without aktualizr service running.

3

Greetings @KV1979,

At the current moment Aktualizr has no mechanism for such interaction. That said, we are currently working on adding such a feature. The idea would be to use dbus to allow an outside process/application to send commands and receive information from the Aktualizr client. The design and development of this feature is still relatively early in the R&D process, so I don’t really have anything more specific to share beyond this. But, this sounds like it should suffice for your needs.

An interface to get progress status or an “update exist” event so that our software is able to inform the user and at the time the user confirms update installation, the service is triggered to download and install the update

Is this more or less all the actions/information you would want to perform? Or are there more use-cases you are interested in?

Best Regards,
Jeremias

5

Hello Jeremias,

if I understand you correctly, this means that if we want have this feature contemporary we would have to implement it on our own because your solution won’t be available in the near future, right?

By the way we have some more requirements for the update process. Our application is divided into legally relevant software parts and non-legally relevant parts. The update client has to deliver not only version information but also different status information to the server so that server can decide which update is to be delivered to which client. So the delivering of updates does not only depend on hardware and software versions but on device state, too. Is there a possibility to do that with Aktualizr? Does Torizon cloud support these kind of selection/filtering?

Kind regards,
KV

6

if I understand you correctly, this means that if we want have this feature contemporary we would have to implement it on our own because your solution won’t be available in the near future, right?

Depends what is your timeline for needing this? If you need this very soon then probably we won’t have our feature ready yet, so yes you would need to come up with someone on your side. What can be done right now is you can prevent Aktualizr from doing updates: Aktualizr - Modifying the Settings of Torizon Update Client | Toradex Developer Center

However, the client will still check for updates if they are available. It just won’t download and install them. So in theory you could block the updates while parsing the Aktualizr logs to see if there is an available update. Then you can prompt the user and if they accept, then the block on the update can be removed allowing it to go forward.

Not the most graceful solution I admit, but it should work.

Is there a possibility to do that with Aktualizr? Does Torizon cloud support these kind of selection/filtering?

Could you elaborate more on this requirement to make sure I understand it properly.

So you want the device to send “status” information to the server. What would this status information look like?

Then depending on this information the server should automatically decide what update to send. For example then if the device reports a certain status, then an update should be started automatically?

Am I envisioning your requirement here correctly?

Best Regards,
Jeremias

7

Our concrete application is a weighing instrument (scale), for example for wheel loaders, excavators and other machines. The weighing software running on the device is legally relevant and must not be touched if the scale is sealed by an authority. The legally non relevant software parts may still be updated. This is meant with “status”. If scale has to be sealed or not depends on the particular use case. So the update server has to decide which update is transferred to which device. If device is not sealed the whole software can be updated to the latest software version. If device is sealed, the legally non relevant parts may be updated, the legally relevant parts must not.

So, is there a possibility to do that with Torizon cloud and Aktualizr respectively?

Kind regards,
KV

8

This kind of functionality should be possible, but it would most likely need some work.

This “sealed” status your devices can have. Are they already sealed when they leave the factory floor. Or can they be sealed dynamically on the field?

What I’m thinking is, is the following. Right now Aktualizr reports to the Cloud predetermined state information. I don’t believe it’s possible currently, to send back custom state information like in your case with the sealed/unsealed states.

That said there’s still some options. For context on our devices we have this file that defines all the valid update package types that Aktualizr will accept from the cloud:

{
    "docker-compose": [
        {
            "partial_verifying": false,
            "ecu_hardware_id": "docker-compose",
            "full_client_dir": "/var/sota/storage/docker-compose",
            "ecu_private_key": "sec.private",
            "ecu_public_key": "sec.public",
            "firmware_path": "/var/sota/storage/docker-compose/docker-compose.yml",
            "target_name_path": "/var/sota/storage/docker-compose/target_name",
            "metadata_path": "/var/sota/storage/docker-compose/metadata"
        }
    ],
    "torizon-generic": [
        {
            "partial_verifying": false,
            "ecu_hardware_id": "@@MACHINE@@-bootloader",
            "full_client_dir": "/var/sota/storage/bootloader",
            "ecu_private_key": "sec.private",
            "ecu_public_key": "sec.public",
            "firmware_path": "/var/sota/storage/bootloader/u-boot.img",
            "target_name_path": "/var/sota/storage/bootloader/target_name",
            "metadata_path": "/var/sota/storage/bootloader/metadata",
            "action_handler_path": "/usr/bin/bl_actions.sh"
        }
    ]
}

Here you can see this device will only accept package types with hardware ids matching either docker-compose or <machine>-bootloader. What I was thinking was that you could have separate hardware id types for legal and non-legal software. A device that was unsealed would have both hardware id types listed, while a sealed device would only have the non-legal software listed.

This way from the Cloud side sealed devices wouldn’t even be capable of accepting updates for legal software since it would not be listed as a valid hardware id type for it. Additionally. you would be separating your software into legal and non-legal relevant components anyways so it kind of makes sense to treat these as different package types.

This should be possible today. It does depend a little on how your devices get “sealed” as per my question at the start.

Also if you want I can try to arrange a call with our team so we can better discuss your use-case here and what we can offer you to achieve this.

Best Regards,
Jeremias

1 Like
9

We have discussed your proposal but we decided that this would not be a preferred solution because seal state changes during lifetime of the device.

Thank you for your suggestions so far!

Kind regards,
KV

10

seal state changes during lifetime of the device.

I see, well then if that’s the case there is possibly another option.

Our update stack has a feature called “Subsystem Updates”: How to Use Subsystem Updates | Toradex Developer Center

The overall idea is that it lets you the user define a new type of update along with the update logic that dictates how that update is performed. In theory, if you model your legally relevant parts of software as a subsystem update, you could create your own custom update logic that rejects the update, if the device is “sealed”. Assuming you can determine the “sealed/unsealed” state of the device via software.

This way you can just have this subsystem update on all of your devices from the start. That way it should not matter if they change state later on. As the logic you design should just reject/refuse updates for the legally relevant software if the device is sealed. This gives you control over the updates, and essentially gives you a user-created guardrail to make sure that device only updates the software it’s allowed, given it’s state.

Does this idea align better with your requirements and use-case?

Best Regards,
Jeremias

11

We have discussed the problems and decided not to implement “workarounds” straight at the beginning of our development. So we are currently evaluating an update solution without Torizon Cloud.

Thank you anyway!

Kind regards,
KV

12

If you are still interested I think a call with our team could still be beneficial. Perhaps a more detailed call about your requirements would help us to understand your needs and what we can provide.

Best Regards,
Jeremias