Skip to content
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

Open
gitgonewithwind opened this issue Dec 10, 2021 · 0 comments
Open

Comments

@gitgonewithwind
Copy link

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'

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>
armcc pushed a commit that referenced this issue Jun 12, 2024
gen_fixtures.py:
* Add Scarthgap to slot #1
* Drop EOL Mickledore
* Move Kirkstone to lower slot
* Drop optional slot for EOL Dunfell

Refresh oe-core.xml and poky.xml

(Bitbake rev: e5767800bf93cd71a4588a18d6916cf5501b1e92)

Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc pushed a commit that referenced this issue Jun 13, 2024
gen_fixtures.py:
* Add Scarthgap to slot #1
* Drop EOL Mickledore
* Move Kirkstone to lower slot
* Drop optional slot for EOL Dunfell

Refresh oe-core.xml and poky.xml

(Bitbake rev: 11c7214a292cd296eed5490b6726e672f9179131)

Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc pushed a commit that referenced this issue Jul 1, 2024
Integrating the following commit(s) to linux-yocto/6.6:

1/1 [
    Author: Bruce Ashfield
    Email: bruce.ashfield@gmail.com
    Subject: cpu/amd: inhibit SMP check for qemux86
    Date: Fri, 28 Jun 2024 12:55:18 -0400

    When booting with kvm enabled on a AMD host, the following
    trace is thrown:

      [    0.084519] ------------[ cut here ]------------
      [    0.084519] WARNING: This combination of AMD processors is not suitable for SMP.
      [    0.084519] WARNING: CPU: 1 PID: 0 at /arch/x86/kernel/cpu/amd.c:341 init_amd+0xaee/0xbcc
      [    0.084519] Modules linked in:
      [    0.084519] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.32-yocto-standard #1
      [    0.084519] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014

    This warning is not valid in our configuration and is unnecesarily
    causing issue with debug.

    This has been know for some time (10+ years), but no acceptable
    solutioon has been found upstream:

       https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01428.html
       https://lkml.org/lkml/2010/3/30/397

    We have a configuration CONFIG_QEMUX86 that has been added for
    situations like this. When that value is defined, we inhibit the
    warning, but leave it as-is for other BSPs.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

(From OE-Core rev: f0c03000abb7665352cf107a600da15a112af5fa)

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 Jul 9, 2024
Integrating the following commit(s) to linux-yocto/6.6:

1/1 [
    Author: Bruce Ashfield
    Email: bruce.ashfield@gmail.com
    Subject: cpu/amd: inhibit SMP check for qemux86
    Date: Fri, 28 Jun 2024 12:55:18 -0400

    When booting with kvm enabled on a AMD host, the following
    trace is thrown:

      [    0.084519] ------------[ cut here ]------------
      [    0.084519] WARNING: This combination of AMD processors is not suitable for SMP.
      [    0.084519] WARNING: CPU: 1 PID: 0 at /arch/x86/kernel/cpu/amd.c:341 init_amd+0xaee/0xbcc
      [    0.084519] Modules linked in:
      [    0.084519] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.32-yocto-standard #1
      [    0.084519] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014

    This warning is not valid in our configuration and is unnecesarily
    causing issue with debug.

    This has been know for some time (10+ years), but no acceptable
    solutioon has been found upstream:

       https://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01428.html
       https://lkml.org/lkml/2010/3/30/397

    We have a configuration CONFIG_QEMUX86 that has been added for
    situations like this. When that value is defined, we inhibit the
    warning, but leave it as-is for other BSPs.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

(From OE-Core rev: 1608b8a0303ed24fb5da7c168bb1bc2c81760697)

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f0c03000abb7665352cf107a600da15a112af5fa)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
armcc pushed a commit that referenced this issue Aug 26, 2024
Fixes
ERROR: systemd-1_256.5-r0 do_patch: QA Issue: Fuzz detected:

Applying patch 0017-missing_syscall.h-Define-MIPS-ABI-defines-for-musl.patch
patching file src/basic/missing_syscall.h
Hunk #1 succeeded at 20 with fuzz 1.

The issue surfaces when building with musl

(From OE-Core rev: 4fc73793e0a053211b29d016a09afc430a48e81b)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc pushed a commit that referenced this issue Sep 9, 2024
In systemd/systemd@924453c
ProtectHome was set to true for systemd-coredump in order to reduce risk, since an attacker could craft a malicious binary in order to compromise systemd-coredump.
At that point the object analysis was done in the main systemd-coredump process.
Because of this systemd-coredump is unable to product symbolicated call-stacks for binaries running under /home ("n/a" is shown instead of function names).

However, later in systemd/systemd@61aea45 systemd-coredump was changed to do the object analysis in a forked process,
covering those security concerns.

Let's set ProtectHome to read-only so that systemd-coredump produces symbolicated call-stacks for processes running under /home.

Note: it still does not work in /tmp (because of PrivateTmp=yes) and in /root (for unknown reasons).

Before the change (with minidebuginfo enabled):

    root@qemux86-64:~# /home/sleep 1000 &
    [1] 426
    root@qemux86-64:~# kill -11 $(pidof sleep)
    root@qemux86-64:~# coredumpctl info
               PID: 426 (sleep)
               UID: 0 (root)
               GID: 0 (root)
            Signal: 11 (SEGV)
         Timestamp: Fri 2024-09-06 17:25:18 UTC (3s ago)
      Command Line: /home/sleep 1000
        Executable: /home/sleep
     Control Group: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS0.service
              Unit: serial-getty@ttyS0.service
             Slice: system-serial\x2dgetty.slice
           Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5
        Machine ID: fb279f18f2c849c59768754c7a274ee3
          Hostname: qemux86-64
           Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.426.1725643518000000.zst (present)
      Size on Disk: 16.5K
           Message: Process 426 (sleep) of user 0 dumped core.

                    Stack trace of thread 426:
                    #0  0x00007f365f3849a7 clock_nanosleep (libc.so.6 + 0xd49a7)
                    #1  0x00007f365f38f667 __nanosleep (libc.so.6 + 0xdf667)
                    #2  0x0000561fee703737 n/a (/home/sleep + 0x7737)
                    #3  0x000000003a6227c5 n/a (n/a + 0x0)
                    ELF object binary architecture: AMD x86-64
    [1]+  Segmentation fault      (core dumped) /home/sleep 1000

After the change (with minidebuginfo enabled):

    root@qemux86-64:~# /home/sleep 1000 &
    [1] 450
    root@qemux86-64:~# kill -11 $(pidof sleep)
    root@qemux86-64:~# coredumpctl info
               PID: 450 (sleep)
               UID: 0 (root)
               GID: 0 (root)
            Signal: 11 (SEGV)
         Timestamp: Fri 2024-09-06 17:30:12 UTC (4s ago)
      Command Line: /home/sleep 1000
        Executable: /home/sleep
     Control Group: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyS0.service
              Unit: serial-getty@ttyS0.service
             Slice: system-serial\x2dgetty.slice
           Boot ID: 44ef4ddfaad249ceaa29d1e9f330d3b5
        Machine ID: fb279f18f2c849c59768754c7a274ee3
          Hostname: qemux86-64
           Storage: /var/lib/systemd/coredump/core.sleep.0.44ef4ddfaad249ceaa29d1e9f330d3b5.450.1725643812000000.zst (present)
      Size on Disk: 16.5K
           Message: Process 450 (sleep) of user 0 dumped core.

                    Stack trace of thread 450:
                    #0  0x00007f795dd689a7 clock_nanosleep (libc.so.6 + 0xd49a7)
                    #1  0x00007f795dd73667 __nanosleep (libc.so.6 + 0xdf667)
                    #2  0x0000561965c9d737 rpl_nanosleep (sleep + 0x7737)
                    #3  0x0000561965c9d0c1 xnanosleep (sleep + 0x70c1)
                    #4  0x0000561965c985c8 main (sleep + 0x25c8)
                    #5  0x00007f795dcba01b __libc_start_call_main (libc.so.6 + 0x2601b)
                    #6  0x00007f795dcba0d9 __libc_start_main (libc.so.6 + 0x260d9)
                    #7  0x0000561965c98685 _start (sleep + 0x2685)
                    ELF object binary architecture: AMD x86-64
    [1]+  Segmentation fault      (core dumped) /home/sleep 1000

(From OE-Core rev: b8c1f999038b7cd6fc2e80ed215541c8a4d9e19f)

Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc pushed a commit that referenced this issue Oct 10, 2024
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.

But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'

And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
    # No need to check the exit code as we know it's going to be
    # non-zero, but that's what we expect.

(From OE-Core rev: 6bb50f19de88f1c22d1ccbb3ce3802a6f0dddf4e)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
armcc pushed a commit that referenced this issue Oct 11, 2024
Fixed:
1) $ bitbake virtual/kernel -cmenuconfig
Do some changes and save the new config to default .config.
2) $ bitbake virtual/kernel -cdiffconfig
The config fragment is dumped into ${WORKDIR}/fragment.cfg.

But the .config which was saved by step #1 is overridden by .config.orig, so
the changes will be lost if run 'bitbake virtual/kernel'

And the following comment is for subprocess.call(), not for shutil.copy(),
so move subprocess.call() to the correct location.
    # No need to check the exit code as we know it's going to be
    # non-zero, but that's what we expect.

(From OE-Core rev: 6cccf6b02f92dad514e65fd779ff659b19eb6be7)

Signed-off-by: Robert Yang <liezhi.yang@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
Labels
None yet
Development

No branches or pull requests

1 participant