First of, the
zeus release is looking good and hopefully nothing unexpected will show up and it can be tagged up properly soon.
In our company we are making moves to continually stay on the current version of Poky so we are up to date with security patches and upstream software version
Does this mean you are tracking master branch of Poky?
Is there official policy around what versions of Poky Mender plans on supporting at any given time?
Can not really point you to a policy, but so far we have tried to keep as close possible to the Yocto Project releases. This is probably the closest we get to a policy, https://docs.mender.io/2.3/architecture/compatibility
Unfortunately we have lagged for both
zeus with approx 6 months. Up until these releases we have been pretty close to the Yocto Project releases.
I’d be interested the community can be part of the process of keeping Mender support closer to the tip of Poky.
Would gladly work on enabling the community more to support us on this.
Also, another +1 to tpiepho’s suggestion of working to get u-boot integration in upstream. The current patch based method has complications especially if you need to be using a vendor version of u-boot for your board/SoC. I’d be interested in discussing what the blockers are to getting that going.
I do not know of any blockers on this and if anyone wants to pick this up and start a discussion on the U-Boot mailing list I think we would be able to support that effort. I think it would be beneficial if it is an community effort.
With this said, the generic U-Boot patches are rarely a big problem when it comes to Yocto Project upgrades. We did not even need to update them for
zeus support, or well we did but this was to silence a fuzz warning (see here). If you also look at the history of the U-Boot patches they do not change much over time.
So what is the problem you might ask? I will come back to this
I’ve done a big update of a project that hadn’t changed in two years. Rocko to Zeus. Mender 1.5 to 2.1.
Well this I would expect to be slightly painful, regardless
More detailed look in to meta-mender
Since there is large community interest in this I wanted to dig deeper in meta-mender as some things might not be obvious and we could probably document this a bit better. So here is an attempt at that.
Please note that I do not have a detailed insight in everything that I mention here, and if I have gotten any details wrong I hope someone will correct me :). Also there is probably more to it, then I can cover here so this primarily to give you an overview.
Mender officially supports a number of targets that we regularly run acceptance test against, regularly meaning on each PR on pretty much all repositories that we have. The targets are:
- Beaglebone Black
Acceptance test means:
- Run a number of tests on the output files
- this includes booting the QEMU and testing updates/rollback etc… (read the source for more information :))
We also have integration tests that run on
qemux86_64_uefi_grub, integration tests include spinning up an Mender server and doing end-to-end tests. This primarily test the Mender client as the device integrations have been verified using the acceptance tests.
So the follow-up question here would be, what do all these targets mean? Some are self explanatory, some might need some additional details. But before we try understand the targets, we need to understand what type of device integrations Mender supports.
We support ARM and x86_64 devices, this is obvious I guess :).
On x86_64 we support:
- Legacy boot (BIOS)
- UEFI boot
On ARM we support U-Boot, but there are a number of ways to integrate a device with U-Boot,
- raw NAND flash (UBI)
- managed NAND flash (SD & eMMC)
- Manual U-Boot integration (user creates device specific patches to integrate Mender)
- U-Boot Auto Patcher
- This is a set of scripts that will try to generate the device specific patches
- U-Boot -> UEFI -> GRUB
- This an integration that bypasses requirement to patch U-Boot and instead relies on EFI support in U-Boot to launch GRUB (EFI application) which will have the Mender integration
Good opportunity to get some feedback on what type of integration you are using :), please click below (it is multi choice):
- Raw NAND flash (UBI)
- Managed NAND flash (SD & eMMC)
- Manual U-Boot integration
- Auto Patcher
So lets get back to the different targets and what they use/test:
It shall be noted that the criteria for creating a new Yocto branch all the mentioned targets must pass build and acceptance tests, and obviously integration tests on
I guess what I wanted to highlight with this post is that there is some complexity to all this and usually it is not about refreshing U-Boot patches. Our testing has an high coverage to ensure an high quality solution, and we do not release something unless it is tested according to our standards.
You can take a look at the tasks for
Again, would love feedback on all this and how we can enable the community to support us better.
One alternative is to easy up on testing with community maintained branches vs branches maintained by us. Some people are already using
zeus together with Mender (e.g with a custom fork) and it works for them. Maybe this can be done in a structured way?
Also the next Yocto Project release will be an LTS (two years of support) release and this might have impact on how to things are done in the future.