[yocto] Fwd: Basehash value changed issue
Hi, Can anybody give me hint over below issue. Thanks -- Forwarded message -- From: techi eth Date: Thu, Jun 21, 2018 at 6:30 PM Subject: Basehash value changed issue To: yocto@yoctoproject.org Hi, I am facing issue with basehash value changed while building image on one of my test board (Ref of beagle bone) on morty branch. Error : gateway.bb.do_rootfs, the basehash value changed from e685a429b8df6dcff60063f087d425ee to 3f98a102f48ea8722835ad0d65bfbc1f. The metadata is not deterministic and this needs to be fixed When i run bitbake-diffsigs -t gateway do_rootfs I found below O/P. basehash changed from 8e6b9498c9704590bd016491efcbf9f9 to 3f98a102f48ea8722835ad0d65bfbc1f Variable TIME value changed from '112854' to '115745' After googling I found that TIME need's to be added in vardepsexclude list. I added below in conf/distro/machine.conf but error persist. do_rootfs[vardepsexclude] = "TIME DATE DATETIME" Please suggest me where & what has to be added to come out of issue. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Regarding Use the Latest LTP on Latest YOCTO build
Hello Team,
Could you please provide your suggestion regarding above issue.
On Thu, Jun 28, 2018 at 1:05 PM, Abhishek Kumar Rai <
abhish...@eximiusdesign.com> wrote:
> Hi Burton Ross,
> Thanks for your prompt reply.
>
> I have some doubt please clarify
> I can use the latest release also but i am getting below error in version
> 2.3
> {{{
>
> ltp-20170116-r0 do_compile: NOTE: ltp: compiling from external source
> tree ~/build/https:/github.com/linux-test-project/ltp.git
> ERROR: ltp-20170116-r0 do_compile: oe_runmake failed
> ERROR: ltp-20170116-r0 do_compile: Function failed: do_compile (log
> file is located at
> ~/build/tmp/work/cortexa9hf-neon-agl-linux-gnueabi/ltp/20170116-
> r0/temp
> /log.do_compile.161006)
> ERROR: Logfile of failure stored in:
> ~/build//tmp/work/cortexa9hf-neon-agl-
> linux-gnueabi/ltp/20170116-r0/temp/log.do_compile.161006
> Log data follows:
> | DEBUG: Executing python function externalsrc_compile_prefunc
> | NOTE: ltp: compiling from external source tree~/build//https:/
> github.com/linux-test-project/ltp.git
> | DEBUG: Python function externalsrc_compile_prefunc finished
> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
> 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 16
> | ERROR: oe_runmake failed
> | make: Entering directory '~/build/https:/github.com/linux-test-
> project/ltp.git/testcases/kernel'
> | make: 'include/linux_syscall_numbers.h' is up to date.
> | make: Leaving directory '~/build/https:/github.com/linux-test-
> project/ltp.git/testcases/kernel'
> | ~/build/https:/github.com/linux-test- project/ltp.git/include/mk/
> automake.mk:108: *** target pattern contains no '%'. Stop.
> | ERROR: Function failed: do_compile (log file is located at
> ~/build/tmp/work/cortexa9hf-neon-agl-linux-gnueabi/ltp/20170116-
> r0/temp/log.do_compile.161006)
>
> }}}
> Note :
> $ bitbake --version
>BitBake Build Tool Core version 1.34.0
> Regards,
> Abhishek
>
> On Thu, Jun 28, 2018 at 12:49 PM, Burton, Ross
> wrote:
>
>> Just so you know, 2.3 is a year old. 2.5 is the latest release.
>>
>> On 28 June 2018 at 06:59, Abhishek Kumar Rai > > wrote:
>>
>>> Hi Team,
>>>
>>> I am planning to use the LTP latest version on YOCTO latest vesion.
>>> It seems that the earlier YOCTO versions are released with LTP and
>>> latest version are not.
>>> Found the below difficulties so far:
>>> 1. Latest LTP version(20180118) suitable for old gcc version(4.8).
>>> 2. But at the same time, latest version of YOCTO build(2.3) supporting
>>> latest
>>> gcc version(6.3) only.
>>>
>>> so we want to use a latest LTP version(20180118) with latest YOCTO
>>> build(2.3) which has latest gcc version(6.3) .
>>>
>>> Please share your valuable inputs with me to achieve the same.
>>>
>>> Thanks & Regards,
>>> Abhishek Rai
>>>
>>> The information contained in this e-mail message (including any
>>>
>>> attachments) may be confidential, proprietary, privileged, or otherwise
>>>
>>> exempt from disclosure under applicable laws. It is intended to be
>>>
>>> conveyed only to the designated recipient(s). Any use, dissemination,
>>>
>>> distribution, printing, retaining or copying of this e-mail (including
>>> its
>>>
>>> attachments) by unintended recipient(s) is strictly prohibited and may
>>>
>>> be unlawful. If you are not an intended recipient of this e-mail, or
>>> believe
>>>
>>> that you have received this e-mail in error, please notify the sender
>>>
>>> immediately (by replying to this e-mail), delete any and all copies of
>>>
>>> this e-mail (including any attachments) from your system, and do not
>>>
>>> disclose the content of this e-mail to any other person. Thank you for
>>> your cooperation.
>>>
>>> *This e-mail message (including any attachments) may be confidential,
>>> proprietary, privileged, or otherwise exempt from disclosure under
>>> applicable laws. If you are not an intended recipient, please delete this
>>> message. Thank you.*
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>
--
The information contained in this e-mail message (including
any
attachments) may be confidential, proprietary, privileged, or
otherwise
exempt from disclosure under applicable laws. It is intended to
be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including
its
attachments) by unintended recipient(s) is strictly prohibited and
may
be unlawful. If you are not an intended recipient of this e-mail, or
believe
that you have received this e-mail in error, please notify the
sender
immediately (by replying to this e-mail), delete any and all
[yocto] [Recipe reporting system] Upgradable recipe name list
This mail was sent out by Recipe reporting system. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade at this time, they can fill RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable" You can check the detail information at: http://recipes.yoctoproject.org/ Package Version Upstream version Maintainer NoUpgradeReason --- --- -- libgloss 3.0.03.0.0.20180226Alejandro Hernandez newlib3.0.03.0.0.20180226Alejandro Hernandez usbutils 009 010 Alexander Kanavin webkitgtk 2.20.2 2.20.3Alexander Kanavin ca-certificates 20170717 20180409 Alexander Kanavin gdbm 1.14.1 1.16 Alexander Kanavin vala 0.40.4 0.40.7Alexander Kanavin createrepo-c 0.10.0+gitX 0.11.0Alexander Kanavin dnf 2.7.53.0.2 Alexander Kanavin librepo 1.8.11.9.0 Alexander Kanavin ffmpeg4.0 4.0.1 Alexander Kanavin icu 61.1 62.1 Alexander Kanavin btrfs-tools 4.16.1 4.17 Alexander Kanavin procps3.3.14 3.3.15Alexander Kanavin psmisc23.0 23.1 Alexander Kanavin sysprof 3.26.1 3.28.1Alexander Kanavin Waiting for resolution of h... cantarell-fonts 0.0.24 0.0.25Alexander Kanavin epiphany 3.28.1.1 3.28.3.1 Alexander Kanavin libdnf0.11.1 0.15.2Alexander Kanavin busybox 1.27.2 1.29.0Andrej Valek apt 1.2.24 1.6.2 Aníbal Limón apt-native1.2.24 1.6.2 Aníbal Limón dpkg 1.18.24 1.19.0.5 Aníbal Limón gst-examples 0.0.1+gitX 0.0.1-new-commits... Anuj Mittal xf86-input-mouse 1.9.21.9.3 Armin Kuster xf86-video-fbdev 0.4.40.5.0 Armin Kuster nss 3.37.1 3.38 Armin Kuster bind 9.10.6 9.13.1Armin Kuster xserver-xorg 1.19.6 1.20.0Armin Kuster linux-libc-headers4.15.7 4.17.3Bruce Ashfield connman 1.35 1.36 Changhyeok Bae ethtool 4.16 4.17 Changhyeok Bae iputils s20161105s20180629 Changhyeok Bae pciutils 3.5.63.6.0 Chen Qi acl 2.2.52 2.2.53Chen Qi attr 2.4.47 2.4.48Chen Qi systemd-boot 237 239 Chen Qi cups 2.2.62.2.8 Chen Qi flex 2.6.02.6.4 Chen Qi systemd 237 239 Chen Qi bison 3.0.43.0.5 Chen Qi sed 4.2.24.5 Chen Qi shadow4.2.14.6 Chen Qi sysstat 11.7.3 11.7.4Chen Qi coreutils 8.29 8.30 Chen Qi lzop 1.03 1.04 Denys Dmytriyenko xz5.2.35.2.4 Denys Dmytriyenko python3-dbus 1.2.61.2.8 Derek Straka python-numpy 1.14.2 1.14.5Derek Straka python3-pygobject 3.28.1 3.28.3Derek Straka python3 3.5.53.7.0 Derek Straka python2.7.14 2.7.15Derek Straka python3-git 2.1.82.1.10Derek Straka python3-pip 9.0.310.0.1Derek Straka python-setuptools 39.0.1 39.2.0Derek Straka python3-numpy 1.14.2 1.14.5Derek Straka python3-pycairo 1.15.6 1.17.0Derek Straka python3-setuptools39.0
Re: [yocto] Kernel Crash when moving from Pyro to Rocko (or master): change in kernel compile process or flags?
Hi,
We too are experiencing this crash when attempting to upgrade from
Pyro to Rocko.
Has anyone been able to work out the cause, or can someone look into
it? I can supply any debug information needed (just let me know).
Regards,
Mathew
> Hi,
> I am experiencing a Kernel crash when moving my system from Yocto 2.3 (Pyro)
> to Rocko or Master.
> Target system is an ARMv7 (NXP Layerscape LS1021a, built on Cortex-A7).
> This is what I did:
> 1) switched poky version
> 2) re-built same image in a new, blank directory
> Results:
> Root-FS works fine, the kernel crashes with an undefined instruction oops.
> Just exchanging the kernel zImage with the one compiled with Pyro (same
> recipe), my system works fine again.
> What I tried so far:
> 1) checked and compared the kernel configs generated: 100% identical
> 2) switched gcc back to the version used in Pyro (6.3) instead of 7.2: kernel
> still crashes, same oops, no changes. So it's not related to GCC 7.2
> 3) checked on different boards: same issue for the same board type, but the
> switch to rocko worked fine for a system based on Cortex-A9.
> I am using separate tmp directories and am not sharing sstate. I always
> started builds in blank build directories.
> The error is reproducible (100%)
> It was also present with all of the various snapshots of the master branch I
> tried
> What I suspect: there are some changes in the ways that gcc is called from
> pyro to rocko. Maybe one of the switches, or features, etc
> Before deep-diving into the trial and error phase of reproducing the CFLAGS,
> etc:
> Is anyone experiencing the same issues?
> * What exactly has changed in the way the kernel build is called (methods,
> compile/link flags, etc) between pyro and rocko? *
> * Is there a way to (easily) disable some of the features to test which one
> causes the issue? *
> * Any suspicions about what could cause this? *
> Pls. find a log of the crash below, and an excerpt of my kernel recipe and
> machine configuration.
> Thanks in advance for your help,
> Best regards,
> Michael
> -
> VFS: Mounted root (ext4 filesystem) on device 179:1.
> devtmpfs: mounted
> Freeing unused kernel memory: 2048K
> Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
> Modules linked in:
> CPU: 1 PID: 1 Comm: init Not tainted 4.14.2-avnet-nxp #2
> Hardware name: Freescale LS1021A
> task: bf0a task.stack: bf09a000
> PC is at ret_fast_syscall+0x2/0x52
> LR is at SyS_brk+0x109/0x128
> pc : [<80205fc2>]lr : [<802c513d>]psr: 6013
> sp : bf09bfa8 ip : 70c5387d fp : 1000
> r10: r9 : bf09a000 r8 : 802061a4
> r7 : 002d r6 : 76f71bac r5 : 00010034 r4 : 0009
> r3 : 000273c8 r2 : 0001 r1 : r0 : 00028000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 70c5387d Table: be7d1000 DAC: fffbfff3
> Process init (pid: 1, stack limit = 0xbf09a210)
> Stack: (0xbf09bfa8 to 0xbf09c000)
> bfa0: 0009 00010034 7ee86fea 0001
> bfc0: 0009 00010034 76f71bac 002d 0001 0001 1000
> bfe0: 7ee86f14 7ee86e4c 76f87a58 76f88e88 6010
> Code: 20012000 bd08 b672 (2008f8d9)
> ---[ end trace 7bab6dceda641aab ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
> CPU0: stopping
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 4.14.2-avnet-nxp #2
> Hardware name: Freescale LS1021A
> [<8020bbe9>] (unwind_backtrace) from [<80208e77>] (show_stack+0xb/0xc)
> [<80208e77>] (show_stack) from [<8066af19>] (dump_stack+0x69/0x78)
> [<8066af19>] (dump_stack) from [<8020b1d5>] (handle_IPI+0x261/0x274)
> [<8020b1d5>] (handle_IPI) from [<802012b1>] (gic_handle_irq+0x61/0x64)
> [<802012b1>] (gic_handle_irq) from [<8067d953>] (__irq_svc+0x53/0x7c)
> Exception stack(0x80e01f38 to 0x80e01f80)
> 1f20: 27d0
> 1f40: 3eb79000 80212641 e000 80e03cd0 80e03c74 80e7f3ab 8096e480 80e03c40
> 1f60: 80e8ce00 80c42a30 0140 80e01f88 80206a3d 80206a3e 4033
> [<8067d953>] (__irq_svc) from [<80206a3e>] (arch_cpu_idle+0x22/0x24)
> [<80206a3e>] (arch_cpu_idle) from [<802405bf>] (do_idle+0x9f/0xe4)
> [<802405bf>] (do_idle) from [<802407bb>] (cpu_startup_entry+0x13/0x14)
> [<802407bb>] (cpu_startup_entry) from [<80c00a05>] (start_kernel+0x305/0x310)
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> ---
> Excerpt from linux_xxx.bb:
>
> DEPENDS_kernel-base += "kernel-devicetree"
> LINUX_VERSION = "4.14-stable"
> S = "${WORKDIR}/git"
> PR = "r1"
> SRCREV = "8292fd8d726105abc01dae26d0a2cddcf53d4e0f"
> PV = "4.14.2"
> SRC_URI = " \
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=master;protocol=git;nobranch=1
> \
> "
> SRC_URI_append_ls1021a = " file://defconfig "
> SRC_URI_append_ls1021
