Meta data about the image. This depends on the type in header-info. For rootfs-image there are no additional information needed and the file might be empty.
Thanks for reaching out. Reading through the documentation and code, it sounds like this might be a regression from Client 3.x to 4.x/5.x, but I have to verify it. I take it that you’re using a custom-crafted mechanism to create the artifact? Did this work up to now, or is it a recent addition?
Judging from the code additionally, a very quick workaround might be to not include the meta-data key at all, as it is considered fully optional.
Yeah right, this is a regression, mender-client 3.10.0 accepts these files.
Not using any custom mechanism to create the artifact, meta-mender with the image type mender for both kirkstone and scarthgap seems to create files like this using the mender-artifact tool.
This indeed seems like a bad regression. I cannot understand (yet) how it went unnoticed.
Could you share the headers of the exact artifact that is triggering this issue? I crafted this command that should do the job, but check the output before pasting it here in case it has some sensitive information from your end:
tar -xf YOUR-ARTIFACT.mender header.tar.gz
tar -xf header.tar.gz
echo header-info; cat header-info; echo;
for file in $(find headers/ -type f); do echo $file; cat $file; echo; done
The header is just fine. You can see that the meta-data is a purely empty file, which is allowed, and also from your logs you can see a trace one saying: “Received an empty Json body. Not treating this as an error”
So the parsing of the Artifact header succeeds, and indeed the Client starts the installation.
Then, the error triggers.
It is a big mystery for me right now. The only relevant place in the code that GetChildren() is used is here, but that should be called before we do “Installing Artifact…” (and it is also called even before when performing the API call to the server).
I need to experiment a bit more to find out the root cause.
Can you provide the output of mender-update show-provides ?
Oh I see, I was focused on that error but it does actually continue a little bit.
mender-update -l trace show-provides
record_id=1 severity=debug time="2025-Mar-21 14:09:03.382745" name="Global" msg="Failed to load config from '/var/lib/mender/mender.conf': Failed to open '/var/lib/mender/mender.conf': No such file or directory"
Could not fulfill request: Type error: Invalid JSON type to get children from
We have been using /etc/mender/mender.conf but that is no longer used… ?
mender-update -c /etc/mender/mender.conf -l trace show-provides
record_id=1 severity=debug time="2025-Mar-21 14:14:27.017670" name="Global" msg="Failed to load config from '/var/lib/mender/mender.conf': Failed to open '/var/lib/mender/mender.conf': No such file or directory"
Could not fulfill request: Type error: Invalid JSON type to get children from
First, please note that the error message there is just a debug entry - it warns that it did correctly parsed /etc/mender/mender.conf but failed on the extra one in the persistent partition /var/lib/.... It might be that you are just not using it on your deployment. But this is not an issue.
The issues is in parsing the provides from the database, as I suspected. Although it is still a mystery why the client can do the API call for asking for deployments if it cannot even read the stored provides (unless it is defaulting to the v1 deployments/next )
I unfortunately don’t have more time today to help out but the next step is to dump the database and see what are the contents of the artifact_provides key. I can help on that next week, of mabye @TheYoctoJester can give you the recipe.
Also please let’s look at the logs of the API calls when the client checks for deployments, I bet there is an error there and it is just silently doing a fallback to the v1 deployments/next API call.
After running rm /var/lib/mender/mender-store* I could run mender-update install. Just trying to understand the problem, not suggesting this is a solution…
@ernstp-se I’ve been offline few days, just today catching up and wanted to provide you the recipe to do the backup + dump the database… I see it is too late now
After running rm /var/lib/mender/mender-store* I could run mender-update install
There was something corrupted in the database, hence the error from show-provides but I wanted to find out how you ended up in that situation. Did you take a backup of the database? Otherwise we cannot investigate further.
I see this thread is older than one year, but since I stumbled across the (presumambly) same issue, I want to share my findings.
In my case I wanted to update rather old devices running mender 2.2 (Yocto thud) to 5.1.0 (Yocto scarthgap).
However when trying to update, I get OP’s error as well: Could not fulfill request: Type error: Invalid JSON type to get children from
I dumped the mender-store database, whose data part converted from HEX to ASCII is this: artifact-group
artifact-name 1.3.12 artifact-provides null
Not sure how the database ended up in this state. I could not reproduce it on a freshly installed device.
Anyway I checked the mender source code and think mender 5.1.0 does not handle the value string null very well in src/mender-update/context/context.cpp:177-185. For me, this simple patch did the trick:
diff --git a/src/mender-update/context/context.cpp b/src/mender-update/context/context.cpp
index b32e4bf7..4533373e 100644
--- a/src/mender-update/context/context.cpp
+++ b/src/mender-update/context/context.cpp
@@ -174,7 +174,7 @@ ExpectedProvidesData MenderContext::LoadProvides(kv_db::Transaction &txn) {
if (artifact_group != "") {
ret["artifact_group"] = artifact_group;
}
- if (artifact_provides_str == "") {
+ if (artifact_provides_str == "" || artifact_provides_str == "null") {
// nothing more to do
return ret;
}
)
Otherwise we cannot investigate further.