Progress Handling Rework

From a user perspective, probably the most notable change with v1.10 is the progress handling, which is now more realistic and fine-grained.

Historically, the progress information in RAUC, emitted by either the D-Bus Progress property or shown by CLI when calling rauc install --progress, was badly distributed. This means that actual image copying started at 80%, while everything before was just some checks and verification.

This has never been a realistic distribution of the actual duration for each task, but has become much worse with the introduction of the 'verity' format which made the initial verification happen quite quickly. As a result (depending on the actual write speeds etc.), the progress bar had reached 80% after completing ~10% of the installation job.

Improvements of rauc info

$ rauc info --output-format=json-2 test/good-adaptive-meta-bundle.raucb
{
  "update" : {
    "version" : "2023.03-1",
    "compatible" : "Test Config"
  },
  "images" : [
    {
      "slot-class" : "rootfs",
      "filename" : "rootfs.img",
      "checksum" : "101a4fc5c369a5c89a51a61bcbacedc90[...]",
      "size" : 8192,
      "hooks" : []
    },
  ],
  "manifest-hash" : "4f471ebf24aeb566fad623c1084cd448[...]",
  [...]
  "meta" : {
    "update" : {
      "poll" : "86400"
    },
    "version" : {
      "channel" : "beta",
      "release-notes" : "https://example.com/release-notes"
    }
  }
}

Introduction of Transaction UUIDs

With v1.10, another element for better tracking of the life-cycle of an installation was added to RAUC: The (installation) transaction UUID.

While the manifest hash, introduced with RAUC v1.9, allowed us to unambiguously tell which exact bundle was installed, one aim of the transaction UUID is to tell which exact installation invocations led to the current state of the system. Further plans are to use this information for tracking the installation procedure beyond just the basic slot writing and allows a user to know if an installation actually resulted in the expected system being booted, etc.

For this, RAUC generates a new UUID when starting an installation. Alternatively, D-Bus callers can provide their own ID here, e.g. for update servers that already have a concept of an ID per installation.

Currently, RAUC prints the transaction UUID in the logs, writes it to the slot status file(s) and shows it in the rauc status --detailed output and in the corresponding D-Bus API.

Sealing the Leak

Triggered by a community contribution fixing a memory leak that was revealed by using the libfuzzer and the address sanitizer capabilities of the compiler, we added a new sanitzier action workflow to the GitHub CI.

Enabling address sanitizer checking for test cases required a number of memory leaks to be fixed in the test cases itself, but in the end also revealed some remaining memory leaks in RAUC itself.

While most unit tests now run with address sanitizer enabled, some still need to be done. However, the new checks already help to detect memory leaks and other regressions in RAUC.

Meson Support

Meson support was introduced with RAUC v1.9 to replace the ancient autotools. They were kept in parallel with autotools for this release to simplify migration.

We have then agreed on keeping both even in the v1.10 release. Not only to have a longer grace period, but also since we still had some smaller issues that were fixed now, like a dependency issue for test builds, a wrong file mode for the rauc-service.sh wrapper, and finally we missed installing our fine man page.

In the next release, autotools support will likely be dropped, thus package maintainers who haven't migrated to Meson yet should consider it.

Luckily, by the time of writing, most have already migrated anyway. Buildroot did it with the v1.9 migration (thanks to Heiko Thiery), same for meta-rauc, and for PTXdist I prepared a patch just yesterday.

Outlook: HTTP Header Customization

As outlined in concept #1114, we have plans to improve support for simple update servers by optionally providing some information about the system state to the server in the first HTTP request's headers. The server can then use this for more detailed logging or even for making simple decisions based on the data.

With v1.10, some other preparations made into RAUC: The so-far quite limited system-info handler was extended to return custom system information as environment-like variables. Specially named variables are then planned to be exposed via HTTP headers, too. The actual header implementation is already available in PR #1152.

Thanks

Many thanks again to all contributors of the v1.10 release: Christian Hitz, Christian Hohnstaedt, Christian Meusel, Enrico Jörns, Jan Lübbe, Lars Poeschel, René Fischer, Stefan Wahren, Ulrich Ölmann, b4yuan