|
Re: Mising init and systemd binary files
On Sat, 30 Nov 2019, at 11:28, JH wrote:
Hi,Are you using an existing image recipe or writing your own? If it's your own, do you have packagegroup-core-boot included? Thanks, -- Paul Barker
|
|
|
|
|
|
Mising init and systemd binary files
JH
Hi,
I built a Yocto image, but could not find /init, usually it should be a symbolic link in /init->/sbin/init->/lib/systemd/systemd, In /lib/systemd directory, it only contains a subdirectory system, all other systemd binaries are missing, many system commands in /sbin are also missing. What could I get wrong here to miss out all systemd files? Thank you. Kind regards, - jh
|
|
|
|
|
|
Re: How does metadata include in an image recipe work?
Morne
but when I run bitbake ex-image2, it only built ex-image2 image, it did not built images defined in ex-image1.bb.See this previous answer on the mailing list to a similar question: https://www.yoctoproject.org/pipermail/yocto/2018-August/042220.html - Morné
|
|
|
|
|
|
Add package to rootfs
JH
Hi,
I built a Yocto image in a file app-image.rootfs.tar.gz, I also built a kernel initramfs to bundle the rootfs, but that kernel rootfs is different to my app-image.rootfs.tar.gz, how to define IMAGE_ROOTFS to have my kernel rootfs point to the same rootfs packaged to app-image.rootfs.tar.gz? Thank you. Kind regards, - jh
|
|
|
|
|
|
How does metadata include in an image recipe work?
JH
Hi,
I have two images recipes, one is included in another image recipe: $ ls recipes-core/images ex-image1.bb ex-image2.bb $ cat recipes-core/images/ex-image2.bb include ex-image1.bb ...... My understanding that the metadata "include" is to include all image files defined in the included recipe as well, but when I run bitbake ex-image2, it only built ex-image2 image, it did not built images defined in ex-image1.bb. What could I be missing here? How could I build an image to include all image files included in another image.bb? Thank you. Kind regards, - jh
|
|
|
|
|
|
[matchbox-wm][PATCH] keys: Avoid freeing Wm_config member pointer in keys_load_config().
Simon Haggett
If the Wm_config instance contains a non-NULL pointer in its kbd_conf_file
member, then (in a build that does not use gconf) keys_load_config() will assign that pointer to a local conf_path variable. However, keys_load_config() later calls free() on this conf_path variable (since it may instead have been assigned a malloc'd buffer). This can therefore leave Wm_config::kbd_conf_file as a dangling pointer. Furthermore, if the user has specified the -kbdconfig argument when starting matchbox-window-manager then this pointer comes from argv and so the call to free() can lead to a segmentation fault. This patch fixes the issue by using strdup() to make a copy of the string pointed to by the Wm_config::kbd_conf_file member pointer. This matches the approach used when conf_path is required to take the value of a string literal, and ensures that free() can safely be called on conf_path. Signed-off-by: Simon Haggett <simon.haggett@gmail.com> --- src/keys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/keys.c b/src/keys.c index bc83bd4..ca77f81 100644 --- a/src/keys.c +++ b/src/keys.c @@ -326,7 +326,7 @@ keys_load_config(Wm *w) }; if (w->config->kbd_conf_file != NULL) - conf_path = w->config->kbd_conf_file; + conf_path = strdup(w->config->kbd_conf_file); if (conf_path == NULL && getenv("HOME")) { -- 2.17.1
|
|
|
|
|
|
Copy initramfs to rootfs
Sinisa <sgujic@...>
Hello everyone,
I started to build kernel with initramfs, and so far all that works great. I got my new shiny zImage-initramfs--4.1.14..xxx.bin. I can boot it over tftp, its does exactly what i want. Problem im facing is, how do i put this new zImage instead of originally built zImage in final rootfs archive (tar.gz). To clarify, upon a "bitbake create-my-fancy-image" i got in tmp/deploy/images two zImage files, one without initramfs and one with initramfs. When i inspect my rootfs.tar.gz /boot folder, i have zImage inisde (symlink and DTB also). I would like to replace somehow this zImage with initramfs version. How do i do that? Documentations talks only about this IMAGE_BUNDLE that is going to merge kernel with initramfs, but i cant find any obvious way to get this into rootfs, to replace somehow original zImage. The best idea i have so far (that does not work) is to do something like this: initramfs_postprocess() { # NOTE: pseudo code rm ${IMAGE_ROOTFS}/boot/zImage-custom* unlink ${IMAGE_ROOTFS}/boot/zImage # Im not sure how do i reference file from tmp/deploy/images, which is my question number 2 cp zImage-initramfs-* to ${WORKDIR}/boot/zImage } ROOTFS_POSTPROCESS_COMMAND += "initramfs_postprocess; " This above looks very dirty to me, but its best "idea" i have atm. So, in my local.conf i have: INITRAMFS_IMAGE_BUNDLE = "1" # means fuse kernel + initramfs And in my main image recipe i have: INITRAMFS_IMAGE = "initramfs-custom" #name of the recipe that provides some custom /init INITRAMFS_FSTYPES = "cpio.gz" # make a compressed cpio out of initramfs One thing to note, im trying to avoid doing this with wks and creating a special /boot partition. This is not something im really targeting, i know its possible, but i want to have my kernel inside rootfs.tar.gz in /boot from single image recipe due the various reasons. Any suggestion is much appreciated. Regards, Sinisa
|
|
|
|
|
|
Re: [meta-mingw][PATCH] gettext: adapt for version 0.20
Alexander Kanavin
On Fri, 29 Nov 2019 at 16:24, Joshua Watt <jpewhacker@...> wrote: On Thu, Nov 28, 2019 at 11:47 AM Alexander Kanavin It probably will, yes (I didn't test, but it drops a patch that's apparently needed in 0.19). Alex >
|
|
|
|
|
|
Re: [patchtest][PATCH 1/2] patchtest: Fix printing of exception tracebacks
On Fri, 15 Nov 2019, at 13:23, Paul Barker wrote:
The addError() handler is called outside of an actual exception handlerPing on this and the following patch. -- Paul Barker
|
|
|
|
|
|
Re: [patchtest-oe][PATCH] test_patch_upstream_status: Be explicit about case sensitivity
On Fri, 15 Nov 2019, at 13:09, Paul Barker wrote:
The case sensitivity of the checks for the "Upstream-Status" labelPing. -- Paul Barker
|
|
|
|
|
|
Re: [meta-mingw][PATCH] gettext: adapt for version 0.20
Joshua Watt
On Thu, Nov 28, 2019 at 11:47 AM Alexander Kanavin
<alex.kanavin@gmail.com> wrote: I've applied this to master-next, we can pull up master once the oe-core patch lands. I'm assuming this will break the current master AB builds if it's applied to master without the oe-core patch?
|
|
|
|
|
|
Re: Private: Re: [yocto] source.list for apt tool in yocto image for raspberry pi
#yocto
#raspberrypi
#debian
#apt
Josef Holzmayr <holzmayr@...>
On Fri, Nov 29, 2019 at 04:29:59AM -0800, keyurthumar0402@gmail.com wrote:
On Fri, Nov 29, 2019 at 04:23 AM, Josef Holzmayr wrote:You have to write recipes, then. Please see: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipeHey thank you for the reply. (And keep the threads on-list please.) Greetz -- ——————————————— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——————————————— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _____________________________________________________________ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
|
|
|
|
|
|
Re: source.list for apt tool in yocto image for raspberry pi
#yocto
#raspberrypi
#debian
#apt
Josef Holzmayr <holzmayr@...>
On Fri, Nov 29, 2019 at 03:56:41AM -0800, keyurthumar0402@gmail.com wrote:
There is a lot of things confused in here, it seems. I Have built yocto image for raspberry pi.Ok. Congratulations! It is debian based and...You mean, you set packege PACKAGE_CLASSES ?= "package_deb"? ...apt is already installed....which in the end is juut a binary. What should i write in source.list ? As I don' t have my personal repository please suggest some standard repository.There is none. The standard practise is to build the image with all the things you need, and not use runtime package management. If you want to use it like a debian, and think it should behave like a debian, then you probably should just run debian. Yocto builds a custom distribution, therefore no "official" packages exist. Greetz. -- ——————————————— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——————————————— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _____________________________________________________________ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548
|
|
|
|
|
|
source.list for apt tool in yocto image for raspberry pi
#yocto
#raspberrypi
#debian
#apt
keyurthumar0402@...
|
|
|
|
|
|
Re: Private: Re: [yocto] Which layer is best for tpm2 stack
Maciej Pijanowski
On 29.11.2019 11:01, Diego Santa Cruz
via Lists.Yoctoproject.Org wrote:
I'm currently using meta-tpm from meta-security for tpm2-tools. My reasoning was that this one will likely be the one to go in the long run since it's hosted on the poky git (?).
-- Maciej Pijanowski Embedded Systems Engineer GPG: F1401D2E1CCB19EF https://3mdeb.com | @3mdeb_com
|
|
|
|
|
|
Re: Private: Re: [yocto] Which layer is best for tpm2 stack
Diego Santa Cruz
Dear all,
I got the feedback below by private email (was meant to be sent to the m-l), so I think I’ll go with meta-tmp2 from meta-secure-core for now.
But I may switch to meta-tpm from meta-security in the future as it seems to have more tpm2 related recipes (I’m on thud for now and the tpm2-tools in thud branch of meta-security is too old).
Any other feedback from the community?
Thanks,
Diego
-- spinetix.com
From: Dan O'Donovan via Lists.Yoctoproject.Org <dan=emutex.com@...>
Sent: 28 November 2019 12:00 To: Diego Santa Cruz <Diego.SantaCruz@...> Subject: Private: Re: [yocto] Which layer is best for tpm2 stack
On Wed, Nov 27, 2019 at 02:56 PM, Diego Santa Cruz wrote:
I've personally used the meta-tpm2 layer in meta-secure-core repo with good success on both Intel and ARM platforms with Infineon TPM chips. In particular, I used the cryptfs-tpm2 and secure-core initramfs recipes from that layer for managing
root fs encryption. IIRC, this layer seemed to offer the best support for what we needed regarding TPM2 on Yocto 'Sumo' at the time.
|
|
|
|
|
|
[meta-mingw][PATCH] gettext: adapt for version 0.20
Alexander Kanavin
Drop backported patch (new gettext includes the updates).
Drop version from the .bbappend (hopefully no version-specific tweaks will be needed going forward). Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> --- .../fix-gl_cv_prog_as_underscore-test.patch | 67 ------------------- ...ext_0.19.%.bbappend => gettext_%.bbappend} | 1 - 2 files changed, 68 deletions(-) delete mode 100644 recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch rename recipes-core/gettext/{gettext_0.19.%.bbappend => gettext_%.bbappend} (87%) diff --git a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch b/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch deleted file mode 100644 index 636789f..0000000 --- a/recipes-core/gettext/gettext/fix-gl_cv_prog_as_underscore-test.patch +++ /dev/null @@ -1,67 +0,0 @@ -Backport gnulib fix for mingw into gettext's included version of gnulib - -http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=68b6adebef05670a312fb92b05e7bd089d2ed43a - -Upstream-Status: Backport -Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> - ---- a/gettext-runtime/gnulib-m4/asm-underscore.m4 -+++ b/gettext-runtime/gnulib-m4/asm-underscore.m4 -@@ -27,11 +27,11 @@ - #endif - int foo(void) { return 0; } - EOF - # Look for the assembly language name in the .s file. - AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1 -- if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then -+ if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then - gl_cv_prog_as_underscore=yes - else - gl_cv_prog_as_underscore=no - fi - rm -f conftest* ---- a/gettext-runtime/configure -+++ b/gettext-runtime/configure -@@ -24601,11 +24601,11 @@ - { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5 - (eval $ac_try) 2>&5 - ac_status=$? - $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5 - test $ac_status = 0; }; } >/dev/null 2>&1 -- if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then -+ if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then - gl_cv_prog_as_underscore=yes - else - gl_cv_prog_as_underscore=no - fi - rm -f conftest* ---- a/gettext-tools/gnulib-m4/asm-underscore.m4 -+++ b/gettext-tools/gnulib-m4/asm-underscore.m4 -@@ -27,11 +27,11 @@ - #endif - int foo(void) { return 0; } - EOF - # Look for the assembly language name in the .s file. - AC_TRY_COMMAND(${CC-cc} $CFLAGS $CPPFLAGS $gl_c_asm_opt conftest.c) >/dev/null 2>&1 -- if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then -+ if LC_ALL=C grep -E '(^|[[^a-zA-Z0-9_]])_foo([[^a-zA-Z0-9_]]|$)' conftest.$gl_asmext >/dev/null; then - gl_cv_prog_as_underscore=yes - else - gl_cv_prog_as_underscore=no - fi - rm -f conftest* ---- a/gettext-tools/configure -+++ b/gettext-tools/configure -@@ -32284,11 +32284,11 @@ - { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5 - (eval $ac_try) 2>&5 - ac_status=$? - $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5 - test $ac_status = 0; }; } >/dev/null 2>&1 -- if LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext >/dev/null; then -+ if LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext >/dev/null; then - gl_cv_prog_as_underscore=yes - else - gl_cv_prog_as_underscore=no - fi - rm -f conftest* diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend b/recipes-core/gettext/gettext_%.bbappend similarity index 87% rename from recipes-core/gettext/gettext_0.19.%.bbappend rename to recipes-core/gettext/gettext_%.bbappend index 21749f3..d518698 100644 --- a/recipes-core/gettext/gettext_0.19.%.bbappend +++ b/recipes-core/gettext/gettext_%.bbappend @@ -2,7 +2,6 @@ EXTRA_OECONF_append_mingw32 = " --enable-static" FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:" SRC_URI_append_mingw32 = " \ - file://fix-gl_cv_prog_as_underscore-test.patch \ " FILES_libgettextlib_mingw32 = "${bindir}/libgettextlib-*.dll" -- 2.17.1
|
|
|
|
|
|
Re: Architecture of .wic approach; image of images
Leon Woestenberg
On Thu, Nov 28, 2019 at 10:01 AM Josef Holzmayr <holzmayr@...> wrote: On Thu, Nov 28, 2019 at 09:37:12AM +0100, Leon Woestenberg wrote: My finding is: ...only if *artifacts* (also) includes a rootfs. The image class dependency on rootfs seems very hardcoded. I cannot create a recipe that works without *creating* a rootfs. (even though I have no rootfs other than the initramfs image which is already there, as an *artifact*). inherit image IMAGE_FSTYPES = "wic" DEPENDS += "my-initramfs" IMAGE_FEATURES = "" IMAGE_INSTALL = "" # This image does not generate its own root filesystem # I have tried to exclude it, but it's hardcoded even in buildhistory. #do_rootfs[noexec] = "1" #do_image[noexec] = "1" #do_image_wic[noexec] = "1" #do_rootfs_wicenv[noexec] = "1" WKS_FILE = "my-disk-image.wks" my-disk-image.wks: part /boot --source bootimg-efi --sourceparams="loader=grub-efi,initrd=my-initramfs.cpio.gz" --ondisk sda --label msdos --active --align 1024 --use-uuid bootloader --ptable gpt --timeout=1
|
|
|
|
|
|
Re: Yocto Image Build for NXP i.MX8M
Aj Cit
Hello, I'm getting the following error when I have tried to simulate the image on QEMU adminuser@verathon:~/poky/build$ runqemu qemux86 runqemu - INFO - Running MACHINE=qemux86 bitbake -e... runqemu - ERROR - /home/adminuser/poky/build/tmp/deploy/images/qemux86 not a directory valid DEPLOY_DIR_IMAGE ls: cannot access '/home/adminuser/poky/build/tmp/deploy/images/qemux86/*.qemuboot.conf': No such file or directory runqemu - ERROR - Command 'ls -t /home/adminuser/poky/build/tmp/deploy/images/qemux86/*.qemuboot.conf' returned non-zero exit status 2. runqemu - INFO - Cleaning up tnQ
On Thu, Nov 28, 2019 at 5:33 PM Aj Cit via Lists.Yoctoproject.Org <aj.ci.01.239=gmail.com@...> wrote:
|
|
|
|
|
|
Re: Architecture of .wic approach; image of images
Leon Woestenberg
On Thu, Nov 28, 2019 at 1:52 PM Josef Holzmayr
<holzmayr@rsi-elektrotechnik.de> wrote: Yes, up to there everything is clean and nice. And I understand I can build multiple images. I have used this feature since 2006. My point is, that we do not support images of images correctly. Or, I do not understand how it works. If I have an initramfs image, my next step is to build a disk image that has the initramfs.cpio.gz, but without generating a new rootfs. How would I do that?
|
|
|
|