On 7/15/20 7:36 AM, Robert Varga wrote:

Thank you for instructions...
build SDK for arm64. e.g. MACHINE=qemuarm64 bitbake -cpopulate_sdk
core-image-sato
After long attempts I finally managed to create an SDK with qemuarm64. However, I did not use the core-minimal-sato as suggested, but used the same setup as in my-image.bb (which is based on the core-image-full-cmdline).
With this new SDK I then did the same experiment and compiled the application, and it worked! There were no linker error messages.
Now the question for me is, why did it compile with qemuarm64, but not with my settings?
Is there anything else I can do to isolate the issue?
Thanks for your support so far.

Can you check if your glibc is compiled with --enable-static-pie ?
search for GLIBCPIE and its value, if its set to --enable-static-pie then disable it for arm with GLIBCPIE_arm = ""

and retry

--
Rob

Hi,

From meta-dpdk.git, the latest dufell branch is using dpdk 19.11.2.
Is there a plan to support dpdk 20.0x? 
(and maybe using meason/ninja to build?)

Rick

From the source config file:

ExecStart=@SBINDIR@/sshd -D $OPTIONS

From your reply:

But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.

If you run the command: /usr/sbin/sshd -D -f /etc/ssh/sshd_config, I
bet it'll fail again!

So, I have no idea what -D option does mean (lazy to investigate),
seems that this was the main cause of the problem:
https://unix.stackexchange.com/questions/390224/openssh-server-start-failed-with-result-timeout

Please, read this link carefully.

Best Regards,
Zoran
_______

On Thu, Jul 16, 2020 at 5:53 PM <srijan.nandi@...> wrote:

Hello Zoran,

I started the service and then ran journalctl -u sshd.service -r -n 10

This is what I see:

sshd.service Failed with result 'timeout'
sshd.service: start operation timed out. Terminating.

But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.

Thanks,
-=Srijan Nandi

--
Thanks & Regards 
Exaleap
Babu p

Hello Zoran,

I started the service and then ran journalctl -u sshd.service -r -n 10

This is what I see:

sshd.service Failed with result 'timeout'
sshd.service: start operation timed out. Terminating.

But if I run the /usr/sbin/sshd -f /etc/ssh/sshd_config, it starts fine.

Thanks,
-=Srijan Nandi

On my BBB board (as test vehicle), the following is true:

root@arm:~# uname -a
Linux arm 5.7.6 #1 SMP Tue Jun 30 16:46:05 CEST 2020 armv7l GNU/Linux
root@arm:~# lshw -short
H/W path Device Class Description
========================================
system TI AM335x BeagleBone Black
/0 bus Motherboard
/0/0 processor cpu
/0/1 processor idle-states
/0/2 memory 491MiB System memory
/1 eth0 network Ethernet interface
root@arm:~# which systemctl
/bin/systemctl
root@arm:~# systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
Active: active (running) since Thu 2020-07-16 12:21:59 UTC; 2h 33min ago
Docs: man:sshd(8)
man:sshd_config(5)
Process: 435 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 765 (sshd)
Memory: 2.1M
CGroup: /system.slice/ssh.service
└─765 /usr/sbin/sshd -D

Jul 16 12:00:13 arm systemd[1]: Starting OpenBSD Secure Shell server...
Jul 16 12:21:59 arm sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 16 12:21:59 arm sshd[765]: Server listening on :: port 22.
Jul 16 12:21:59 arm systemd[1]: Started OpenBSD Secure Shell server.
root@arm:~#

Although I am not running YOCTO there, you can see that I have systemd
present, and that my sshd server is running.

You should give us more info using: $ journalctl -u sshd.service -r -n 1

Zoran
_______

In Yocto Warrior, it appears that the default scheduler configuration is SCHED_NORMAL. We are trying to do some time-critical I/O, and it seems like we may be missing some data. I'd like to increase the thread priority for our data acquisition, but am not sure how to do so.
Is it possible to reconfigure the kernel to use SCHED_FIFO or some other "real-time" scheduler? If so, how?
And what are the risks of changing the scheduler configuration?

Scott D. Whitney

Hello Everyone,

I have installed mongodb on zeus. It seems the mogod.service and the mongod.conf files are missing. Can someone tell me where I can find these or maybe point me to some documentation where I can make these files using .bbappend. 

Thanks,
-=Srijan Nandi

This is what I did. I ran the following:

bitbake <image> -e |grep -v ^# |grep "^DISTRO_FEATURES=\|^IMAGE_FEATURES="

Found out the DISTRO_FEATURES and IMAGE_FEATURES. Thne used DISTRO_FEATURES_remove in the local.conf to remove the features that I do not need. Hope this helps.

-=Srijan Nandi

On 7/15/20 6:38 PM, Scott Murray wrote:

On Wed, 15 Jul 2020, Yi Zhao wrote:

On 7/15/20 12:19 AM, Scott Murray wrote:

On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
    If we still keep two versions of refpolicy, it is difficult to maintain
    two huge local patchsets. So drop this version and only keep the git
    version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.

[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd.  That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration.  My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"

Ah, poky is missing "pam", I somehow missed that when I checked
previously.  I can get logged in when I add it and rebuild.  It likely
would make sense to use the check_features class in e.g.
core-image-selinux to catch this.  Would you be okay with a patch that
does so?

Thanks. It makes sense. I can send a patch later or you can also do it.

If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda"
ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.

Having spurious denials seems like it would make using them for detecting
actual bad behavior harder, I'll likely start looking at the policy to
see if some of this can be fixed.

You can install auditd into the rootfs and startup the daemon to let the denials messages write to audit.log rather than print to the console.

//Yi

For this issue, there is a discussion in http://oss.tresys.com/pipermail/refpolicy/2017-September/009865.html

Actually I saw lots of map denials on /etc/passwd or /etc/group for various commands. I'm not sure if we should allow them all via files_map_etc_files(domain) or dontaudit them ...


//Yi

Thanks,

Scott

On 7/15/20 6:38 PM, Scott Murray wrote:

On Wed, 15 Jul 2020, Yi Zhao wrote:

On 7/15/20 12:19 AM, Scott Murray wrote:

On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain
two huge local patchsets. So drop this version and only keep the git
version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.

[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"

Ah, poky is missing "pam", I somehow missed that when I checked
previously. I can get logged in when I add it and rebuild. It likely
would make sense to use the check_features class in e.g.
core-image-selinux to catch this. Would you be okay with a patch that
does so?

Thanks. It makes sense. I can send a patch later or you can also do it.

If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda"
ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.

Having spurious denials seems like it would make using them for detecting
actual bad behavior harder, I'll likely start looking at the policy to
see if some of this can be fixed.

For this issue, there is a discussion in http://oss.tresys.com/pipermail/refpolicy/2017-September/009865.html

Actually I saw lots of map denials on /etc/passwd or /etc/group for various commands. I'm not sure if we should allow them all via files_map_etc_files(domain) or dontaudit them ...


//Yi

Thanks,

Scott

build SDK for arm64. e.g. MACHINE=qemuarm64 bitbake -cpopulate_sdk
core-image-sato

Rob

what is the simplest way to disable any use of sstate for a new build?
i see bitbake has a "--no-setscene" option that would appear to do that:

Do not run any setscene tasks. sstate will be ignored
and everything needed, built.

i've also seen some solutions that involve setting to empty strings
various variables like SSTATE_DIR, SSTATE_MIRRORS and so on. so if all
i want is to make sure everything is fetched, configured and built with
no use of sstate cache whatsoever, is "--no-setscene" the way to go?

rday

p.s. is this mentioned anywhere in the bitbake or a YP manual? seems
like this would be useful information for rigorous testing purposes.

On Wed, 15 Jul 2020, Yi Zhao wrote:

On 7/15/20 12:19 AM, Scott Murray wrote:

On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain
two huge local patchsets. So drop this version and only keep the git
version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.

[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"

Ah, poky is missing "pam", I somehow missed that when I checked
previously. I can get logged in when I add it and rebuild. It likely
would make sense to use the check_features class in e.g.
core-image-selinux to catch this. Would you be okay with a patch that
does so?

If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd"
dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda"
ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.

Having spurious denials seems like it would make using them for detecting
actual bad behavior harder, I'll likely start looking at the policy to
see if some of this can be fixed.

Thanks,

Scott

Howdy!

Am Mi., 15. Juli 2020 um 07:40 Uhr schrieb Soi, Sheng Leong
<sheng.leong.soi@...>:

The question is how to completely uninstall the pre-installed package in Yocto. Thanks

I found out that one of the packages in Yocto is unwanted, and wish to completely uninstall the package.

In contrast to a general purpose distribution where you have little
control over the default set, there is no need to install anything you
do not want. So the correct solution is: do not install that package.

Even moreso, removing it later might be impossible if the image
doesn't have package management enabled.

Greetz

On 7/15/20 12:19 AM, Scott Murray wrote:

On Tue, 7 Jul 2020, Yi Zhao wrote:

Here is the changelog for this is patchset:

* Drop refpolicy 2.20190201
If we still keep two versions of refpolicy, it is difficult to maintain two huge local patchsets. So drop this version and only keep the git version.

* Add patches to make systemd/sysvinit can work with all policy types.

Here are the results with this patcheset:

Machine: qemux86-64
Image: core-image-selinux
Init manager: sysvinit and systemd
Policy types: minimum, targeted, standard, mcs, mls
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1 enforcing=1" qemuparams="-m 1024"

1. All refpolicy type can be built without problems.

2. With parameter selinux=1 & enforcing=1
The qemu can boot up and login with all policy types.

[snip]

I suspect I'm really missing something, but I'm unable to successfully
make this work with poky + meta-selinux and its meta-openembedded
dependencies with either sysvinit or systemd; I see denials on boot and
cannot log in due to denials on reading /etc/passwd. That's also the
behavior I see without this update, so I'm wondering if I'm just doing
something significantly wrong with respect to configuration. My
local.conf additions for testing are just:

DISTRO_FEATURES_append = " selinux"

Please set the following DISTRO_FEATURES:

DISTRO_FEATURES_append = " acl xattr pam selinux"


If you see some AVC denials for {map} like below:

avc:  denied  { map } for  pid=249 comm="dbus-daemon" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=319 comm="avahi-daemon" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0
avc:  denied  { map } for  pid=379 comm="login" path="/etc/passwd" dev="vda" ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0

They are harmless.


//Yi

PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-targeted"

Any ideas?

Thanks,

Scott

Hi,

I found out that one of the packages in Yocto is unwanted, and wish to completely uninstall the package.

 

The question is how to completely uninstall the pre-installed package in Yocto. Thanks

FYI, I am new in building and compiling Yocto image.

 

 

ERROR: lib32-ccs-tools-1.8.4-r0 do_install: oe_runmake failed
ERROR: lib32-ccs-tools-1.8.4-r0 do_install: Execution of
'/build-armv8/tmp/work/armv7ahf-neon-mllib32-linux-gnueabi/lib32-ccs-tools/1.8.4-r0/temp/run.do_install.22368'
failed with exit code 1:
make: *** No rule to make target 'install'.  Stop.
WARNING: exit code 1 from a shell command.

Signed-off-by: Zheng Ruoqin <zhengrq.fnst@...>
---
 recipes-mac/ccs-tools/ccs-tools_1.8.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

merged.
Thanks

diff --git a/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb b/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
index 2e37c0b..79af6a5 100644
--- a/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
+++ b/recipes-mac/ccs-tools/ccs-tools_1.8.4.bb
@@ -13,7 +13,7 @@ SRC_URI = "http://osdn.dl.sourceforge.jp/tomoyo/49693/${BPN}-${PV}-${DS}.tar.gz"
 SRC_URI[md5sum] = "eeee8eb96a7680bfa9c8f6de55502c44"
 SRC_URI[sha256sum] = "c358b80a2ea77a9dda79dc2a056dae3acaf3a72fcb8481cfb1cd1f16746324b4"
 
-S = "${WORKDIR}/${PN}"
+S = "${WORKDIR}/${BPN}"
 
 inherit features_check
 

merged