On Fri, Nov 3, 2023 at 5:15 AM Sverdlin, Alexander <[email protected]> wrote: > > 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.
if you are enabling the virtualization distro feature, and are including meta-virtualization, that repository is a requirement. That's how it ensures that subtle runtime errors don't creep in with incorrect kernel configurations. So why not just mirror it ? > > 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. That's not what my local tests show. It is keying off an inherit of kernel-yocto, not kmeta, but even by extension, seeing that fragment merging is available (whether keyed of kmeta or the inherit of kernel-yocto), that is the logic as to why it pulls it in (and the use of it is what I explained above). Unless I have a way to see the issue locally, I can't easily address it (if required). Bruce > > -- > Alexander Sverdlin > Siemens AG > www.siemens.com -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8416): https://lists.yoctoproject.org/g/meta-virtualization/message/8416 Mute This Topic: https://lists.yoctoproject.org/mt/102338788/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/leave/6693005/21656/1014668956/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
