Hello Bruce,
thanks for the quick reply!
On Thu, 2023-11-02 at 15:13 -0400, Bruce Ashfield wrote:
> > My current understanding is that
> > meta-virtualization/recipes-kernel/linux/linux-yocto_virtualization.inc
> > makes an assumption that any type=kmeta will point to upstream
> > git://git.yoctoproject.org/yocto-kernel-cache but this doesn't hold
> > for my use case.
>
> close.
>
> The support assumes that if something is on the src_uri named
> "kernel-cache" that it is a complete, similarly formatted repository
> to the upstream / centralized one that I maintain
>
> If that is found, it is preferred over the yocto-kernel-cache provided
> by the yocto-cfg-fragments recipe.
[...]
> > The only type=kmeta is my local file:// storage and the following
> > linux-yocto_virtualization.inc part leads to fetch failure (fetch
> > from Internet not expected/forbidden):
> >
> > # if kernel-yocto has been inherited (how we can check for configuration
> > # fragment merging suport at the moment, then add a dependency on the
> > # configuration fragment repository. This allows us to be sure that our
> > # features can be enabled via the fragments
> > do_kernel_metadata[depends] += "${@['',
> > 'yocto-cfg-fragments-native:do_populate_sysroot'][(bb.data.inherits_class('kernel-yocto',
> > d))]}"
> >
> > Summary: 1 task failed:
> > virtual:native:.../projects/ccp-sd-virt/../../meta-virtualization/recipes-kernel/linux/yocto-cfg-fragments.bb:do_fetch
>
> At a glance, I'm not seeing how your local kmeta is causing
> the full fragments recipe to fail to fetch.
>
Fetch failure is expected, as there is simply no access to outside world and
all expected packages are mirrored.
Now the real issue is that providing local type=kmeta pulls
git://git.yoctoproject.org/yocto-kernel-cache and currently we require no
of the upstream fragments, so there is no point in mirroring the
yocto-kernel-cache
repo just to satisfy fetch as we don't require these features.
Currently I see no way to control this behaviour...
> > When I read the comment "if the kernel-yocto meta-data routine automatically
> > starts to add the recipe-sysroot-native..." I get a feeling that
> > this feature is still "work in progress". Are there any further developments
> > I could test in this direction?
>
> There's nothing that would fix that issue. The in-progress part of that
> is that I plan to remove all of the local fragments in the virtualization
> layer and rely on the cloned kernel-cache from that recipe.
>
> I don't suppose there's a layer I can look at which has your fragments
> and the related kernel bbappend ? I'd like to reproduce the issue
> locally so I can debug it in more detail.
I cannot easily point you to something publicly available... But roughly it's a
combination of meta-virtualization and a kernel recipe derived from
kernel-yocto.bbclass.
Now I long as one doesn't have any type=kmeta, meta-virtualization doesn't pull
git://git.yoctoproject.org/yocto-kernel-cache and adding
"file://features/debug;type=kmeta;destsuffix=features/debug" to SRC_URI causes
yocto-kernel-cache to be pulled even though there is no logical reason for this.
--
Alexander Sverdlin
Siemens AG
www.siemens.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8415):
https://lists.yoctoproject.org/g/meta-virtualization/message/8415
Mute This Topic: https://lists.yoctoproject.org/mt/102338788/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
