[yocto] Different package versions between host SDK and target image

[Benjamin Crawford]

Hi,

I've been happily building images for the Renesas R-Car platform using the
Yocto project until recently. After clearing the sstate-cache and
rebuilding, I'm now suddenly encountering an issue where the version of
OpenCV being installed into the host SDK and the one being installed into
the target rootfs are different (OpenCV 3.3.x vs 3.4.x). Obviously, I now
can't develop applications as the binaries try to link to the wrong version
of the library. Can anyone tell what might have happened?

Kind regards,
Ben
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][PATCH] ref-manual: Correct the requirements for KERNEL_DEVICETREE

[Adrian Bunk]

Signed-off-by: Adrian Bunk 
---
 documentation/ref-manual/ref-variables.xml | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index 0080364e4f..33afaa5f45 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7580,15 +7580,9 @@
 However, providing just the .dtb
 file is preferred.
 
-In order to use this variable, you must have the include
-files in your kernel recipe:
-
- require recipes-kernel/linux/linux-dtb.inc
-
-or
-
- require recipes-kernel/linux/linux-yocto.inc
-
+In order to use this variable, the
+kernel-devicetree
+class must be inherited.
 
 
 
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to include the checksum of the (read-only) rootfs in an initramfs

[Patrick Doyle]

Is this a solved problem?  If so, what is the correct solution?

Here are some more details of the problem statement...
I want to verify that my read-only rootfs has not been modified when I
boot.  So I bundle the checksum of the the rootfs in /etc/rootfs.hash
in my initramfs using something a lot like:

do_install() {
install -d -m 0755 ${D}/etc
sha256sum -b ${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz
| cut -c-64 > ${D}/etc/rootfs.hash
install -d -m 0755 ${D}/init.d
install -m 0755 ${WORKDIR}/rootfs ${D}/init.d/90-rootfs
}

This is part of my "validate-rootfs.bb" recipe which is part of my
initramfs image.

The problem is, I need to ensure that
${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz is up to date
prior to the execution of my do_install() task.  So I added:

do_install[depends] += "base-image:do_image_complete"

to my recipe.  That has worked great... until I noticed that if I do:

$ bitbake base-image -ccleansstate
$ bitbake base-image

I generate a new rootfs, with new timestamps, which means that it will
have a new checksum.

The problem is, since none of the inputs to base-image.bb have
changed, none of the checksums have changed, so bitbake doesn't think
it needs to run my validate-rootfs.bb recipe, so I don't get a new
checksum embedded in my initramfs.

So, I feel like I am doing something wrong here.  I _could_ generate
rootfs.hash as part of generating
${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz, but I think I
would still have the problem of making validate-rootfs.bb notice that
a file in ${DEPLOY_DIR_IMAGE} has changed and therefore it should run
again.

Digging through the output of

$ bitbake-dumpsig -t validate-rootfs do_install

I noticed a line that read:

This task depends on the checksums of files: []

which looked promising.  Digging through the source code, I intuited
that I could add something like:

do_install[file-checksums] +=
"${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz:False"

to my recipe.  This appeared to work at first, but also appears to be
totally undocumented, and even as I write this, I am seeing situations
where the checksum doesn't get recalculated.

So I wonder if other folks have tried to solve this problem, and how
they have done so.

--wpd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH 1/2] linux-stable: rename to more generic bbappend

[Armin Kuster]

use wildcards

Signed-off-by: Armin Kuster 
---
 recipes-kernel/linux/{linux-stable_5.2.bbappend => linux-%_5.%.bbappend} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename recipes-kernel/linux/{linux-stable_5.2.bbappend => 
linux-%_5.%.bbappend} (100%)

diff --git a/recipes-kernel/linux/linux-stable_5.2.bbappend 
b/recipes-kernel/linux/linux-%_5.%.bbappend
similarity index 100%
rename from recipes-kernel/linux/linux-stable_5.2.bbappend
rename to recipes-kernel/linux/linux-%_5.%.bbappend
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH 2/2] apparmor: fix RDPENDS

[Armin Kuster]

apparmor-2.13.2-r0 do_package_qa: QA Issue: /usr/bin/aa-easyprof contained in 
package apparmor requires /usr/bin/python3, but no providers found in 
RDEPENDS_apparmor? [file-rdeps]

Signed-off-by: Armin Kuster 
---
 recipes-mac/AppArmor/apparmor_2.13.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.2.bb 
b/recipes-mac/AppArmor/apparmor_2.13.2.bb
index 4eaec00..1e9715d 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.2.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.2.bb
@@ -155,6 +155,6 @@ FILES_${PN} += "/lib/apparmor/ ${sysconfdir}/apparmor 
${PYTHON_SITEPACKAGES_DIR}
 FILES_mod-${PN} = "${libdir}/apache2/modules/*"
 
 RDEPENDS_${PN} += "bash lsb"
-RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','python','python3 
python3-modules','', d)}"
+RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','python','python3-core 
python3-modules','', d)}"
 RDEPENDS_${PN}_remove += 
"${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
 RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib bash"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] selinux-init: use systemd (re)labelling

[Mark Asselstine]

Boot loops were being seen when booting with selinux enabled, when the
init system in use is systemd. Once logs were retrieved from the
failing system the error was found to be

selinux-init.sh[284]: /sbin/restorecon: Could not set context for 
/sys/fs/cgroup/cpuacct:  Read-only file system
selinux-init.sh[284]: /sbin/restorecon: Could not set context for 
/sys/fs/cgroup/cpu:  Read-only file system

Systemd mounts /sys/fs/cgroup read-only and the (re)labelling code
used by selinux-init.sh is unable to handle this. On top of this the
system is basically presenting two methods of (re)labelling; using the
built in systemd approach via selinux-autorelabel.service *and* the
code we have in selinux-init.sh. This can get confusing especially
given that most online resources will speak to the systemd approach
using selinux-autorelabel.service and /.autorelabel.

These changes leave the current approach in place when sysvinit is the
init system used, but if systemd is being used we make use of it's
internal (re)labelling functionality. Overall the workflow remains the
same but we now avoid boot loops (systemd remounts /sys/fs/cgroup rw
during the (re)labelling procedure).

Signed-off-by: Mark Asselstine 
---
 .../selinux/selinux-init/selinux-init.sh   | 14 +-
 .../selinux/selinux-init/selinux-init.sh.sysvinit  | 14 ++
 recipes-security/selinux/selinux-init_0.1.bb   |  8 +---
 recipes-security/selinux/selinux-initsh.inc|  8 
 4 files changed, 28 insertions(+), 16 deletions(-)
 create mode 100644 
recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit

diff --git a/recipes-security/selinux/selinux-init/selinux-init.sh 
b/recipes-security/selinux/selinux-init/selinux-init.sh
index ead4f00..f93d231 100644
--- a/recipes-security/selinux/selinux-init/selinux-init.sh
+++ b/recipes-security/selinux/selinux-init/selinux-init.sh
@@ -33,18 +33,6 @@ check_rootfs()
/sbin/shutdown -f -h now
 }
 
-# If first booting, the security context type of init would be
-# "kernel_t", and the whole file system should be relabeled.
-if [ "`${SECON} -t --pid 1`" = "kernel_t" ]; then
-   echo "Checking SELinux security contexts:"
-   check_rootfs
-   echo " * First booting, filesystem will be relabeled..."
-   test -x /etc/init.d/auditd && /etc/init.d/auditd start
-   ${SETENFORCE} 0
-   ${RESTORECON} -RF /
-   ${RESTORECON} -F /
-   echo " * Relabel done, rebooting the system."
-   /sbin/reboot
-fi
+# sysvinit firstboot relabel placeholder HERE
 
 exit 0
diff --git a/recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit 
b/recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit
new file mode 100644
index 000..d4f3f71
--- /dev/null
+++ b/recipes-security/selinux/selinux-init/selinux-init.sh.sysvinit
@@ -0,0 +1,14 @@
+# Contents will be added to selinux-init.sh to support relabelling with 
sysvinit
+# If first booting, the security context type of init would be
+# "kernel_t", and the whole file system should be relabeled.
+if [ "`${SECON} -t --pid 1`" = "kernel_t" ]; then
+   echo "Checking SELinux security contexts:"
+   check_rootfs
+   echo " * First booting, filesystem will be relabeled..."
+   test -x /etc/init.d/auditd && /etc/init.d/auditd start
+   ${SETENFORCE} 0
+   ${RESTORECON} -RF /
+   ${RESTORECON} -F /
+   echo " * Relabel done, rebooting the system."
+   /sbin/reboot
+fi
diff --git a/recipes-security/selinux/selinux-init_0.1.bb 
b/recipes-security/selinux/selinux-init_0.1.bb
index 38b5900..78f571c 100644
--- a/recipes-security/selinux/selinux-init_0.1.bb
+++ b/recipes-security/selinux/selinux-init_0.1.bb
@@ -14,9 +14,11 @@ ${PN}_RDEPENDS = " \
 policycoreutils-setfiles \
 "
 
-SRC_URI = "file://${BPN}.sh \
-   file://${BPN}.service \
-   "
+SRC_URI = " \
+file://${BPN}.sh \
+file://${BPN}.sh.sysvinit \
+file://${BPN}.service \
+"
 
 INITSCRIPT_PARAMS = "start 01 S ."
 
diff --git a/recipes-security/selinux/selinux-initsh.inc 
b/recipes-security/selinux/selinux-initsh.inc
index bcdd449..8e31cda 100644
--- a/recipes-security/selinux/selinux-initsh.inc
+++ b/recipes-security/selinux/selinux-initsh.inc
@@ -17,9 +17,15 @@ inherit update-rc.d systemd
 
 SYSTEMD_SERVICE_${PN} = "${SELINUX_SCRIPT_SRC}.service"
 
+FILES_${PN} += "/.autorelabel"
+
 do_install () {
install -d ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh 
${D}${sysconfdir}/init.d/${SELINUX_SCRIPT_DST}
+   # Insert the relabelling code which is only needed with sysvinit
+   sed -i -e '/HERE/r ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh.sysvinit' \
+  -e '/.*HERE$/d' -e '/.*Contents.*sysvinit/d' \
+  ${D}${sysconfdir}/init.d/${SELINUX_SCRIPT_DST}
 
install -d ${D}${systemd_unitdir}/system
install -m 0644 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.service 
${D}${systemd_unitdir}/system
@@ -27,6 +33,8 @@ do

Re: [yocto] [yocto-docs][PATCH] ref-manual: Correct the requirements for KERNEL_DEVICETREE

[Scott Rifenbark]

Adrian,

Thanks for the update to the KERNEL_DEVICETREE variable.  I have applied
this patch to the 2.8 version of the reference manual:
https://yoctoproject.org/docs/2.8/ref-manual/ref-manual.html#var-KERNEL_DEVICETREE
.

Scott

On Fri, Aug 23, 2019 at 8:06 AM Adrian Bunk  wrote:

> Signed-off-by: Adrian Bunk 
> ---
>  documentation/ref-manual/ref-variables.xml | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 0080364e4f..33afaa5f45 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -7580,15 +7580,9 @@
>  However, providing just the
> .dtb
>  file is preferred.
>  
> -In order to use this variable, you must have the
> include
> -files in your kernel recipe:
> -
> - require recipes-kernel/linux/linux-dtb.inc
> -
> -or
> -
> - require recipes-kernel/linux/linux-yocto.inc
> -
> +In order to use this variable, the
> + linkend='ref-classes-kernel-devicetree'>kernel-devicetree
> +class must be inherited.
>  
>  
>  
> --
> 2.17.1
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wic create - bad ownership of directories inside image

[Randy MacLeod]

On 8/22/19 11:23 AM, Behnke, Jochen wrote:

Hello Randy,

thanks for your reponse and sorry for my late reaction.

In order to test, if the problem can be reproduced reliably, I 
performed a clean rebuild as follows


$ source oe-init-build-env build-tca5-32
$ rm -rf tmp
$ rm -rf sstate-cache
$ bitbake core-image-minimal
$ wic create mkefidisk -e core-image-minmal

I then mounted the resulting image file 
"mkefidisk-201908221701-sda.direct" using a loopback device (losetup)
Inside the Image all directories have UID/GID 1000/1000, which 
corresponds to my host user.

Files however have UID/GID 0/0.


Hi Jochen,

I'm not able to reproduce the error, see below (1).

What version of oe-core/bitbake are you using?

I'm using the latest master branches:

oe-core: 64f9fd2a1e quilt: added less to RDEPENDS list
bitbake:  28b3f0d8  runqueue: Optimise build_taskdepdata slightly




So the answer to your question is "yes I can reproduce the behavior".

One sidenote
- I am using an appended core-image-minimal not the default




What is the bbappend? Is it publicly clonable? What happens if you drop 
that addition?


../Randy


(1)

I followed your steps above and mounted my image as follows:

$ fdisk -l mkefidisk-201908230902-sda.direct
Disk mkefidisk-201908230902-sda.direct: 94.4 MiB, 98956288 bytes, 193274 
sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1E5F9B4E-ED8A-4677-82CD-7B146807C145

Device  Start    End Sectors  Size Type
mkefidisk-201908230902-sda.direct1   2048  51433   49386 24.1M Microsoft 
basic data
mkefidisk-201908230902-sda.direct2  53248 103127   49880 24.4M Linux 
filesystem

mkefidisk-201908230902-sda.direct3 103128 193239   90112   44M Linux swap


# 53248*512 = 27262976

$ sudo mount -o loop,offset=27262976 ./mkefidisk-201908230902-sda.direct 
/mnt/loop


$ ls -l /mnt/loop/bin/busybox.nosuid
-rwxr-xr-x 1 root root 625296 Aug 23 11:45 /mnt/loop/bin/busybox.nosuid

$ ls -l /mnt/loop/usr | head -3
total 10
drwxr-xr-x 2 root root 3072 Aug 23 11:52 bin
drwxr-xr-x 2 root root 1024 Aug 23 11:29 games


../Randy


- In my other image I am using qt5 (v5.12)



Regards
Jochen

On 8/12/19 5:11 AM, Behnke, Jochen wrote:
> Hello,
>
> I am using poky 2.6.1 (thud) and create images using the wic utility.
>
> Recently I noticed that all directories contained in the created image
> are owned by UID 1000 and not by root. The files inside the image
> however are owned by root.
>
> The UID 1000 refers to my unprivileged user on the host system.
>
> Here is the command I use to create the image
>
> “wic create mkefidisk –e core-image-minimal”
>
> The images created by bitbake directly (.tar.bz2, .hddimg) are correct
> so this seems to be a wic related problem.
>
> Does anybody have a solution for this?

Hi Jochen,

No and I've never seen this particular extreme symptom.

There is a known, generally rare bug:
    Bug 12434 - pseudo: Incorrect UID/GID in packaged files
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but that usually shows up when building.

You could check you build logs for the generic stings from:

    glibc-locale-2.26: glibc-locale:
/glibc-binary-localedata-en-gb/usr/lib/locale/en_GB/LC_MEASUREMENT
    is owned by uid 3004, which is the same as the user running bitbake.
    This may be due to host contamination [host-user-contaminated]


Is your issue 100% reproducible?

../Randy


>
> Many thanks in advance, any hint is appreciated.
>
> Regards
>
> Jochen
>
> 
>
>
> __
> *SCHMIDT Technology GmbH*
> Feldbergstrasse 1
> 78112 St. Georgen/Germany
> Telefon +49 (0) 77 24 / 89 90
> Fax +49 (0) 77 24 / 89 91 01
> i...@schmidttechnology.de 
> http://www.schmidttechnology.de
>
> USt-Id Nr. DE 811725105 · Registergericht Freiburg HRB 600 755
> Geschaeftsfuehrung: Oliver Schmidt, Stephan Schmidt
>
> 
>
>
>


--
# Randy MacLeod
# Wind River Linux



--
# Randy MacLeod
# Wind River Linux

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto