rauc / rauc-hawkbit-updater

The RAUC hawkBit updater is a simple commandline tool/daemon that runs on your target and interfaces between RAUC and hawkBit's DDI API.

RAUC hawkBit Updater

The RAUC hawkBit updater is a simple command-line tool/daemon written in C (glib). It is a port of the RAUC hawkBit Client written in Python. The daemon runs on your target and operates as an interface between the RAUC D-Bus API and the hawkBit DDI API.

Quickstart

The RAUC hawkBit updater is primarily meant to be used as a daemon, but it also allows you to do a one-shot instantly checking and install new software.

To quickly get started with hawkBit server, follow this instruction.

Setup target (device) configuration file:

  [client]
  hawkbit_server            = 127.0.0.1:8080
  ssl                       = false
  ssl_verify                = false
  tenant_id                 = DEFAULT
  target_name               = test-target
  auth_token                = bhVahL1Il1shie2aj2poojeChee6ahShu
  #gateway_token            = bhVahL1Il1shie2aj2poojeChee6ahShu
  bundle_download_location  = /tmp/bundle.raucb
  retry_wait                = 60
  connect_timeout           = 20
  timeout                   = 60
  log_level                 = debug
  post_update_reboot        = false
  #stream_bundle            = true

  [device]
  product                   = Terminator
  model                     = T-1000
  serialnumber              = 8922673153
  hw_revision               = 2
  key1                      = value
  key2                      = value

All key/values under [device] group are sent to hawkBit as data (attributes). The attributes in hawkBit can be used in target filters.

Finally start the updater as daemon:

$ ./rauc-hawkbit-updater -c config.conf

Debugging

When setting the log level to 'debug' the RAUC hawkBit client will print JSON payload sent and received. This can be done by using option -d.

$ ./rauc-hawkbit-updater -d -c config.conf

Compile

Install build pre-requisites:

• meson
• libcurl
• libjson-glib

$ sudo apt-get update
$ sudo apt-get install meson libcurl4-openssl-dev libjson-glib-dev

$ meson setup build
$ ninja -C build

Test Suite

Prepare test suite:

$ sudo apt install libgirepository1.0-dev nginx-full
$ python3 -m venv venv
$ source venv/bin/activate
(venv) $ pip install --upgrade pip
(venv) $ pip install -r test-requirements.txt

Run hawkBit docker container:

$ docker pull hawkbit/hawkbit-update-server
$ docker run -d --name hawkbit -p 8080:8080 hawkbit/hawkbit-update-server \
    --hawkbit.server.security.dos.filter.enabled=false \
    --hawkbit.server.security.dos.maxStatusEntriesPerAction=-1

Run test suite:

(venv) $ ./test/wait-for-hawkbit-online && dbus-run-session -- pytest -v

Pass -o log_cli=true to pytest in order to enable live logging for all test cases.

Usage / Options

$ /usr/bin/rauc-hawkbit-updater --help
Usage:
  rauc-hawkbit-updater [OPTION?]

Help Options:
  -h, --help               Show help options

Application Options:
  -c, --config-file        Configuration file
  -v, --version            Version information
  -d, --debug              Enable debug output
  -r, --run-once           Check and install new software and exit
  -s, --output-systemd     Enable output to systemd

rauc-hawkbit-updater's Issues

Curl Follow Location

Hi,

In our version, we added
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);

is it an option that make sense by default ?

Thread 10 "gdbus" received SIGSEGV. Segmentation Fault

Hi,
We're trying to integrate the rauc-hawkbit-updater service into an embedded SOM for a client. We are using Bosch IOT Rollouts as the hawkbit server, and have been able to successfully download a rauc bundle. Unfortunately, it is not getting beyond this.

Here is a snippet from the console logs (tenant ID and controller id removed below)

MESSAGE: Download complete. 2.12 MB/s
MESSAGE: File checksum OK.
DEBUG: Request body: {"id":"168548","time":"20200401T121811","status":{"result":{"progress":{"of":1,"cnt":3},"finished":"none"},"execution":"proceeding","details":["File checksum OK."]}}

DEBUG: Feedback progress status: 200, URL: https://device.eu1.bosch-iot-rollouts.com/<tenant-id>/controller/v1/<controller-id>/deploymentBase/168548/feedback
DEBUG: Creating RAUC DBUS proxy

[17634.526359] audit: type=1701 audit(1585743725.596:169): auid=4294967295 uid=993 gid=990 ses=4294967295 pid=856 comm="gdbus" exe="/usr/bin/rauc-hawkbit-updater" sig=11 res=1
Segmentation fault (core dumped)

Any ideas what might be happening here ?

Thanks,

Sidd (delhiryder)

Allow overriding polling time from config

It would be helpful to have development/staging targets poll hawkbit more often than the server-side defined polling interval (which is set to multiple hours so we save mobile bandwidth).

Our development targets are connected via an ethernet connection though and it would ease the testing workflow if we could tell those to just poll hawkbit every minute instead.

Moving Repository to 'rauc' GitHub Organization?

Hi,

as this piece of software seems to raise more and more interest for people that look for a non-python alternative of https://github.com/rauc/rauc-hawkbit and do not want to reinvent the wheel, I would like to ask you if you are interested in moving the repository to the rauc organization on GitHub. This could give the project even more attention and makes it visibly belonging to RAUC.

We also plan to integrate this into meta-rauc and would like to clarify a future-proof location before ;)

Thus, if you are interested, we could move the repository keeping all issues etc intact and add you (@prevas-lkmi and other if desired) as maintainer for the project's team.

Would be great if you let me know which variant you prefer. If you have any concerns or questions, just let me know.

Best regards, Enrico

tenant_id/target_name are not encoded properly

Configuring tenant_id or target_name with spaces or special characters leads to errors. These URL components should be properly URL-encoded.

hawkbit-client.c: memory leak on debug messages

hawkbit-client. c is making use of json_to_string() for debugging messages (1, 2). However, this is provoking a small leak as said function returns a char * that must be released manually.

A possible fix could be:

char *str = json_to_string(resp_root, TRUE);
g_debug("Deployment response: %s\n", str);
free(str);

If this approach is OK, we can proceed to generate a PR :)

Rauc hawkbit, azure docker container returns 301

We have set up hawkbit in azure app services using an app service https certificate.

We also have this as our rauc manifest config.

[client]
hawkbit_server = myserver.com
ssl = true
ssl_verify = false
tenant_id = DEFAULT
target_name = 127086
auth_token = token
bundle_download_location = /mnt/data/rauc/bundle.raucb
retry_wait = 60
connect_timeout = 20
timeout = 60
log_level = debug
post_update_reboot = true
[device]
product = aps400a
model = aps400a
serialnumber = 127086
hw_revision = 1

When we run sudo rauc-hawkbit-updater -c /mnt/data/hawkbit.conf -r --debug

The server response body comes back as

DEBUG: Response body: {
"config" : {
"polling" : {
"sleep" : "00:05:00"
}
},
"_links" : {
"deploymentBase" : {
"href" : "http://myserver.com/DEFAULT/controller/v1/127086/deploymentBase/6?c=416217484"
}
}
}

and then says

WARNING: HTTP request failed: 301; server response:

Are we missing a toggle that needs to be set? When we turn off forced HTTPS and SSL it is able to do the download however when we turn it back on we get the error 301.

g_object_unref: assertion 'G_IS_OBJECT (object)' failed

This error is coming from;

static gboolean process_deployment(JsonNode *req_root, GError **error)

in case json_response_parser is NULL

        if (status != 200 || json_response_parser == NULL) {
                g_debug("Failed to get resource from hawkbit server. Status: %d", status);
                goto proc_error;
        }

jumping in proc_error:

proc_error:
        g_object_unref(json_response_parser);

<stdbool.h> not required

Sharing a minor change:

---
 include/rauc-installer.h   | 1 -
 src/rauc-hawkbit-updater.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/include/rauc-installer.h b/include/rauc-installer.h
index 55e67c8..baa021f 100644
--- a/include/rauc-installer.h
+++ b/include/rauc-installer.h
@@ -22,7 +22,6 @@
 #ifndef __RAUC_INSTALLER_H__
 #define __RAUC_INSTALLER_H__
 
-#include <stdbool.h>
 #include <stdio.h>
 #include <glib-2.0/glib.h>
 #include "rauc-installer-gen.h"
diff --git a/src/rauc-hawkbit-updater.c b/src/rauc-hawkbit-updater.c
index 6cba97f..2cbd189 100644
--- a/src/rauc-hawkbit-updater.c
+++ b/src/rauc-hawkbit-updater.c
@@ -24,8 +24,6 @@
  *
  */
 
-
-#include <stdbool.h>
 #include <stdio.h>
 #include <glib-2.0/glib.h>
 #include "rauc-installer.h"

Reports Success Before Being Verified via Reboot

In a typical implementation of RAUC it is the responsibility of the newly updated slots to mark their status good or bad.

rauc-hawkbit-updater to my knowledge does not support reporting success back to hawkbit after the newly updated slot has been validated via a boot or external test, rather it reports success immediately upon a ""successful"" install.

I would consider this a problem as it may falsely label a failed install as successful. This is made worse by Hawkbit's lack of API to update the recorded software version number. So not only is a failed install labeled as successful, Hawkbits is unaware of any rollback the target system has performed and will skip reinstall attempts because it thinks the current software is up to date.
See this other user with similar problems: eclipse/hawkbit#446

With SWUpdate's Hawkbit client, it's the responsibility of the updated OS to report a successful install... I think... or its reporting mechanism is broken.

Am I the only person seeing this problem or am missing something in my implementation?
Is it possible to have rauc-hawkbit-updater only inform hawkbit of a successful update after the update has been truly validated?

Temporarily no network connectivity: Scheduled check for new software failed

Hello,
thanks for this nice piece of software. I just switched from rauc-hawkbit-client to rauc-hawkbit-updater and noticed a bug:
when I execute rauc-hawkbit-updater from an autostart script it only prints these two lines and after that it does not retry to connect again:

MESSAGE: Checking for new software...
DEBUG: Scheduled check for new software failed status code: 0

probably this line is also printed (but not written to my log file):

CRITICAL: HTTP Error: HTTP request failed: Couldn't resolve host name

It is possible that at that point in time the network interfaces of the system are not up or configured properly, but with rauc-hawkbit-client that was not a problem - a later retry did work there. I encounter the same problem when I shut down the ethernet interface and then start the application manually.

When I then kill rauc-hawkbit-updater and execute it again manually (when ethernet is active) it does connect to the server. Any ideas how to fix this?
Thanks!

SSL peer certificate or SSH remote key was not OK

Hello,

I have a rauc-hawkbit-updater client setup to download software artifacts from HawkBit server. But, I am getting below error from rauc-hawkbit-updater about SSL verification. The same client is also present on other devices and communicating to same HawkBit server. And rauc-hawkbit-updater is working fine on them.

rauc-hawkbit-updater[6797]: Checking for new software...
rauc-hawkbit-updater[6797]: HTTP Error: HTTP request failed: SSL peer certificate or SSH remote key was not OK

The client is part of systemd service and is called like
/usr/bin/rauc-hawkbit-updater -s -c /etc/hawkbit/config.cfg

I tried to get the debug output with -d flag. But, the -d option is not outputting anything (client is not executed). And I see that verbose mode is not enabled. I think, it would be better to include this to get more debug messages.

/* ask libcurl to show us the verbose output */
  curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);

Should this be inluded in hawkbit-client.c?

Can anyone please let me know what could be the issue here?

Thank you,
Sourabh

Update .gitignore for the temporary files generated by uncrustify

Hi,

I was playing with the code a little when I run uncrustify.sh to guarantee the your code convention. That is when I noticed that uncrustify leftovers are not ignored. Not a big deal, but if one is lazy at the moment of calling git add we may end with trash on the commits, wasting time on the PR reviews .

As a mitigation, .gitignore may be updated to include the following lines:

# Backup files done by uncrustify
.uncrustify/
*~

json_root not released in hawkbit_pull_cb

in function static gboolean hawkbit_pull_cb(gpointer user_data)
JsonNode *json_root = json_parser_get_root(json_response_parser);
but it is not unref.

+g_object_unref(json_root);
g_object_unref(json_response_parser);

rauc-hawkbit-updater failed when dbus is restarted

According to my testing, rauc-hawkbit-upater failed when dbus process is restarted.

rauc-hawkbit-updater.service should also set statement:

After=rauc.service dbus.socket
Requires=rauc.service dbus.socket

in order to restart in case rauc or dbus failure

HTTP Request failed with 301

Hi, I've decided to use newer version of updater in our system but I got an error.

I was using b38f5a5 previously and Now, using latest commit cc2cd6e.

I've also tested 5a55ab7 but no success.

Here's the log message that I've got

root@DEV:~# /usr/bin/rauc-hawkbit-updater -d -c /userdata/rauc-hawkbit-updater/config.conf
MESSAGE: Checking for new software...
DEBUG: Response body: {
  "config" : {
    "polling" : {
      "sleep" : "00:05:00"
    }
  },
  "_links" : {
    "deploymentBase" : {
      "href" : "http://URL/default/controller/v1/MY_DEVICE_ID/deploymentBase/918?c=1258468636"
    }
  }
}
WARNING: HTTP request failed: 301; server response: <html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.17.5</center>
</body>
</html>

Does anyone has an idea?

Support for offline updates ?

Hi,

There has been a discussion on offline deployments (ex: manual updates using a USB drive) leading to updating the UI regarding the update information, available here and here.

Is this supported by rauc-hawkbit-updater when running as a daemon ?

hawkbit URL regression

I am unable use the new tags v1.0 and v1.1. I've identified the issue stemming from a regression caused by commit 8624e71

I had a look at the old code

rauc-hawkbit-updater/src/hawkbit-client.c

Line 638 in cbafe65

int status = rest_request(GET, get_resource_url, NULL, &json_response_parser, error);

and the new

rauc-hawkbit-updater/src/hawkbit-client.c

Line 605 in 8624e71

int status = rest_request(GET, deployment, NULL, &json_response_parser, error);

and printed the variables deployment in the new version and get_resource_url in the old version, and see that in the new deployment variable the domain name and TLD of the URL is missing.

(gdb) print deployment
$1 = (gchar *) 0xaaaaaabc7100 "http://hawkbit:8080/DEFAULT/controller/v1/TEST/deploymentBase/2065?c=-1956918325"  `

(gdb) print get_resource_url
$1 = (gchar *) 0xaaaaaaceb560 "https://hawkbit.mydomain.se/DEFAULT/controller/v1/TEST/deploymentBase/2065?c=-1956918325"

Feature Wish List

Note: This was in the Wiki before as 'Roadmap'. Moved it to an issue to close the (unused) wiki but not lose these items.

• "Ask" permission to download (D-BUS).
• "Ask" permission to install (D-BUS).
• Expose download and install progress via D-BUS (like Rauc service does).
• Support casync

Inconsistency in naming variables

Should the name of enable_streaming in the example configuration file in the readme be stream_bundle instead? In the code it looks like this: (src/config-file.c lines 303-304)

       if (!get_key_bool(ini_file, "client", "stream_bundle", &config->stream_bundle, FALSE,
                          error))

This should not be a mayor issue but still is inconsistent if I am right.

GError HTTP Request Failed with Server

Hi there,

I have been struggling with the rauc-hawkbit-updater service for a few days now and keeping hitting the error below when I try to deploy a new artifact.

Here is my rauc-config.conf file:

root@raspberrypi4:~# cat rauc-config.conf
[client]
# host or IP and optional port
hawkbit_server = ***.com
ssl                       = false
ssl_verify                = false
tenant_id                 = DEFAULT
target_name               = dev01 
auth_token                = abc123 #dummy value for actual token 
bundle_download_location  = /tmp/bundle.raucb
retry_wait                = 60
connect_timeout           = 20
timeout                   = 60
log_level                 = debug 
post_update_reboot        = false 

[device]
mac_address               = MACADDRESS
hw_revision               = 1
model                     = dev01

Whenever I try to run with the above config file, this is the result:

root@raspberrypi4:~# rauc-hawkbit-updater -d -c rauc-config.conf
MESSAGE: Checking for new software...
DEBUG: Response body: {
  "config" : {
    "polling" : {
      "sleep" : "00:05:00"
    }
  },
  "_links" : {
    "deploymentBase" : {
      "href" : "http://***.com/DEFAULT/controller/v1/dev01/deploymentBase/2?c=412523400"
    },
    "configData" : {
      "href" : "http://***.com/DEFAULT/controller/v1/dev01/configData"
    }
  }
}
DEBUG: Identifying ourself to hawkbit server
DEBUG: Request body: {
  "time" : "20210324T125933",
  "status" : {
    "result" : {
      "finished" : "success"
    },
    "execution" : "closed"
  },
  "data" : {
    "model" : "dev01",
    "mac_address" : "MACADDRESS",
    "hw_revision" : "1"
  }
}

(rauc-hawkbit-updater:421): GLib-WARNING **: 12:59:33.452: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: HTTP request failed: No error
DEBUG: Failed to get resource from hawkbit server. Status: 400
CRITICAL: Error: HTTP request failed: No error

Based on that response, it seems to be successfully communicating with my server. As for why it is failing to pull the new artifact I am deploying, I cannot figure out. Am I doing something blatantly wrong here? The error - CRITICAL: ERROR: HTTP request failed: No error - is quite... frustrating to debug with 😅

Thank you for you time and assistance

Trailing spaces in config values are not stripped

This can lead to strange situations depending on the configuration option. If target_name contains trailing spaces, polling the base resource succeeds:

GET /DEFAULT/controller/v1/test  HTTP/1.1

But other resources fail:

POST /DEFAULT/controller/v1/test /deploymentBase/9/feedback HTTP/1.1

We saw reports of this in #78 and elsewehere. So trailing spaces should be stripped in all config options.

downloadonly deployment is never finished

When downloadonly assignment is pushed from Hawkbit, it's finished with the action status none. According to DDI documentation this would keep action in the state running and is never finished (which can be observed in the Hawkbit Management UI). But downloadonly should not expect any other activities after download, so we should finish the action after download is complete.

Compilation doesn't work since change to meson

I am trying to compile this code, but everytime I run meson setup build ther is an error ERROR: Neither directory contains a build file meson.build.. I use this command in the base folder of the project .../rauc-hawkbit-updater/. Do you know how to fix this?

I use a crosscompiler. With cmake it worked fine. This schould not be a problem with meson?

Segmentation fault caused by "config.conf" file

Hi,
when using the rauc-hawkbit-updater, we get a SIGSEGV. Segmentation Fault.
We noticed, that the updater crashes while trying to get the data from the “config.conf” file.
It seems, that the Boolean variables in the “config.conf” file are not parsed correctly and because of that the comments, which are declared with a “#” on the same line, are being ignored as comments and written into the variables.

Did anyone have the same Problem?

Thanks.

downloaded bundle has the wrong owner

The downloaded bund is saved with the owner root:rauc-hawkbit-updater and permissions 644.
rauc-hawkbit-updater is running by the systemd service file.
So the updater fails to delete the old bundle either to download a new one.

Any suggestion support install casync bundle from hawkbit?

I'm building casync bundle for minimizing updates size.

But I see hawkbit only support upload files not directory of castr

So can I specify location of castr or other means to do update casync bundle via hawkbit?

I see casync section in Reference, I can specify storepath, if this will be a static path, how can I migrate different versions of castr ?

How to handle new features of hawkbit with rauc-hawkbit-updater?

Hello,

Recently, hawkbit released a new version 0.3.0M8 https://github.com/eclipse/hawkbit/releases/tag/0.3.0M8 which included support for "Request confirmation for actions before proceeding with download/install process." option. As ststed in the release notes "The new feature facilitates the implementation of user consent requirements (e.g. as mandated by the European Tangible Goods Directive) by enhancing the action state machine with a new state WAITING_FOR_CONFIRMATION". It can be activated/set in hawkBit UI under System Config. Then the target needs to either set confirmed or denied to make an action available for download confirm-action. "The action will be transferred into the RUNNING state in case the device is confirming it. Afterwards it will be exposed by the deploymentBase."

I believe these operations are not currently part of rauc-hawkbit-updater.
Is there any plan to support these operations in the next release of the client?

Thanks in advance

Stable version tags

Could you make tags for stable versions of this software?

meta-rauc is currently supplying an unstable version of rauc-hawkbit-updater, commit d909982 which does not include #35. It would save time debugging, a fixed issue #21, if I realized that meta-rauc were shipping an old unstable version. This could have been prevented if this project used version tags, at leas tagged commits that are considered stable.

rauc-hawkbit-updater with streaming can easily exceed hawkbit quota on action updates

Hawkbit has a default quota, that each action can have up to 1K status updates.

With streaming enabled, this nearly instantly overflows the quota with a sufficiently large image.

lis 23 13:18:42 odo hawkbit.hawkbit[963]: 2022-11-23 13:18:42.219 WARN 963 --- [tp1756726852-23] o.e.h.repository.jpa.utils.QuotaHelper : Cannot assign 1 ActionStatus entities to Action '51' because of the configured quota limit 1000. Currently, there are 1001 ActionStatus entities assigned.

Transfer any file to the target board using Rauc-hawkbit-updater

How can i transfer any binary file into target board using Hawkbit Tool?

Actually i am able to send the rauc bundles from the PC to the target board. And it is successfully installing the rauc bundles in the board, but when i am trying to send any file(binay file) into the target board it is not visible and also rauc-hawkbit-updater is trying to install that file.

I only want to send a simple binary file into target board. If it is possible then please share the answers for my query.

Thankyou

Segfaulting when new software is found

Application segfaults on armv7 target (Marvell Armada-388 EV board). When hawkbit indicates that a new software is available, the application dies in a g_message call.

Cmake output:

-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /src/manifest/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/rauc-hawkbit-updater/1.0-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
-- Check for working C compiler: /src/manifest/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/rauc-hawkbit-updater/1.0-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /src/manifest/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/rauc-hawkbit-updater/1.0-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-- Check for working CXX compiler: /src/manifest/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/rauc-hawkbit-updater/1.0-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /src/manifest/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/rauc-hawkbit-updater/1.0-r0/recipe-sysroot-native/usr/bin/pkg-config (found version "0.29.2")
-- Checking for module 'libsystemd'
-- Found libsystemd, version 239
-- Checking for module 'libcurl>=7.47.0'
-- Found libcurl, version 7.61.0
-- Checking for module 'gio-2.0>=2.26.0'
-- Found gio-2.0, version 2.58.0
-- Checking for module 'gio-unix-2.0>=2.26.0'
-- Found gio-unix-2.0, version 2.58.0
-- Checking for module 'json-glib-1.0'
-- Found json-glib-1.0, version 1.4.2
-- Configuring done
-- Generating done

Problem is that the g_message call at hawkbit-client.c:618 is passing the file size as %ld in format. Must be %lld due to the data type holding the file size. If this is not changed the application will segfault in a strlen call in extension of the g-message call.

Also the g_strdup_printf call at hawkbit-client.c:624 should have the %ld changed to %lld.

Keeping the %ld entries also produces compiler warnings in GCC 8.2.0

Invalid checksum Error - Yocto OS Update

Hello!,
I want to do an OS update with Yocto. I am using rauc-hawkbit-updater and rauc for the delivering the OS to the device and for installing the OS respectively. Hawkbit is in sync with AWS S3 bucket which has the OS distribution.

Rauc-Hawkbit-Updater downloads the OS file from hawkbit, however it is throwing this error Software: DeviceOS VR1.3.4. Invalid checksum: da39a3ee5e6b4b0d3255bfef95601890afd80709 expected 762186110ac2b74675eb7fdb1dfe1801191e364f

The logs are:

> Jun 28 11:18:01 device-2021400048 rauc-hawkbit-updater[4431]: No new software.
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Checking for new software...
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Response body: {
>                                                                "config" : {
>                                                                   "polling" : {
>                                                                    "sleep" : "00:05:00"
>                                                                  }
>                                                                },
>                                                                "_links" : {
>                                                                  "deploymentBase" : {
>                                                                    "href" : "http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/deploymentBase/30?c=438411779"
>                                                                  }
>                                                                }
>                                                              }
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Response body: {
>                                                                "id" : "30",
>                                                                "deployment" : {
>                                                                  "download" : "forced",
>                                                                  "update" : "forced",
>                                                                  "chunks" : [
>                                                                    {
>                                                                      "part" : "os",
>                                                                      "version" : "R1.3.4",
>                                                                      "name" : "OS",
>                                                                      "artifacts" : [
>                                                                        {
>                                                                          "filename" : "casync-bundle.raucb",
>                                                                          "hashes" : {
>                                                                            "sha1" : "762186110ac2b74675eb7fdb1dfe1801191e364f",
>                                                                            "md5" : "ad1607ba7cdcb686d0029930f474774e",
>                                                                            "sha256" : "b28c2157685459df40172f03a3cc8babbb20a5cfa402b4ab2f9d9d965924f245"
>                                                                          },
>                                                                          "size" : 1579439,
>                                                                          "_links" : {
>                                                                            "download-http" : {
>                                                                              "href" : "http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/softwaremodules/12/artifacts/casync-bundle.raucb"
>                                                                            },
>                                                                            "md5sum-http" : {
>                                                                              "href" : "http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/softwaremodules/12/artifacts/casync-bundle.raucb.MD5SUM"
>                                                                            }
>                                                                          }
>                                                                        }
>                                                                      ]
>                                                                    }
>                                                                  ]
>                                                                }
>                                                              }
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: New software ready for download. (Name: DeviceOS, Version: R1.3.4, Size: 1579439, URL: http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/softwaremodules/12/artifacts/casync-bundle.raucb)
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Start downloading: http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/softwaremodules/12/artifacts/casync-bundle.raucb
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Request body: {
>                                                                "id" : "30",
>                                                                "time" : "20220628T112303",
>                                                                "status" : {
>                                                                  "result" : {
>                                                                    "finished" : "none"
>                                                                  },
>                                                                  "execution" : "proceeding",
>                                                                  "details" : [
>                                                                    "Download complete. 0.00 MB/s"
>                                                                  ]
>                                                                }
>                                                              }
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Feedback progress status: 200, URL: http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/deploymentBase/30/feedback
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Download complete. 0.00 MB/s
> Jun 28 11:23:03 device-2021400048 rauc-hawkbit-updater[4431]: Request body: {
>                                                                "id" : "30",
>                                                                "time" : "20220628T112303",
>                                                                "status" : {
>                                                                  "result" : {
>                                                                    "finished" : "failure"
>                                                                  },
>                                                                  "execution" : "closed",
>                                                                  "details" : [
>                                                                    "Software: DeviceOS VR1.3.4. Invalid checksum: da39a3ee5e6b4b0d3255bfef95601890afd80709 expected 762186110ac2b74675eb7fdb1dfe1801191e364f"
>                                                                  ]
>                                                                }
>                                                              }
> Jun 28 11:23:04 device-2021400048 rauc-hawkbit-updater[4431]: Feedback status: 200, URL: http://hawkbitUrl:8080/DEFAULT/controller/v1/developerDevices_2021400048/deploymentBase/30/feedback
> Jun 28 11:23:04 device-2021400048 rauc-hawkbit-updater[4431]: Software: DeviceOS VR1.3.4. Invalid checksum: da39a3ee5e6b4b0d3255bfef95601890afd80709 expected 762186110ac2b74675eb7fdb1dfe1801191e364f
> Jun 28 11:28:04 device-2021400048 rauc-hawkbit-updater[4431]: Checking for new software...

Would really appreciate some insight of what I could be doing wrong on this.

Doesn't support rauc configured without dbus

Currently rauc-hawkbit-updater doesn't support rauc when configured without dbus (--disable-service)

potential SEGV with error

In function main, when config is NULL, it error could also be NULL so
g_printerr("Loading config file failed: %s\n", error->message);
could crash

It miss a test error != NULL to call error->message

also in load_config_file before returning NULL, it would be better to set error:
g_set_error(error, xxx)

like in each call like:

 if (!g_key_file_load_from_file(ini_file, config_file, G_KEY_FILE_NONE, error))
                return NULL;

Fail to download artifact: g_file_test: assertion 'filename != NULL' failed

Hi,

I am running the rauc-hawkbit-updater v1.3 together with hawkbit 0.3.0M7.
When I configure a rollout the rauc-hawkbit-updater crashes with:

g_file_test: assertion 'filename != NULL' failed

Settings and Log:
rauc-hawkbit-updater.conf
fail-rauc-hawlbit-updater.log

What am I doing wrong?

Can anyone please provide the steps for cross compiling the rauc-hawkbit-updater on raspberrypi with the aarch64?

updater use http for deploymentBase link instead of https (301 Moved Permanently)

rauc-hawkbit-updater can connect successfull with the hawkbit. check for new software is ok.
the rauc-hawkbit-updater do not use https for the deploymentBase. My old version (commit id (28900b5) use https and it runs.

rauc-hawkbit-updater -d -c /mnt/config/hawkbit/config.cfg
MESSAGE: Checking for new software...
DEBUG: Response body: {
"config" : {
"polling" :
{ "sleep" : "00:05:00" }

},
"_links" : {
"deploymentBase" :
{ "href" : "http://hawkbit.xxxx/DEFAULT/controller/v1/xxxxxx/deploymentBase/1?c=411599879" }

,
"configData" :
{ "href" : "http://hawkbit.xxxxx/DEFAULT/controller/v1/xxxxx/configData" }

}
}
DEBUG: Providing meta information to hawkbit server
DEBUG: Request body: {
"time" : "20210420T142812",
"status" : {
"result" :
{ "finished" : "success" }

,
"execution" : "closed"
},
"data" :
{ "mac_address" : "00:00:00:00:00:00" }

}
WARNING: HTTP request failed: 301; server response: <html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
</body>
</html>

config file is

[client]
hawkbit_server = hawkbit.xxxx
ssl=true
ssl_verify = true
tenant_id = DEFAULT
target_name = xxxx
auth_token = xxxx
bundle_download_location = /tmp/hawkbit.raucb
log_level = message

[device]
mac_address = 00:00:00:00:00:00

Improve reboot behaviour

The docs for the post_update_reboot flag currently state:

Note that this results in an immediate reboot without contacting the system manager and without terminating any processes or unmounting any file systems. This may result in data loss.

This sounded a bit too scary for us, so we patched this to instead call sudo systemctl reboot via system() (with whitelisted systemctl reboot cmd in sudoers file). While that works, relying on sudo and calling the external cmd isn't really great either. It seems that via dbus this is only possibly if you run logind which we currently don't. In non-systemd systems running an external command (/sbin/reboot?) is probably the only solution anyway though.

I mainly wanted to start the discussion on finding an upstream solution to this problem here.

Can we automatically discover how the system should be rebooted (if logind is available, etc.)? Do we need a reboot-method config option?

Status command

We are working on an embedded device where the user will have to manually trigger the download & install of an update when one is available. We will be calling rauc-hawkbit-updater --run-once whenever the user requests to install an update. We want to show the details of the upcoming update to the user before downloading.

We need a way to know what rauc-hawkbit-updater would do if it were invoked. I propose we add the --status command that prints in a single-line status message and exits with a status code. For example:

exit code	message
0	Everything up-to-date. No updates available.
1	Update available: <name> (<version>)

More statuses could be added.

The --status flag would only work when running together with --run-once.

What do you think? Let's talk! I am happy to implement this if we agree on the interface.

"CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/rauc-hawkbit-updater.dir/all' failed" - when cross compiling with aarch64

I am cross compiling the rauc-hawkbit-updater with aarch64. I created tool chain file and added the cross compiler related options and cmake was successful. but make command is giving the error. The build error log of make command is below.

/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/libio.h:154:14: error: parameter '_IO_lock_t' has incomplete type
 typedef void _IO_lock_t;
              ^
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/libio.h:154:14: error: declaration for parameter '_IO_lock_t' but no such parameter
In file included from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/libio.h:49:0,
                 from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/stdio.h:74,
                 from /home/unknown/Music/rauc-hawkbit-updater-master/src/rauc-hawkbit-updater.c:10:
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/lib/gcc/aarch64-linux-gnu/4.9.3/include/stdarg.h:40:27: error: declaration for parameter '__gnuc_va_list' but no such parameter
 typedef __builtin_va_list __gnuc_va_list;
                           ^
In file included from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/libio.h:31:0,
                 from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/stdio.h:74,
                 from /home/unknown/Music/rauc-hawkbit-updater-master/src/rauc-hawkbit-updater.c:10:
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/_G_config.h:30:3: error: declaration for parameter '_G_fpos64_t' but no such parameter
 } _G_fpos64_t;
   ^
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/_G_config.h:25:3: error: declaration for parameter '_G_fpos_t' but no such parameter
 } _G_fpos_t;
   ^
In file included from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/_G_config.h:20:0,
                 from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/libio.h:31,
                 from /opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/stdio.h:74,
                 from /home/unknown/Music/rauc-hawkbit-updater-master/src/rauc-hawkbit-updater.c:10:
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/wchar.h:94:3: error: declaration for parameter '__mbstate_t' but no such parameter
 } __mbstate_t;
   ^
In file included from /home/unknown/Music/rauc-hawkbit-updater-master/src/rauc-hawkbit-updater.c:10:0:
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/stdio.h:64:25: error: parameter '__FILE' has incomplete type
 typedef struct _IO_FILE __FILE;
                         ^
/opt/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/libc/usr/include/stdio.h:64:25: error: declaration for parameter '__FILE' but no such parameter
/home/unknown/Music/rauc-hawkbit-updater-master/src/rauc-hawkbit-updater.c:164:1: error: expected '{' at end of input
 }
 ^
/home/unknown/Music/rauc-hawkbit-updater-master/src/rauc-hawkbit-updater.c:164:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
CMakeFiles/rauc-hawkbit-updater.dir/build.make:71: recipe for target 'CMakeFiles/rauc-hawkbit-updater.dir/src/rauc-hawkbit-updater.c.o' failed
make[2]: *** [CMakeFiles/rauc-hawkbit-updater.dir/src/rauc-hawkbit-updater.c.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/rauc-hawkbit-updater.dir/all' failed
make[1]: *** [CMakeFiles/rauc-hawkbit-updater.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Handle network errors instead of starting rauc-hawkbit-updater after network-online.target

This pull request #86 sets rauc-hawkbit-updater to start after network-online.target. The PR links https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ which states that waiting for network-online.target is a poor solution.

$network is a mechanism that is required only to deal with software that assumes continuous network is available (i.e. of the simple non-well-written kind)

It goes on to state:

If it cannot reach a server it must retry. If network configuration connectivity is lost it must react.
...
A service written like this is robust, can be started at any time, and will always do the best of the circumstances it is running in.
...
A robust system boots up independently of external services. More specifically, if a network DHCP server does not react this should not slow down boot on most setups, but only for those where network connectivity is strictly needed

IMO rauc-hawkbit-updater should handle the network errors and try again later rather than delaying startup like #86 does.

The current solution delays boot until:

all configured network devices are up and have an IP address assigned

This has been problematic for us because we have a mobile modem that sometimes takes 2-3 minutes to connect, so even if we have a network connection on other interfaces (LAN/wifi), rauc-hawkbit-updater will delay the boot process waiting for the modem. Rauc-hawkbit-updater properly handling network errors instead of waiting for network-online.target would solve this issue.

systemd service assuming user and group "rauc-hawkbit"

Is there a specific reason for specifying a user and group for the systemd service?

[Service]
User=rauc-hawkbit
Group=rauc-hawkbit

This assumes the target system has such a user, which I'd argue is not the case for almost all systems by default. Would it be an option to leave this out and let users add their own user and group if they want? Otherwise the service simply will not start.

@prevas-lkmi Can you elaborate on this?

Download loop when resume_downloads and missing bundle

If for some reason the bundle from Hawkbit is no longer available eg returns 404 rauc-hawkbit-updater will try re-download the files forever. Forcing the rollout to stop via Hawkbit does not stop this behavior, the only way is to stop and restart the rauc-hawkbit-updater service.

I believe that resume_downloads should only resume if there is any hope for a successful download. HTTP status codes 4xx and 5xx should be aborted and report a failure back to Hawkbit.

I believe that force-stopping an update should also stop resume_downloads. The addition of a limit may also be wise.

Our hope was that resume_downloads would allow us to reduce data usage in the event of a data outage mid-download. However, the risk of getting stuck in an endless loop of trying to download is too high and has the possibility to use an unlimited amount of data.
There is also the risk of a self-inflicted DDoS attack, a fleet of systems continually trying to download a nonexistent file forever without any way to stop them would not be not ideal.

I encountered this problem while setting up a test production environment and had some reverse proxies misconfigured and Hawkbit was doing dumb things. However, an infrastructure outage may also have this effect. For example, a Hawkbit container may fail but any load balancer may keep going sending 503 error codes.