Created attachment 1149 [details] Screenshot showing the issue Building core-image-sato partially from sstate for qemuarm with latest master, I see that instead of the text being displayed properly I see squares as if the correct font were not installed (see attached screenshot). I haven't checked yet to see if other machines are affected.
Additional info: when shutting down I can see the following warnings on the console: (matchbox-desktop:447): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='latin' (matchbox-desktop:447): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' Additionally, comparing buildhistory output for a recently built image on another machine that does work, I can see that in the broken image /etc/pango/pango.modules is empty as is /etc/gtk-2.0/gtk.immodules.
Even more, from log.do_rootfs: Running intercept scripts: > Executing update_font_cache WARNING: intercept script "update_font_cache" failed, falling back to running postinstalls at first boot > Executing update_icon_cache > Executing update_pixbuf_cache WARNING: intercept script "update_pixbuf_cache" failed, falling back to running postinstalls at first boot
Created attachment 1155 [details] update_font_cache intercept script output I just did a from-scratch rebuild on the same machine; same result. Laurentiu and I have discussed the issue and with some extra logging have found the attached errors from the intercept script that calls fc-cache which might hint at the problem; the update_pixbuf_cache script is similarly afflicted. My guess at the moment based upon the error and what a Google search turns up about it is some bad interaction between pseudo, qemu and AppArmor (I'm using Ubuntu 12.10 as a host distribution which enables AppArmor by default). However a test running the ARM ld-2.17.so binary under qemu-arm within pseudo didn't appear to cause any issues.
Upon further investigation this is nothing to do with pseudo or apparmor. Laurentiu and I have boiled the test down to an invocation outside of the build system of qemu-arm as follows: export D=/path/to/rootfs export PATH="$PATH:/path/to/native/sysroot" qemu-arm $D/lib/ld-2.17.so --library-path $D/lib:$D/usr/lib $D/usr/bin/fc-cache --help This fails with: /path/to/usr/bin/fc-cache: error while loading shared libraries: /path/to/usr/bin/fc-cache: failed to map segment from shared object: Operation not permitted With some experimentation it has been found that either specifying the base address to qemu-arm with -B 1048576 or setting /proc/sys/vm/mmap_min_addr to 0 fixes the problem. Laurentiu cannot reproduce this issue on his machine and has the same default /proc/sys/vm/mmap_min_addr value (65536). His host OS is 64-bit whereas mine is 32-bit, if that makes any difference.
I sent a fix for this on the ML.
Patch merged: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1872ee316b77926d2b9ede27f9d428a3b2a8b3fe
Still seeing this with sugarbay, as of 02ae9b357676c904721d92a9c6f74ecc6b7a4476.
Apparently there was another issue introduced recently, when using RPM, making run-postinsts script to not be deployed on target. So, if the postinstalls failed on host, they were not run on target either. Patch sent on the ML to fix this issue.
Patch merged: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=51959f5662283f47d9a64fcef7fdeff45a14e768
On commit 1b93e2bc913af90b6a8274215ae9848ee628198b, I still have this problem but only on core-image-sato-sdk (machine qemux86-64); core-image-sato it's okay. The postinstall scripts aren't run because it seems that sato-sdk pulls opkg which installs it's own run-postinst script. My local.conf has PACKAGE_CLASSES ?= "package_rpm"
Reopening because we found another issue (happening for core-image-sato-sdk), leading to the same problem. Apparently, opkg postinstall overwrites the run-postinsts script and rpm postinstalls do not have a chance to run...
Sent a fix for the run-postinsts script overwriting.
The fix for run-postinsts overwriting has been merged. Marking the bug as fixed and, hopefully, will stay this way: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8b29120a8cdd92a0429f383f4811f7f84c6c350e
Verified in poky master:c567366d3b933d6a840e793845f81c3ecbe83585