On Wed, Aug 31, 2022 at 07:32:11AM -0700, Colin Finck wrote:

After talking to Jason A. Donenfeld, it turned out that updating to
the latest wireguard 1.0.x version is the only solution supported by
the author. We should never maintain our own fork of wireguard
1.0.20200401, even less so considering that it's a highly
security-critical component.
The major and minor version of the latest wireguard stays the same.
Hence, this is even a solution for a Yocto LTS release like dunfell.

As a consequence, I'm importing the latest wireguard version in this
PR: https://github.com/openembedded/meta-openembedded/pull/599

Thanks. Indeed, to confirm this outside of IRC, using old snapshots of
wireguard-linux-compat is almost never a good idea, for anybody's
system, anywhere.

Jason

Hi Steve

I think this was sent to the wrong list. Can you include this in your
queue please?

Thanks,

Anuj

The following changes since commit ff3d1e122233a58799451b0b99779a4d73453679:

scripts/archive_buildstats: Exit early if buildstats isn't present (2022-08-30 16:19:11 +0100)

are available in the Git repository at:

git://git.yoctoproject.org/yocto-autobuilder-helper contrib/kirkstone-next
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/log/?h=contrib/kirkstone-next

Ross Burton (1):
config.json: Set SDKMACHINE to aarch64 for oe-selftest-armhost

config.json | 1 +
1 file changed, 1 insertion(+)

--
2.25.1

Default is to install the service in /usr/lib

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/cryptmount/cryptmount_5.3.3.bb | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/recipes-security/cryptmount/cryptmount_5.3.3.bb b/recipes-security/cryptmount/cryptmount_5.3.3.bb
index fb522cb..6741a5f 100644
--- a/recipes-security/cryptmount/cryptmount_5.3.3.bb
+++ b/recipes-security/cryptmount/cryptmount_5.3.3.bb
@@ -22,6 +22,16 @@ PACKAGECONFIG[gcrypt] = "--with-libgcrypt, --without-libgcrypt, libgcrypt"
PACKAGECONFIG[luks] = "--enable-luks, --disable-luks, cryptsetup"
PACKAGECONFIG[nls] = "--enable-nls, --disable-nls, "

+SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE:${PN} = "cryptmount.service"

+do_install:append () {
+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+ install -D -m 0644 ${S}/sysinit/cryptmount.service ${D}${systemd_system_unitdir}/cryptmount.service
+ rm -fr ${D}/usr/lib
+ fi
+}
+
+FILES:${PN} += "${systemd_system_unitdir}"
+
RDEPENDS:${PN} = "libdevmapper"
--
2.25.1

Adding back mailing list.

On Fri, Sep 2, 2022 at 10:30 AM Mahendra Sondagar
<mahendrasondagar08@...> wrote:

On Fri, Sep 2, 2022 at 02:21 AM, Khem Raj wrote:

inux-firmware-rtl8761b

Hi... Khem Raj

Thanks for the quick revert

Yes, i have made the changes as per your suggestions
Unfortunately, it's seems the same result

you have not followed what I said. The bbappend is still a kernel
bbappend, so please make a bbappend for linux-firmware recipe
instead as suggested.

secondly, the bbappend itself has issues

PACKAGES =+ "${PN}-rtl8761b"
FILES_${PN}-example = "/lib/firmware/rtl_bt/rtl8761b.bin"

PACKAGES and FILES do not match. what you want is something like

PACKAGES =+ "${PN}-rtl8761b"
FILES_${PN}-rtl8761b = "/lib/firmware/rtl_bt/rtl8761b.bin"

then in image add.

IMAGE_INSTALL += "linux-firmware-rtl8761b"

here is the error logs
Can you please check ?
-----------------------------------------------------------

Loaded 3484 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'linux-firmware-rtl8761b' (but /home/mahendra/STM32MPU_workspace/Digikey_YoctoSeries/Digikey_Yocto/meta-custom/recipes-core/images/custom-image.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'linux-firmware-rtl8761b' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['linux-firmware-rtl8761b']
ERROR: Required build target 'custom-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['custom-image', 'linux-firmware-rtl8761b']

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code

----------------------------------------

Thanks

Mahendra

I'm using Yocto Zeus and found that there is a memory leak in Python 3.7 threading.py

https://github.com/python/cpython/commit/c10c2ec7a0e06975e8010c56c9c3270f8ea322ec
As far as I know, this was not fixed until Python 3.9.
What is the easiest way to incorporate this fix into Zeus?  Create a patch with devtool?  Upgrade Python to at least 3.9?

With the recent template config changes to oe-core its content is no longer
backwards compatible.

'-f' is to guarantee future compatibility with build setups where the file
is not present.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/run-patchmetrics | 1 +
1 file changed, 1 insertion(+)

diff --git a/scripts/run-patchmetrics b/scripts/run-patchmetrics
index 1c805ec..50d9214 100755
--- a/scripts/run-patchmetrics
+++ b/scripts/run-patchmetrics
@@ -34,6 +34,7 @@ for branch in master kirkstone dunfell; do
git -C $PARENTDIR reset origin/$branch --hard
rm conf/local.conf
rm conf/bblayers.conf
+ rm -f conf/templateconf.cfg
rm tmp/ -rf
unset BB_ENV_PASSTHROUGH_ADDITIONS
unset BB_ENV_EXTRAWHITE
--
2.37.2

On 9/1/22 11:51 AM, Mahendra Sondagar wrote:

Hi... There
Hope all are doing well
Right now, I'm dealing with the *TP-Link Bluetooth dongle*.
My goal is to add the Bluetooth functionality with the Yocto custom image
After some research i got to know that the Bluetooth dongle, that I'm using is unsupported by activating the Bluetooth drivers only by menuconfig
I'll have to manually add the *rtl8761b_fw.bin* file with the image
Here is the good post for the same
https://askubuntu.com/questions/1370663/bluetooth-scan-doesnt-detect-any-device-on-ubuntu-21-10 <https://askubuntu.com/questions/1370663/bluetooth-scan-doesnt-detect-any-device-on-ubuntu-21-10>
Now, my problem is, I'm getting some errors after adding it's firmware file
Here is the steps, which i have gone through
1. Created linux-firmware file under recpies-kernel directory

there already is a linux-firmware recipe meta/recipes-kernel/linux-firmware/linux-firmware_20220708.bb

2. added the rtl8761b_fw.bin to /files directory under linux-firmware file

OK

3. Created .bbappend file as per the available kernel name called *"linux-stm32mp_%.bbappend"*

bbappend should be for linux-firmware recipe.

4. installed the .bin image with the custom recipes file called custom-image.bb as follows
    # Drivers for the TPL-Link Bluetooth dongle
    IMAGE_INSTALL += "linux-firmware-rtl8761b_fw"

I think it will be called something else then perhaps linux-firmware-rtl8761b or some such. Avoid using '_' in the name as its used a version separator and can confuse the packaging

5. bake the image with bitbake custom-image
here is the tree of the directories
The error screenshot is mentioned here
The content of the .bbappend file is listed here
Can any one help me here ?
All suggestions and comments welcome :)
Regards
Mahendra Sondagar

Hi... There

Hope all are doing well

Right now, I'm dealing with the TP-Link Bluetooth dongle.
My goal is to add the Bluetooth functionality with the Yocto custom image
After some research i got to know that the Bluetooth dongle, that I'm using is unsupported by activating the Bluetooth drivers only by menuconfig
I'll have to manually add the rtl8761b_fw.bin file with the image

Here is the good post for the same
https://askubuntu.com/questions/1370663/bluetooth-scan-doesnt-detect-any-device-on-ubuntu-21-10

Now, my problem is, I'm getting some errors after adding it's firmware file

Here is the steps, which i have gone through

1. Created linux-firmware file under recpies-kernel directory

2. added the rtl8761b_fw.bin to /files directory under linux-firmware file

3. Created .bbappend file as per the available kernel name called "linux-stm32mp_%.bbappend"

4. installed the .bin image with the custom recipes file called custom-image.bb as follows
    # Drivers for the TPL-Link Bluetooth dongle
    IMAGE_INSTALL += "linux-firmware-rtl8761b_fw"

5. bake the image with bitbake custom-image

here is the tree of the directories


The error screenshot is mentioned here




The content of the .bbappend file is listed here



Can any one help me here ?
All suggestions and comments welcome :)

Regards
Mahendra Sondagar

Hi Jerome,

  Parsec doesn't depend on optee-client and doesn't require it at all. If Parsec is built with the Trusted Services provider included  then `libts` is added into DEPENDS and RDEPENDS:

https://git.yoctoproject.org/meta-security/tree/meta-parsec/recipes-parsec/parsec-service/parsec-service_1.0.0.bb#n23

The libts recipe (it will be merged into meta-arm later today or tomorrow together with other generic recipes for Trusted Services Secure Partitions (SWd side) and test/demo tools (NWd side)) creates `teeclnt` group.

Cheers,
Anton

Hi Anton,

The teeclnt (TEE client) group should be created by the optee-client recipe. I realize that it is not upstream at the moment but only in a Linaro .bbappend:
https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/kirkstone/meta-ledge-secure/recipes-security/optee/optee-client_%25.bbappend#L35

As for https://git.yoctoproject.org/meta-security/tree/meta-parsec/recipes-parsec/parsec-service/parsec-service_1.0.0.bb#n75 this looks good but shouldn't there be a DEPENDS on optee-client so that the recipe is executed after the group is created? (that was an oversight in my patch BTW). My limited knowledge of Yocto doesn't allow me to comprehend how trusted-service-provider is supposed to be used.

Thanks,
--
Jerome

Thank you, and I am looking at kirkstone...

On 8/31/22 4:36 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Thank you for the quick replay...
The no graphic option does work but the kernel comes up with errors...
Will full wayland support be added to the dunfell release ?

you can use vnc backend which is enabled by default. by using
runqemu publicvnc

I wish runqemu was smart enough to prioritize, interactive UI e.g. sdl/gtk if not available then fall back to vnc, and then use nographic
in order.

and please look at kirkstone if you are evaluating next LTS, dunfell is still supported but is already inching towards its end comparatively you get more modern package versions with kirkstone.

Steve
-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Alexander Kanavin
Sent: Wednesday, August 31, 2022 7:23 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #dunfell #qemux86-64
External Email Alert
This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.
You need to run this in a X11 session, or use 'nographic' parameter.
Alex
On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Hello:



I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.



When building the default : core-image-minimal or core-image-sato,
clean with no errors/warnings, on execution

I get the following error for both (see below)…



(1) Is this an issue with the release ?, and is there another release I should be using ?

(2) Is there something I need to pre-configure for these builds to run properly ?

(3) How might I resolve this issue ?



06:57 smonsees@yix490016
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfe
ll_Min>runqemu qemux86-64

runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...

runqemu - INFO - Continuing with the following parameters:

KERNEL:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb
08507_85f0668fea-r0-qemux86-64-20220830151817.bin]

MACHINE: [qemux86-64]

FSTYPE: [ext4]

ROOTFS:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-202
20830151817.rootfs.ext4]

CONFFILE:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunf
ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-202
20830151817.qemuboot.conf]



runqemu - INFO - Setting up tap interface under sudo

[sudo] password for smonsees:

runqemu - INFO - Network configuration:
ip=192.168.7.2::192.168.7.1:255.255.255.0

runqemu - INFO - Running /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw -show-cursor -usb -device usb-tablet -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -cpu core2duo -m 256 -serial mon:vc -serial null -kernel /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220830151817.bin -append 'root=/dev/vda rw mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 '



runqemu - ERROR - Failed to run qemu: Could not initialize SDL(x11 not
available) - exiting



runqemu - INFO - Cleaning up

Set 'tap0' nonpersistent



Thank you for your help,

Steve

Thanks for the quick response, Armin!

After talking to Jason A. Donenfeld, it turned out that updating to the latest wireguard 1.0.x version is the only solution supported by the author. We should never maintain our own fork of wireguard 1.0.20200401, even less so considering that it's a highly security-critical component.
The major and minor version of the latest wireguard stays the same. Hence, this is even a solution for a Yocto LTS release like dunfell.

As a consequence, I'm importing the latest wireguard version in this PR: https://github.com/openembedded/meta-openembedded/pull/599

I have tested that PR and it works like a charm on latest Yocto/Poky dunfell.
Even no longer reports a "dirty" version or warns about "loading out-of-tree module taints kernel".

Colin

"Monsees, Steven C (US) via lists.yoctoproject.org" <steven.monsees=baesystems.com@...> writes:

I will have to double check, but the issue did not appear under zeus...
so qemu changed sometime after zeus ?

Not qemu but runqemu script has been changed not so long time ago (this
year) to pass `-display sdl` parameter unless nographic option has been
specified. As it was mentioned you have to pass -nographic to use
runqemu without SDL frontend

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 31, 2022 8:12 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros. For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


The issue is on your side, not on yocto's. By default qemu is
configured to show graphical output in a X11 window, so you need to
run it in a X11 session, with correctly set DISPLAY environment
variable.

Alex

On Wed, 31 Aug 2022 at 14:10, Monsees, Steven C (US) <steven.monsees@...> wrote:

One final question, does this issue exist in kirkstone-4.0.2 ?

Thanks,
Steve

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 31, 2022 7:42 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.
For further information on how to spot phishing, access
“Cybersecurity OneSpace Page” and report phishing by clicking the
button “Report Phishing” on the Outlook toolbar.


I need to see the errors to give a useful answer. If you want wayland, use core-image-weston as the image.

Alex

On Wed, 31 Aug 2022 at 13:37, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Thank you for the quick replay...

The no graphic option does work but the kernel comes up with errors...

Will full wayland support be added to the dunfell release ?

Steve

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Alexander Kanavin
Sent: Wednesday, August 31, 2022 7:23 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are
requested to click on a link, decrypt/open an attachment, or
enable macros. For further information on how to spot phishing,
access “Cybersecurity OneSpace Page” and report phishing by
clicking the button “Report Phishing” on the Outlook toolbar.


You need to run this in a X11 session, or use 'nographic' parameter.

Alex

On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Hello:



I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.



When building the default : core-image-minimal or core-image-sato,
clean with no errors/warnings, on execution

I get the following error for both (see below)…



(1) Is this an issue with the release ?, and is there another release I should be using ?

(2) Is there something I need to pre-configure for these builds to run properly ?

(3) How might I resolve this issue ?



06:57 smonsees@yix490016
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/d
un
fe
ll_Min>runqemu qemux86-64

runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...

runqemu - INFO - Continuing with the following parameters:

KERNEL:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/
du
nf
ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3
fe cb 08507_85f0668fea-r0-qemux86-64-20220830151817.bin]

MACHINE: [qemux86-64]

FSTYPE: [ext4]

ROOTFS:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/
du
nf
ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64
-2
02
20830151817.rootfs.ext4]

CONFFILE:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/
du
nf
ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64
-2
02
20830151817.qemuboot.conf]



runqemu - INFO - Setting up tap interface under sudo

[sudo] password for smonsees:

runqemu - INFO - Network configuration:
ip=192.168.7.2::192.168.7.1:255.255.255.0

runqemu - INFO - Running
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64
-device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev
tap,id=net0,ifname=tap0,script=no,downscript=no -drive
file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw
-show-cursor -usb -device usb-tablet -object
rng-random,filename=/dev/urandom,id=rng0 -device
virtio-rng-pci,rng=rng0 -cpu core2duo -m 256 -serial mon:vc
-serial null -kernel
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220830151817.bin
-append 'root=/dev/vda rw mem=256M
ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 '



runqemu - ERROR - Failed to run qemu: Could not initialize SDL(x11
not
available) - exiting



runqemu - INFO - Cleaning up

Set 'tap0' nonpersistent



Thank you for your help,

Steve

I will have to double check, but the issue did not appear under zeus...
so qemu changed sometime after zeus ?

The issue is on your side, not on yocto's. By default qemu is
configured to show graphical output in a X11 window, so you need to
run it in a X11 session, with correctly set DISPLAY environment
variable.

Alex

On Wed, 31 Aug 2022 at 14:10, Monsees, Steven C (US)
<steven.monsees@...> wrote:

One final question, does this issue exist in kirkstone-4.0.2 ?

Thanks,
Steve

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@...>
Sent: Wednesday, August 31, 2022 7:42 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


I need to see the errors to give a useful answer. If you want wayland, use core-image-weston as the image.

Alex

On Wed, 31 Aug 2022 at 13:37, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Thank you for the quick replay...

The no graphic option does work but the kernel comes up with errors...

Will full wayland support be added to the dunfell release ?

Steve

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Alexander Kanavin
Sent: Wednesday, August 31, 2022 7:23 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #dunfell #qemux86-64

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


You need to run this in a X11 session, or use 'nographic' parameter.

Alex

On Wed, 31 Aug 2022 at 13:17, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Hello:



I am attempting to evaluate dunfell -23.0.17, on a cetos7 linux box.



When building the default : core-image-minimal or core-image-sato,
clean with no errors/warnings, on execution

I get the following error for both (see below)…



(1) Is this an issue with the release ?, and is there another release I should be using ?

(2) Is there something I need to pre-configure for these builds to run properly ?

(3) How might I resolve this issue ?



06:57 smonsees@yix490016
/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dun
fe
ll_Min>runqemu qemux86-64

runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e ...

runqemu - INFO - Continuing with the following parameters:

KERNEL:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/du
nf
ell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fe
cb 08507_85f0668fea-r0-qemux86-64-20220830151817.bin]

MACHINE: [qemux86-64]

FSTYPE: [ext4]

ROOTFS:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/du
nf
ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-2
02
20830151817.rootfs.ext4]

CONFFILE:
[/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/du
nf
ell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-2
02
20830151817.qemuboot.conf]



runqemu - INFO - Setting up tap interface under sudo

[sudo] password for smonsees:

runqemu - INFO - Network configuration:
ip=192.168.7.2::192.168.7.1:255.255.255.0

runqemu - INFO - Running /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=/disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20220830151817.rootfs.ext4,if=virtio,format=raw -show-cursor -usb -device usb-tablet -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -cpu core2duo -m 256 -serial mon:vc -serial null -kernel /disk0/scratch/smonsees/yocto/yocto-dunfell/poky-dunfell-23.0.17/dunfell_Min/tmp/deploy/images/qemux86-64/bzImage--5.4.192+gitAUTOINC+3fecb08507_85f0668fea-r0-qemux86-64-20220830151817.bin -append 'root=/dev/vda rw mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 '



runqemu - ERROR - Failed to run qemu: Could not initialize SDL(x11
not
available) - exiting



runqemu - INFO - Cleaning up

Set 'tap0' nonpersistent



Thank you for your help,

Steve

One final question, does this issue exist in kirkstone-4.0.2 ?

Thanks,
Steve