[OE-core] [PATCH][hardknott] parselogs: ignore floppy error on qemu-system-x86 at boot stage
From: Yanfei Xu
We can disable floppy drive by BIOS on a hardware, but an empty floppy
drive is connected by default on qemu-system-x86. Linux usually detect
the device and modprode the matched floppy.ko at the boot stage. Due to
we don't specify a floppy deivce in qemu boot arguments, then the errors
about floppy reading comes out.
It is harmless and normal, so we could ignore this error message on
qemux86.
Seen if kernel-modules is included in the image which pulls in the
relavent kernel module.
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01402.html
Signed-off-by: Yanfei Xu
Signed-off-by: Richard Purdie
(cherry picked from commit 3359f23ee9351c70997d5e0a17d17d1e47d59623)
Signed-off-by: Yanfei Xu
---
meta/lib/oeqa/runtime/cases/parselogs.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py
b/meta/lib/oeqa/runtime/cases/parselogs.py
index 4714741aff..1bb0425521 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -88,6 +88,8 @@ qemux86_common = [
'tsc: HPET/PMTIMER calibration failed',
"modeset(0): Failed to initialize the DRI2 extension",
"glamor initialization failed",
+"blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ)",
+"floppy: error",
] + common_errors
ignore_errors = {
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150740):
https://lists.openembedded.org/g/openembedded-core/message/150740
Mute This Topic: https://lists.openembedded.org/mt/82255249/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] parselogs: ignore floppy error on qemu-system-x86 at boot stage
On 4/14/21 2:32 PM, Xu, Yanfei wrote: On 4/9/21 9:13 PM, Richard Purdie wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, 2021-04-09 at 17:03 +0800, Xu, Yanfei wrote: From: Yanfei Xu We can disable floppy drive by BIOS on a hardware, but an empty floppy drive is connected by default on qemu-system-x86. Linux usually detect the device and modprode the matched floppy.ko at the boot stage. Due to we don't specify a floppy deivce in qemu boot arguments, then the errors about floppy reading comes out. It is harmless and normal, so we could ignore this error message on qemux86. https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01402.html Signed-off-by: Yanfei Xu --- meta/lib/oeqa/runtime/cases/parselogs.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index 4714741aff..1bb0425521 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -88,6 +88,8 @@ qemux86_common = [ 'tsc: HPET/PMTIMER calibration failed', "modeset(0): Failed to initialize the DRI2 extension", "glamor initialization failed", + "blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ)", + "floppy: error", ] + common_errors I'm a little puzzled about why we don't see this on the autobuilder. Are you configuring qemu differently? Hi Richard, I didn't configure my qemu, and I made a comparison between my and yocto's qemu command line outputted by runqemu. There is no difference. With the previous email, the error log did exist in yocto's dmesg. But it's strange why yocto's parselog didn't report it. Thanks, Yanfei Sorry for the late reply. I build a poky raw project and do some tests: bitbake core-image-minimal -c testimage //the dmesg don't contain floppy error, as the kernel-modules package is not install. Then I add IMAGE_INSTALL_append = " kernel-modules" and use systemd to instead of sysvinit. The error appears in qemu dmesg. [ 4.879016] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [ 4.880255] floppy: error 10 while reading block 0 The log tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/testimage/qemu_boot_log.20210414061409 is attached Best regards, Yanfei Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150653): https://lists.openembedded.org/g/openembedded-core/message/150653 Mute This Topic: https://lists.openembedded.org/mt/81963905/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] parselogs: ignore floppy error on qemu-system-x86 at boot stage
On 4/9/21 9:13 PM, Richard Purdie wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On Fri, 2021-04-09 at 17:03 +0800, Xu, Yanfei wrote: From: Yanfei Xu We can disable floppy drive by BIOS on a hardware, but an empty floppy drive is connected by default on qemu-system-x86. Linux usually detect the device and modprode the matched floppy.ko at the boot stage. Due to we don't specify a floppy deivce in qemu boot arguments, then the errors about floppy reading comes out. It is harmless and normal, so we could ignore this error message on qemux86. https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01402.html Signed-off-by: Yanfei Xu --- meta/lib/oeqa/runtime/cases/parselogs.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index 4714741aff..1bb0425521 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -88,6 +88,8 @@ qemux86_common = [ 'tsc: HPET/PMTIMER calibration failed', "modeset(0): Failed to initialize the DRI2 extension", "glamor initialization failed", +"blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ)", +"floppy: error", ] + common_errors I'm a little puzzled about why we don't see this on the autobuilder. Are you configuring qemu differently? Sorry for the late reply. I build a poky raw project and do some tests: bitbake core-image-minimal -c testimage //the dmesg don't contain floppy error, as the kernel-modules package is not install. Then I add IMAGE_INSTALL_append = " kernel-modules" and use systemd to instead of sysvinit. The error appears in qemu dmesg. [4.879016] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [4.880255] floppy: error 10 while reading block 0 The log tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/testimage/qemu_boot_log.20210414061409 is attached Best regards, Yanfei Cheers, Richard [0.00] Linux version 5.10.25-yocto-standard (oe-user@oe-host) (x86_64-poky-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1.20210209) #1 SMP PREEMPT Mon Mar 22 19:08:27 UTC 2021 [0.00] Command line: root=/dev/vda rw mem=512M ip=192.168.7.2::192.168.7.1:255.255.255.0 console=ttyS0 console=ttyS1 oprofile.timer=1 printk.time=1 [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1ffdafff] usable [0.00] BIOS-e820: [mem 0x1ffdb000-0x1fff] reserved [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [0.00] BIOS-e820: [mem 0xfffc-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] user-defined physical RAM map: [0.00] user: [mem 0x-0x0009fbff] usable [0.00] user: [mem 0x0009fc00-0x0009] reserved [0.00] user: [mem 0x000f-0x000f] reserved [0.00] user: [mem 0x0010-0x1ffdafff] usable [0.00] user: [mem 0x1ffdb000-0x1fff] reserved [0.00] user: [mem 0xfeffc000-0xfeff] reserved [0.00] user: [mem 0xfffc-0x] reserved [0.00] SMBIOS 2.8 present. [0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [0.00] Hypervisor detected: KVM [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [0.00] kvm-clock: cpu 0, msr c3cd001, primary cpu clock [0.00] kvm-clock: using sched offset of 1239015809 cycles [0.04] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.08] tsc: Detected 3099.990 MHz processor [0.000931] last_pfn = 0x1ffdb max_arch_pfn = 0x4 [0.000969] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.009102] found SMP MP-table at [mem 0x000f5a90-0x000f5a9f] [0.009159] check: Scanning 1 areas for low memory corruption [0.009280] ACPI: Early table checksum verification disabled [0.009291] ACPI: RSDP 0x000F58B0 14 (v00 BOCHS ) [0.009297] ACPI: RSDT 0x1FFE15BA 34 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.009305] ACPI: FACP 0x1FFE146E 74 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.009310] ACPI: DSDT 0x1FFE0040 00142E (v01 BOCHS BXPCDSDT 0001 BXPC 0
[OE-core][PATCH] parselogs: ignore floppy error on qemu-system-x86 at boot stage
From: Yanfei Xu
We can disable floppy drive by BIOS on a hardware, but an empty floppy
drive is connected by default on qemu-system-x86. Linux usually detect
the device and modprode the matched floppy.ko at the boot stage. Due to
we don't specify a floppy deivce in qemu boot arguments, then the errors
about floppy reading comes out.
It is harmless and normal, so we could ignore this error message on
qemux86.
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01402.html
Signed-off-by: Yanfei Xu
---
meta/lib/oeqa/runtime/cases/parselogs.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py
b/meta/lib/oeqa/runtime/cases/parselogs.py
index 4714741aff..1bb0425521 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -88,6 +88,8 @@ qemux86_common = [
'tsc: HPET/PMTIMER calibration failed',
"modeset(0): Failed to initialize the DRI2 extension",
"glamor initialization failed",
+"blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ)",
+"floppy: error",
] + common_errors
ignore_errors = {
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150333):
https://lists.openembedded.org/g/openembedded-core/message/150333
Mute This Topic: https://lists.openembedded.org/mt/81963905/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2] glibc: fix pthread_cond_destroy hangs with process-shared mutex
From: Yanfei Xu
This bug can cause pthread_cond_destroy hang with process-shared
mutex. And it is since glibc-2.32, will be fixed in glibc-2.34.
Signed-off-by: Yanfei Xu
---
v2:
1. remove an unused debug adding in glibc_2.33.bb
2. correct the patch status from accepted to backport.
...-private-futex-optimization-BZ-27304.patch | 49 +++
meta/recipes-core/glibc/glibc_2.33.bb | 1 +
2 files changed, 50 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
diff --git
a/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
b/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
new file mode 100644
index 00..39fde5b785
--- /dev/null
+++
b/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
@@ -0,0 +1,49 @@
+From c4ad832276f4dadfa40904109b26a521468f66bc Mon Sep 17 00:00:00 2001
+From: Florian Weimer
+Date: Thu, 4 Feb 2021 15:00:20 +0100
+Subject: [PATCH] nptl: Remove private futex optimization [BZ #27304]
+
+It is effectively used, unexcept for pthread_cond_destroy, where we do
+not want it; see bug 27304. The internal locks do not support a
+process-shared mode.
+
+This fixes commit dc6cfdc934db9997c33728082d63552b9eee4563 ("nptl:
+Move pthread_cond_destroy implementation into libc").
+
+Reviewed-by: Adhemerval Zanella
+
+Upstream-Status: Backport
[https://sourceware.org/bugzilla/show_bug.cgi?id=27304]
+Signed-off-by: Yanfei Xu
+---
+ sysdeps/nptl/lowlevellock-futex.h | 14 +-
+ 1 file changed, 1 insertion(+), 13 deletions(-)
+
+diff --git a/sysdeps/nptl/lowlevellock-futex.h
b/sysdeps/nptl/lowlevellock-futex.h
+index ecb729da6b..ca96397a4a 100644
+--- a/sysdeps/nptl/lowlevellock-futex.h
b/sysdeps/nptl/lowlevellock-futex.h
+@@ -50,20 +50,8 @@
+ #define LLL_SHAREDFUTEX_PRIVATE_FLAG
+
+ #ifndef __ASSEMBLER__
+-
+-# if IS_IN (libc) || IS_IN (rtld)
+-/* In libc.so or ld.so all futexes are private. */
+-# define __lll_private_flag(fl, private) \
+- ({ \
+-/* Prevent warnings in callers of this macro. */ \
+-int __lll_private_flag_priv __attribute__ ((unused)); \
+-__lll_private_flag_priv = (private); \
+-((fl) | FUTEX_PRIVATE_FLAG); \
+- })
+-# else
+-# define __lll_private_flag(fl, private) \
++# define __lll_private_flag(fl, private) \
+ (((fl) | FUTEX_PRIVATE_FLAG) ^ (private))
+-# endif
+
+ # define lll_futex_syscall(nargs, futexp, op, ...) \
+ ({\
+--
+2.27.0
+
diff --git a/meta/recipes-core/glibc/glibc_2.33.bb
b/meta/recipes-core/glibc/glibc_2.33.bb
index c47826a51e..9feb6615ed 100644
--- a/meta/recipes-core/glibc/glibc_2.33.bb
+++ b/meta/recipes-core/glibc/glibc_2.33.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0030-powerpc-Do-not-ask-compiler-for-finding-arch.patch \
file://0031-x86-Require-full-ISA-support-for-x86-64-level-marker.patch \
file://0032-string-Work-around-GCC-PR-98512-in-rawmemchr.patch \
+ file://0001-nptl-Remove-private-futex-optimization-BZ-27304.patch \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build-${TARGET_SYS}"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149320):
https://lists.openembedded.org/g/openembedded-core/message/149320
Mute This Topic: https://lists.openembedded.org/mt/81272760/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] glibc: fix pthread_cond_destroy hang with process-shared mutex
On 3/12/21 11:57 AM, Khem Raj wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Thu, Mar 11, 2021 at 7:22 PM Xu, Yanfei wrote:
From: Yanfei Xu
This bug can cause pthread_cond_destroy hang with process-shared
mutex. And it is since glibc-2.32, will be fixed in glibc-2.34.
Signed-off-by: Yanfei Xu
---
...-private-futex-optimization-BZ-27304.patch | 49 +++
meta/recipes-core/glibc/glibc_2.33.bb | 3 ++
2 files changed, 52 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
diff --git
a/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
b/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
new file mode 100644
index 00..19f391cc84
--- /dev/null
+++
b/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
@@ -0,0 +1,49 @@
+From c4ad832276f4dadfa40904109b26a521468f66bc Mon Sep 17 00:00:00 2001
+From: Florian Weimer
+Date: Thu, 4 Feb 2021 15:00:20 +0100
+Subject: [PATCH] nptl: Remove private futex optimization [BZ #27304]
+
+It is effectively used, unexcept for pthread_cond_destroy, where we do
+not want it; see bug 27304. The internal locks do not support a
+process-shared mode.
+
+This fixes commit dc6cfdc934db9997c33728082d63552b9eee4563 ("nptl:
+Move pthread_cond_destroy implementation into libc").
+
+Reviewed-by: Adhemerval Zanella
+
+Upstream-Status: Accepted
[https://sourceware.org/bugzilla/show_bug.cgi?id=27304]
+Signed-off-by: Yanfei Xu
+---
+ sysdeps/nptl/lowlevellock-futex.h | 14 +-
+ 1 file changed, 1 insertion(+), 13 deletions(-)
+
+diff --git a/sysdeps/nptl/lowlevellock-futex.h
b/sysdeps/nptl/lowlevellock-futex.h
+index ecb729da6b..ca96397a4a 100644
+--- a/sysdeps/nptl/lowlevellock-futex.h
b/sysdeps/nptl/lowlevellock-futex.h
+@@ -50,20 +50,8 @@
+ #define LLL_SHAREDFUTEX_PRIVATE_FLAG
+
+ #ifndef __ASSEMBLER__
+-
+-# if IS_IN (libc) || IS_IN (rtld)
+-/* In libc.so or ld.so all futexes are private. */
+-# define __lll_private_flag(fl, private) \
+- ({ \
+-/* Prevent warnings in callers of this macro. */ \
+-int __lll_private_flag_priv __attribute__ ((unused)); \
+-__lll_private_flag_priv = (private); \
+-((fl) | FUTEX_PRIVATE_FLAG); \
+- })
+-# else
+-# define __lll_private_flag(fl, private) \
++# define __lll_private_flag(fl, private) \
+ (((fl) | FUTEX_PRIVATE_FLAG) ^ (private))
+-# endif
+
+ # define lll_futex_syscall(nargs, futexp, op, ...) \
+ ({\
+--
+2.27.0
+
diff --git a/meta/recipes-core/glibc/glibc_2.33.bb
b/meta/recipes-core/glibc/glibc_2.33.bb
index c47826a51e..6ba8cd9b71 100644
--- a/meta/recipes-core/glibc/glibc_2.33.bb
+++ b/meta/recipes-core/glibc/glibc_2.33.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0030-powerpc-Do-not-ask-compiler-for-finding-arch.patch \
file://0031-x86-Require-full-ISA-support-for-x86-64-level-marker.patch \
file://0032-string-Work-around-GCC-PR-98512-in-rawmemchr.patch \
+ file://0001-nptl-Remove-private-futex-optimization-BZ-27304.patch \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build-${TARGET_SYS}"
@@ -55,6 +56,8 @@ PACKAGES_DYNAMIC = ""
BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir}"
+TARGET_CFLAGS += " ${PROFILING_OPTIMIZATION} "
why do we need this change ?
My fault, don't need it. It's just a debug operation during I was
debugging this issue. Will remove it in v2.
Thanks for reviewing.
Yanfei
+
GLIBC_BROKEN_LOCALES = ""
GLIBCPIE ??= ""
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149319):
https://lists.openembedded.org/g/openembedded-core/message/149319
Mute This Topic: https://lists.openembedded.org/mt/81271629/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] glibc: fix pthread_cond_destroy hang with process-shared mutex
From: Yanfei Xu
This bug can cause pthread_cond_destroy hang with process-shared
mutex. And it is since glibc-2.32, will be fixed in glibc-2.34.
Signed-off-by: Yanfei Xu
---
...-private-futex-optimization-BZ-27304.patch | 49 +++
meta/recipes-core/glibc/glibc_2.33.bb | 3 ++
2 files changed, 52 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
diff --git
a/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
b/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
new file mode 100644
index 00..19f391cc84
--- /dev/null
+++
b/meta/recipes-core/glibc/glibc/0001-nptl-Remove-private-futex-optimization-BZ-27304.patch
@@ -0,0 +1,49 @@
+From c4ad832276f4dadfa40904109b26a521468f66bc Mon Sep 17 00:00:00 2001
+From: Florian Weimer
+Date: Thu, 4 Feb 2021 15:00:20 +0100
+Subject: [PATCH] nptl: Remove private futex optimization [BZ #27304]
+
+It is effectively used, unexcept for pthread_cond_destroy, where we do
+not want it; see bug 27304. The internal locks do not support a
+process-shared mode.
+
+This fixes commit dc6cfdc934db9997c33728082d63552b9eee4563 ("nptl:
+Move pthread_cond_destroy implementation into libc").
+
+Reviewed-by: Adhemerval Zanella
+
+Upstream-Status: Accepted
[https://sourceware.org/bugzilla/show_bug.cgi?id=27304]
+Signed-off-by: Yanfei Xu
+---
+ sysdeps/nptl/lowlevellock-futex.h | 14 +-
+ 1 file changed, 1 insertion(+), 13 deletions(-)
+
+diff --git a/sysdeps/nptl/lowlevellock-futex.h
b/sysdeps/nptl/lowlevellock-futex.h
+index ecb729da6b..ca96397a4a 100644
+--- a/sysdeps/nptl/lowlevellock-futex.h
b/sysdeps/nptl/lowlevellock-futex.h
+@@ -50,20 +50,8 @@
+ #define LLL_SHAREDFUTEX_PRIVATE_FLAG
+
+ #ifndef __ASSEMBLER__
+-
+-# if IS_IN (libc) || IS_IN (rtld)
+-/* In libc.so or ld.so all futexes are private. */
+-# define __lll_private_flag(fl, private) \
+- ({ \
+-/* Prevent warnings in callers of this macro. */ \
+-int __lll_private_flag_priv __attribute__ ((unused)); \
+-__lll_private_flag_priv = (private); \
+-((fl) | FUTEX_PRIVATE_FLAG); \
+- })
+-# else
+-# define __lll_private_flag(fl, private) \
++# define __lll_private_flag(fl, private) \
+ (((fl) | FUTEX_PRIVATE_FLAG) ^ (private))
+-# endif
+
+ # define lll_futex_syscall(nargs, futexp, op, ...) \
+ ({\
+--
+2.27.0
+
diff --git a/meta/recipes-core/glibc/glibc_2.33.bb
b/meta/recipes-core/glibc/glibc_2.33.bb
index c47826a51e..6ba8cd9b71 100644
--- a/meta/recipes-core/glibc/glibc_2.33.bb
+++ b/meta/recipes-core/glibc/glibc_2.33.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0030-powerpc-Do-not-ask-compiler-for-finding-arch.patch \
file://0031-x86-Require-full-ISA-support-for-x86-64-level-marker.patch \
file://0032-string-Work-around-GCC-PR-98512-in-rawmemchr.patch \
+ file://0001-nptl-Remove-private-futex-optimization-BZ-27304.patch \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build-${TARGET_SYS}"
@@ -55,6 +56,8 @@ PACKAGES_DYNAMIC = ""
BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir}"
+TARGET_CFLAGS += " ${PROFILING_OPTIMIZATION} "
+
GLIBC_BROKEN_LOCALES = ""
GLIBCPIE ??= ""
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149317):
https://lists.openembedded.org/g/openembedded-core/message/149317
Mute This Topic: https://lists.openembedded.org/mt/81271629/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2] lttng-tools: upgrade 2.12.2->2.12.3
From: Yanfei Xu
This is a bug fix release. Meanwhile, this upgrade will solve a
lttng-tools testcase failure that test_notification_kernel hangs
with linux-yocto-dev.
Signed-off-by: Yanfei Xu
---
.../lttng/{lttng-tools_2.12.2.bb => lttng-tools_2.12.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.12.2.bb =>
lttng-tools_2.12.3.bb} (98%)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
similarity index 98%
rename from meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
index 0787e04d19..eae95da2ed 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
@@ -37,7 +37,7 @@ SRC_URI =
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-tests-regression-disable-the-tools-live-tests.patch \
"
-SRC_URI[sha256sum] =
"9ed9161795ff023b076f9f95afaa4f1f822ec42495c0fa04c586ab8fa74e84f1"
+SRC_URI[sha256sum] =
"2890da230edd523fcf497e9eb28133b7606d64fa01bcbffadbfcba42104db153"
inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148925):
https://lists.openembedded.org/g/openembedded-core/message/148925
Mute This Topic: https://lists.openembedded.org/mt/81069059/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] lttng-tools: upgrade 2.12.2->2.12.3
On 3/3/21 9:10 PM, Bruce Ashfield wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Wed, Mar 3, 2021 at 1:16 AM Xu, Yanfei wrote:
From: Yanfei Xu
We should get into the habit of summarizing the changes in version
bump commits, along with a comment explaining if it is a bug fix
release, features, etc.
Thanks, will do it in v2.
Yanfei
Bruce
Signed-off-by: Yanfei Xu
---
.../lttng/{lttng-tools_2.12.2.bb => lttng-tools_2.12.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.12.2.bb =>
lttng-tools_2.12.3.bb} (98%)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
similarity index 98%
rename from meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
index 0787e04d19..eae95da2ed 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
@@ -37,7 +37,7 @@ SRC_URI =
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-tests-regression-disable-the-tools-live-tests.patch \
"
-SRC_URI[sha256sum] =
"9ed9161795ff023b076f9f95afaa4f1f822ec42495c0fa04c586ab8fa74e84f1"
+SRC_URI[sha256sum] =
"2890da230edd523fcf497e9eb28133b7606d64fa01bcbffadbfcba42104db153"
inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
--
2.27.0
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148924):
https://lists.openembedded.org/g/openembedded-core/message/148924
Mute This Topic: https://lists.openembedded.org/mt/81046498/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] lttng-tools: upgrade 2.12.2->2.12.3
From: Yanfei Xu
Signed-off-by: Yanfei Xu
---
.../lttng/{lttng-tools_2.12.2.bb => lttng-tools_2.12.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.12.2.bb =>
lttng-tools_2.12.3.bb} (98%)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
similarity index 98%
rename from meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
index 0787e04d19..eae95da2ed 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.3.bb
@@ -37,7 +37,7 @@ SRC_URI =
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-tests-regression-disable-the-tools-live-tests.patch \
"
-SRC_URI[sha256sum] =
"9ed9161795ff023b076f9f95afaa4f1f822ec42495c0fa04c586ab8fa74e84f1"
+SRC_URI[sha256sum] =
"2890da230edd523fcf497e9eb28133b7606d64fa01bcbffadbfcba42104db153"
inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148879):
https://lists.openembedded.org/g/openembedded-core/message/148879
Mute This Topic: https://lists.openembedded.org/mt/81046498/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] kernel-yocto: Fix an inappropriate process with include path
On 9/2/20 8:27 PM, Bruce Ashfield wrote:
On Wed, Sep 2, 2020 at 8:14 AM Bruce Ashfield via
lists.openembedded.org
wrote:
On Tue, Sep 1, 2020 at 11:20 PM Xu, Yanfei wrote:
From: Yanfei Xu
We just want to remove the first '-I' in $d, hence removing the
'g' of sed avoid changing the real path which is include '-I'
The g was intentional. Is it actually causing a bug ? if not, I see no
reason to change it.
Anyone with paths with embedded '-I' have more issues than this sed expression.
Actually, on further thought. I'll just pull this into my queued patches.
It is my habit to almost always use /g on my sed expressions, but
there's no reason to leave this lurking (but my comment still stands
about configurations that have -I in their actual paths :)
Yes， Bruce. I did meet a bug cause by this reason When I looked into
it and found this point.
The path is like
"builds/08311812-ICS_Custom/intel-x86-64-standard-small/build"
Thanks，
Yanfei
Bruce
Bruce
Signed-off-by: Yanfei Xu
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 96ea612258..b672a1143a 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -225,7 +225,7 @@ do_kernel_metadata() {
for feature in ${KERNEL_FEATURES}; do
feature_found=f
for d in $includes; do
- path_to_check=$(echo $d | sed 's/-I//g')
+ path_to_check=$(echo $d | sed 's/-I//')
if [ "$feature_found" = "f" ] && [ -e
"$path_to_check/$feature" ]; then
feature_found=t
fi
--
2.18.2
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142124):
https://lists.openembedded.org/g/openembedded-core/message/142124
Mute This Topic: https://lists.openembedded.org/mt/76575762/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] kernel-yocto: Fix an inappropriate process with include path
From: Yanfei Xu
We just want to remove the first '-I' in $d, hence removing the
'g' of sed avoid changing the real path which is include '-I'
Signed-off-by: Yanfei Xu
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 96ea612258..b672a1143a 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -225,7 +225,7 @@ do_kernel_metadata() {
for feature in ${KERNEL_FEATURES}; do
feature_found=f
for d in $includes; do
- path_to_check=$(echo $d | sed 's/-I//g')
+ path_to_check=$(echo $d | sed 's/-I//')
if [ "$feature_found" = "f" ] && [ -e
"$path_to_check/$feature" ]; then
feature_found=t
fi
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142092):
https://lists.openembedded.org/g/openembedded-core/message/142092
Mute This Topic: https://lists.openembedded.org/mt/76575762/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v4] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
This patch can make ensure that unversioned kernel image symlink will be
added to the rootfs during do_install by post install and it can fall
back to make a copy if the unversioned kernel image symlink creation
fails on target.
I have done the basic test on my board and the oe-selftest for this
patch. The test passed.
$ oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi
2020-07-03 10:16:29,211 - oe-selftest - INFO - Adding layer libraries:
2020-07-03 10:16:29,211 - oe-selftest - INFO -
/buildarea/raid0/yxu2/repo/poky/poky/meta/lib
2020-07-03 10:16:29,211 - oe-selftest - INFO -
/buildarea/raid0/yxu2/repo/poky/poky/meta-yocto-bsp/lib
2020-07-03 10:16:29,212 - oe-selftest - INFO -
/buildarea/raid0/yxu2/repo/poky/poky/meta-selftest/lib
2020-07-03 10:16:29,212 - oe-selftest - INFO - Running bitbake -e to
test the configuration is valid/parsable
2020-07-03 10:16:43,055 - oe-selftest - INFO - Adding: "include
selftest.inc" in
/buildarea/raid0/yxu2/repo/poky/poky/1285-st/conf/local.conf
2020-07-03 10:16:43,055 - oe-selftest - INFO - Adding: "include
bblayers.inc" in bblayers.conf
2020-07-03 10:16:43,056 - oe-selftest - INFO - test_boot_efi
(efibootpartition.GenericEFITest)
2020-07-03 11:40:03,056 - oe-selftest - INFO - Keepalive message
2020-07-03 12:29:28,901 - oe-selftest - INFO - ... ok
2020-07-03 12:30:46,074 - oe-selftest - INFO -
--
2020-07-03 12:30:46,074 - oe-selftest - INFO - Ran 1 test in 8055.415s
2020-07-03 12:30:46,074 - oe-selftest - INFO - OK
2020-07-03 12:30:51,602 - oe-selftest - INFO - RESULTS:
2020-07-03 12:30:51,602 - oe-selftest - INFO - RESULTS -
efibootpartition.GenericEFITest.test_boot_efi: PASSED (7965.85s)
2020-07-03 12:30:51,617 - oe-selftest - INFO - SUMMARY:
2020-07-03 12:30:51,617 - oe-selftest - INFO - oe-selftest () - Ran 1
test in 8055.416s
2020-07-03 12:30:51,617 - oe-selftest - INFO - oe-selftest - OK - All
required tests passed (successes=1, skipped=0, failures=0, errors=0)
Cheers，
Yanfei
On 7/3/20 9:55 PM, Xu, Yanfei wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure wh
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 20a0135fc9..b01c1699ae 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,25 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_%s-image-%s' % (kname,typelower), """set +e
+if [ -n "$D" ]; then
+ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+else
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling
back to copied image (%s)."
+install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION}
${KERNEL_IMAGEDEST}/%s
+fi
+fi
+set -e
+""" % (type, type, type, type, type, type, type))
+d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """set +e
+if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
+rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+fi
+set -e
+""" % (type, type, type))
+
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to
0,
@@ -385,9 +404,6 @@ kernel_do_install() {
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
- if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
- fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140297):
https://lists.openembedded.org/g/openembedded-core/message/140297
Mute This Topic: https://lists.openembedded.org/mt/75279494/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v4] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 20a0135fc9..b01c1699ae 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,25 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_%s-image-%s' % (kname,typelower), """set +e
+if [ -n "$D" ]; then
+ln -sf %s-${KERNEL_VERSION} $D/${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+else
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks,
falling back to copied image (%s)."
+install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION}
${KERNEL_IMAGEDEST}/%s
+fi
+fi
+set -e
+""" % (type, type, type, type, type, type, type))
+d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """set +e
+if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
+rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+fi
+set -e
+""" % (type, type, type))
+
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0,
@@ -385,9 +404,6 @@ kernel_do_install() {
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
- if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
- fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140294):
https://lists.openembedded.org/g/openembedded-core/message/140294
Mute This Topic: https://lists.openembedded.org/mt/75279494/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 7/2/20 8:37 PM, Bruce Ashfield wrote:
On Thu, Jul 2, 2020 at 5:49 AM Xu, Yanfei wrote:
On 7/2/20 3:46 PM, Richard Purdie wrote:
On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote:
On 7/1/20 9:42 PM, Bruce Ashfield wrote:
On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei
wrote:
On 6/28/20 8:21 PM, Xu, Yanfei wrote:
On 6/25/20 12:18 AM, Richard Purdie wrote:
On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote:
On 6/24/20 9:08 PM, Richard Purdie wrote:
On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote:
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield
wrote:
On Fri, Jun 19, 2020 at 7:47 AM <
yanfei...@windriver.com>
wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you
will get
failure
when
you install or update the kernel rpm package. Now
we use a
copy
of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield <
bruce.ashfi...@gmail.com>
Suggested-by: Richard Purdie <
richard.pur...@linuxfoundation.org>
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19
---
1 file changed, 16 insertions(+), 3
deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' %
kname, ' %s-
image-
%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' %
(kname,typelower),
'%s-
image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname,
typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' %
(kname,
typelower),
'1')
+d.setVar('pkg_postinst_ontarget_%s-
image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if
the
unversioned
image link/copy was deferred until boot. I don't
see a
summary of
why
that's no longer a concern in the v3 of the patch.
Can you
confirm
that it isn't an issue ? Is it simply because the
booted
image
isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing
selftest
failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce
new
issues?
Yes, I reverted it and retested and confirmed this patch
causes the
selftest failure in the link to the build above.
OK, I am trying to analyse the log. But I haven't figured
out what
cause
it fialed， and how to reproduce it on my mechine. I'd
apprecate any
information.
The command to reproduce should be:
oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi
I've addressed this failure why due to boot partation in wic
doesn't
contain no-versioned image. This result is different from the
previous
I verified, because of the different configuraions in wks.
"--source" field in wks decides where the files in boot
partation come
from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot
which is
installed by rpm package. Blow is the wks used by 'oe-selftest
-r
efibootpartition.GenericEFITest.test_boot_efi'
bootloader --ptable gpt
part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
--fstype=vfat --label boot --active --align 1024 --use-uuid
--overhead-factor 1.0
part / --source rootfs --fstype=ext4 --label root --align 1024
--exclude-path boot/
Hence we still should keep the no-versioned iamge in kernel-
image*.rpm
which is like the previous v2 patch.
Any opinions? It does cause the kernel rpm larger. However, the
kernel
image is not always large, only a few MB. And it will be changed
to
symlink when installed on targe. So this patch's only negative
effect
is the little increasement about update payloads.
I'm trying to follow the description that you had about the
oe-selftest and I'm missing something.
Can you describe it again ? In a way that someone not familiar with
that the selftest is seeing as a failure can grok ?
i.e. in the selftest configuration are we not getting the
(un)versioned kernel image because the symlink (or copy fallback)
is
in an on-boot post install hook ? And the test is looking for the
versioned/unversioned kernel image at image construction time ?
So that leaves us at either installing both the versioned and
unversioned, or some sort of package install time testing of the
target filesystem ? Does that partition exist at package install
time
? Is that the approach we tried in v1 of the patch (I know v2 was
keeping both as copies in the package, and converting it to a
symlink
on boot).
Sorry for the uncleared discription.
For the os-selftest failure: The failure happened at qemu booting
with
its wic image. Qemu could not find the unversioned kernel image in
wic
image for booting itself ,then cause
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 7/2/20 3:46 PM, Richard Purdie wrote:
On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote:
On 7/1/20 9:42 PM, Bruce Ashfield wrote:
On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei
wrote:
On 6/28/20 8:21 PM, Xu, Yanfei wrote:
On 6/25/20 12:18 AM, Richard Purdie wrote:
On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote:
On 6/24/20 9:08 PM, Richard Purdie wrote:
On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote:
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield
wrote:
On Fri, Jun 19, 2020 at 7:47 AM <
yanfei...@windriver.com>
wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you
will get
failure
when
you install or update the kernel rpm package. Now
we use a
copy
of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield <
bruce.ashfi...@gmail.com>
Suggested-by: Richard Purdie <
richard.pur...@linuxfoundation.org>
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19
---
1 file changed, 16 insertions(+), 3
deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' %
kname, ' %s-
image-
%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' %
(kname,typelower),
'%s-
image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname,
typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' %
(kname,
typelower),
'1')
+d.setVar('pkg_postinst_ontarget_%s-
image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if
the
unversioned
image link/copy was deferred until boot. I don't
see a
summary of
why
that's no longer a concern in the v3 of the patch.
Can you
confirm
that it isn't an issue ? Is it simply because the
booted
image
isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing
selftest
failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce
new
issues?
Yes, I reverted it and retested and confirmed this patch
causes the
selftest failure in the link to the build above.
OK, I am trying to analyse the log. But I haven't figured
out what
cause
it fialed， and how to reproduce it on my mechine. I'd
apprecate any
information.
The command to reproduce should be:
oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi
I've addressed this failure why due to boot partation in wic
doesn't
contain no-versioned image. This result is different from the
previous
I verified, because of the different configuraions in wks.
"--source" field in wks decides where the files in boot
partation come
from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot
which is
installed by rpm package. Blow is the wks used by 'oe-selftest
-r
efibootpartition.GenericEFITest.test_boot_efi'
bootloader --ptable gpt
part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
--fstype=vfat --label boot --active --align 1024 --use-uuid
--overhead-factor 1.0
part / --source rootfs --fstype=ext4 --label root --align 1024
--exclude-path boot/
Hence we still should keep the no-versioned iamge in kernel-
image*.rpm
which is like the previous v2 patch.
Any opinions? It does cause the kernel rpm larger. However, the
kernel
image is not always large, only a few MB. And it will be changed
to
symlink when installed on targe. So this patch's only negative
effect
is the little increasement about update payloads.
I'm trying to follow the description that you had about the
oe-selftest and I'm missing something.
Can you describe it again ? In a way that someone not familiar with
that the selftest is seeing as a failure can grok ?
i.e. in the selftest configuration are we not getting the
(un)versioned kernel image because the symlink (or copy fallback)
is
in an on-boot post install hook ? And the test is looking for the
versioned/unversioned kernel image at image construction time ?
So that leaves us at either installing both the versioned and
unversioned, or some sort of package install time testing of the
target filesystem ? Does that partition exist at package install
time
? Is that the approach we tried in v1 of the patch (I know v2 was
keeping both as copies in the package, and converting it to a
symlink
on boot).
Sorry for the uncleared discription.
For the os-selftest failure: The failure happened at qemu booting
with
its wic image. Qemu could not find the unversioned kernel image in
wic
image for booting itself ,then caused the test failed.
Why the booted partition in wic image doesn't contain the unversioned
kerne
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 7/1/20 9:42 PM, Bruce Ashfield wrote:
On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei wrote:
On 6/28/20 8:21 PM, Xu, Yanfei wrote:
On 6/25/20 12:18 AM, Richard Purdie wrote:
On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote:
On 6/24/20 9:08 PM, Richard Purdie wrote:
On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote:
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote:
On Fri, Jun 19, 2020 at 7:47 AM
wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get
failure
when
you install or update the kernel rpm package. Now we use a
copy
of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie <
richard.pur...@linuxfoundation.org>
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-
image-
%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-
image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname,
typelower),
'1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if the
unversioned
image link/copy was deferred until boot. I don't see a
summary of
why
that's no longer a concern in the v3 of the patch. Can you
confirm
that it isn't an issue ? Is it simply because the booted
image
isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing selftest
failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce new
issues?
Yes, I reverted it and retested and confirmed this patch causes the
selftest failure in the link to the build above.
OK, I am trying to analyse the log. But I haven't figured out what
cause
it fialed， and how to reproduce it on my mechine. I'd apprecate any
information.
The command to reproduce should be:
oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi
I've addressed this failure why due to boot partation in wic doesn't
contain no-versioned image. This result is different from the previous
I verified, because of the different configuraions in wks.
"--source" field in wks decides where the files in boot partation come
from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is
installed by rpm package. Blow is the wks used by 'oe-selftest -r
efibootpartition.GenericEFITest.test_boot_efi'
bootloader --ptable gpt
part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
--fstype=vfat --label boot --active --align 1024 --use-uuid
--overhead-factor 1.0
part / --source rootfs --fstype=ext4 --label root --align 1024
--exclude-path boot/
Hence we still should keep the no-versioned iamge in kernel-image*.rpm
which is like the previous v2 patch.
Any opinions? It does cause the kernel rpm larger. However, the kernel
image is not always large, only a few MB. And it will be changed to
symlink when installed on targe. So this patch's only negative effect
is the little increasement about update payloads.
I'm trying to follow the description that you had about the
oe-selftest and I'm missing something.
Can you describe it again ? In a way that someone not familiar with
that the selftest is seeing as a failure can grok ?
i.e. in the selftest configuration are we not getting the
(un)versioned kernel image because the symlink (or copy fallback) is
in an on-boot post install hook ? And the test is looking for the
versioned/unversioned kernel image at image construction time ?
So that leaves us at either installing both the versioned and
unversioned, or some sort of package install time testing of the
target filesystem ? Does that partition exist at package install time
? Is that the approach we tried in v1 of the patch (I know v2 was
keeping both as copies in the package, and converting it to a symlink
on boot).
Sorry for the uncleared discription.
For the os-selftest failure: The failure happened at qemu booting with
its wic image. Qemu could not find the unversioned kernel image in wic
image for booting itself ,then caused the test failed.
Why the booted partition in wic image doesn't contain the unversioned
kernel image? Cause the wks can decide where the unversioned kernel
images in wic image comes from. For this test, it comes from
${IMAGE_ROOTFS}/boot which is installed b
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 6/28/20 8:21 PM, Xu, Yanfei wrote:
On 6/25/20 12:18 AM, Richard Purdie wrote:
On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote:
On 6/24/20 9:08 PM, Richard Purdie wrote:
On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote:
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote:
On Fri, Jun 19, 2020 at 7:47 AM
wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get
failure
when
you install or update the kernel rpm package. Now we use a
copy
of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie <
richard.pur...@linuxfoundation.org>
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-
image-
%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-
image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname,
typelower),
'1')
+ d.setVar('pkg_postinst_ontarget_%s-image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if the
unversioned
image link/copy was deferred until boot. I don't see a
summary of
why
that's no longer a concern in the v3 of the patch. Can you
confirm
that it isn't an issue ? Is it simply because the booted
image
isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing selftest
failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce new
issues?
Yes, I reverted it and retested and confirmed this patch causes the
selftest failure in the link to the build above.
OK, I am trying to analyse the log. But I haven't figured out what
cause
it fialed， and how to reproduce it on my mechine. I'd apprecate any
information.
The command to reproduce should be:
oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi
I've addressed this failure why due to boot partation in wic doesn't
contain no-versioned image. This result is different from the previous
I verified, because of the different configuraions in wks.
"--source" field in wks decides where the files in boot partation come
from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is
installed by rpm package. Blow is the wks used by 'oe-selftest -r
efibootpartition.GenericEFITest.test_boot_efi'
bootloader --ptable gpt
part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
--fstype=vfat --label boot --active --align 1024 --use-uuid
--overhead-factor 1.0
part / --source rootfs --fstype=ext4 --label root --align 1024
--exclude-path boot/
Hence we still should keep the no-versioned iamge in kernel-image*.rpm
which is like the previous v2 patch.
Any opinions? It does cause the kernel rpm larger. However, the kernel
image is not always large, only a few MB. And it will be changed to
symlink when installed on targe. So this patch's only negative effect
is the little increasement about update payloads.
BTW, should I resend the v2 patch?
Cheers,
Yanfei
Cheers，
Yanfei
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140166):
https://lists.openembedded.org/g/openembedded-core/message/140166
Mute This Topic: https://lists.openembedded.org/mt/74977721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 6/25/20 12:18 AM, Richard Purdie wrote:
On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote:
On 6/24/20 9:08 PM, Richard Purdie wrote:
On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote:
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote:
On Fri, Jun 19, 2020 at 7:47 AM
wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get
failure
when
you install or update the kernel rpm package. Now we use a
copy
of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie <
richard.pur...@linuxfoundation.org>
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-
image-
%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-
image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname,
typelower),
'1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if the
unversioned
image link/copy was deferred until boot. I don't see a
summary of
why
that's no longer a concern in the v3 of the patch. Can you
confirm
that it isn't an issue ? Is it simply because the booted
image
isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing selftest
failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce new
issues?
Yes, I reverted it and retested and confirmed this patch causes the
selftest failure in the link to the build above.
OK, I am trying to analyse the log. But I haven't figured out what
cause
it fialed， and how to reproduce it on my mechine. I'd apprecate any
information.
The command to reproduce should be:
oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi
I've addressed this failure why due to boot partation in wic doesn't
contain no-versioned image. This result is different from the previous
I verified, because of the different configuraions in wks.
"--source" field in wks decides where the files in boot partation come
from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is
installed by rpm package. Blow is the wks used by 'oe-selftest -r
efibootpartition.GenericEFITest.test_boot_efi'
bootloader --ptable gpt
part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
--fstype=vfat --label boot --active --align 1024 --use-uuid
--overhead-factor 1.0
part / --source rootfs --fstype=ext4 --label root --align 1024
--exclude-path boot/
Hence we still should keep the no-versioned iamge in kernel-image*.rpm
which is like the previous v2 patch.
Cheers，
Yanfei
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140062):
https://lists.openembedded.org/g/openembedded-core/message/140062
Mute This Topic: https://lists.openembedded.org/mt/74977721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 6/24/20 9:08 PM, Richard Purdie wrote:
On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote:
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote:
On Fri, Jun 19, 2020 at 7:47 AM wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get
failure
when
you install or update the kernel rpm package. Now we use a copy
of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie <
richard.pur...@linuxfoundation.org>
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-
%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-
image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname,
typelower),
'1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if the
unversioned
image link/copy was deferred until boot. I don't see a summary of
why
that's no longer a concern in the v3 of the patch. Can you
confirm
that it isn't an issue ? Is it simply because the booted image
isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing selftest failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce new issues?
Yes, I reverted it and retested and confirmed this patch causes the
selftest failure in the link to the build above.
OK, I am trying to analyse the log. But I haven't figured out what cause
it fialed， and how to reproduce it on my mechine. I'd apprecate any
information.
Regards，
Yanfei
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139892):
https://lists.openembedded.org/g/openembedded-core/message/139892
Mute This Topic: https://lists.openembedded.org/mt/74977721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 6/24/20 5:51 AM, Richard Purdie wrote:
On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote:
On Fri, Jun 19, 2020 at 7:47 AM wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure
when
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass
b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image-
%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower),
'1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' %
(kname,typelower), """
You were previously concerned about boot issues if the unversioned
image link/copy was deferred until boot. I don't see a summary of why
that's no longer a concern in the v3 of the patch. Can you confirm
that it isn't an issue ? Is it simply because the booted image isn't
installed via this package, and hence we are fine ?
I'm suspecting this patch is why we're seeing selftest failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055
Do you mean this patch has been applied? and introduce new issues?
Regards,
Yanfei
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139873):
https://lists.openembedded.org/g/openembedded-core/message/139873
Mute This Topic: https://lists.openembedded.org/mt/74977721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
On 6/23/20 10:31 PM, Bruce Ashfield wrote:
On Fri, Jun 19, 2020 at 7:47 AM wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """
You were previously concerned about boot issues if the unversioned
image link/copy was deferred until boot. I don't see a summary of why
that's no longer a concern in the v3 of the patch. Can you confirm
that it isn't an issue ? Is it simply because the booted image isn't
installed via this package, and hence we are fine ?
Yes, it is. Previously I have a wrong thounght that the booted image in
boot partation is installed via this package. Then I confirmed it isn't
like that by compiling wic image with an empty kernel-image*.rpm（modify
kernel.bbclass）, the no-versioned iamge still be contained boot
partation.
Hence we are fine.
Yanfei
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back
to copied image (%s)."
+install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION}
${KERNEL_IMAGEDEST}/%s
+fi
+set -e
+""" % (type, type, type, type, type))
+d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """
+set +e
+if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
+rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+fi
+set -e
+""" % (type, type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to
0,
@@ -385,9 +401,6 @@ kernel_do_install() {
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
- if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
- fi
For on-target installs, this is what I was doing in the past as well.
Make the symlink during package install, that way we are encapsulated
in that unit.
That just leaves my boot question as the last remaining thing for the change.
Bruce
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139872):
https://lists.openembedded.org/g/openembedded-core/message/139872
Mute This Topic: https://lists.openembedded.org/mt/74977721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH 0/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
ping Bruce On 6/19/20 7:47 PM, Xu, Yanfei wrote: From: Yanfei Xu v1->v2->v3: 1.Put the symlink creation at postinstall script instead of build time. 2.Add a postremove script for removing image created in postinstall. Yanfei Xu (1): classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks meta/classes/kernel.bbclass | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139816): https://lists.openembedded.org/g/openembedded-core/message/139816 Mute This Topic: https://lists.openembedded.org/mt/74977720/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Suggested-by: Richard Purdie
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 20a0135fc9..1269b54343 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,22 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling
back to copied image (%s)."
+install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION}
${KERNEL_IMAGEDEST}/%s
+fi
+set -e
+""" % (type, type, type, type, type))
+d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """
+set +e
+if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then
+rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+fi
+set -e
+""" % (type, type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0,
@@ -385,9 +401,6 @@ kernel_do_install() {
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
- if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
- fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139690):
https://lists.openembedded.org/g/openembedded-core/message/139690
Mute This Topic: https://lists.openembedded.org/mt/74977721/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 0/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
From: Yanfei Xu v1->v2->v3: 1.Put the symlink creation at postinstall script instead of build time. 2.Add a postremove script for removing image created in postinstall. Yanfei Xu (1): classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks meta/classes/kernel.bbclass | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) -- 2.18.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139689): https://lists.openembedded.org/g/openembedded-core/message/139689 Mute This Topic: https://lists.openembedded.org/mt/74977720/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] classes/kernel: Use a copied image for kernel*.rpm if fs don't support symlinks
On 6/18/20 8:31 PM, Xu, Yanfei wrote:
On 6/18/20 5:52 PM, Richard Purdie wrote:
On Thu, 2020-06-18 at 15:57 +0800, Xu, Yanfei wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copied iamge
for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 41101a64a0..749d1a0f29 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,14 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' %
(kname, typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+ d.setVar('pkg_postinst_ontarget_%s-image-%s' %
(kname,typelower), """
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+ echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support
symlinks, falling back to copied image (%s)."
+fi
+set -e
+""" % (type, type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE
is set to 0,
@@ -386,7 +394,7 @@ kernel_do_install() {
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
+ install -m 0644
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
I am a bit concerned about this since whilst it solves one problem,
doesn't having two copies of the same file around significantly
increase the size of the packages and the update payloads updating such
systems would need? Are these two copies of the file in the same
package or not?
Perhaps the symlink creation should fall back to a copy on device
rather than having the copy at build time (as I understand it)?
I had a wrong understanding about the no-versioned Image in /boot
partation from wic. And I just verified that the no-versioned Image in
/boot partation seems doesn't from kernel image package. So you are
right, we don't need to have the other no-versioned image in packages.
I'll change the logic to having the copy at build time in v3.
sorry, at the postinstall thread.
Cheers,
Yanfei
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139640):
https://lists.openembedded.org/g/openembedded-core/message/139640
Mute This Topic: https://lists.openembedded.org/mt/74954288/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] classes/kernel: Use a copied image for kernel*.rpm if fs don't support symlinks
On 6/18/20 5:52 PM, Richard Purdie wrote:
On Thu, 2020-06-18 at 15:57 +0800, Xu, Yanfei wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copied iamge
for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 41101a64a0..749d1a0f29 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,14 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back
to copied image (%s)."
+fi
+set -e
+""" % (type, type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to
0,
@@ -386,7 +394,7 @@ kernel_do_install() {
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
+ install -m 0644
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
I am a bit concerned about this since whilst it solves one problem,
doesn't having two copies of the same file around significantly
increase the size of the packages and the update payloads updating such
systems would need? Are these two copies of the file in the same
package or not?
Perhaps the symlink creation should fall back to a copy on device
rather than having the copy at build time (as I understand it)?
I had a wrong understanding about the no-versioned Image in /boot
partation from wic. And I just verified that the no-versioned Image in
/boot partation seems doesn't from kernel image package. So you are
right, we don't need to have the other no-versioned image in packages.
I'll change the logic to having the copy at build time in v3.
Cheers,
Yanfei
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139639):
https://lists.openembedded.org/g/openembedded-core/message/139639
Mute This Topic: https://lists.openembedded.org/mt/74954288/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] classes/kernel: Use a copied image for kernel*.rpm if fs don't support symlinks
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copied iamge
for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 41101a64a0..749d1a0f29 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,14 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling
back to copied image (%s)."
+fi
+set -e
+""" % (type, type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0,
@@ -386,7 +394,7 @@ kernel_do_install() {
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
+ install -m 0644
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139628):
https://lists.openembedded.org/g/openembedded-core/message/139628
Mute This Topic: https://lists.openembedded.org/mt/74954288/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/1] classes/kernel: Use a copy for kernel*.rpm when fs don't support symlink
On 6/17/20 9:48 PM, Bruce Ashfield wrote:
On Wed, Jun 17, 2020 at 2:20 AM wrote:
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failed when
you install or update the kernel rpm package. Now we use a copy for
these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 41101a64a0..e9b5a84de7 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,14 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlink, then use a
copy."
This could say "... doesn't support symlinks, falling back to copied
image (%s)" (and fill in the image file we are actually using).
This discription is more clear. I will rewrite the message.
+fi
I expected to see the fallback copy here in the postinstall, but this
looks ok to me .. I'm going to just type in my process of reading the
At the beginning, I was going to only place versioned-image in rpm
package, then make symlink or copy in postinstall on target. But it will
cause rpm package don't contain no-versioned image. However, ARM device
may use the no-versioned image for booting in boot partation. So I
didn't implement it like that.
patch so you can correct me if I'm wrong.
The logic is split between the two places. Below during the build
(do_install), and here in the postinstall.
In do_install(), we no longer symlink, but instead copy the versioned
image into the non versioned 'image' file. And then in the
postinstall, we try and make a symlink (which may fail) to the same
thing (the versioned image to a non versioned one), and that's a force
symlink so it will clobber the previously copied one if possible, or
implicitly fall back if the symlink fails.
Your understanding is right.
So yes, that logic seems fine to me.
The reason I went through all that, is that for on-target upgrades.
You won't have the do_install() to place the versioned image, have you
confirmed that the versioned image file is packaged and will be
I have confirmed that both non versioned image and versioned image are
packaged in rpm package.
[bcm_2xxx_rpi4]$ rpm -qpl
kernel-image-image-5.4.46-yocto-standard-5.4.x+git0+f8c88c4331_87b52c3030-r0.bcm_2xxx_rpi4.rpm
/boot
/boot/Image
/boot/Image-5.4.46-yocto-standard
Besides, I have tested "dnf install" on target, it did place files of
package and then run postinstall script.
present on an on-target install ? So the logic is the same with the
symlink ? It should be, otherwise this would never work, but I just
wanted to be sure.
Yes, the logic is the same with the original symlink, hence I also think
there is no new bug introduced to on-target upgrades.
+set -e
+""" % (type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to
0,
@@ -386,7 +394,7 @@ kernel_do_install() {
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
+ install -m 0644
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
Looking at this, can the existing line:
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
be combined with the one you added ?
We are copying the non-versioned image into a versioned image file,
and then in the new logic, coping that versioned image into a
non-versioned one. Couldn't we just have one copy of the non-versioned
image, into the non-versioned image in KERNEL_IMAGEDEST ?
I don't think it could be. Cause the existing line :
"if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then"
can't be ingnored.
Thanks for reviewing,
Yanfei
Cheers,
Bruce
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
@@ -602,6 +610,7 @@ pkg_postinst_${KERNEL_PACKAGE_NAME}-base () {
fi
}
+
PACKAGESPLITFUNCS_prepend = "split_kernel_packages "
python split_kernel_packages () {
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messa
[OE-core] [PATCH 0/1] classes/kernel: Use a copy for kernel*.rpm when fs don't support symlink
From: Yanfei Xu
Some explains about this patch:
1.Why does it copy a ${imageType} before postintall?
We should ensure the rpm package contain a iamge named ${imageType}
before runing on target.
2.Why should we have this patch?
Cause some arm boards always mount their booting partition on /boot
and then upgrade kernel packages. But if the /boot filesystems don't
support symlink, it will fail.
Yanfei Xu (1):
classes/kernel: Use a copy for kernel*.rpm when fs don't support
symlink
meta/classes/kernel.bbclass | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139581):
https://lists.openembedded.org/g/openembedded-core/message/139581
Mute This Topic: https://lists.openembedded.org/mt/74932614/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/1] classes/kernel: Use a copy for kernel*.rpm when fs don't support symlink
From: Yanfei Xu
Some filesystems don't support symlink, then you will get failed when
you install or update the kernel rpm package. Now we use a copy for
these filesystems instead of symlink.
Suggested-by: Bruce Ashfield
Signed-off-by: Yanfei Xu
---
meta/classes/kernel.bbclass | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 41101a64a0..e9b5a84de7 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -94,6 +94,14 @@ python __anonymous () {
d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname,
typelower))
d.setVar('PKG_%s-image-%s' % (kname,typelower),
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
+d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """
+set +e
+ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1
+if [ $? -ne 0 ]; then
+echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlink, then use
a copy."
+fi
+set -e
+""" % (type, type))
image = d.getVar('INITRAMFS_IMAGE')
# If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0,
@@ -386,7 +394,7 @@ kernel_do_install() {
for imageType in ${KERNEL_IMAGETYPES} ; do
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
- ln -sf ${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
+ install -m 0644
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
${D}/${KERNEL_IMAGEDEST}/${imageType}
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
@@ -602,6 +610,7 @@ pkg_postinst_${KERNEL_PACKAGE_NAME}-base () {
fi
}
+
PACKAGESPLITFUNCS_prepend = "split_kernel_packages "
python split_kernel_packages () {
--
2.18.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139580):
https://lists.openembedded.org/g/openembedded-core/message/139580
Mute This Topic: https://lists.openembedded.org/mt/74932613/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] kernel: update rpm failed for the vfat
On 6/12/20 9:27 PM, Bruce Ashfield wrote:
On Fri, Jun 12, 2020 at 3:47 AM Xu, Yanfei wrote:
Ping Bruce.
Hmm, yes. I did miss the original message.
gmail isn't as effective at highlighting messages that are to me (and
also to the list) as I would like.
On 6/9/20 6:32 PM, Xu, Yanfei wrote:
Hi Bruce,
I encountered an issue that updating kernel rpm package will fail when
the /boot dir was mount with vfat filesystem. The root cause is vfat
don't support symlink.
cut here--
error: unpacking of archive failed on file /boot/Image;5eda8385: cpio:
symlink failed - Resource temporarily unavailable
error:
kernel-image-image-5.4.43-yocto-standard-5.4.x+git0+f8c88c4331_9961cc8b79-r0.bcm_2xxx_rpi4:
install failed
root@bcm-2xxx-rpi4:/boot#
Currently I have two ideas to fix it:
1. we use 'install' cmd instead of 'ln -sf' in kernel_do_install to
avoid generating symlink in kernel-image-image*.rpm. And then add an
postinstall to this rpm. It will check if the /boot dir is vfat, if not,
we remove the copy image* and make a softlink for the image.
Note that for this option, you have to make sure that it really is
done in a post install or you end up with overlapping file errors in
scenarios where multiple kernel packages are installed (i.e. an
upgrade).
2. we specially add an package type which doesn't contain symlink for
the vfat filesystem.
For the first idea, I met an problem when I try to add
pkg_postinst_packagename function in kernel.bbclass file. Due to there
are not package name variables defined for the kernel-image-image.gz
kernel-image-image or other type kernel images. So I can not add
postinst functions statically why that how many packages and packages'
name are not certainly.
You can still generate the package names in python, i.e.:
d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,
typelower), 'ln -sf ' + type + '-${KERNEL_VERSION}
/${KERNEL_IMAGEDEST}/' + type)
This is a piece of very useful code!
Thanks for your detailed suggestions, and I have implemented it basicly. ：)
Cheers,
Yanfei
that's from a patch that I've had locally for a while, that deals with
kernel upgrade issues.
Any logic that deals with this really does have to be on target,
otherwise, information about the image (and partitions) is leaking
into the packages, and you'd need to carry specific image package
lists for the filesystem layout.
My suggestion for the post install is that it simply try and create
the symlink, and if that fails, then do a copy. That way there's no
need to detect filesystem types, etc.
You also need to ensure that you test the kernel upgrade path, since
with copies, you may end up with more kernel images around boot and
not get some of the implicit cleanup that you get by simply
redirecting a symlink (but if you are always copying the active kernel
to "image", then simply overwriting the target will get you that same
cleanup).
Cheers,
Bruce
Do you have any opinions about these?
Regards,
Yanfei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139495):
https://lists.openembedded.org/g/openembedded-core/message/139495
Mute This Topic: https://lists.openembedded.org/mt/74771247/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] kernel: update rpm failed for the vfat
Ping Bruce. On 6/9/20 6:32 PM, Xu, Yanfei wrote: Hi Bruce, I encountered an issue that updating kernel rpm package will fail when the /boot dir was mount with vfat filesystem. The root cause is vfat don't support symlink. cut here-- error: unpacking of archive failed on file /boot/Image;5eda8385: cpio: symlink failed - Resource temporarily unavailable error: kernel-image-image-5.4.43-yocto-standard-5.4.x+git0+f8c88c4331_9961cc8b79-r0.bcm_2xxx_rpi4: install failed root@bcm-2xxx-rpi4:/boot# Currently I have two ideas to fix it: 1. we use 'install' cmd instead of 'ln -sf' in kernel_do_install to avoid generating symlink in kernel-image-image*.rpm. And then add an postinstall to this rpm. It will check if the /boot dir is vfat, if not, we remove the copy image* and make a softlink for the image. 2. we specially add an package type which doesn't contain symlink for the vfat filesystem. For the first idea, I met an problem when I try to add pkg_postinst_packagename function in kernel.bbclass file. Due to there are not package name variables defined for the kernel-image-image.gz kernel-image-image or other type kernel images. So I can not add postinst functions statically why that how many packages and packages' name are not certainly. Do you have any opinions about these? Regards, Yanfei -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139433): https://lists.openembedded.org/g/openembedded-core/message/139433 Mute This Topic: https://lists.openembedded.org/mt/74771247/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] kernel: update rpm failed for the vfat
Hi Bruce, I encountered an issue that updating kernel rpm package will fail when the /boot dir was mount with vfat filesystem. The root cause is vfat don't support symlink. cut here-- error: unpacking of archive failed on file /boot/Image;5eda8385: cpio: symlink failed - Resource temporarily unavailable error: kernel-image-image-5.4.43-yocto-standard-5.4.x+git0+f8c88c4331_9961cc8b79-r0.bcm_2xxx_rpi4: install failed root@bcm-2xxx-rpi4:/boot# Currently I have two ideas to fix it: 1. we use 'install' cmd instead of 'ln -sf' in kernel_do_install to avoid generating symlink in kernel-image-image*.rpm. And then add an postinstall to this rpm. It will check if the /boot dir is vfat, if not, we remove the copy image* and make a softlink for the image. 2. we specially add an package type which doesn't contain symlink for the vfat filesystem. For the first idea, I met an problem when I try to add pkg_postinst_packagename function in kernel.bbclass file. Due to there are not package name variables defined for the kernel-image-image.gz kernel-image-image or other type kernel images. So I can not add postinst functions statically why that how many packages and packages' name are not certainly. Do you have any opinions about these? Regards, Yanfei -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139355): https://lists.openembedded.org/g/openembedded-core/message/139355 Mute This Topic: https://lists.openembedded.org/mt/74771247/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
