I get an error while building an image using Yocto (dizzy):
ERROR: Creation of tar /mnt/workspace/build/tmp/deploy/tar/xev-dbg-1.2.1-r0.tar.gz failed.
and bitbake command fails with the following report:
No currently running tasks (6291 of 6292)
NOTE: Tasks Summary: Attempted 6292 tasks of which 18 didn't need to be rerun and all succeeded.
Summary: There were 13 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
If I check the file xev-dbg-1.2.1-r0.tar.gz, I get:
$ file /mnt/workspace/build/tmp/deploy/tar/xev-dbg-1.2.1-r0.tar.gz
/mnt/workspace/build/tmp/deploy/tar/xev-dbg-1.2.1-r0.tar.gz: gzip compressed data, from Unix, last modified: Mon Mar 27 20:19:55 201
and it is the same case for the remaining two errors.
I am confused:
if there was an error, why bitbake is reporting that all tasks succeeded?
If the file were successfully created, why bitbake exits with non zero value?
Bitbake did not return a 0 exit-code. This mean that there are errors in the bitbake process.
There are 3 errors when it is trying to create the tar files as shown.
The compressed file is there but it is not complete. E.g. Just like how you could download a file and interrupt it and the download file is still there. So we usually use md5sum or some kind of hash number to check on the completeness of the file.
A better understanding might be: Bitbake attempted to run 6292 task. 18 of them do not need to rerun. Bitbake attempted to rerun the rest 6274(6292-18) and succeeded in rerunning them. This does not mean that all of them are successfully compiled. In the process of rerunning them, there are 13 warnings and and 3 errors appeared. Because of the 3 errors, bitbake returns with a non-zero exit code.
No currently running tasks (6291 of 6292)
NOTE: Tasks Summary: Attempted 6292 tasks of which 18 didn't need to be rerun and all succeeded.
Summary: There were 13 WARNING messages shown.
Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
Related
I have read through the direvent documentation and am trying to get a simple watch working. Since I am having so much trouble with it, I am wondering if the issue has to do with the fact that the system I am using is nixos.
Here is the simple watcher file, watcher, I've created:
watcher {
path ./dir;
command "echo $file";
}
I run it in the foreground, so I can see the output, with direvent --foreground watcher. Once it's running, I create a file in dir, thus creating an event for it to respond to. However, it fails with the following output:
$ direvent --foreground watcher
direvent: [INFO] direvent 5.2 started
direvent: [ERROR] process 8552 failed with status 127
direvent: [ERROR] process 8555 failed with status 127
direvent: [ERROR] process 8557 failed with status 127
Since 127 usually means 'command not found', I tried specifying the path to echo, i.e. running this watcher instead:
watcher {
path ./dir;
command "/run/current-system/sw/bin/echo $file";
}
Then the output still gives an error, albeit a different one:
$ direvent --foreground watcher
direvent: [INFO] direvent 5.2 started
direvent: [ERROR] process 8645 failed with status 1
direvent: [ERROR] process 8651 failed with status 1
direvent: [ERROR] process 8652 failed with status 1
So the failure is now with status 1. I am not sure what to try next. I'm wondering if this issue is due to the fact that I am running nixos. Anyone know what I might try next to get direvent working?
direvent has two other flag that may be useful for you.
--debug(-d) to give extra information.
There's also --lint(t) that check the configuration file for errors, but I suspect this isn't your issue if direvent is running.
Source: https://www.gnu.org.ua/software/direvent/manual/direvent.html
When running formatjs extract this is what we got. From the stack trace it seems that the issue is from formatjs themselves. Feel like I am stuck on what the issue is here.
$ formatjs extract './src/**/*.{js,ts,tsx}' --out-file './src/i18n/messages/messages.json' --extract-from-format-message-call --throws
Error: Debug Failure. Output generation failed
at Object.transpileModule (/Users/.../node_modules/#formatjs/cli/node_modules/typescript/lib/typescript.js:126894:29)
at processFile (/Users/.../node_modules/#formatjs/cli/src/extract.js:104:39)
at /Users/.../node_modules/#formatjs/cli/src/extract.js:163:59
at step (/Users/.../node_modules/#formatjs/cli/src/extract.js:44:23)
at Object.next (/Users/.../node_modules/#formatjs/cli/src/extract.js:25:53)
at fulfilled (/Users/.../node_modules/#formatjs/cli/src/extract.js:16:58)
error Command failed with exit code 1.
You might be processing a file that needs to be ignored using --ignore. Can you upgrade to the latest version and re-run your command? Long added the filename in this commit https://github.com/formatjs/formatjs/commit/ceb0bf8a58c13fe6811bc35191018ee1c431484a
Reference: https://github.com/formatjs/formatjs/issues/2044
Due to the Internet connect is poor on customer side, I copied the tar file of my Yocto Project to customer.
However, customer met an issue while untar the Yocto Project and run the bitbake command to build project on their PC.
Customer got the following build code error:
s32v#s32v-vm:~/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release$ bitbake fsl-image-s32v2xx
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Error, TMPDIR has changed location. You need to either move it back to /media/2T_HDD_for_SDK/Amingo/S32V/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp or rebuild
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
I edited /build_s32v234evb_release/tmp/saved_tmpdir file to re-position the tmp directory, this error has pass.
However, I got another error while building Kernel, it seems the directory parameter is still wrong... (There is no error while building U-Boot only.)
s32v#s32v-vm:~/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release$ bitbake fsl-image-s32v2xx
Loading cache: 100% |########################################################################################################################################################################| ETA: 00:00:00
Loaded 2462 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.26.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-14.04"
TARGET_SYS = "aarch64-fsl-linux"
MACHINE = "s32v234evb"
DISTRO = "fsl-networking"
DISTRO_VERSION = "1.8"
TUNE_FEATURES = "aarch64"
TARGET_FPU = ""
meta
meta-yocto
meta-yocto-bsp = "(nobranch):03b0fbcf6b3b5cd16ae16738fbaabd1c6bf98536"
meta-fsl-arm = "(nobranch):c9f259a4bf8472dfa3ff75f1c3fcbe5e0ded7aaf"
meta-fsl-networking = "(nobranch):b8ff02a8d508464a16c84e1d13c155f45aa98cbe"
meta-fsl-toolchain = "(nobranch):0a235c4bcd4057608ee60b8c898eec9509632b95"
meta-virtualization = "(nobranch):0277cbcb47db4239d0a4aa3b37c5c6a705070951"
meta-fsl-s32v = "<unknown>:<unknown>"
meta-oe
meta-networking
meta-python
meta-webserver
meta-filesystems = "(nobranch):c841231b9f327d2d06d19d2ba1324dd86b83617c"
meta-linaro
meta-aarch64
meta-linaro-toolchain = "(nobranch):5075a82bd510d19617803fb16da2375605225cbb"
NOTE: Preparing RunQueue
WARNING: /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/meta-fsl-s32v/recipes-kernel/linux/linux-s32v2xx_4.1.26.bb.do_compile is tainted from a forced run
WARNING: /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/meta-fsl-s32v/recipes-bsp/u-boot/u-boot-s32v2xx_2016.01.bb.do_compile is tainted from a forced run
WARNING: /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/meta-fsl-s32v/recipes-bsp/u-boot/u-boot-s32v2xx_2016.01.bb.do_deploy is tainted from a forced run
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_compile (log file is located at /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/s32v234evb-fsl-linux/linux-s32v2xx/4.1.26-r0/temp/log.do_compile.17853)
ERROR: Logfile of failure stored in: /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/s32v234evb-fsl-linux/linux-s32v2xx/4.1.26-r0/temp/log.do_compile.17853
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4 Image CC=aarch64-fsl-linux-gcc --sysroot=/home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/sysroots/s32v234evb LD=aarch64-fsl-linux-ld.bfd --sysroot=/home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/sysroots/s32v234evb
| make: *** /media/2T_HDD_for_SDK/Amingo/S32V/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work-shared/s32v234evb/kernel-source: No such file or directory. Stop.
| make: *** [__sub-make] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/s32v234evb-fsl-linux/linux-s32v2xx/4.1.26-r0/temp/log.do_compile.17853)
ERROR: Task 76 (/home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/meta-fsl-s32v/recipes-kernel/linux/linux-s32v2xx_4.1.26.bb, do_compile) failed with exit code '1'
ERROR: Function failed: do_compile (log file is located at /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_compile.17854)
ERROR: Logfile of failure stored in: /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_compile.17854
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4
| LINK tests/qemu-iotests/socket_scm_helper
| GEN qemu-doc.html
| GEN qemu.1
| CC qga/commands.o
| cc1: warning: /media/2T_HDD_for_SDK/Amingo/S32V/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/sysroots/x86_64-linux/usr/include/pixman-1: No such file or directory [enabled by default]
| cc1: warning: /media/2T_HDD_for_SDK/Amingo/S32V/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/sysroots/x86_64-linux/usr/include/glib-2.0: No such file or directory [enabled by default]
| cc1: warning: /media/2T_HDD_for_SDK/Amingo/S32V/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/sysroots/x86_64-linux/usr/lib/glib-2.0/include: No such file or directory [enabled by default]
| /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/qemu-2.2.0/qga/commands.c:13:18: fatal error: glib.h: No such file or directory
| #include <glib.h>
| ^
| compilation terminated.
| make: *** [qga/commands.o] Error 1
| make: *** Waiting for unfinished jobs....
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/build_s32v234evb_release/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_compile.17854)
ERROR: Task 2849 (virtual:native:/home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/poky/meta/recipes-devtools/qemu/qemu_2.2.0.bb, do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1504 tasks of which 1502 didn't need to be rerun and 2 failed.
Waiting for 0 running tasks to finish:
Summary: 2 tasks failed:
/home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/meta-fsl-s32v/recipes-kernel/linux/linux-s32v2xx_4.1.26.bb, do_compile
virtual:native:/home/s32v/s32v_15.0/yocto_auto_linux_bsp15.0/poky/meta/recipes-devtools/qemu/qemu_2.2.0.bb, do_compile
Summary: There were 3 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
My question is:
Is it possible to copy the Yocot Project to another PC by tar file?
What configuration / initial files I need to edit except saved_tmpdir file?
Which file does Yocto Project define the "kernel-source" directory?
Best Regards,
Wayne Kuo
when you copy tar project to another PC, two files will be modified:
build/conf/bblayers.conf
build/tmp/saved_tmpdir
If it's only a matter of internet connection, I suggest you create a download folder mirror.
On your side, you add BB_GENERATE_MIRROR_TARBALLS and build.
Then copy entire DL_DIR folder at customer side, and use BB_NO_NETWORK there.
You can look here and here for usage example.
You can then make a new build at customer side without internet connection. to speed up process, you can also copy your sstate-cache folder to customer side and add a sstate mirror with SSTATE_MIRRORS.
No, you will need a fresh build folder
You need to create a new Yocto environment at customer side
It's bitbake variable STAGING_KERNEL_DIR
Error, TMPDIR has changed location. You need to either move it back to...
I built all yocto stuff with the user jamie. Due to disk space running out, I copied the whole $HOME directory of jamie to another disk /dev/sdb1, which had a larger storage.
When I tried to run bitbake command to make a test, I got the same error. Here is a simple solution which worked for me:
mount /dev/sdb1 /mnt/sdb1/
mount --bind /mnt/sdb1/home_jamie/ /home/jamie/
What I want was to restore the exact original filesystem layout which the bitbake commands were once run with.
To make the above changes permanent, write above mounting as entries of /etc/fstab.
I've been reading through LFS while following the instructions till I got to the point where I needed to compile glibc-2.25 for the actual system.
After running make check, have encountered the following failures:
FAIL: nptl/tst-cond17
FAIL: posix/tst-getaddrinfo4
FAIL: posix/tst-getaddrinfo5
Summary of test results:
3 FAIL
2640 PASS
26 UNSUPPORTED
43 XFAIL
2 XPASS
make[1]: *** [Makefile:355: tests] Error 1
make[1]: Leaving directory '/sources/glibc-2.25'
make: *** [Makefile:9: check] Error 2
Both posix/tst-getaddrinfo4 and posix/tst-getaddrinfo5 failures should pose no real threat as indicated by LFS, but I am not sure about the first failure nptl/tst-cond17.
I have checked the source file and found out that all it does is defining some sort of variable. Here's the code.
#define UNLOCK_AFTER_BROADCAST 1
#include "tst-cond16.c"
Is it not critical to the build process? or should I try to fix it somehow?
EDIT:
The files nptl/tst-cond17.o, nptl/tst-cond17.o.d and nptl/tst-cond17.out are empty, while the contents of the file nptl/tst-cond17.test-result are:
FAIL: nptl/tst-cond17
original exit status 127
I have checked our records, and tst-cond17 is not generally known to generate spurious failures (or as being affected by unfixed kernel bugs). I found a reference to a tst-cond17 failure in the glibc 2.20 release notes, but the submitter comments that, ‘The NPTL failures not mentioned as architecture-independent are thought to result from general unreliability of the board being used for testing.’, so I assume that this does not count.
I would say the tst-cond17 failure is worth investigating further, especially if you can reproduce it.
I have a BitBake build process that runs on a Docker container (CentOS 7). The BitBake fails during recipe gcc-cross-i586-5.2.0-r0: task do_compile on each run that I try it in.
An example of bitbake's output:
NOTE: recipe gcc-cross-i586-5.2.0-r0: task do_compile: Started
ERROR: Worker process (367) exited unexpectedly (-9), shutting down...
ERROR: Worker process (367) exited unexpectedly (-9), shutting down...
ERROR: Worker process (367) exited unexpectedly (-9), shutting down...
ERROR: Worker process (367) exited unexpectedly (-9), shutting down...
NOTE: Tasks Summary: Attempted 1538 tasks of which 17 didn't need to be rerun and all succeeded.
Is this a problem with recipe gcc-cross-i586-5.2.0-r0: task do_compile? Perhaps an out-of-memory error? I don't know what the -9 refers to or how to find out more information about it.
Try:
$ bitbake -c cleansstate gcc-cross ; bitbake -k gcc-cross
How much you have memory of ram?
Report log error here.
This worked for me,
Edit conf/local.conf and decrease the number of working threads by adding the following to you conf/local.conf file (under the build directory):
BB_NUMBER_THREADS = "6"
Just a long shot, -9 in kernel land means EBADF (bad file number.) Is it possible you have done some operations as root and some files are not accessible during the build? Is the issue reproducible? ie. can you rm -rf tmp and does it happen again? Make sure you don't have any permissions issues in your project directory and associated file system(s).