-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EXTRA_USERS_PARAMS usermod not work in yocto update syntax? #1
Comments
armcc
pushed a commit
that referenced
this issue
Jul 11, 2022
- curl-ptest is taking around 200 seconds to execute so added curl-ptest to PTESTS_SLOW - This patch is rework on an existing patch provided by Maxin B. John (maxin.john@intel.com) https://www.openembedded.org/pipermail/openembedded-core/2017-July/139176.html - Below is the run log of curl-ptest START: ptest-runner 2022-07-03T15:52 BEGIN: /usr/lib/curl/ptest ********* System characteristics ******** * curl 7.83.1 (x86_64-poky-linux-gnu) * libcurl/7.83.1 OpenSSL/3.0.3 zlib/1.2.12 libidn2/2.3.2 * Features: alt-svc AsynchDNS Debug HSTS HTTPS-proxy IDN Largefile libz NTLM SSL TLS-SRP UnixSockets * Disabled: headers-api * Host: qemux86-64 * System: Linux qemux86-64 5.15.44-yocto-standard #1 SMP PREEMPT Tue May 31 20:28:59 UTC 2022 x86_64 GNU/Linux * OS: linux * Servers: HTTP-unix * Env: * Seed: 238593 ***************************************** PASS: test 0001 (1 out of 1466, remaining: 25:07, took 1.029s, duration: 00:01) PASS: test 0002 (2 out of 1466, remaining: 13:21, took 0.065s, duration: 00:01) ... ... PASS: test 3019 (1460 out of 1466, remaining: 00:00, took 0.012s, duration: 03:16) PASS: test 3020 (1461 out of 1466, remaining: 00:00, took 0.011s, duration: 03:16) test 3025...The tool set in the test case for this: 'lib3025' does not exist TESTDONE: 1280 tests were considered during 197 seconds. TESTDONE: 783 tests out of PASS: 783 report: 100% DURATION: 202 END: /usr/lib/curl/ptest 2022-07-03T15:56 STOP: ptest-runner TOTAL: 1 FAIL: 0 - disable the curl tests that are expected to fail - remove the generated file configurehelp.pm from curl test beacuse it is causing reproducible build failure. this file is used by some curl tests to scan symbols from curl headers. we are anyway not installing curl headers and already have disabled those tests. [YOCTO #6707] (From OE-Core rev: a0ea00daace826129cdec8f714ca7b7c60e9dadf) Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Oct 20, 2022
Backport a patch to fix the following on powerpc64 ABIv2. root@qemuppc64:~# lttng create trace_session --live -U net://127.0.0.1 Spawning a session daemon lttng_kretprobes: loading out-of-tree module taints kernel. BUG: Unable to handle kernel data access on read at 0xfffffffffffffff8 Faulting instruction address: 0xc0000000001f6fd0 Oops: Kernel access of bad area, sig: 11 [#1] <snip> (From OE-Core rev: 4781fee6aea9512b7cb390b76e6f9f0a86a5bd11) Signed-off-by: He Zhe <zhe.he@windriver.com> Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 18, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 6c34772963cdafce45bce62cb28ead2dfdadc5cb) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 19, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 6c34772963cdafce45bce62cb28ead2dfdadc5cb) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 24, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 3bf203ec37a72a207c4cf7c73d532022cc148bfc) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 24, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 1cd439b22b2be83a6071a31d4dc12bdfd34529cb) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 25, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 3469af61b529b3ba1578ea5491bf80712c8fb1e3) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 26, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 3469af61b529b3ba1578ea5491bf80712c8fb1e3) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 27, 2023
* the last patch added in: https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=874b72fe259cd3a23f4613fccfe2e9cc3f79cd6a doesn't apply cleanly. * fixes: ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected: Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch patching file libavcodec/vp3.c Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines). (From OE-Core rev: 6060dec1fc9d215f6b2ff9d6571bac802ac6a09b) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 27, 2023
On master oe, build a qemuppc64 with systemd as default init, when we use nfs bootup, the kernel might panic due to missing symbol in dynamic libraries as below: hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.0-3/input0 /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by /usr/lib64/libkmod.so.2) Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1 Call Trace: [c000000007443ba0] [c0000000009538d0] dump_stack_lvl+0x74/0xa8 (unreliable) [c000000007443be0] [c000000000103524] panic+0x170/0x3cc [c000000007443c80] [c00000000010cf64] do_exit+0xb44/0xb50 [c000000007443d50] [c00000000010d040] do_group_exit+0x60/0xd0 [c000000007443d90] [c00000000010d0d4] sys_exit_group+0x24/0x30 [c000000007443db0] [c00000000002cfd4] system_call_exception+0x194/0x2f0 [c000000007443e10] [c00000000000c2cc] system_call_common+0xec/0x250 --- interrupt: c00 at 0x7fff9ed9e840 NIP: 00007fff9ed9e840 LR: 00007fff9ed7da20 CTR: 0000000000000000 REGS: c000000007443e80 TRAP: 0c00 Not tainted (5.15.78-yocto-standard) MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24022442 XER: 00000000 One or more of the libraries systemd depends on failed to load due to unresolved symbols/functions. This was intermittent - with a failure rate estimated between 5% and 30%. After checking the code, this issue happens on gcc 12, kirkstone is using gcc 11 works well, with both using the exact same v5.15.84 kernel commit. There is a kernel fix from upstream [1], they changed the rsize / wsize to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have its own linux-yocto kernel branch, so apply this change might cause regression with other platforms which share branch with qemuppc64. So, we added an extra option for nfs rootfs, and set the qemuppc64 default r/w size to 524288 to line up with the kernel fix[1]. Yocto did a similar thing in the distant past[2] - prior to boot-arg adjustments existing - by allowing a Kconfig to set the defaults on nfsboot, in order to work around hardware limitations. Reference: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf [2] https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base&id=a96cfd98add95 (From OE-Core rev: 14a81556ff1be326647e654424c8f1bf9d0db912) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Nov 14, 2023
Qemu introduced a commit "target/i386: Enable AVX cpuid bits when using TCG" since v7.2.0. It causes qemu-system-i386 hang with following error: traps: rndc-confgen[342] general protection fault ip:b7ef5545 sp:bfcc6e6c error:0 ------------[ cut here ]------------ Bad FPU state detected at __restore_fpregs_from_fpstate+0x2f/0x60, reinitializing FPU registers. WARNING: CPU: 7 PID: 353 at arch/x86/mm/extable.c:65 fixup_exception+0x29c/0x2d0 Modules linked in: cfg80211 8021q parport_pc parport sch_fq_codel openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 kvm irqbypass fuse configfs CPU: 7 PID: 353 Comm: in:imklog Not tainted 5.15.78-yocto-standard #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 EIP: fixup_exception+0x29c/0x2d0 Code: 05 ed da 89 df 01 68 b0 cb 5f df e8 4f e7 b6 00 0f 0b 58 e9 9d fe ff ff c6 05 ef da 89 df 01 50 68 f0 cb 5f df e8 35 e7 b6 00 <0f> 0b 5b 5e e9 0a ff ff ff ba 01 00 00 00 89 f0 e8 8a c1 b6 00 0f EAX: 00000060 EBX: df734b60 ECX: f5be9cd0 EDX: f5be9ccc ESI: c3485eec EDI: 0000000d EBP: c3485e64 ESP: c3485e4c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00000096 CR0: 80050033 CR2: b79fdde0 CR3: 03cbe000 CR4: 001506d0 Call Trace: ? __restore_fpregs_from_fpstate+0x2f/0x60 exc_general_protection+0x9a/0x390 ? exc_bounds+0x90/0x90 handle_exception+0x133/0x133 Upstream has been fixed this issue[1], so backport the patch to fix it. Ref: [1] https://gitlab.com/qemu-project/qemu/-/commit/48b60eb6c917646df9efa7ddb4c25929f358d647 (From OE-Core rev: 11370f237dcf140e05014f82200e07d5cff38bd3) Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Steve Sakoman <steve@sakoman.com>
armcc
pushed a commit
that referenced
this issue
Dec 26, 2023
…ctor Integrating the following commit(s) to linux-yocto/6.5: 1/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Sync core before enabling interrupts Date: Thu, 7 Dec 2023 20:49:24 +0100 text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are reenabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] 2/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place Date: Thu, 7 Dec 2023 20:49:26 +0100 apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set special as it optimizes the existing NOPs in place. Unfortunately this happens with interrupts enabled and does not provide any form of core synchronization. So an interrupt hitting in the middle of the update and using the affected code path will observe a half updated NOP and crash and burn. The following 3 NOP sequence was observed to expose this crash halfways reliably under QEMU 32bit: 0x90 0x90 0x90 which is replaced by the optimized 3 byte NOP: 0x8d 0x76 0x00 So an interrupt can observe: 1) 0x90 0x90 0x90 nop nop nop 2) 0x8d 0x90 0x90 undefined 3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi 4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously. Disable interrupts around this NOP optimization and invoke sync_core() before reenabling them. Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives") Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] (From OE-Core rev: 1c8d29ab6b02c5b783429db3b67583deb1637142) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 3, 2024
…ctor Integrating the following commit(s) to linux-yocto/6.6: 1/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Sync core before enabling interrupts Date: Thu, 7 Dec 2023 20:49:24 +0100 text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are reenabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] 2/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place Date: Thu, 7 Dec 2023 20:49:26 +0100 apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set special as it optimizes the existing NOPs in place. Unfortunately this happens with interrupts enabled and does not provide any form of core synchronization. So an interrupt hitting in the middle of the update and using the affected code path will observe a half updated NOP and crash and burn. The following 3 NOP sequence was observed to expose this crash halfways reliably under QEMU 32bit: 0x90 0x90 0x90 which is replaced by the optimized 3 byte NOP: 0x8d 0x76 0x00 So an interrupt can observe: 1) 0x90 0x90 0x90 nop nop nop 2) 0x8d 0x90 0x90 undefined 3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi 4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously. Disable interrupts around this NOP optimization and invoke sync_core() before reenabling them. Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives") Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] (From OE-Core rev: 533b092be41428400e30d6a38a5412011bc29d77) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 4, 2024
…ctor Integrating the following commit(s) to linux-yocto/6.5: 1/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Sync core before enabling interrupts Date: Thu, 7 Dec 2023 20:49:24 +0100 text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are reenabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] 2/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place Date: Thu, 7 Dec 2023 20:49:26 +0100 apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set special as it optimizes the existing NOPs in place. Unfortunately this happens with interrupts enabled and does not provide any form of core synchronization. So an interrupt hitting in the middle of the update and using the affected code path will observe a half updated NOP and crash and burn. The following 3 NOP sequence was observed to expose this crash halfways reliably under QEMU 32bit: 0x90 0x90 0x90 which is replaced by the optimized 3 byte NOP: 0x8d 0x76 0x00 So an interrupt can observe: 1) 0x90 0x90 0x90 nop nop nop 2) 0x8d 0x90 0x90 undefined 3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi 4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously. Disable interrupts around this NOP optimization and invoke sync_core() before reenabling them. Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives") Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] (From OE-Core rev: eaa14acddf8259bef87143956766e7d3cf01d6ff) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 1c8d29ab6b02c5b783429db3b67583deb1637142) Signed-off-by: Steve Sakoman <steve@sakoman.com>
armcc
pushed a commit
that referenced
this issue
Jan 4, 2024
…ctor Integrating the following commit(s) to linux-yocto/6.6: 1/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Sync core before enabling interrupts Date: Thu, 7 Dec 2023 20:49:24 +0100 text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are reenabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] 2/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place Date: Thu, 7 Dec 2023 20:49:26 +0100 apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set special as it optimizes the existing NOPs in place. Unfortunately this happens with interrupts enabled and does not provide any form of core synchronization. So an interrupt hitting in the middle of the update and using the affected code path will observe a half updated NOP and crash and burn. The following 3 NOP sequence was observed to expose this crash halfways reliably under QEMU 32bit: 0x90 0x90 0x90 which is replaced by the optimized 3 byte NOP: 0x8d 0x76 0x00 So an interrupt can observe: 1) 0x90 0x90 0x90 nop nop nop 2) 0x8d 0x90 0x90 undefined 3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi 4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously. Disable interrupts around this NOP optimization and invoke sync_core() before reenabling them. Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives") Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] (From OE-Core rev: 366dd2622f5aceb5a205145adc49f017fb14ebe9) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 5, 2024
…ctor Integrating the following commit(s) to linux-yocto/6.6: 1/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Sync core before enabling interrupts Date: Thu, 7 Dec 2023 20:49:24 +0100 text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are reenabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] 2/2 [ Author: Thomas Gleixner Email: tglx@linutronix.de Subject: x86/alternatives: Disable interrupts and sync when optimizing NOPs in place Date: Thu, 7 Dec 2023 20:49:26 +0100 apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set special as it optimizes the existing NOPs in place. Unfortunately this happens with interrupts enabled and does not provide any form of core synchronization. So an interrupt hitting in the middle of the update and using the affected code path will observe a half updated NOP and crash and burn. The following 3 NOP sequence was observed to expose this crash halfways reliably under QEMU 32bit: 0x90 0x90 0x90 which is replaced by the optimized 3 byte NOP: 0x8d 0x76 0x00 So an interrupt can observe: 1) 0x90 0x90 0x90 nop nop nop 2) 0x8d 0x90 0x90 undefined 3) 0x8d 0x76 0x90 lea -0x70(%esi),%esi 4) 0x8d 0x76 0x00 lea 0x0(%esi),%esi Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously. Disable interrupts around this NOP optimization and invoke sync_core() before reenabling them. Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives") Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> ] (From OE-Core rev: 6e1d5d1301ae5dbc7fa1a09da831e8e9bf03671c) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 23, 2024
[YOCTO #15162] when doing devtool modify, sources are extracted into a devtool temporary workdir. The main source is moved inside build/workspace/sources/${BPN}/ and local files are moved inside build/workspace/sources/${BPN}/oe-local-files. Secondary sources are currently not handled and are lost. Here is the output of devtool modify/build on bzip2 recipe: NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2 ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None) ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368 Log data follows: | DEBUG: Executing shell function do_install_ptest_base | NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest | sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \ | ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile | cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2 | cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory | WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/ 1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress' | WARNING: Backtrace (BB generated script): | #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189 | #2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158 | #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226 ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1' NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed. Summary: 1 task failed: <...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base externalsrc class modify SRC_URI to keep only: * 'file', 'npmsw' and 'crate' sources * url with type parameter matching 'kmeta' or 'git-dependency' So by forcing to add type='git-dependency' on secondary sources, we ensure that when building the recipe, the secondary sources can be unpacked into WORKDIR. This allows recipes containing several sources to be built under a devtool context, but it has some limitations: * user would not be able to generate patches for the secondary sources * type="git-dependency" is added for secondary sources even on non git sources, so we may want to rename this parameter (From OE-Core rev: 4534e271f89b40ffcf9adc6050b9d0b19a685a9b) Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 24, 2024
[YOCTO #15162] when doing devtool modify, sources are extracted into a devtool temporary workdir. The main source is moved inside build/workspace/sources/${BPN}/ and local files are moved inside build/workspace/sources/${BPN}/oe-local-files. Secondary sources are currently not handled and are lost. Here is the output of devtool modify/build on bzip2 recipe: NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2 ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None) ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368 Log data follows: | DEBUG: Executing shell function do_install_ptest_base | NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest | sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \ | ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile | cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2 | cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory | WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/ 1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress' | WARNING: Backtrace (BB generated script): | #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189 | #2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158 | #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226 ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1' NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed. Summary: 1 task failed: <...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base externalsrc class modify SRC_URI to keep only: * 'file', 'npmsw' and 'crate' sources * url with type parameter matching 'kmeta' or 'git-dependency' So by forcing to add type='git-dependency' on secondary sources, we ensure that when building the recipe, the secondary sources can be unpacked into WORKDIR. This allows recipes containing several sources to be built under a devtool context, but it has some limitations: * user would not be able to generate patches for the secondary sources * type="git-dependency" is added for secondary sources even on non git sources, so we may want to rename this parameter (From OE-Core rev: 0d2cd26812954ebf9decfaa932030f449d85d58b) Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Jan 24, 2024
[YOCTO #15162] when doing devtool modify, sources are extracted into a devtool temporary workdir. The main source is moved inside build/workspace/sources/${BPN}/ and local files are moved inside build/workspace/sources/${BPN}/oe-local-files. Secondary sources are currently not handled and are lost. Here is the output of devtool modify/build on bzip2 recipe: NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2 ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None) ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368 Log data follows: | DEBUG: Executing shell function do_install_ptest_base | NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest | sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \ | ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile | cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/ | ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2 | cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory | WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/ 1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress' | WARNING: Backtrace (BB generated script): | #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189 | #2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158 | #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226 ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1' NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed. Summary: 1 task failed: <...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base externalsrc class modify SRC_URI to keep only: * 'file', 'npmsw' and 'crate' sources * url with type parameter matching 'kmeta' or 'git-dependency' So by forcing to add type='git-dependency' on secondary sources, we ensure that when building the recipe, the secondary sources can be unpacked into WORKDIR. This allows recipes containing several sources to be built under a devtool context, but it has some limitations: * user would not be able to generate patches for the secondary sources * type="git-dependency" is added for secondary sources even on non git sources, so we may want to rename this parameter (From OE-Core rev: cfd5ee890163a3d975093359016dda104e7b71df) Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc
pushed a commit
that referenced
this issue
Mar 15, 2024
Add --system parameter for useradd to avoid intruducing .bashrc and .profile under home dir to fix the below error. $ bitbake core-image-weston | DEBUG: Executing python function set_image_size | DEBUG: 352679.600000 = 271292 * 1.300000 | DEBUG: 455079.600000 = max(352679.600000, 65536)[352679.600000] + 102400 | DEBUG: 455080.000000 = int(455079.600000) | DEBUG: 455080 = aligned(455080) | DEBUG: returning 455080 | DEBUG: Python function set_image_size finished | DEBUG: Executing shell function do_image_tar | tar: ./home/weston/.bashrc: Unknown file type; file ignored | tar: ./home/weston/.profile: Unknown file type; file ignored | tar: Exiting with failure status due to previous errors | WARNING: /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897:150 exit 1 from '[ $? -eq 1 ]' | WARNING: Backtrace (BB generated script): #1: do_image_tar, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897, line 150 #2: main, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_tar.1972897, line 156 | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing python function set_image_size | DEBUG: 352679.600000 = 271292 * 1.300000 | DEBUG: 455079.600000 = max(352679.600000, 65536)[352679.600000] + 102400 | DEBUG: 455080.000000 = int(455079.600000) | DEBUG: 455080 = aligned(455080) | DEBUG: returning 455080 | DEBUG: Python function set_image_size finished | DEBUG: Executing shell function do_image_ext4 | DEBUG: Executing dd if=/dev/zero of=/buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.ext4 seek=455080 count=0 bs=1024 | 0+0 records in | 0+0 records out | 0 bytes copied, 0.00136946 s, 0.0 kB/s | DEBUG: Actual Rootfs size: 268184 /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs | DEBUG: Actual Partition size: 466001920 | DEBUG: Executing mkfs.ext4 -F -i 4096 /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.ext4 -d /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs | mke2fs 1.47.0 (5-Feb-2023) | Discarding device blocks: done | Creating filesystem with 455080 1k blocks and 113792 inodes | Filesystem UUID: 2031373e-63cd-4711-968b-4023ff7d6a90 | Superblock backups stored on blocks: | 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 | | Allocating group tables: done | Writing inode tables: done | Creating journal (8192 blocks): done | Copying files into the device: __populate_fs: ignoring entry ".bashrc" | .bashrc: File not found by ext2_lookup while looking up ".bashrc" | mkfs.ext4: File not found by ext2_lookup while populating file system | WARNING: /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895:178 exit 1 from 'mkfs.$fstype -F $extra_imagecmd /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/deploy-core-image-weston-image-complete/core-image-weston-qemux86-64.rootfs-20240315032140.$fstype -d /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs' | WARNING: Backtrace (BB generated script): | #1: oe_mkext234fs, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 178 | #2: do_image_ext4, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 150 | #3: main, /buildarea1/test/yocto/builds/poky-build-weston/tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/temp/run.do_image_ext4.1972895, line 215 ERROR: Task (/buildarea1/test/yocto/poky/meta/recipes-graphics/images/core-image-weston.bb:do_image_ext4) failed with exit code '1' Before the patch: $ ls -a tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs/home/weston/ . .. .bashrc .profile After the patch: $ ls -a tmp/work/qemux86_64-poky-linux/core-image-weston/1.0/rootfs/home/weston/ . .. (From OE-Core rev: 83e6422c19e4589a39466a3a1812df7df422c50c) Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
hi all,
I use poky commit
commit 65c94ca
but it's failed to use the below lines in local.conf
INHERIT += "extrausers"
ROOT_PASSWORD = "12345"
EXTRA_USERS_PARAMS = "usermod -P ${ROOT_PASSWORD} root;"
EXTRA_USERS_PARAMS += "useradd -P ${ROOT_PASSWORD} myuser;"
before config version 1 works well.
how can I create a extra user and password now in the updated yocto syntax, where can I find the guide and differences?
I can not find the solutions online.
Thank you very much.
I also posted the error at here:
agherzan/meta-raspberrypi#944
error output:
ERROR: core-image-base-1.0-r0 do_rootfs: core-image-base: useradd command did not succeed.
ERROR: core-image-base-1.0-r0 do_rootfs: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function:
0001:
*** 0002:do_rootfs(d)
0003:
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/meta/classes/image.bbclass', lineno: 250, function: do_rootfs
0246: progress_reporter.next_stage()
0247:
0248: # generate rootfs
0249: d.setVarFlag('REPRODUCIBLE_TIMESTAMP_ROOTFS', 'export', '1')
*** 0250: create_rootfs(d, progress_reporter=progress_reporter, logcatcher=logcatcher)
0251:
0252: progress_reporter.finish()
0253:}
0254:do_rootfs[dirs] = "${TOPDIR}"
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/meta/lib/oe/rootfs.py', lineno: 383, function: create_rootfs
0379:
0380: img_type = d.getVar('IMAGE_PKGTYPE')
0381:
0382: cls = get_class_for_type(img_type)
*** 0383: cls(d, manifest_dir, progress_reporter, logcatcher).create()
0384: os.environ.clear()
0385: os.environ.update(env_bkp)
0386:
0387:
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/meta/lib/oe/rootfs.py', lineno: 214, function: create
0210: execute_pre_post_process(self.d, rootfs_post_install_cmds)
0211:
0212: self.pm.run_intercepts()
0213:
*** 0214: execute_pre_post_process(self.d, post_process_cmds)
0215:
0216: if self.progress_reporter:
0217: self.progress_reporter.next_stage()
0218:
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/meta/lib/oe/utils.py', lineno: 263, function: execute_pre_post_process
0259: for cmd in cmds.strip().split(';'):
0260: cmd = cmd.strip()
0261: if cmd != '':
0262: bb.note("Executing %s ..." % cmd)
*** 0263: bb.build.exec_func(cmd, d)
0264:
0265:# For each item in items, call the function 'target' with item as the first
0266:# argument, extraargs as the other arguments and handle any exceptions in the
0267:# parent thread
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/bitbake/lib/bb/build.py', lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0257:
0258: try:
0259: curcwd = os.getcwd()
0260: except:
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/bitbake/lib/bb/build.py', lineno: 507, function: exec_func_shell
0503: with open(fifopath, 'r+b', buffering=0) as fifo:
0504: try:
0505: bb.debug(2, "Executing shell function %s" % func)
0506: with open(os.devnull, 'r+') as stdin, logfile:
*** 0507: bb.process.run(cmd, shell=False, stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0508: except bb.process.ExecutionError as exe:
0509: # Find the backtrace that the shell trap generated
0510: backtrace_marker_regex = re.compile(r"WARNING: Backtrace (BB generated script)")
0511: stdout_lines = (exe.stdout or "").split("\n")
File: '/home/rnd2/work/pi4/nacho-update/layers/poky/bitbake/lib/bb/process.py', lineno: 186, function: run
0182:
0183: if pipe.returncode != 0:
0184: if log:
0185: # Don't duplicate the output in the exception if logging it
*** 0186: raise ExecutionError(cmd, pipe.returncode, None, None)
0187: raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
0188: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of '/home/rnd2/work/pi4/nacho-update/build/tmp/work/qemux86_64-poky-linux/core-image-base/1.0-r0/temp/run.set_user_group.25283' failed with exit code 1
ERROR: Logfile of failure stored in: /home/rnd2/work/pi4/nacho-update/build/tmp/work/qemux86_64-poky-linux/core-image-base/1.0-r0/temp/log.do_rootfs.25283
ERROR: Task (/home/rnd2/work/pi4/nacho-update/layers/poky/meta/recipes-core/images/core-image-base.bb:do_rootfs) failed with exit code '1'
The text was updated successfully, but these errors were encountered: