feat: add support for Yocto 5.0 "scarthgap" #2099
Conversation
TheYoctoJester
force-pushed
the
scarthgap
branch
from
bc25fc6
to
8bb2de7
Compare
|
Started an "early feedback" CI run here. |
TheYoctoJester
force-pushed
the
scarthgap
branch
from
8bb2de7
to
1e727c2
Compare
|
Started another one here (first one failed because of operator error 🙂). |
|
And yet another one here. |
|
@TheYoctoJester: The error I'm now getting in the CI is of this nature: Does it ring a bell for you? We do have this section, which looks related, but it should be active in your build as well, so I don't know why you don't see it. Are you using |
|
@kacf strange. I have Is there a way to see the effective |
|
For the past few days, I have been successfully running Mender on Yocto Scarthgap with my branch at https://github.com/enlyze/meta-mender/tree/feature/scarthgap-support-for-master Feel free to cherry-pick what is still missing. |
You are probably looking for running bitbake on your target image with the |
@ColinFinck heh yeah that one is obvious. The problem is, it works in my builds but seems to fail in the automated test runs that the team runs on GitLab. So the question is about seeing the effective |
|
I think I found the issue here, our build files are using the old |
Nope, I was way off here, we are using the right syntax. But in any case, I did figure out the reason, and I took the liberty of pushing to this branch. @TheYoctoJester, can you check the commit I added, which has some implications, and see if you agree with my reasoning? |
|
New full CI pipeline here. |
Hi @kacf, interesting catch. From the pure Yocto point of view, this approach is definitely to be preferred, as it requires users to make conscious decisions instead of "hidden" magic. |
When building from git master, it is necessary to also fetch the vendored submodules. Switching the recipe to the gitsm:// fetcher fixes this process. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
…psule The existing mender artifact class can only be used for generating system/rootfs update artifacts. For the UEFI capsule, we need a custom module image artifact with specific flags/conditions enabled These are the following changes: * Add new class, this has a dependency on the UEFI capsule class from other layers which generates the required UEFI firmware capsule * Add new variables * Generate the `provides` and `depends` in the below format: `uefi-firmware.<guid>.name:<name>` `uefi-firmware.<guid>.version:<version>` by using `MENDER_ARTIFACT_CAPSULE_PROVIDES` and `MENDER_ARTIFACT_CAPSULE_DEPENDS` variables Changelog: Title Ticket: None Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Vikas Katariya <vikas.katariya@arm.com>
Changelog: None Ticket: None Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com>
Changelog: Title Ticket: None Signed-off-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Signed-off-by: Vikas Katariya <vikas.katariya@arm.com>
Bump the `meta-mender-core` and `meta-mender-demo` compatibility to `langdale` Signed-off-by: Vikas Katariya <vikas.katariya@arm.com>
To facilitate ongoing build testing on the master/main branches, release compatibility needs to be declared. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
Recent bitbake/Yocto releases check for the Upstream-Status of all patches they apply, in order to track them. The Mender-specific patches are considered inappropriate for U-Boot upstream and annotated as such. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
The generic bootlimit patch was labeled as experimental and not being used anywhere, so can be removed for moving forwards. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
This is a refresh of the u-boot board integration patch for the Raspberry Pi family of boards. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
The patch which added a header to fix build breakage is not required anymore, as upstream has been fixed. The other u-boot patches have been renamed accordingly. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
Adjust the LAYERSERIES_COMPAT of all layer.conf files to scarthgap. Where multiple releases were supported, those are removed. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
The patch is refreshed to the 2024.01 release of u-boot, including upstream state set to Inappropriate. Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
(cherry picked from commit 41ab89c)
Setting hardcoded path "/lib/systemd/system" to
SYSTEMD_UNIT_DIR variable, is causing following failure:
| do_package: Didn't find service unit 'mender-updated.service',
| specified in SYSTEMD_SERVICE:mender-update
Set SYSTEMD_UNIT_DIR to bitbake env variable ${systemd_system_unitdir}.
When usrmerge DISTRO_FEATURE is enabled, ${root_prefix} points to
${exec_prefix} otherwise to ${base_prefix}.
Ref:
https://git.openembedded.org/openembedded-core/commit/?id=700848c6ebd03bf3105d09a41d758883ab875618
Signed-off-by: Preeti Sachan <preeti.sachan@intel.com>
(cherry picked from commit 12a5b99)
The existing setting "/bin/bash" breaks with the usrmerge of the scarthgap release, where bash is located at /usr/bin/bash. Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
The meta-mender-raspberrypi and meta-mender-raspberrypi-demo layers are move to the meta-mender-community repository to decouple board integration from Mender product development and maintenance. Changelog: Title Ticket: None Signed-off-by: Josef Holzmayr <jester@theyoctojester.info>
It does not look like it's possible to do it safely anymore. The old
approach with `DISTRO_FEATURES_BACKFILL` will not work on scarthgap
and later, because there is a separate variable `INIT_MANAGER`, which,
if set to `sysvinit` (the fault), it starts competing with us, using
`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
The next logical step would then be to use `INIT_MANAGER` instead, but
this does not work either because it eventually leads to loading
`init-manager-${INIT_MANAGER}.inc`. This particular step is sensitive
to load ordering, and therefore our assignment comes to late to have
any effect, leading to the `sysvinit` variant being loaded, even if we
have set it to `systemd`. The mentioned load step comes from
`bitbake.conf`, and the only files loaded before that are `local.conf`
and `layer.conf` files. We can not (reasonably) utilize any of these
files for what we want to do, because feature selection comes much
later in the load order.
So we pick the safest variant, and ask the user to set their
`INIT_MANAGER` variable correctly instead. We could have made it
adaptive instead, and simply disabled the `mender-systemd` feature if
that `INIT_MANAGER` is not used. But since we have poor support for
this, and it's likely to break daemon mode, default to an error
message instead. `mender-systemd` can still be disabled manually,
which will get rid of the message.
Changelog: Enabling systemd as init manager is no longer done
automatically by the meta-mender layer. In order to re-enable it, put
`INIT_MANAGER = "systemd"` in your `local.conf` file. Alternatively,
use `MENDER_FEATURES_DISABLE = "mender-systemd"`, but be aware that
this can break daemon mode.
Ticket: None
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
|
Yet another one. |
This is a proof of concept to prepare for compatibility with the Yocto 5.0 release
scarthgap. It is based on theprepare_master_for_scarthgapbranch and not fit for direct merge, but provides a known good starting point.Changelog: Title
Ticket: MEND-7157