Date   

Re: [meta-security][dunfell][PATCH 0/9] Some IMA/EVM fixes to dunfell branch

Ming Liu <liu.ming50@...>
 

Hi, akuster808:

I saw this patch set has been merged to gatesgarth, may I ask, any plan for dunfell? I am asking because dunfell is a LTS branch and many users are building their products based on it. Thanks!

the best,
thank you

series in build testing

-armin

On 3/2/21 6:57 AM, liu.ming50@... wrote:
> From: Ming Liu <ming.liu@...>
>
> Cherry pick some IMA/EVM fixes to LTS dunfell branch, with these
> patches applied, I could run a ima enabled image with sysvinit/systemd
> on qemuarm/qemuarm64 and some NXP machines.
>
> Ming Liu (9):
>   ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
>   initramfs-framework-ima: fix a wrong path
>   ima-evm-keys: add recipe
>   initramfs-framework-ima: RDEPENDS on ima-evm-keys
>   meta: refactor IMA/EVM sign rootfs
>   README.md: update according to the refactoring in
>     ima-evm-rootfs.bbclass
>   initramfs-framework-ima: let ima_enabled return 0
>   ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic
>   ima-policy-hashed: add CGROUP2_SUPER_MAGIC fsmagic
>
>  meta-integrity/README.md                      |  4 ++-
>  meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
>  .../initrdscripts/initramfs-framework-ima.bb  |  2 +-
>  .../initrdscripts/initramfs-framework-ima/ima |  3 +-
>  .../ima-evm-keys/ima-evm-keys_1.0.bb          | 16 +++++++++
>  .../ima-evm-utils/ima-evm-utils_git.bb        |  1 +
>  .../ima_policy_hashed/files/ima_policy_hashed |  3 ++
>  7 files changed, 41 insertions(+), 21 deletions(-)
>  create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb
>


Re: Assign IP address at boot time

Zoran
 

Hello,

Maybe you can stop in the U-Boot monitor, and check your environment?
=>
=> print serverip
=> print ipaddr
=> print gatewayip
=> print gw_ip

And see what and how your bootcmd and similar env variables look like?

And if you do not have defined above, to add them (according to ash
script) and try booting again?

Zee
_______


On Tue, Mar 9, 2021 at 10:28 PM jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@lists.yoctoproject.org> wrote:


Where do I assign a static IP address to my sole network interface?

I tried using the Linux boot parameters (in extlinux.conf):

LABEL Arria10 SOCDK SDMMC
KERNEL ../zImage
FDT ../socfpga_arria10_phead.dtb
APPEND root=/dev/mmcblk0p2 rw rootwait earlyprintk console=ttyS0,115200n8 ip=192.168.0.101:255.255.255.0:eth0

Then I tried editing: /etc/network/interfaces

iface eth0 inet static
address 192.168.0.101
netmask 255.255.255.0

Both failed. Where do I go?



what version of YP will next wind river (LTS20) be based on?

Robert P. J. Day
 

i suspect i know the answer, just want to confirm ... friend tells
me yesterday he's working with LTS20, i said, "uh, that's not even out
yet," he assures he his company has an early release, but he couldn't
tell me what version of YP it corresponded to.

based on regularity of releases on both sides, i would *guess* it's
equivalent to gatesgarth, is that a good guess?

rday


Re: Assign IP address at boot time

jchludzinski
 

To start, do you have the driver required for your network interface?
Yes, the network/Ethernet device is recognized by Linux and the appropriate driver is loaded. If I use:

$ ip add add 192.168.9.101/24 dev eth0

I’m up and running. But I want the IP assignment to happen during boot time.


Re: [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config

Yi Zhao
 

On 3/9/21 11:32 PM, Joe MacDonald wrote:
[Re: [yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 14:53) Anatol Belski wrote:

Hi Joe,

thanks for the quick check. The patch applies fine to dunfell and
gatesgarth, master has the changed recipe version in the bb name. I was
about to rebase to master but pulling shows already did it. I was too slow
:) thanks for the quick fix.
No problem! I assumed you were working on a just-slightly-out-of-date
master branch and my work tree already had your patch half applied when
the 'git am' failed, so I just finished that part up.

Hi Joe,


This patch doesn't need to be merged into master because I have fixed it in commit fb15056ff44318d7886fd0f68e2f6dba716e9be4.


//Yi


I'll get to the other branches in a bit.

-Joe.

Regards

Anatol

On 3/9/2021 2:00 PM, Joe MacDonald wrote:
Hi Anatol,

I will confirm this against the other branches (dunfell and gatesgarth)
but your patch doesn't appear to be against the current master branch (and
it's unlikely one patch will apply to all branches). Can you send out
specific patches against the head of tree for each branch you care about,
please? Then I can get them merged for you.

Thanks,
-Joe.

[[yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 11:55) Anatol Belski wrote:

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX
require ${BPN}.inc
+inherit python3targetconfig
+
LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
--
2.17.1


[PATCH v2] yocto-bsp: update reference platforms to latest 5.10

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Bumping our reference boards to match the latest in OE-core. Not only
do we get the latest, we fix a configuration warning with genericx86.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---

The edgerouter had a compilation issue due to a dropped #ifdef
during merge.

This fixes up the build.

Bruce

.../linux/linux-yocto_5.10.bbappend | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 87e47352a6..bc2b3bf576 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,17 +7,17 @@ KMACHINE_genericx86 ?= "common-pc"
KMACHINE_genericx86-64 ?= "common-pc-64"
KMACHINE_beaglebone-yocto ?= "beaglebone"

-SRCREV_machine_genericx86 ?= "cdca78778415b4b3bd64e8390ee8adf04bf7e17a"
-SRCREV_machine_genericx86-64 ?= "cdca78778415b4b3bd64e8390ee8adf04bf7e17a"
-SRCREV_machine_edgerouter ?= "2e1fb8f84f09ca768eb531f33a126a40bb90e791"
-SRCREV_machine_beaglebone-yocto ?= "cdca78778415b4b3bd64e8390ee8adf04bf7e17a"
+SRCREV_machine_genericx86 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_genericx86-64 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_edgerouter ?= "965ab3ab746ae8a1158617b6302d9c218ffbbb66"
+SRCREV_machine_beaglebone-yocto ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"

COMPATIBLE_MACHINE_genericx86 = "genericx86"
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"

-LINUX_VERSION_genericx86 = "5.10.12"
-LINUX_VERSION_genericx86-64 = "5.10.12"
-LINUX_VERSION_edgerouter = "5.10.12"
-LINUX_VERSION_beaglebone-yocto = "5.10.12"
+LINUX_VERSION_genericx86 = "5.10.21"
+LINUX_VERSION_genericx86-64 = "5.10.21"
+LINUX_VERSION_edgerouter = "5.10.21"
+LINUX_VERSION_beaglebone-yocto = "5.10.21"
--
2.19.1


Re: Assign IP address at boot time

Rudolf J Streif
 

Hi there,

On 3/9/21 1:27 PM, jchludzinski via lists.yoctoproject.org wrote:
Where do I assign a static IP address to my sole network interface?

That depends on whether or not you are using a network manager and if so which one.

You haven't told us much about your board and it's network interfaces and how you built your system.

I tried using the Linux boot parameters (in extlinux.conf):

LABEL Arria10 SOCDK SDMMC
    KERNEL ../zImage
    FDT ../socfpga_arria10_phead.dtb
    APPEND root=/dev/mmcblk0p2 rw rootwait earlyprintk console=ttyS0,115200n8 ip=192.168.0.101:255.255.255.0:eth0
 
Then I tried editing: /etc/network/interfaces
 
iface eth0 inet static
address 192.168.0.101
netmask 255.255.255.0
 
Both failed. Where do I go?

To start, do you have the driver required for your network interface? You can use ifconfig -a to see if your network interface is detected by the kernel. You should also look at the kernel log if the network interface is configured.

:rjs




-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Assign IP address at boot time

jchludzinski
 

Where do I assign a static IP address to my sole network interface?

I tried using the Linux boot parameters (in extlinux.conf):

LABEL Arria10 SOCDK SDMMC
    KERNEL ../zImage
    FDT ../socfpga_arria10_phead.dtb
    APPEND root=/dev/mmcblk0p2 rw rootwait earlyprintk console=ttyS0,115200n8 ip=192.168.0.101:255.255.255.0:eth0
 
Then I tried editing: /etc/network/interfaces
 
iface eth0 inet static
address 192.168.0.101
netmask 255.255.255.0
 
Both failed. Where do I go?


[PATCH] yocto-bsp: update reference platforms to latest 5.10

Bruce Ashfield
 

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Bumping our reference boards to match the latest in OE-core. Not only
do we get the latest, we fix a configuration warning with genericx86.

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
.../linux/linux-yocto_5.10.bbappend | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 87e47352a6..aa2c3dd1c1 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,17 +7,17 @@ KMACHINE_genericx86 ?= "common-pc"
KMACHINE_genericx86-64 ?= "common-pc-64"
KMACHINE_beaglebone-yocto ?= "beaglebone"

-SRCREV_machine_genericx86 ?= "cdca78778415b4b3bd64e8390ee8adf04bf7e17a"
-SRCREV_machine_genericx86-64 ?= "cdca78778415b4b3bd64e8390ee8adf04bf7e17a"
-SRCREV_machine_edgerouter ?= "2e1fb8f84f09ca768eb531f33a126a40bb90e791"
-SRCREV_machine_beaglebone-yocto ?= "cdca78778415b4b3bd64e8390ee8adf04bf7e17a"
+SRCREV_machine_genericx86 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_genericx86-64 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_edgerouter ?= "9c8757a2d62bd748f52a4973bd421d4dd8ebe216"
+SRCREV_machine_beaglebone-yocto ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"

COMPATIBLE_MACHINE_genericx86 = "genericx86"
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"

-LINUX_VERSION_genericx86 = "5.10.12"
-LINUX_VERSION_genericx86-64 = "5.10.12"
-LINUX_VERSION_edgerouter = "5.10.12"
-LINUX_VERSION_beaglebone-yocto = "5.10.12"
+LINUX_VERSION_genericx86 = "5.10.21"
+LINUX_VERSION_genericx86-64 = "5.10.21"
+LINUX_VERSION_edgerouter = "5.10.21"
+LINUX_VERSION_beaglebone-yocto = "5.10.21"
--
2.19.1


Re: Swap management: vm.swappiness best values?

Laurent Gauthier
 

Hi again,

kswapd is triggered (even when there is no swap space) to reclaim some space when the memory runs low. There is no way to turn it completely off, with the swappiness parameter you can control how pro-active it will be.

One of the ways it manages to "reclaim" memory (even if there is no swap storage defined) is that it can trigger a compaction of memory zones, therefore reducing memory fragmentation by removing "holes".

This defragmentation will help with the allocation of larger memory blocks.

If you reduce the swappiness setting to zero it will still trigger at some point, but just much later.

Kind regards, Laurent.


On Tue, Mar 9, 2021 at 5:21 PM Mauro Ziliani <mauro@...> wrote:
Thank you for the answer.

May be I explain my problem not so well :-(

I don't have enabled swap partition in fstab and if I run swapon nothing is shown.
The swap partition is not defined anywhere in the system. Only the manager is available in the kernel.

I made an analisys of memory usage before posting this,  and I see that when the free ram drop under 600MB the kernel thread mmcq/2 and kswap0 starts to work.
I see the this 600MB is 60% of 1GB, and vm.swapping=60.

So I ask  here if someone has some experience.  with vm.swappiness  value on embedded.

You have centered perfecly the matter about the slow-down: when memory drop to low, the system is tired to work.

I cannot explain why even if no swap spaces are defined, kswap0 works

Now I try to put vm.swappiness=6  and it seems to work well

MZ

On mar 9 2021, at 12:17 pm, Laurent Gauthier <laurent.gauthier@...> wrote:
Ciao Mauro,

Sounds more like a pure Linux/UNIX question than a yocto one :-)

As you most likely know on an embedded system which uses permanent storage (NAND flash or eMMC) that is subject to wear it is important to completely turn off swap.

At runtime if the system is up and running then you should issue the "swapoff -a" command.

But the proper fix is to remove any entry from your /etc/fstab designating a swap partition.

However I would be surprised if you had a swap partition configured in your system as most embedded systems don't have one.

Instead what I am thinking is that you are likely seeing a system slow-down due to your system's memory usage coming close to 100% of the available RAM, which in turn causes all calls to memory allocation functions to slow down (algorithms have to look harder to find available memory).

I would suggest that when the issue occurs that you first check the current system memory usage and have a look at which application is using the most memory and figure out if there is a way to optimize it and reduce the memory usage.

Kind regards, Laurent.

On Tue, Mar 9, 2021 at 10:03 AM Mauro Ziliani <mauro@...> wrote:
Hi all.
I'm working with Krogoth on a imx6dl board with 1GB of RAM.
I don't setup the swap space, but sometimes I see that kswap0 task starts, and the board slow down.

I'd like to change  the value of vm.swappiness to avoid swap requests

The default value  of vm.swappiness is 60.

There is a minimum value for vm.swappiness?

Best regards,
   MZ




--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429


--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
https://soccasys.com


Re: #yocto #sdk #yocto #sdk

Khem Raj
 


On Tue, Mar 9, 2021 at 4:40 AM Monsees, Steven C (US) <steven.monsees@...> wrote:

 

What is the difference between using “SIGGEN_UNLOCKED_RECIPES +=” and “BB_HASHBASE_WHITELIST_append =” ?

 

 

From: Khem Raj <raj.khem@...>
Sent: Thursday, March 4, 2021 1:22 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk

 

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.

 

right, the change seems to be happening in task checksums and that happens if some of bitbake variables change when SDK is built built and when it is being installed ( when it will run parse again ) perhaps the workspace under the hood is still accessible and you can use bitbake-diffsigs to narrow it down the variable that is changing

 

On Thu, Mar 4, 2021 at 9:38 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

I am seeing similar issues on line  for my eSDK install issue, but no resolutions…

 

Can someone advise on best course of action to debug this ?

 

11:10 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk> ./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |##########################################################################################| Time: 0:01:36

Initialising tasks: 100% |#######################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |###############################################################| Time: 0:00:02

WARNING: The efitools:do_compile sig is computed to be 5851605e22907038837428950427053e22ea655641a08b5dafa39d6d6e1c5e15, but the sig is locked to b81a26e3591c71acd3d22212bfdb70a15a0df49af72e7634e6a39851f16e18b5 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be 13a65b26dfff91f2432a8064d98003559eafffa214d81c3c6ea112c2dfba0391, but the sig is locked to 2058fc9032b0e7f5c1ea358de4fa8d25ccec7204b73ebc636e79222d8cc00469 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be ac0c5c19cdbe7484046657ccb7b768c02fbbabb43166befa93b71a85d5fcf55b, but the sig is locked to cf5c3f72489f447b1199aafe4b4148988ff91cecd970422352f2238afb127683 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be 4e16b100c32e9428126eb10864508038527cec795c5e4391208d96a55735c90a, but the sig is locked to a2bd26be0297624af53d6f8cf657d79740fb229db821c446d564c5ee9dc80ea3 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be 630cc346f7ececf98c54f9134e8fee546e85c92f1e3c6ac3c258a1cdf24d4565, but the sig is locked to 802bba0874ce26169a9e16dcdb440795e8fa904977b036d637d6c4086ce72de8 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be faf0ae3c9159ef3ebb13d2521ecf51dfeeac0c2c47691cd0aaa80de91187af3c, but the sig is locked to 0075bbd34297bfbc62685ff5477feec11d0dd2bcda6787a151cfb7927a7f39c2 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be 30c09f3e8db4059b7e1ff23823f208be94d0e622904fc43eda497027be095a71, but the sig is locked to a9e8ddd9ecac11e67c66d9fccbabe23b6eb4a19c5996baef8ff960dfcdc898ed in SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/db/db_5.3.28.bb:do_populate_sysroot, unihash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0, taskhash dcfb179ae99ac73583d33eec1357ff5d06fb58f160e5d7285061b6e1c9c3a9c0

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-extended/sed/sed_4.2.2.bb:do_package_write_ipk, unihash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3, taskhash a37dc1cc0064749d1f6de69d0a9b8eab9ff6ef4089eff28a76e1851f8f8f8fe3

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:do_package_qa, unihash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8, taskhash 2b17b70b3e1568840e3b39488b9e6470c89d5ffd502f02b2c129331d7609add8

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-connectivity/openssh/openssh_8.0p1.bb:do_package_qa, unihash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155, taskhash 87a24567344a646de9ab6fba50b398e41711ff4d1bca749ebe02d84359c2a155

.

.

 

 

https://www.mail-archive.com/search?l=yocto@...&q=subject:%22Re%5C%3A+%5C%5Byocto%5C%5D+eSDK+install+script+failure%22&o=newest&f=1

 

https://www.yoctoproject.org/pipermail/yocto/2017-August/037359.html

 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12344

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Thursday, March 4, 2021 8:13 AM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #yocto #sdk

 

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.

 

 

 

Is there a list of certain classes that might interfere with the ability of the eSDK to lock down the configuratiuon ?
 
Thanks,
Steve

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, March 2, 2021 3:26 PM
To: yocto@...
Subject: [yocto] #yocto #sdk

 

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 still appear to be having an issue with the SXT SDK install…

 

Building for zeus/x86_64 Intel based platform…

I build my kernel image clean, fully functional…

Standard SDK builds clean and appears functional…

 

Ext SDK builds clean, but on install I am still seeing Error below…

 

(1)    What is it comparing  between unhash/task hash ?, more sig issues ?

 

(2)    What is meant by “This is usually due to missing setscene tasks” ?

 

(3)    In the local.conf under the SDK they set :

 

SSTATE_MIRRORS += " file://universal/(.*) file://universal-4.9/\1 file://universal-4.9/(.*) file://universal-4.8/\1"

 

Under sdk-extra.conf I set :

 

SSTATE_MIRRORS += file://.* file:///ede/tms/yocto/zeus/sstate_cache/PATH

 

My SSTATE_MIRRIOR is based off the clean builds I mentioned above, is this the correct procedure ?

 

I am trying to figure out how best to debug this issue, it is occurring on the post install, and everything pretty much appears in place.

 

Steve

 

14:43 smonsees@yix490038 /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |###########################################################################################| Time: 0:01:32

Initialising tasks: 100% |########################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |################################################################| Time: 0:00:03

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-support/liburcu/liburcu_0.11.1.bb:do_populate_sysroot, unihash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601, taskhash cdb08644b85fa162bd9f88cb00113fe3193cc347e39e33e8f405f9c23f60c601

Task /disk0/scratch/smonsees/testSDK/layers/poky/meta/recipes-devtools/python/python3_3.7.8.bb:do_packagedata, unihash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f, taskhash 925a72cbe872aad09bd3fbbe74ed1c944e9c19a732e120feae5c4784e6330d4f

.

.

.

 

This is usually due to missing setscene tasks. Those missing in this build were:

 

<<appears to list every recipe under ./testSDK/layers directory here>>



Re: avahi_0.8 issue with latest version

Khem Raj
 

if the process is dead them perhaps it will be helpful to get a
stacktrace and see whats going on.

On Fri, Mar 5, 2021 at 8:15 AM sateesh m <sateesh0457@gmail.com> wrote:

Hi Guys,

I have installed avahi_0.8 version using gatesgreath version. its compiled successfully .but i am facing issue with pid is remove automatically when i restart my service.

avahi configuration : hostname,domain name, allow ipv4, allow eth0,reflector =yes i did all this avahi-daemon.conf
dependencies: gtk+3,gtk,dbus,avahi-daemon,avahi-utils ,libnss-mdns.
is i miss any configuration or any patchwork work for this packages please update me i will modify it.

( avahi-daemon[625]: Process 592 died: No such process; trying to remove PID file. (/run/avahi-daemon//pid))


0;1;32m*[[0m avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
Active: [[0;1;32mactive (running)[[0m since Fri 2021-03-05 13:12:17 UTC; 7min ago
TriggeredBy: [[0;1;32m*[[0m avahi-daemon.socket
Main PID: 625 (avahi-daemon)
Status: "avahi-daemon 0.8 starting up."
Tasks: 2 (limit: 9561)
Memory: 620.0K
CGroup: /system.slice/avahi-daemon.service
|-625 avahi-daemon: running [foo.local]
`-626 avahi-daemon: chroot helper

Mar 05 13:12:17 mysystem systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Mar 05 13:12:17 mysystem avahi-daemon[625]: Process 592 died: No such process; trying to remove PID file. (/run/avahi-daemon//pid)
Mar 05 13:12:17 my system systemd[1]: Started Avahi mDNS/DNS-SD Stack.



root@mysystem:~# pgrep -f -l avahi
192 systemctl
200 systemctl
210 systemctl
216 journalctl
503 systemctl
539 systemctl
547 systemctl
559 systemctl
575 systemctl
582 systemctl
594 systemctl
625 avahi-daemon: running [foo.local]
626 avahi-daemon: chroot helper


Thanks & Regards,
Sateesh





Yocto Technical Team Minutes/Engineering Sync for Mar 9, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for Mar 9, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Alexandre Belloni, Armin Kuster, Steve
Sakoman, Joshua Watt, Jan-Simon Möller, Richard Purdie, Paul Barker, John
Kaldas, Jon Mason, Michael Halstead, Randy MacLeod, sakib.sajal, Saul Wold,
Scott Murray, Tim Orling, Ross Burton

== notes ==
- -m3 not yet built
- rust deferred to 3.4
- reproducibility is good

== general ==
RP: side-tracked with a run-queue bug (in bitbake), good to have it resolved
RP: there was also a bitbake logging fix which was why we couldn’t get logs
for some things
RP: wrt to the regression we saw last week (long initial parsing time)
haven’t confirmed or looked into it, but am quite sure I know which
patch caused it (multiconfig)


Randy: Sakib and I have developed a tool to help with some AB intermittent
issues. looked at the dmesg output of one builder and saw that it was
unable to schedule for 120s.
RP: it might be tricky to write one script that will work on all systems (e.g.
on some dmesg requires root)
RP: AB-helper might be useful too. it could be that disk cache wiping might be
an issue
MichaelH: only some of the workers have that at this point
RP: could you give us a list of which workers have that enabled? maybe we will
see a correlation
MichaelH: sure


PaulB: pr-serv changes going into the next release
RP: yes, i was under the impression we’d need a bit more time for it
PaulB: yes, i’m not 100% available at the moment
RP: no problem, it’ll reduce the pressure
PaulB: agreed, getting it in too close to the release could be risky


RP: i’m looking at removing a bunch of code related to dynamic hashing.
i’m pretty sure it’s not being used anymore, but need to double-check
it


RP: there are ~6 reproducibility issues, have patches for them (submitted
upstream) including:
- ignoring the Go issue
- i think Bruce is close to getting perf working
- meson python compiled header issue
- ovmf hard-coded path issue (Ross is looking into it) strange build
system (edk2)
- ruby-docs


Randy: there’s a valgrind release in the works, but we can wait for it
Ross: there’s grub as well (CVEs)
RP: do we have any timeline?
Randy: upstream says “…in a matter of days…” 8 days ago
RP: i won’t block -m3 on it
RP: would prefer to not upgrade valgrind too close to a release (history of
causing ptest issues)
AlexB: are the ptest issues performance-related?
RP: not necessarily, just that we often get issues


Re: Swap management: vm.swappiness best values?

Mauro Ziliani
 

Thank you for the answer.

May be I explain my problem not so well :-(

I don't have enabled swap partition in fstab and if I run swapon nothing is shown.
The swap partition is not defined anywhere in the system. Only the manager is available in the kernel.

I made an analisys of memory usage before posting this,  and I see that when the free ram drop under 600MB the kernel thread mmcq/2 and kswap0 starts to work.
I see the this 600MB is 60% of 1GB, and vm.swapping=60.

So I ask  here if someone has some experience.  with vm.swappiness  value on embedded.

You have centered perfecly the matter about the slow-down: when memory drop to low, the system is tired to work.

I cannot explain why even if no swap spaces are defined, kswap0 works

Now I try to put vm.swappiness=6  and it seems to work well

MZ


On mar 9 2021, at 12:17 pm, Laurent Gauthier <laurent.gauthier@...> wrote:
Ciao Mauro,

Sounds more like a pure Linux/UNIX question than a yocto one :-)

As you most likely know on an embedded system which uses permanent storage (NAND flash or eMMC) that is subject to wear it is important to completely turn off swap.

At runtime if the system is up and running then you should issue the "swapoff -a" command.

But the proper fix is to remove any entry from your /etc/fstab designating a swap partition.

However I would be surprised if you had a swap partition configured in your system as most embedded systems don't have one.

Instead what I am thinking is that you are likely seeing a system slow-down due to your system's memory usage coming close to 100% of the available RAM, which in turn causes all calls to memory allocation functions to slow down (algorithms have to look harder to find available memory).

I would suggest that when the issue occurs that you first check the current system memory usage and have a look at which application is using the most memory and figure out if there is a way to optimize it and reduce the memory usage.

Kind regards, Laurent.

On Tue, Mar 9, 2021 at 10:03 AM Mauro Ziliani <mauro@...> wrote:
Hi all.
I'm working with Krogoth on a imx6dl board with 1GB of RAM.
I don't setup the swap space, but sometimes I see that kswap0 task starts, and the board slow down.

I'd like to change  the value of vm.swappiness to avoid swap requests

The default value  of vm.swappiness is 60.

There is a minimum value for vm.swappiness?

Best regards,
   MZ




--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429


Yocto Project Status WW10`21

Stephen Jolley
 

Current Dev Position: YP 3.3 Feature Freeze

Next Deadline: 1st March 2021 YP 3.3 M3 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3 M3 is due to build soon, we are now at feature freeze
  • M3 has not been built yet whilst the status of various pending patches was ascertained and several bugs investigated. A key runqueue bug in bitbake was finally identified and resolved, other seeming state manifest issues were traced to a bad patch. There is a performance regression which still needs debugging and fixing. We also need to get a better understanding of autobuilder load issues triggering intermittent failures although that may be deferred to M4.
  • It looks like the rust addition patches will be deferred to 3.4, as will the PR server changes.
  • Reproducibility is trending well for this release at 99.83% with a remaining intermittent issue in ltp due to be fixed imminently. Meson and ruby have intermittent issues, ovmf has a hardcoded path and much progress has been made in resolving the perf issues so hopefully that will be fixed soon. The only other issue is Go Language related.

https://www.yoctoproject.org/reproducible-build-results/

We had a mention in Reproducible Builds newsletter: https://reproducible-builds.org/reports/2021-02/

  • “Pending” state patch review is still needed, we have some really old stale ones which really need decisions to be made about their future. It would help a lot if recipe maintainers could review recipe patchsets and upstream them or remove them if they are no longer relevant. 
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.2.3 build date 2021/03/15
  • YP 3.2.3 release date 2021/03/26
  • YP 3.1.7 build date 2021/03/29
  • YP 3.1.7 release date 2021/04/09
  • YP 3.2.4 build date 2021/05/3
  • YP 3.2.4 release date 2021/05/14
  • YP 3.1.8 build date 2021/05/17
  • YP 3.1.8 release date 2021/05/28

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config

Joe MacDonald
 

[Re: [yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 14:53) Anatol Belski wrote:

Hi Joe,

thanks for the quick check. The patch applies fine to dunfell and
gatesgarth, master has the changed recipe version in the bb name. I was
about to rebase to master but pulling shows already did it. I was too slow
:) thanks for the quick fix.
No problem! I assumed you were working on a just-slightly-out-of-date
master branch and my work tree already had your patch half applied when
the 'git am' failed, so I just finished that part up.

I'll get to the other branches in a bit.

-Joe.


Regards

Anatol

On 3/9/2021 2:00 PM, Joe MacDonald wrote:
Hi Anatol,

I will confirm this against the other branches (dunfell and gatesgarth)
but your patch doesn't appear to be against the current master branch (and
it's unlikely one patch will apply to all branches). Can you send out
specific patches against the head of tree for each branch you care about,
please? Then I can get them merged for you.

Thanks,
-Joe.

[[yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 11:55) Anatol Belski wrote:

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
---
recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX
require ${BPN}.inc
+inherit python3targetconfig
+
LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
--
2.17.1


--
-Joe MacDonald.
:wq


Re: how often would one use "VAR_someoverride_append = ..."?

Quentin Schulz
 

Hi Leon,

On Tue, Mar 09, 2021 at 03:55:03PM +0100, Leon Woestenberg wrote:
Hello Robert, all,

On Tue, Mar 9, 2021 at 3:39 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
is there an actual practical usage of, say:

VAR_x86_append = "huh"
$grep -re '[A-Z_]\+_[a-z0-9]\+_append' poky/meta*
poky/meta/recipes-support/gmp/gmp_6.2.0.bb:EXTRA_OECONF_mipsarchr6_append
= " --disable-assembly"
poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb:IMAGE_CMD_ext4_append
() {
poky/meta/recipes-devtools/python/python3_3.8.2.bb:RDEPENDS_libpython3_append_libc-glibc
= " libgcc"
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux-gnueabi
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux-gnueabi
= " glibc-thread-db "

which is appending an override variable conditionally with another
override condition. (If I put this correctly.) Is this a valid use
case where += would not work?
Define what you mean by "where += would not work", I'm not sure to have
enough context to answer this question.

gdb/gdbserver above would be replaced with ${PN} in many/most recipes.
I am not sure how ${PN} "overrides" are handled but that would be a
valid use case for VAR_foo_append.

I think Robert and I were talking about foo being part of OVERRIDES
variable meaning we (I at least) oversaw this, thanks for the heads up.

Other appearances without an override condition:
$ grep -re '[A-Z_]\+_[a-z0-9]\+_append' meta-*
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_mipsarchn32_append
= " -Dvapi=false"
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_riscv32_append =
" -Dvapi=false"

Could these have been replaced with the following?

EXTRA_OEMESON_mipsarchn32 += "-Dvapi=false"
EXTRA_OEMESON_riscv32 += "-Dvapi=false"
Considering there are no EXTRA_OEMESON_mipsarchn32 in any of the classes
included and that EXTRA_OEMESON expects a space-separated list of
strings, it'd probably be ok.

However, this seems fishy... It is possible that this is a mistake and
one should have written EXTRA_OEMESON_append_mipsarchn32...

If EXTRA_OEMESON was intended to be overwritten completly for
mipsarchn32 to disable gobject-introspection, having
GI_DATA_ENABLED_mipsarchn32 = "False" and
EXTRA_OEMESON_append_mipsarchn32 = " -Dvapi=false" would be more
suitable.

If I were you, I would ask on the ML if it was intended and adding the
committer in Cc :)

Quentin


Re: how often would one use "VAR_someoverride_append = ..."?

Leon Woestenberg
 

Hello Robert, all,

On Tue, Mar 9, 2021 at 3:39 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
is there an actual practical usage of, say:

VAR_x86_append = "huh"
$grep -re '[A-Z_]\+_[a-z0-9]\+_append' poky/meta*
poky/meta/recipes-support/gmp/gmp_6.2.0.bb:EXTRA_OECONF_mipsarchr6_append
= " --disable-assembly"
poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb:IMAGE_CMD_ext4_append
() {
poky/meta/recipes-devtools/python/python3_3.8.2.bb:RDEPENDS_libpython3_append_libc-glibc
= " libgcc"
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux-gnueabi
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux-gnueabi
= " glibc-thread-db "

which is appending an override variable conditionally with another
override condition. (If I put this correctly.) Is this a valid use
case where += would not work?

Other appearances without an override condition:
$ grep -re '[A-Z_]\+_[a-z0-9]\+_append' meta-*
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_mipsarchn32_append
= " -Dvapi=false"
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_riscv32_append =
" -Dvapi=false"

Could these have been replaced with the following?

EXTRA_OEMESON_mipsarchn32 += "-Dvapi=false"
EXTRA_OEMESON_riscv32 += "-Dvapi=false"

Seems like a good test case indeed.

Regards,

Leon.


Re: how often would one use "VAR_someoverride_append = ..."?

Robert P. J. Day
 

On Tue, 9 Mar 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote:

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.
Yes, in 99% of the cases, you want VAR_append_foo and not
VAR_foo_append.

VAR_foo_append makes sense when you want to append to VAR_foo which
is a way to override completely VAR for builds matching the foo
override. This happens in kernel-yocto recipes where branches and
defconfigs are different per machine for example.

The sneaky thing about VAR_foo_append is that it creates VAR_foo
even if it didn't exist beforehand, meaning you though you
*appended* something to VAR while you actually replaced VAR entirely
with what VAR_foo_append is set too.
i remember testing this a few years back, and making sure i
appreciated the subtleties. i might take a shot at rewriting that
section, since i think it has potential for confusion. mostly, warning
the reader that the first form is almost always what they want.

rday


Re: how often would one use "VAR_someoverride_append = ..."?

Quentin Schulz
 

Hi Robert,

On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote:

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.
Yes, in 99% of the cases, you want VAR_append_foo and not VAR_foo_append.

VAR_foo_append makes sense when you want to append to VAR_foo which is a
way to override completely VAR for builds matching the foo override.
This happens in kernel-yocto recipes where branches and defconfigs are
different per machine for example.

The sneaky thing about VAR_foo_append is that it creates VAR_foo even if
it didn't exist beforehand, meaning you though you *appended* something
to VAR while you actually replaced VAR entirely with what VAR_foo_append
is set too.

Quentin

2201 - 2220 of 54812