Mender Client 3.5 on Yocto Scarthgap

General Discussions
, ,
1

Thanks for the initial scarthgap support. We are experimenting with GitHub - TheYoctoJester/meta-mender at scarthgap at the moment.

The biggest issue seems to be the default in scarthgap is the c++ based mender client 4.0.

I’ve worked around by pinning mender-client to 3.5.2 in my local.conf:

PREFERRED_VERSION_mender-client = "3.5.2"
PREFERRED_PROVIDER_mender-native = "mender-client-native"
PREFERRED_RPROVIDER_mender-auth = "mender-client"
PREFERRED_RPROVIDER_mender-update = "mender-client"

just sharing here because the client re-re-name from mender-client to mender (again??) requires the non-obvious PREFERRED_PROVIDERs as well as PREFERRED_VERSION.

2

Hi @cveilleux,

Thanks for sharing the snippet! Yes indeed, currently this is a way “backwards”. Any specific reason why you are selecting 3.5.x, though?

Greets,
Josef

3

To be honest I assumed an update from mender-client 3 to the c++ mender 4 was simply not supported because it failed when I tried.

i just gave it another shot to collect more details…

Our use case is that we have intel machines using grub, currently running kirkstone/mender-client 3.5.2.

When I attempt to upgrade to a scarthgap/mender 4.0.2 using your in-progress branch, we get an error on the grub screen:

The environment is corrupt. Trying to boot from (rootfs b) in 10 seconds, but this is not guaranteed to be a valid partition...

ref: grub-mender-grubenv/04_mender_setup_env_functions_grub.cfg at master · mendersoftware/grub-mender-grubenv · GitHub

We then luckily boots into the scarthgap rootfs, but then mender-update commit complains there is nothing to commit.

mender-update show-artifact shows unknown.

A reboot then rolls back to the kirkstone/mender 3.5.2 version.

If I pin mender-client to 3.5.2 with the above configs, everything works flawlessly. We can install, reboot then commit using the normal process. We can also go back to kirkstone without problems.

If it has an impact, we are using the mender-partuuid feature.

4

@cveilleux thanks for the detailed description. That definitely should not happen :frowning: Are there any specialities in the boot flow, or is it a mostly generic x86-grub setup?

Greetz,
Josef

5

It’s a straight intel/mender/grub flow. We have not customized it, other than enabling mender-partuuid feature.

Since you are confirming it should be working, I will run more tests and gather more debug output.

I will update this thread once I figure it out.