Good fix. Please pull this in, as it is causing autobuilder errors
See https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/601/steps/23/logs/stdio

Thanks,
Jon

On Wed, Mar 23, 2022 at 1:33 PM Richard Purdie
<richard.purdie@...> wrote:

A newer version of this was merged to OE-Core and there shouldn't be a hard
version dependency in meta-virtualization so this can be droped from here.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
recipes-devtools/python/python3-sphinx_4.2.0.bb | 11 -----------
1 file changed, 11 deletions(-)
delete mode 100644 recipes-devtools/python/python3-sphinx_4.2.0.bb

diff --git a/recipes-devtools/python/python3-sphinx_4.2.0.bb b/recipes-devtools/python/python3-sphinx_4.2.0.bb
deleted file mode 100644
index 01f36ea..0000000
--- a/recipes-devtools/python/python3-sphinx_4.2.0.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-DESCRIPTION = "Python documentation generator"
-HOMEPAGE = "http://sphinx-doc.org/"
-SECTION = "devel/python"
-LICENSE = "BSD-2-Clause & BSD-3-Clause & MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=82cc7d23060a75a07b820eaaf75abecf"
-
-PYPI_PACKAGE = "Sphinx"
-
-SRC_URI[sha256sum] = "94078db9184491e15bce0a56d9186e0aec95f16ac20b12d00e06d4e36f1058a6"
-
-inherit setuptools3 pypi
--
2.32.0

A newer version of this was merged to OE-Core and there shouldn't be a hard
version dependency in meta-virtualization so this can be droped from here.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
recipes-devtools/python/python3-sphinx_4.2.0.bb | 11 -----------
1 file changed, 11 deletions(-)
delete mode 100644 recipes-devtools/python/python3-sphinx_4.2.0.bb

diff --git a/recipes-devtools/python/python3-sphinx_4.2.0.bb b/recipes-devtools/python/python3-sphinx_4.2.0.bb
deleted file mode 100644
index 01f36ea..0000000
--- a/recipes-devtools/python/python3-sphinx_4.2.0.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-DESCRIPTION = "Python documentation generator"
-HOMEPAGE = "http://sphinx-doc.org/"
-SECTION = "devel/python"
-LICENSE = "BSD-2-Clause & BSD-3-Clause & MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=82cc7d23060a75a07b820eaaf75abecf"
-
-PYPI_PACKAGE = "Sphinx"
-
-SRC_URI[sha256sum] = "94078db9184491e15bce0a56d9186e0aec95f16ac20b12d00e06d4e36f1058a6"
-
-inherit setuptools3 pypi
--
2.32.0

On Wed, 2022-03-23 at 08:38 +0000, Bertrand Marquis wrote:

Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.

Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.

hardknott is not LTS, it is about to go EOL.

https://wiki.yoctoproject.org/wiki/Releases

Cheers,

Richard

Hi Bruce

On 23 Mar 2022, at 09:38, Bertrand Marquis via lists.yoctoproject.org <bertrand.marquis=arm.com@...> wrote:

Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.

Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.

In fact hardnott is not LTS (my mistake) but as support is broken it would still make sense to backport this I think.

Cheers
Bertrand

Cheers
Bertrand

The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>

wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).

This should not impact the module loading.

So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-

qemuarm64,addr=0x4500000

0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--

5.10.103+git0+792f127

2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--

5.10.103+git0+792f127

2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-

qemuarm6

4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-

module"

fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building

the latest 4.14 version of Xen.

That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.

From what I see modules to load are in a xen.conf in modules-load.d

generated by Xen tools compilation.

Gntdev is properly listed in the current xen source tree as one of the

default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc

in your dom0 roots) ?

I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf

This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.

Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.

No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building

or that systemd is not actually loading modules listed there.

Cheers
Bertrand

Cheers, Paulo.

Hi Paulo

On 22 Mar 2022, at 16:52, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.

Great thanks for the info.

@Bruce: Maybe it would make sense to backport this as hardknott is LTS ?
If yes, please ping me if you need support to do it.

Cheers
Bertrand

The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>

wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).

This should not impact the module loading.

So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-

qemuarm64,addr=0x4500000

0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--

5.10.103+git0+792f127

2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--

5.10.103+git0+792f127

2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-

qemuarm6

4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-

module"

fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building

the latest 4.14 version of Xen.

That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.

From what I see modules to load are in a xen.conf in modules-load.d

generated by Xen tools compilation.

Gntdev is properly listed in the current xen source tree as one of the

default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc

in your dom0 roots) ?

I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf

This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.

Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.

No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building

or that systemd is not actually loading modules listed there.

Cheers
Bertrand

Cheers, Paulo.

In oe-core, the commit:
a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

drops compiler flags overrides for all cmake-based recipes,
causing the ceph compile to fail with the error:
ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status

Add the override back for ceph to fix the build error.

Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"

+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+
export STAGING_DIR_HOST

do_configure:prepend () {
--
2.25.1

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.

The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...> wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu,
as it was not being properly set by the resulting bitbake build (the
resulting image was
pointing to the kernel instead of the xen binary).

This should not impact the module loading.

So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \
-bios ./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \
-device loader,file=./tmp/deploy/images/qemuarm64/xen-qemuarm64,addr=0x45000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \
-drive id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-qemuarm64.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00>
fdt set /chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.

That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.

From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?

I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf

This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be solved in xen master and I will have to check in the 4.14 version used by Yocto LTS.

Not sure if there there is some sort of startup script that was
supposed to move around these files
or even if systemd-modules-load.service would be supposed to be
looking elsewhere.

No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand

Cheers, Paulo.

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu,
as it was not being properly set by the resulting bitbake build (the
resulting image was
pointing to the kernel instead of the xen binary).

So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \
-bios ./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \
-device loader,file=./tmp/deploy/images/qemuarm64/xen-qemuarm64,addr=0x45000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \
-drive id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-qemuarm64.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00>
fdt set /chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.

That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.

From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?

I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
Not sure if there there is some sort of startup script that was
supposed to move around these files
or even if systemd-modules-load.service would be supposed to be
looking elsewhere.

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand

Cheers, Paulo.

____

On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.

Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

- Baseline is hardknott.

Any reason not to use honester ?

The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.

Hi Paulo,

On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.

Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

- Baseline is hardknott.

Any reason not to use honester ?

The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.

From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.

Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

- Baseline is hardknott.

Any reason not to use honester ?

The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.

The rest of the configuration sounds about right.
I will check why gntdev is not in.

- Target image is xen-minimal-image (for the host)
- On local.conf, I have

require xen-host.conf
and the contents of such file is https://paste.debian.net/1235220/

(Also below, just in case the link expires:)

Thanks for the prompt answer.
Kind regards, Paulo.

## Machine Definitions:
MACHINE = "qemuarm64"

## Generate ext4 rootfs for manual handling:
IMAGE_FSTYPES:append = " ext4"

## Virtualization:
DISTRO_FEATURES:append = " virtualization xen"
IMAGE_INSTALL:append = " xen xen-tools"

## Kernel stuff:
IMAGE_INSTALL:append = " kernel-modules"

# Extra Packages:
EXTRA_IMAGE_FEATURES = "debug-tweaks"
EXTRA_IMAGE_FEATURES:append = " tools-sdk"
EXTRA_IMAGE_FEATURES:append = " tools-debug"
EXTRA_IMAGE_FEATURES:append = " eclipse-debug"
IMAGE_INSTALL:append = " nano findutils tree openssh"


## Wayland stuff
DISTRO_FEATURES:remove = " x11"
DISTRO_FEATURES:append = " opengl wayland pam"

## Systemd stuff
DISTRO_FEATURES:append = " systemd pam "
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = " systemd-compat-units"

## Connman:
IMAGE_INSTALL:append = " connman \
connman-client \
connman-static-ip \
"

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_ELF = "u-boot"


IMAGE_INSTALL:append = " lvm2 bridge-utils"

## Extra space for fitting VMs:
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

Cheers
Bertrand

Thanks and kind regards, Paulo.

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

- Baseline is hardknott.

Any reason not to use honester ?

The rest of the configuration sounds about right.
I will check why gntdev is not in.

- Target image is xen-minimal-image (for the host)
- On local.conf, I have

require xen-host.conf
and the contents of such file is https://paste.debian.net/1235220/

(Also below, just in case the link expires:)

Thanks for the prompt answer.
Kind regards, Paulo.

## Machine Definitions:
MACHINE = "qemuarm64"

## Generate ext4 rootfs for manual handling:
IMAGE_FSTYPES:append = " ext4"

## Virtualization:
DISTRO_FEATURES:append = " virtualization xen"
IMAGE_INSTALL:append = " xen xen-tools"

## Kernel stuff:
IMAGE_INSTALL:append = " kernel-modules"

# Extra Packages:
EXTRA_IMAGE_FEATURES = "debug-tweaks"
EXTRA_IMAGE_FEATURES:append = " tools-sdk"
EXTRA_IMAGE_FEATURES:append = " tools-debug"
EXTRA_IMAGE_FEATURES:append = " eclipse-debug"
IMAGE_INSTALL:append = " nano findutils tree openssh"


## Wayland stuff
DISTRO_FEATURES:remove = " x11"
DISTRO_FEATURES:append = " opengl wayland pam"

## Systemd stuff
DISTRO_FEATURES:append = " systemd pam "
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = " systemd-compat-units"

## Connman:
IMAGE_INSTALL:append = " connman \
connman-client \
connman-static-ip \
"

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_ELF = "u-boot"


IMAGE_INSTALL:append = " lvm2 bridge-utils"

## Extra space for fitting VMs:
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

Cheers
Bertrand

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

Kind regards
Bertrand

Kind regards, Paulo

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

Kind regards, Paulo

On 2022-03-16 11:20, sakib.sajal@... wrote:

commit a83623a54a375d3ae9198a135b94379881a2b7a5 was added
to oe-core which removes

The phrase:
"was added ... which removes"
is awkward. As a student of Strunk and White, I suggest:

---
In oe-core, the commit:
a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

drops compiler flags overrides for all cmake-based recipes,
causing the ceph compile to fail with the error:
ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status


Add the override back for ceph to fix the build error.

---

It's always good to include the key parts of the error log
so that someone can search the commit logs for help given
a keyword.

Bruce,

Did/does this error show up in your meta-virt testing?

CXXFLAGS and CFLAGS causing
compilation for ceph to fail.
Set CXXFLAGS and CFLAGS to resolve the issue.
Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"
+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"

Does ceph need both of the _ARCH and _OPTIONS to be set?
Since the error is at link time, try adding only TOOLCHAIN_OPTIONS
as is done for:

recipes-core/runx/runx_git.bb

97: export CFLAGS="${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${CFLAGS}"

98: export LDFLAGS="${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH} ${LDFLAGS}"




../Randy

+
export STAGING_DIR_HOST
do_configure:prepend () {

--
# Randy MacLeod
# Wind River Linux

commit a83623a54a375d3ae9198a135b94379881a2b7a5 was added
to oe-core which removes CXXFLAGS and CFLAGS causing
compilation for ceph to fail.

Set CXXFLAGS and CFLAGS to resolve the issue.

Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"

+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+
export STAGING_DIR_HOST

do_configure:prepend () {
--
2.33.0

--