diff options
author | Paul Gortmaker <paul.gortmaker@windriver.com> | 2023-06-21 10:13:33 -0700 |
---|---|---|
committer | Armin Kuster <akuster808@gmail.com> | 2023-06-25 15:05:28 -0400 |
commit | 3b88f75323bd399615eb6c0897b13cbb59e35e64 (patch) | |
tree | f50d025393bc0191e55e941b55a07ddcff9210d6 /dynamic-layers/meta-python/recipes-devtools/python | |
parent | 4922b3053af9e0f66a3e0a65bd25b9f51df3a4f9 (diff) | |
download | meta-security-3b88f75323bd399615eb6c0897b13cbb59e35e64.tar.gz |
dm-verity: add wks.in fragment with dynamic build hash data
Export the dynamic build data for consumption in wic image generation.
It can either be included directly or manually parsed for useful chunks
in custom configurations people end up making.
For convenience, it is placed alongside the work-shared/dm-verity dir
where we already store the plain environment file and the veritysetup
formatting argument that was used.
There is a subtle thing going on here with respect to using an include,
which warrants a mention. The wic (wks.in) stuff only has access to
normal Yocto/OE/bitbake variables.
So, instead of a fragment, say if you had:
DM_VERITY_ROOT_HASH = "__not_set__"
and then later, did a:
d.setVar("DM_VERITY_ROOT_HASH", value)
after the image was built, and the hash was known - that seems sane.
But the problem is that once you do that, your variables are tracked
by default, and bitbake/lib/bb/siggen.py will be angry with you for
changing metadata during a build. In theory one should be able to avoid
this with BB_BASEHASH_IGNORE_VARS and "vardepsexclude" but it means more
exposed variables, and as much as I tried, I couldn't get this to work.
Creating a fragment with the dynamic data for inclusion avoids all that.
The wks template itself remains static, and hence doesn't trigger warns.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Diffstat (limited to 'dynamic-layers/meta-python/recipes-devtools/python')
0 files changed, 0 insertions, 0 deletions