Date   

[meta-rockchip][PATCH] Rock64: add machine

Yann Dirson
 

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

conf/machine/include/rk3328.inc | 25 +++++++++++++++++++
conf/machine/rock64.conf | 28 ++++++++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 1 +
3 files changed, 54 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk332=
8.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY =3D "rk3328"
+
+DEFAULTTUNE ?=3D "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?=3D "defconfig"
+KERNEL_CLASSES =3D "kernel-fitimage"
+KERNEL_IMAGETYPE =3D "fitImage"
+
+TFA_PLATFORM =3D "rk3328"
+TFA_BUILD_TARGET =3D "bl31"
+
+UBOOT_SUFFIX ?=3D "itb"
+UBOOT_ENTRYPOINT ?=3D "0x06000000"
+
+SERIAL_CONSOLES =3D "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?=3D "u-boot"
+SPL_BINARY ?=3D "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..88a8434
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,28 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES +=3D "usbhost serial"
+
+UBOOT_MACHINE =3D "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE =3D "rockchip/rk3328-rock64.dtb"
+
+RK_BOOT_DEVICE =3D "mmcblk0"
+WKS_FILE ?=3D "rock-pi-4.wks"
+IMAGE_FSTYPES +=3D "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?=3D " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?=3D "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG =3D "defconfig"
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..f453281 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,4 @@ COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 =3D "rock64"
--=20
2.30.2


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

What about the following:
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

To be enhanced/added with the following:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-hardknott/README.md

Best Regards,
Zee
_______

On Fri, May 28, 2021 at 3:02 PM Swapna Nannapaneni
<sayinswapna@...> wrote:

Typo. No leading space INIT_MANAGER = "sysvinit".

Thanks,
Priya.

On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:

you don't want the leading space.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday


precedence problem with custom xserver-xf86-config_0.1.bbappend recipe

Stefan Seefeld
 

Hello,

I'm trying to add a custom `xorg.conf` file to my yocto build, by defining a `recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend` recipe to my layer.

However, it seems like I always end up getting the (empty) `xorg.conf` file from `meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend`, even though poky's `meta-yocto-bsp` layer has lower priority (5) than my own (6).
I do get my own `xorg.conf` file if I remove (or rename) the meta-yocto-bsp recipe, so this really looks like a precedence problem.

Any idea what I may be missing ?

Thanks !

Stefan
-- 

      ...ich hab' noch einen Koffer in Berlin...


[meta-security][PATCH 5/5] packagegroup-core-security: drop python3-scapy

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 --
1 file changed, 2 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index cf9620f..e7b6d9b 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -37,7 +37,6 @@ RDEPENDS_packagegroup-security-utils = "\
pinentry \
python3-privacyidea \
python3-fail2ban \
- python3-scapy \
softhsm \
libest \
opendnssec \
@@ -89,7 +88,6 @@ RDEPENDS_packagegroup-meta-security-ptest-packages = "\
ptest-runner \
samhain-standalone-ptest \
libseccomp-ptest \
- python3-scapy-ptest \
suricata-ptest \
python3-fail2ban-ptest \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack-ptest", "",d)} \
--
2.24.3


[meta-security][PATCH 4/5] python3-scapy: drop , now in meta-python

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/scapy/files/run-ptest | 4 ---
recipes-security/scapy/python3-scapy_2.4.5.bb | 30 -------------------
2 files changed, 34 deletions(-)
delete mode 100644 recipes-security/scapy/files/run-ptest
delete mode 100644 recipes-security/scapy/python3-scapy_2.4.5.bb

diff --git a/recipes-security/scapy/files/run-ptest b/recipes-security/scapy/files/run-ptest
deleted file mode 100644
index 797d8ec..0000000
--- a/recipes-security/scapy/files/run-ptest
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-UTscapy3 -t regression.uts -f text -l -C \
- -o @PTEST_PATH@/scapy_ptest_$(date +%Y%m%d-%H%M%S).log \
- 2>&1 | sed -e 's/^passed None/PASS:/' -e 's/^failed None/FAIL:/'
diff --git a/recipes-security/scapy/python3-scapy_2.4.5.bb b/recipes-security/scapy/python3-scapy_2.4.5.bb
deleted file mode 100644
index 8f36520..0000000
--- a/recipes-security/scapy/python3-scapy_2.4.5.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "Network scanning and manipulation tool"
-DESCRIPTION = "Scapy is a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more. It can easily handle most classical tasks like scanning, tracerouting, probing, unit tests, attacks or network discovery (it can replace hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, tethereal, p0f, etc.). It also performs very well at a lot of other specific tasks that most other tools can't handle, like sending invalid frames, injecting your own 802.11 frames, combining technics (VLAN hopping+ARP cache poisoning, VOIP decoding on WEP encrypted channel, ...), etc."
-SECTION = "security"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-
-SRCREV = "32cd7eb0f620d9adf171c48d55514e8326a538d7"
-SRC_URI = "git://github.com/secdev/scapy.git \
- file://run-ptest"
-
-S = "${WORKDIR}/git"
-
-UPSTREAM_CHECK_COMMITS = "1"
-
-inherit setuptools3 ptest
-
-do_install_append() {
- mv ${D}${bindir}/scapy ${D}${bindir}/scapy3
- mv ${D}${bindir}/UTscapy ${D}${bindir}/UTscapy3
-}
-
-do_install_ptest() {
- install -m 0644 ${S}/test/regression.uts ${D}${PTEST_PATH}
- sed -i 's,@PTEST_PATH@,${PTEST_PATH},' ${D}${PTEST_PATH}/run-ptest
-}
-
-RDEPENDS_${PN} = "tcpdump ${PYTHON_PN}-compression ${PYTHON_PN}-cryptography ${PYTHON_PN}-netclient \
- ${PYTHON_PN}-netserver ${PYTHON_PN}-pydoc ${PYTHON_PN}-pkgutil ${PYTHON_PN}-shell \
- ${PYTHON_PN}-threading ${PYTHON_PN}-numbers ${PYTHON_PN}-pycrypto"
--
2.24.3


[meta-security][PATCH 3/5] initramfs-framework: fix YCL issue.

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../initrdscripts/initramfs-framework.inc | 16 ++++++++++++++++
.../initramfs-framework_1.0.bbappend | 17 +----------------
2 files changed, 17 insertions(+), 16 deletions(-)
create mode 100644 recipes-core/initrdscripts/initramfs-framework.inc

diff --git a/recipes-core/initrdscripts/initramfs-framework.inc b/recipes-core/initrdscripts/initramfs-framework.inc
new file mode 100644
index 0000000..dad9c96
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-framework.inc
@@ -0,0 +1,16 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI_append = "\
+ file://dmverity \
+"
+
+do_install_append() {
+ # dm-verity
+ install ${WORKDIR}/dmverity ${D}/init.d/80-dmverity
+}
+
+PACKAGES_append = " initramfs-module-dmverity"
+
+SUMMARY_initramfs-module-dmverity = "initramfs dm-verity rootfs support"
+RDEPENDS_initramfs-module-dmverity = "${PN}-base"
+FILES_initramfs-module-dmverity = "/init.d/80-dmverity"
diff --git a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
index dad9c96..dc74e01 100644
--- a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
+++ b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
@@ -1,16 +1 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI_append = "\
- file://dmverity \
-"
-
-do_install_append() {
- # dm-verity
- install ${WORKDIR}/dmverity ${D}/init.d/80-dmverity
-}
-
-PACKAGES_append = " initramfs-module-dmverity"
-
-SUMMARY_initramfs-module-dmverity = "initramfs dm-verity rootfs support"
-RDEPENDS_initramfs-module-dmverity = "${PN}-base"
-FILES_initramfs-module-dmverity = "/init.d/80-dmverity"
+require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity', 'initramfs-framework.inc', '', d)}
--
2.24.3


[meta-security][PATCH 2/5] linux-%_5.%.bbappend: drop recipe

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-kernel/linux/linux-%_5.%.bbappend | 4 ----
1 file changed, 4 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-%_5.%.bbappend

diff --git a/recipes-kernel/linux/linux-%_5.%.bbappend b/recipes-kernel/linux/linux-%_5.%.bbappend
deleted file mode 100644
index 6bc40cd..0000000
--- a/recipes-kernel/linux/linux-%_5.%.bbappend
+++ /dev/null
@@ -1,4 +0,0 @@
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "yama", " features/yama/yama.scc", "" ,d)}"
-KERNEL_FEATURES_append = " ${@bb.utils.contains("IMAGE_CLASSES", "dm-verity-img", " features/device-mapper/dm-verity.scc", "" ,d)}"
--
2.24.3


[meta-security][PATCH 1/5] busybox: drop as libsecomp is in core

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/busybox/busybox/head.cfg | 1 -
recipes-core/busybox/busybox_%.bbappend | 1 -
recipes-core/busybox/busybox_libsecomp.inc | 3 ---
3 files changed, 5 deletions(-)
delete mode 100644 recipes-core/busybox/busybox/head.cfg
delete mode 100644 recipes-core/busybox/busybox_%.bbappend
delete mode 100644 recipes-core/busybox/busybox_libsecomp.inc

diff --git a/recipes-core/busybox/busybox/head.cfg b/recipes-core/busybox/busybox/head.cfg
deleted file mode 100644
index 16017ea..0000000
--- a/recipes-core/busybox/busybox/head.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_FEATURE_FANCY_HEAD=y
diff --git a/recipes-core/busybox/busybox_%.bbappend b/recipes-core/busybox/busybox_%.bbappend
deleted file mode 100644
index 27a2482..0000000
--- a/recipes-core/busybox/busybox_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-require ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'busybox_libsecomp.inc', '', d)}
diff --git a/recipes-core/busybox/busybox_libsecomp.inc b/recipes-core/busybox/busybox_libsecomp.inc
deleted file mode 100644
index 4af22ce..0000000
--- a/recipes-core/busybox/busybox_libsecomp.inc
+++ /dev/null
@@ -1,3 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/busybox:"
-
-SRC_URI_append = " file://head.cfg"
--
2.24.3


Re: #yocto ASUS ROG STRIX Z390-I #yocto

Yocto
 

use meta-intel build for a core-i7 I also have an ASUS ROG board running yocto.

On 5/30/21 6:15 PM, a.elgammal2019@... wrote:
Hello,

I have a ROG STRIX Z390-I motherboard with an Intel® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any guides would be helpful. Thank you



#Tesla T4 Support #tesla

Abdelrahman El-Gammal <a.elgammal2019@...>
 

I am building a custom image for 

ASUS ROG STRIX Z390-I, with Tesla T4

I will build on meta-intel. But the problem is that I am also using Tesla T4 GPU, which requires CUDA toolkit to install. And CUDA requires a supported linux distribution. So, how to setup and use the T4 drivers?


#yocto ASUS ROG STRIX Z390-I #yocto

a.elgammal2019@...
 

Hello,

I have a ROG STRIX Z390-I motherboard with an Intel® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any guides would be helpful.
Thank you


Re: [poky][master][PATCH} VirGL: depends on virtual/gbm

Joel Winarske
 

It looks like a Mesa dependency is looming for NVIDIA:  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902

Thanks

On Fri, May 28, 2021 at 1:30 PM Alexander Kanavin <alex.kanavin@...> wrote:
Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.

The patch should be going to the oe-core list.

Alex

On Fri, 28 May 2021 at 21:16, Joel Winarske <joel.winarske@...> wrote:

This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2






Re: [poky][master][PATCH} VirGL: depends on virtual/gbm

Alexander Kanavin
 

Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.

The patch should be going to the oe-core list.

Alex


On Fri, 28 May 2021 at 21:16, Joel Winarske <joel.winarske@...> wrote:

This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2






[poky][master][PATCH} VirGL: depends on virtual/gbm

Joel Winarske
 


This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2



Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Typo. No leading space  INIT_MANAGER = "sysvinit".

Thanks,
Priya.


On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
> you don't want the leading space.

I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:
>
> On Fri, 28 May 2021, Zoran wrote:
>
> > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
> >
> > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
> > blank at the beginning)?
> >
> > Thank you,
> > Zee
>
>   you don't want the leading space.
>
> rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

you don't want the leading space.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Robert P. J. Day
 

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
_______

On Fri, May 28, 2021 at 1:47 PM Swapna Nannapaneni
<sayinswapna@...> wrote:

Thanks Robert and Raj!!

I am using Yocto 3.1 Dunfell release.

You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend and no longer see the warning.

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf but looks like generated rootfs has init file pointing to init -> ../lib/systemd/systemd

Priya.

On Thu, May 27, 2021 at 7:28 PM Khem Raj <raj.khem@...> wrote:



On 5/27/21 3:04 PM, sayinswapna@... wrote:
Hello Yocto team:

I just started with yocto and would like to know the process for
switching the init manager from systemd to sysvinit.

I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"

I see a warning when building my machine:

No recipe for target:
/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made
for older recipe, these things happen when you mix release branches for
different layers.


When I run this build on my target it still shows me systemd init manager...

Not sure if I am missing any options.
Could you please let me know if there are any pointers I can refer to?

Thanks,
Priya








Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Thanks Robert and Raj!!

I am using Yocto 3.1 Dunfell release.

You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend  and no longer see the warning. 

Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf but looks like generated rootfs has init file pointing to init -> ../lib/systemd/systemd

Priya.

On Thu, May 27, 2021 at 7:28 PM Khem Raj <raj.khem@...> wrote:


On 5/27/21 3:04 PM, sayinswapna@... wrote:
> Hello Yocto team:
>
> I just started with yocto and would like to know the process for
> switching the init manager from systemd to sysvinit.
>
> I tried this options in config file
> VIRTUAL-RUNTIME_init_manager = "busybox"
> PREFERRED_PROVIDER_udev = "sysvinit"
> PREFERRED_PROVIDER_udev-utils = "sysvinit"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> DEFAULT_DISTRO_FEATURES += " sysvinit"
>
> I see a warning when building my machine:
>
> No recipe for target:
> /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend

Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made
for older recipe, these things happen when you mix release branches for
different layers.

>
> When I run this build on my target it still shows me systemd init manager...
>
> Not sure if I am missing any options.
> Could you please let me know if there are any pointers I can refer to?
>
> Thanks,
> Priya
>
>
>
>
>
>


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

Why do I (always) point out the obvious?

And I do need... Geniuses are not meant to fix The World to understand them!?

Geniuses should understand The World (and act properly)!

Extras to geniality, do you, YOCTO primes, think?
_______

Robert... If I am correct, i'm I?

Should you include in docs some examples??? Yes, U should!
As for an example fix:
poky/meta/conf/distro/include/init-manager-*.con, NOT
conf/distro/include/init-manager-*.conf

(full path is more explicit, isn't it?)

And some local.conf examples/snippets (since all descriptions are here
and there very dry):

## Add systemd service
INIT_MANAGER = "systemd"
## DISTRO_FEATURES_append = " systemd"
## DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
## VIRTUAL-RUNTIME_init_manager = "systemd"
## VIRTUAL-RUNTIME_dev_manager = "systemd"
## VIRTUAL-RUNTIME_initscripts = ""

Where INIT_MANAGER = "systemd" replaces all commented commands below....

My two cent advice,
Zee
_______

On Fri, May 28, 2021 at 1:28 AM Khem Raj <raj.khem@...> wrote:



On 5/27/21 3:04 PM, sayinswapna@... wrote:
Hello Yocto team:

I just started with yocto and would like to know the process for
switching the init manager from systemd to sysvinit.

I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"

I see a warning when building my machine:

No recipe for target:
/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made
for older recipe, these things happen when you mix release branches for
different layers.


When I run this build on my target it still shows me systemd init manager...

Not sure if I am missing any options.
Could you please let me know if there are any pointers I can refer to?

Thanks,
Priya






4101 - 4120 of 57773