A little background, looking at oe-core and poky for background, I see the
initramfs images contain:
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
I see this in both oe-core
meta/recipes-core/images/core-image-minimal-initramfs.bb and
core-image-tiny-initramfs.bb.
The "meta-security" layer also seems to the do the same in it's
'dm-verify-image-iniramfs.bb' recipe as well.
However, when I look at meta-openembedded/meta-initramfs (initramfs-debug-image
and initramfs-kexecboot-image), I see:
# Some BSPs use IMAGE_FSTYPES_<machine override> which would override
# an assignment to IMAGE_FSTYPES so we need anon python
python() {
d.setVar("IMAGE_FSTYPES", d.getVar("INITRAMFS_FSTYPES"))
}
This is the exact issue I'm trying to understand. (Ignoring the comment above
uses the older style override syntax), the issue I have is someone is setting:
IMAGE_FSTYPES:<override> = "something"
INITRAMFS_FSTYPES:<override> = "something else"
Then the initramfs recipes in oe-core are failing to set IMAGE_FSTYPES to
INITRAMFS_FSTYPES due to the IMAGE_FSTYPES override, which causes the types to
not be correct.
My question then is, is setting IMAGE_FSTYPES:<override> valid, if not should be
add a sanity check to tell people to NOT do it? If it is valid to do, is the
workaround/fix in meta-openembedded the right solution? If using the python
approach is correct, then I'm happy to generate patches to oe-core but I'm just
not sure what the expected usage is.
Thanks!
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#181028):
https://lists.openembedded.org/g/openembedded-core/message/181028
Mute This Topic: https://lists.openembedded.org/mt/98769851/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
