I am following the instructions in OpenEmbedded-core and am using a newly built Ubuntu 16.04 platform. I have successfully created a LinuxImageV2.7 build and am now attempting to build a LinuxImageV2.8 in a separate directory tree. I had to make several attempts and I believe building without adding Qt is what finally allowed it to complete.
I then modified local.conf as described in the OpenEmbedded-core page, and restarted the build with the added Qt info. I see my Ubuntu session close all windows and then come back to the login screen.
I have included the log file of the added Qt build attempt.
I have seen similar reports that are a year or so old on other sites but haven’t come across this kind of issue on the Toradex site. Can you suggest any possible causes? link text
So it probably just runs out of RAM. My notebook where I rarely do builds has 32 GB and our build server where we run most of our builds does feature 128 GB.
I have also noticed that memory use during the build of Qt seems to have recently increased. Likely your best option, short of adding more RAM, is to create a large swap partition or file (>16GB).
One additional thing to try is to decrease the number of parallel executing tasks. In build/conf/local.conf BB_NUMBER_THREADS and PARALLEL_MAKE are both set to the number of detected CPUs by default.
Decreasing that will decrease the amount of RAM used at the price of longer build times.
So for your CPU the cpu_count() call will be 8, so reducing to 4 will ease the RAM requirements. E.g. change from:
I had already tried to decrease both threads and parallel make to 4 each. I am running a build now (68% done) and it doesn’t look like it is going to reach more than 80% memory usage so swap is not used.
I had previously tried decreasing threads and parallel make to 4 each but that didn’t seem to have an effect. I am building again now to watch the swap (68% done) and memory hasn’t reach 80% yet and no swapping has occurred. swappiness is Ubuntu default 60.
Also, @brandon.tx mentions that Qt builds are requiring more RAM. Have you tried building WITHOUT Qt? Have the baseline Yocto build compiled and cached for future builds and then build an image with Qt?
I had similar problems building Android 's AOSP with an 8GB RAM computer. Maybe try not using desktop (switch to text-based environment with Ctrl+Alt+F1 to F6, close tty7 session) and try again.
All, I apologize for delay in adding more info… I am trying to get real work done by avoiding yocto altogether while encountering these issues. So I attempted to set threads and parallel make to 1 which still didn’t solve the problem however, I do see the following dmesg after the crash with things set to 1:
[288997.931396] systemd[1]: Starting Journal Service...
[289003.095568] systemd-journald[20899]: File /run/log/journal/ddc01f6603e74c5e9ba799ce92ab8fb0/system.journal corrupted or uncleanly shut down, renaming and replacing.
[289003.102032] systemd[1]: Started Journal Service.
[354141.672476] asix 2-1.6.5:1.0 enx000ec6c9a368: link up, 100Mbps, full-duplex, lpa 0x41E1
[354144.744303] asix 2-1.6.5:1.0 enx000ec6c9a368: link up, 100Mbps, full-duplex, lpa 0x41E1
[354152.808225] asix 2-1.6.5:1.0 enx000ec6c9a368: link up, 100Mbps, full-duplex, lpa 0x45E1
[354293.351600] asix 2-1.6.5:1.0 enx000ec6c9a368: link up, 100Mbps, full-duplex, lpa 0x45E1
[367032.179483] asix 2-1.6.5:1.0 enx000ec6c9a368: link up, 100Mbps, full-duplex, lpa 0x45E1
[607233.150820] Chrome_~dThread[7936]: segfault at 0 ip 00007f3f118ca2b6 sp 00007f3f0f9b6af0 error 6 in libxul.so[7f3f10a80000+5893000]
[615137.541783] QDBusConnection[21527]: segfault at 7fe10c7af7d0 ip 00007fe16d9bac9e sp 00007fe1159baba0 error 4 in libQt5Core.so.5.7.1[7fe16d71e000+50c000]
This error is curious because I thought that in using the LinuxImageV2.8 version of iMX7 contained the 5.9.x version of Qt. Does this shed any light on the issue? I still need to get this working or at least understand why it isn’t working.
After fighting with this issue and finding no resolution in the previous recommendations. I finally stumbled across the answer while trying to capture information about what tasks were running when my Ubuntu session / desktop crashes. I used the screen before kicking off my build to capture the terminal window which actually keeps the terminal along with this tasks running through the crash and reboot of the Ubuntu session. Look at detailed information here about screen and how it can relate to keeping a build running.
Now it runs fine through the UI crash and reboot with Qt added from the start, and max threads and parallel makes.
I post this to help others who might find this when searching with this or similar problems.
Yes, when attempts to eliminate Qt from the build, limiting BB_NUMBER_THREADS and PARALLEL_MAKE, creating large swap area, and modifying swappiness, the method of wrapping bitbake in a screen allows it to continue through the crash and restart of the desktop GUI on Ubuntu. I have used this successfully several times now and the write-up linked above is a better jumping off point than I have seen on other posts.
The one downside is you lose the graphical window when the GUI is restarted and through screen you can reconnect to the capture.
I am running with 12 GB of RAM and 32 GB of swap space but that didn’t seem to keep the crashes from happening.
