Bug 13727

This issue is that the kernel recipe is not being bbappended to include ${BPN}_virtualiation.inc

See:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-kernel/linux?h=warrior

Each linux kernel recipe needs a bbappend and a named/symlinked ${BPN}_virtualization.inc, e.g. linux-intel_birtualization.inc and linux-intel_%.bbappend

You can add these to e.g. dynamic-layers/virtualization-layer/recipes-kernel/linux

In other words, meta-virtualization is hard coded to only work with linux-yocto at the moment, so it doesn't understand linux-intel which is set by intel-corei7-64 machine.

Tim,
  Thanks for the investigation.  I did a little testing and the following copy commands do resolve the issue, meaing that your assessment is correct.

cp meta-virtualization/recipes-kernel/linux/linux-yocto_4.19.bbappend meta-virtualization/recipes-kernel/linux/linux-intel_4.19.bbappend 

cp meta-virtualization/recipes-kernel/linux/linux-yocto_virtualization.inc meta-virtualization/recipes-kernel/linux/linux-intel_virtualization.inc

  While this works for me and unblocks me today, what do you recommend for a larger fix?

Kevin

We are coincidentally working on this internally, hence the solution was already known (but not public yet).

I see two possible paths forward:

(1) meta-intel adds the necessary bbappends and incs to dynamic-layers (this is up to Anuj to decide as he is the final word on meta-intel).
{2) meta-virtualization adds the necessary linux-intel files (this is up to Bruce Ashfield as he is the final word on meta-virtualization).

There is probably a third better option than makes the meta-virtualization bbappends more universally applicable. We should start discussion on the meta-virtualization mailing list [1]. There might even be an opportunity to move this to oe-core, but regardless the discussion belongs on the meta-virtualization mailing list.

Backporting to "warrior" might be contentious, so just a heads up that you may need to carry technical debt until you move to 3.1 release (currently "master"). I will assume you have a business need to be on "warrior", rather than ask you why you can't move to a newer release.

[1] https://lists.yoctoproject.org/g/meta-virtualization

Since the linux-intel recipes are good citizens and support fragments, we can make the bappends more generic. If other users of meta-virt have kernel recipes that match, and don't have fragment support .. they won't be harmed either (since they'll just be ignored).

So something like linux-%_<version>.bbappend in meta-virt should meet the need (I *think* the wildcard will work like that in the middle, otherwise, even linux-%.bbappend could be considered).

(In reply to comment #3)
> We are coincidentally working on this internally, hence the solution was
> already known (but not public yet).
> 
> I see two possible paths forward:
> 
> (1) meta-intel adds the necessary bbappends and incs to dynamic-layers (this
> is up to Anuj to decide as he is the final word on meta-intel).
> {2) meta-virtualization adds the necessary linux-intel files (this is up to
> Bruce Ashfield as he is the final word on meta-virtualization).
> 
> There is probably a third better option than makes the meta-virtualization
> bbappends more universally applicable. We should start discussion on the
> meta-virtualization mailing list [1]. There might even be an opportunity to
> move this to oe-core, but regardless the discussion belongs on the
> meta-virtualization mailing list.
> 
> Backporting to "warrior" might be contentious, so just a heads up that you
> may need to carry technical debt until you move to 3.1 release (currently
> "master"). I will assume you have a business need to be on "warrior", rather
> than ask you why you can't move to a newer release.
> 
> [1] https://lists.yoctoproject.org/g/meta-virtualization

I've pushed a patch to meta-virtualization that should resolve this.

If anyone is available to quickly test it, that would be helpful. I'd rather not close this until we get confirmation.

I am testing the patch now.

It still seems to fail on me.

My source is here: https://github.com/ksaye/IoTDemonstrations/blob/master/batch/inteltest.sh

If I comment out lines 56 and 57, it still fails.  Am i missing something?

K

I'll have a look at linux-intel and run some tests.

I can confirm that linux-intel does now use the fragments from meta-virt:

bitbake -e shows:

SRC_URI="            git://github.com/intel/linux-intel-lts.git;protocol=https;name=machine;branch=5.4/yocto;            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=kernel-meta            file://perf-fix-build-with-binutils.patch           file://xt-checksum.scc             file://ebtables.scc           file://vswitch.scc      file://lxc.scc             file://docker.scc              file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch"

If someone can let me know hot to boot the image in qemu (I'm failing on systemd startup), I can also do a docker runtime test.

Cancel that. I hacked the fstab and was able to boot:

root@intel-corei7-64:~# docker pull busybox
Using default tag: latest
latest: Pulling from library/busybox
bdbbaa22dec6: Pull complete 
Digest: sha256:6915be4043561d64e0ab0f8f098dc2ac48e077fe23f488ac24b665166898115a
Status: Downloaded newer image for busybox:latest
docker.io/library/busybox:latest
root@intel-corei7-64:~# docker run -it busybox /bin/sh
docker0: port 1(veth1a3a75a) entered blocking state
docker0: port 1(veth1a3a75a) entered disabled state
device veth1a3a75a entered promiscuous mode
eth0: renamed from vethd917b53
IPv6: ADDRCONF(NETDEV_CHANGE): veth1a3a75a: link becomes ready
docker0: port 1(veth1a3a75a) entered blocking state
docker0: port 1(veth1a3a75a) entered forwarding state
IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready
/ # docker0: port 1(veth1a3a75a) entered disabled state
vethd917b53: renamed from eth0
docker0: port 1(veth1a3a75a) entered disabled state
device veth1a3a75a left promiscuous mode
docker0: port 1(veth1a3a75a) entered disabled state
root@intel-corei7-64:~# uname -a
Linux intel-corei7-64 5.4.15-intel-pk-standard #1 SMP PREEMPT Thu Feb 6 03:40:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@intel-corei7-64:~#

Bruce,
  You seem to be on the 5.4.15 kernel where I am on:

Linux intel-corei7-64 4.19.80-intel-pk-standard #1 SMP PREEMPT Fri Feb 28 00:34:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Note my work around copy commands copy to linux-intel_4.19.bbappend 

Kevin

I realize I'm on 5.4, I'm only working on master for these changes. Testing other branches and requesting a backport needs to be done by someone with the relevant test capabilities.

(In reply to comment #11)
> Bruce,
>   You seem to be on the 5.4.15 kernel where I am on:
> 
> Linux intel-corei7-64 4.19.80-intel-pk-standard #1 SMP PREEMPT Fri Feb 28
> 00:34:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
> 
> Note my work around copy commands copy to linux-intel_4.19.bbappend 
> 
> Kevin

meta-intel master just added bbappend for linux-intel 4.19
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=108c6938a9b8a71b94d2e8d368c2f39e6ec20530

can you try that?

I have tried that and it did not resolve it.

(In reply to comment #14)
> I have tried that and it did not resolve it.

i build it this way and it works. can you try that ?
https://github.com/cheeyanglee/IoTDemonstrations/commit/d9aef05e9772471e2766236a36753e24c2f6ea6e#diff-f5dc6c0071ef0304136c91697342c0ef

Kevin, it looks like we are waiting for confirmation from you of the fix. Can you please test and leave comments on whether it meets your needs?

(In reply to comment #16)
> Kevin, it looks like we are waiting for confirmation from you of the fix.
> Can you please test and leave comments on whether it meets your needs?

Thanks for the reminder, should have this tested by Tuesday 6/30.

All,  I just verified that the fix works as planned.  Thanks all for the resolution!

Kevin