It’s not a real requirement, but I want to start the discussion about the update to zeus 
Does your current scheduling contain also the release of mender for zeus? Do you have an expected release date?
Thank you.
Thanks for starting this thread @Ks89
Definitely have plans to add zeus support and you can watch the relevant task for updates on this matter,
https://tracker.mender.io/browse/MEN-2845
Unfortunately, I can not give you a expected release date as it all depends on priorities.
I encourage the community to comment on this thread if this is blocking them or causing inconvenience, and the more people request/comment, will make prioritization easier.
Likewise I’d like to move up to zeus as it comes with fixes in layers I’m using.
Looking at the issue, whilst it’s a blocking issue for QEMU support is a WIP branch possible (even if it’s on a personal repo)?
There is a zeus-next branch in meta-mender, but it is not usable because it still contains LAYERSERIES_COMPAT_mender = "warrior", this was intentionally left as-is because it is a WIP branch and do not want to people to consider it something stable but if you fork it or make a local modification you can definitely start testing things out and report any findings/issues
2 Likes
We’d also love to see zeus support getting some traction.
There are some new features in recent systemd versions provided in oe-core zeus which we want, and doing a backport of the init manager feels overly risky. Mender is the only thing preventing us from migrating to zeus at this point.
That and since we haven’t yet put in place a solution to quickly deploy security updates, we rely on OE to keep our packages up-to-date-ish, and secure-ish. Staying on Warrior means we’re missing out on an increasing number of security updates.
On a side note, it’s midly unsettling to learn zeus support is not a high priority more than 3 months after release. Shouldn’t it be or am i missing some context ?
+1 for zeus
We would also like to see zeus support in Mender. Will be great to know an official estimation on this 
@mirzak Is there any specific points on which we can help ?
1 Like
This is the list of tasks that we need to fix before we can release zeus. All are on our road map, but not currently scheduled. The Rename task is important to align the Yocto branches with Debian, and the broken U-Boot/UEFI support is important for our ability to test the software. I expect the latter to be quite hard, so I would not attempt it unless you have a lot of determination. The first one could be an ok task if you want to help though. You may need to get your hands dirty with some test code though, so you are warned! 
+1 for zeus
1 Like
I’m using mender with zeus. Still in the initial phase of porting the product firmware to zeus, but everything with mender appears to be working. Just change LAYERSERIES_COMPAT_mender to include zeus.
Unfortunately a number of new issues have surfaced after we fixed the UEFI issue which was blocking us for a long time. Check out the the list.
People are of course free to switch the branch to zeus by themselves (as mentioned in the previous comment), and use that, but we cannot officially endorse the branch until it’s fully working and tested.
We’ve started to test this in real deployments and haven’t found any problems related to Zeus so far. There have been a few related to going from Mender 1.5 to 2.1.
The problems under that issue look like they are mostly related to the mender test infrastructure and some of the u-boot integrations. We’re using Barebox, and used Barebox’s existing bootchooser, so the meta mender layer doesn’t need to modify Barebox. Also looks like mender will change to mender-client, so meta layer need to rename their bbappend files.
Trying to modify U-Boot to add Mender support in way that doesn’t break as U-Boot changes seems like it’s been difficult. Which isn’t really very surprising. Support for OS updates needs to be in U-Boot, not patched in, or it’s going to keep breaking.
I’m adding a big +1 for Zeus. 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. Is there official policy around what versions of Poky Mender plans on supporting at any given time? With Dunfell right around the corner, Mender currently is lagging a release behind upstream Poky. I’d be interested the community can be part of the process of keeping Mender support closer to the tip of Poky.
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.
1 Like
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. Barebox ~2017 to Barebox 2020.03. And so on. I had to re-write most of the code we wrote two years go for Mender to give it Barebox support. And there were issues with Mender artifact version, change to split config files, handling of data partition in Mender/Yocto, and Mender sd image generation partition type changing. And there was a ton of other stuff that broke everywhere else too.
But all the stuff in Barebox that does the boot partition choosing kept working fine and I’ve got zero patches in my Barebox bbappend related to Mender compatibility.
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, Compatibility | Mender documentation
Unfortunately we have lagged for both warrior and 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:
- qemux86_64_bios_grub
- qemux86_64_bios_grub_gpt
- qemux86_64_uefi_grub
- vexpress_qemu
- vexpress_qemu_flash
- vexpress_qemu_uboot_uefi_grub
- Beaglebone Black
Acceptance test means:
- Build
- 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
- U-Boot/UEFI/GRUB
0
voters
So lets get back to the different targets and what they use/test:
-
qemux86_64_bios_grub
- x86_64 with legacy boot (BIOS) and MBR partition table
-
qemux86_64_bios_grub_gpt
- x86_64 with legacy boot (BIOS) and GPT partition table
-
qemux86_64_uefi_grub
- x86_64 with UEFI and GPT partition table
-
vexpress_qemu
- ARM emulation with managed NAND flash (SD & eMMC). Uses “Auto Patcher” for device integration
-
vexpress_qemu_flash
- ARM emulation with raw NAND flash (UBI). Uses “Auto Patcher” for device integration
-
vexpress_qemu_uboot_uefi_grub
- Uses
U-Boot/UEFI/GRUBand is the reference QEMU for this type of integration
- Uses
-
Beaglebone Black
- Uses
U-Boot/UEFI/GRUBand is the reference hardware for this type of integration.
- Uses
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 qemux86_64_uefi_grub.
Conclusion
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 zeus support.
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.
1 Like
Hi,
I am trying to use Zeus branch with RPI.
Got an error.
Any suggestion @mirzak
ERROR: u-boot-fw-utils-mender-auto-provided-1.0-r0 do_check_mender_defines: U-Boot configuration rpi_3_32b_config has setting:
CONFIG_ENV_OFFSET=
but Mender expects:
CONFIG_ENV_OFFSET=0x4000
Please fix U-Boot's configuration file.
A post was split to a new topic: Issue when building with meta-mender zeus-test
It looks like zeus was merged in master today, and we have a zeus branch now
Very observant @guillaumekh :). I was waiting for @kacf to announce it, as he has been hard at work making this possible.
Hopefully dunfell will not cause as much trouble.
1 Like