Skip to content

dbus: rauc: replace tacd-based update polling with native update polling#90

Open
hnez wants to merge 27 commits intolinux-automation:mainfrom
hnez:rauc-polling
Open

dbus: rauc: replace tacd-based update polling with native update polling#90
hnez wants to merge 27 commits intolinux-automation:mainfrom
hnez:rauc-polling

Conversation

@hnez
Copy link
Member

@hnez hnez commented Apr 2, 2025 •
edited
Loading

This uses the native RAUC update polling support introduced in rauc/rauc#1672 to replace the tacd-internal update polling.

Among the various benefits of this approach are the following:

  • ETag-based check for changed bundles on the server. This means unchanged bundles do not have to be inspect on every poll.
  • Automatic installation and boot into new bundles.

Other PRs related to this one:

TODO before un-drafting:

  • Write proper commit messages

@hnez hnez marked this pull request as ready for review April 3, 2025 07:19
@hnez hnez requested a review from jluebbe April 3, 2025 07:22
@hnez
Copy link
Member Author

hnez commented Apr 3, 2025

Hi @jluebbe,

I'd suggest you go first and review the polling integration first and maybe in a next step we ask @KarlK90 to have a look from a Rust point of view?

This was referenced Apr 3, 2025
Draft
Merged
@jluebbe
Copy link
Member

jluebbe commented May 13, 2025

I've created a RAUC feature request to support service config reloading: rauc/rauc#1709

jluebbe
jluebbe requested changes May 13, 2025
View reviewed changes
@hnez
Copy link
Member Author

hnez commented Feb 20, 2026

I have decided to base this PR on #105 so I do not have to worry about conflicting changes too much.
Since that PR is a draft - because it is currently untested - I will also mark this PR as draft until I had a chance to change that.

@hnez hnez marked this pull request as draft February 20, 2026 12:18
hnez
hnez commented Feb 20, 2026
View reviewed changes
@hnez hnez force-pushed the rauc-polling branch 3 times, most recently from 989ed7d to e3e26fc Compare February 24, 2026 09:36
@hnez hnez marked this pull request as ready for review February 24, 2026 09:36
@hnez
Copy link
Member Author

hnez commented Feb 24, 2026

I think we could review and merge this and carry the RAUC changes as patches in meta-lxatac for a bit, until we are sure that we like the API and how it works in RAUC.
What do you think @jluebbe?

@hnez
Copy link
Member Author

hnez commented Mar 5, 2026

We need to get this reviewed. Who could do that? @jluebbe for the RAUC integration and @KarlK90 for the rest?

hnez added 8 commits March 12, 2026 07:29
@hnez
tacd: dbus: rauc: re-introspect services
5028e4b 
RAUC is in the process of adding native update polling support.
Re-introspect the dbus service to add the new APIs.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: systemd: also monitor rauc.service
da37306 
This exposes the status of the RAUC daemon to users inside and outside of
the tacd. As of now neither of them exist, but in the next few commits
support for re-starting the RAUC deamon to reload its configuration will
be added.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: add Channels type to use instead of Vec<Channel>
ddabd21 
This allows us to add methods like "get the primary channel",
that operates on all update channels at once, to this `Channels`
type later on.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: use a UpdateRequest object instead of a simple URL for in…
b01c848 
…stall

Right now the UpdateRequest object also only contains the URL,
just like before, but in the future we will at least add a
`manifest_hash` field that ensures that the user gets exactly
the update bundle they agreed to install.

The change is backwards-compatible. Incoming requests to the
`/v1/tac/update/install` endpoint are first parsed as JSON object
(the new UpdateRequest object) and if that fails as simple string
(the old URL string) and then transformed transparently.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: allow restricting installation to a specific manifest_hash
e5be30b 
This makes sure that an user gets exact the bundle they intended to
install, e.g. the bundle was not replaced by a newer one on the server
or otherwise tampered with.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: remove tacd-based update polling
e880640 
RAUC is in the process of adding native polling support, which we want to
integrate into the tacd.

To do the switch in a reviewable way first remove the tacd-based polling
and then add the native support in separate commits.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: update_channels: add a concept of a single primary channel
74720c2 
RAUC native update polling only supports a single update channel,
while our native update polling did support multiple
(all channels which RAUC would have accepted updates from,
based on the enabled signing certificates, were polled for updates and the
user was asked if they wanted to install updates from them).

Prepare for the change by adding a concept of a single primary update
channel. The primary channel is the first enabled one. Based on the
channel definition file name.

E.g. on production TACs these channel files are available:

    root@lxatac-00011:~# ls /usr/share/tacd/update_channels/
    01_stable.yaml 05_testing.yaml

They are sorted by name when they are read from disk, so if both
`stable.cert.pem` and `testing.cert.pem` are found
in `/etc/rauc/certificates-enabled/`, then the stable channel will be
the primary channel, but bundles from the testing channel may still be
installed via the command line interface (e.g. to facilitate a channel
switch).

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: only install bundles from the primary channel
3f2d11a 
This restricts the sources that the `/v1/tac/update/install` will accept
update requests from to only the primary channel.
The web interface has not exposed the feature to install arbitrary URLs
for some time now and users that want to do so are better served by using
the command line interface instead.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
hnez added 19 commits March 12, 2026 07:29
@hnez
dbus: rauc: system_conf: write runtime RAUC config with polling section
d8c564a 
This configures RAUC to poll for updates on our behalf.
We do not use the information yet or enable automatic installation but
those are next steps.
We also need to trigger RAUC to re-read the file for this to be useful.
All of these features are added in follow-up commits.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: reload rauc daemon when required
fe295a2 
This uses the existing systemd DBus API integration to trigger a daemon
restart (there is no support to just reload the config as of now) and
keep track of the following state changes.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: trigger a single poll for updates after reloading the daemon
da1b02f 
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: forward poller status to broker
cebb3fa 
RAUC native polling provides us with information about the recent poll
attempts. This includes information about the bundle version and wether
it is an update over what is currently running on the device.

In other words: it gives us everything we need to show update
notifications again. Forward this information to the same places we used
with the tacd-based update polling.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: add manifest_hash und effective_url to UpstreamBundle
b9c4fb7 
The RAUC native polling interface provides more information than
just the basic `compatible` and `version` fields.
Among these extra informations are the following:

  - `manifest_hash`

    By using the `manifest_hash` in the `InstallBundle` call we can
    (cryptographically) ensure that the exact bundle (content) that the
    user agreed to install is actually being installed and that no switch
    has happened in between.

  - `effective_url`

    This is the bundle URL after all HTTP redirects have been followed.
    This is e.g. relevant when a "clever" update server is used that
    redirects poll requests to specific bundles to e.g. implement staged
    rollouts or prevents updates from incompatible bundle versions.

    By using this one can ensure that the bundle URL used matches
    the `manifest_hash` provided and that the redirects did not change
    (e.g. because the next step in a staged update was reached)
    between the last poll and the user accepting an update.

The update dialog on the LCD is updated to use this mechanism now,
while the web interface will be updated later.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: add support for enabling the auto install feature
eef85e8 
Automatic installation and boot of updates can be useful when managing a
fleet of devices. This is however a feature that requires strict user
consent, hence why it is off by default.

Add backend-support for enabling this feature. Frontent support in the
web interface will be added later.

We always enable auto-reboot together with auto-install,
since the migration scripts only run once at the end of the installation.
A system that is updated, but not rebooted, would thus accumulate changes
that are not migrated to the other slot.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: implement forced polling via update channel files
768e7a9 
Users managing a fleet of devices with custom-built update bundles and
update channel may want to automatically enable update polling and
automatic installation of updates without having to do so explicitly via
the web ui. (At least we at Pengutronix do).

Enable this usecase by adding optional `force_polling` and
`force_auto_install` config options to the update channel definition
files.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: allow configuring the *_criteria in channel files
237294d 
The native RAUC polling feature allows configuring when a new update
bundle is even considered as an update candidate (`candidate_criteria`),
when it is considered for automatic installation (`install_criteria`)
and under which conditions to auto-boot into another slot after
installation (`reboot_criteria`).

The defaults we have chosen in previous commits generally make sense,
but allow users with custom update channels to customize them if they
deem it necessary.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: allow configuring the inhibt-files feature from channel file
db024eb 
This feature allows disabling the polling for and automatic installation
of update bundles.

If one of the files exsists polling will be paused.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
tacd: inhibit: create and remove inhibit file based on setup_mode status
d763bb2 
When in setup mode we do not want the system to auto-install updates and
suddenly reboot without user input, as that would lead to a bad first
experience with the TAC.

Instead use an inhibit file to delay the first RAUC update poll to when
the setup mode is exited.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
tacd: inhibit: also pause auto updating while the DUT power is on
0f26f3d 
Ideally we would not want to auto-reboot when the TAC is in use,
but deciding when that is, is not easy.
One piece of information we do have is if the DUT is currently powered.
In that case we very likely do not want to reboot right now.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
tacd: dbus: rauc: break out flatten_slot_status()
becfde2 
The return value from InstallerProxy::get_slot_status() needs some
post-processing.
Break that out into a separate function, because we will need to call
`get_slot_status` from another place soon.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
tacd: dbus: rauc: break out booted_slot_other_slot()
df206d8 
This function looks up the two rootfs slots and aranges them based on
which one is booted and which one is not.
This is currently only used in one place, but will be used in another
soon.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
tacd: dbus: rauc: use Err(anyhow!(...)) instead of bail!(...)
6d55a67 
I like this better now, because it makes the control flow more obvious
(bail! returns right there, while Err(anyhow!(...))) follows the normal
control flow.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
tacd: dbus: rauc: mark the booted slot good again after RAUC restart
61f849d 
At least for now the RAUC service will only poll for updates if the booted
slot was marked good during the current runtime of the service.
We restart the service to dynamically update the configuration.
This means we have to mark the booted slot as good again if we want polling.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
web: setup: inform the user about additional headers that are sent now
23b1fcc 
We include the `boot-id` and `uptime` options in the RAUC `send-headers`
config in the hopes of detecting boot-loops during update roll-out.
This was not anticipated when writing the setup page, so we add it now.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
web: indicate to the user when a channel is enabled but not primary
02e3bab 
The channel list in the web interface now contains a "Upgrade" column
with one of the following:

  - "Not enabled" for channels which are not enabled, which means bundles
    from it can not be installed for it.
  - "Not primary" (this one is new) for channels which are enabled,
    but are not the primary one and are thus not polled by the native RAUC
    polling feature.
  - "Polling disabled" if the polling feature is not enabled.
  - A spinner if we do not know the status yet.
  - "Up to date" if the TAC is in sync with this update channel.
  - "Upgrade" (a button) if an update is available.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
web: add toggle switches to enable automatic installation of updates
0faf585 
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
web: use manifest_hash and effective_url when triggering an install
442bb9d 
This ensures that the exact bundle (content) that the user agreed to
install is actually installed.

Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jluebbe jluebbe jluebbe requested changes

Requested changes must be addressed to merge this pull request.

Assignees

@jluebbe jluebbe

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@hnez @jluebbe