Created attachment 3828 [details] task failure DESCRIPTION: When trying to build a poky-tiny with core-image-tiny-initramfs it fails because resource is not available. STEPS TO REPRODUCE ERROR: 1. git clone http://git.yoctoproject.org/git/poky 2. cd poky/ 3. vim meta/recipes-devtools/intltool/intltool_0.51.0.bb changed variable DEPENDS to DEPENDS = "libxml-parser-perl-native gettext-native" 4. git clone git://git.yoctoproject.org/meta-intel 5. cd meta-intel/ git checkout 86c55b1296a1c0b1fab6a3fd339bed0aafc92c07--------I checkout the meta-intel commit released for 2.4 M1 6. cd back poky directory git checkout 6964efddd31c479386d1643c1025bc102710392f-------I checkout the poky commit release for 2.4 M1 7. source oe-init-build-env 8. bitbake-layers add-layer "../meta-intel/ 9. vim conf/local.conf MACHINE ??= "intel-corei7-64" DISTRO ?= "poky-tiny" 10. vim conf/bblayers.conf --- just verified that meta-intel was added as a layer and it was.. "/home/liberta1/poky_tiny/poky/meta-intel \" 11. bitbake core-image-tiny-initramfs EXPECTED OUTCOME: I expected the wic images to be generated for poky tiny. ACTUAL OUTCOME: It fails and in the log there is always a message that says ....."Resource temporarily unavailable" REPRODUCIBILITY: I have tried to compile 4 times every time it fails on different task but somewhere in the log there is always a message that says ....."Resource temporarily unavailable" I send log, I am using a server for building this image and its the only task running. IMPORTANT NOTE: This issue has a fix in master, but a bug must be opened to track in the QA testcycle report for 2.4 M1 commit.
commit that holds the fix: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=be8ceea70d3016027806d6c5adc8b567e8176aa6 I will be testing this commit to verify the bug, but this will be reported in 2.4M1 and it has to block testing. Because we have to run test on the commits released for 2.4 M1.
I'm not sure this fix is linked to this issue. The issue is likely caused by low memory on the machine in question or values of parallelisation which are too high. Either way, resource issues like this are likely not really bugs in the build system but lack of resources on the build machine. Can you detail the memory available, number of builds running and numbers of cpu cores on this system please?
(In reply to comment #1) > commit that holds the fix: > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/ > ?id=be8ceea70d3016027806d6c5adc8b567e8176aa6 > > I will be testing this commit to verify the bug, but this will be reported > in 2.4M1 and it has to block testing. Because we have to run test on the > commits released for 2.4 M1. Like I said via email, this commit fixes the gettext dependency, so its related to a part of the instructions to reproduce the bug (Step #3), this it not a fix, for the issue mentioned above, and I agree with Richard, its very unlikely that this is an actual bug, this is more related to the build machine that its being used, the information Richard just asked would help to figure out what the problem is.
(In reply to comment #2) > I'm not sure this fix is linked to this issue. The issue is likely caused by > low memory on the machine in question or values of parallelisation which are > too high. Either way, resource issues like this are likely not really bugs > in the build system but lack of resources on the build machine. Can you > detail the memory available, number of builds running and numbers of cpu > cores on this system please? Only two members of GDC are asigned to the yctb05 server and I was the only one running builds at the time of this failure. I dont think resources of the server were the problem. I am not testing with the recent instructions given by hernandez. liberta1@yctb05:~/poky_tiny/poky/build> free -h total used free shared buffers cached Mem: 125G 103G 21G 365M 179M 99G -/+ buffers/cache: 4.7G 121G Swap: 1.8G 5.3M 1.8G liberta1@yctb05:~/poky_tiny/poky/build> df Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 65975532 8 65975524 1% /dev tmpfs 65982704 0 65982704 0% /dev/shm tmpfs 65982704 338684 65644020 1% /run tmpfs 65982704 0 65982704 0% /sys/fs/cgroup /dev/sda3 18574068 10260708 7346808 59% / none 65982704 40668 65942036 1% /tmp /dev/sda1 523248 4620 518628 1% /boot/efi /dev/sda4 11696218112 600924600 11095293512 6% /home tmpfs 13196544 0 13196544 0% /run/user/1089 tmpfs 13196544 0 13196544 0% /run/user/1098 yocto-nas://gdc 90716806144 10236900352 80479905792 12% /srv liberta1@yctb05:~/poky_tiny/poky/build> lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 48 On-line CPU(s) list: 0-47 Thread(s) per core: 2 Core(s) per socket: 12 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 62 Model name: Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz Stepping: 4 CPU MHz: 2034.218 CPU max MHz: 3500.0000 CPU min MHz: 1200.0000 BogoMIPS: 5399.97 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 30720K NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt
(In reply to comment #3) > (In reply to comment #1) > > commit that holds the fix: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/ > > ?id=be8ceea70d3016027806d6c5adc8b567e8176aa6 > > > > I will be testing this commit to verify the bug, but this will be reported > > in 2.4M1 and it has to block testing. Because we have to run test on the > > commits released for 2.4 M1. > > Like I said via email, this commit fixes the gettext dependency, so its > related to a part of the instructions to reproduce the bug (Step #3), this > it not a fix, for the issue mentioned above, and I agree with Richard, its > very unlikely that this is an actual bug, this is more related to the build > machine that its being used, the information Richard just asked would help > to figure out what the problem is. Thanks for the response, I have again tried to build poky-tiny with the same steps described above except step 3. It keeps failing I attached the file "logs_tasks_failed"
Created attachment 3832 [details] logs_tasks_failed
(In reply to comment #6) > Created attachment 3832 [details] > logs_tasks_failed According to the log, these are the errors I found: Summary: 3 tasks failed: /home/liberta1/poky_tiny/poky/meta/recipes-support/libcap/libcap_2.25.bb:do_package_write_rpm Caused by: | libgomp: Thread creation failed: Resource temporarily unavailable /home/liberta1/poky_tiny/poky/meta/recipes-devtools/gcc/gcc-runtime_7.1.bb:do_package_write_rpm Caused by: | libgomp: Thread creation failed: Resource temporarily unavailable /home/liberta1/poky_tiny/poky/meta-intel/common/recipes-kernel/linux/linux-intel_4.9.bb:do_compile Caused by: | make[4]: fork: Resource temporarily unavailable | /home/liberta1/poky_tiny/poky/build/tmp/work-shared/intel-corei7-64/kernel-source/scripts/Makefile.build:544: recipe for target 'net/8021q' failed | make[3]: *** [net/8021q] Error 2 This is likely being caused becuase a certain user is only allowed to run a certain number of processes, and in this case the user exceeded the specified limit, hence why when fork tries to run it shows an error. The amount of processes a user can run can be checked by: $ ulimit -a It might be worth it to monitor a runnning build to see if the limit is exceeded, once we can verify that, we can close this since if this is the case, then its not a bug.
This looks like a 48 core system and I suspect its running too many things in parallel and running out of resources. Please try something like BB_NUMBER_THREADS = "20" and PARALLEL_MAKE = "-j 20" and see if the issue still occurs. Monitoring the number of open files and active processes (etc.) during a running build would help narrow down which kinds of resource the system is running out of.
Poky tiny images were successfully created (core2-32 and corei7-64).
Poky tiny images were successfully created (core2-32 and corei7-64).(In reply to comment #9) > Poky tiny images were successfully created (core2-32 and corei7-64). tested in commit:98099349e358a9caaec8ec81f0d4abe588909cfe