Bug 3918

Summary: core-image-sato -c rootfs fails on executing update_icon_cache
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Stefan Stanacar <sstncr>
Component: configurationAssignee: Laurentiu Palcu <laurentiu.palcu>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: laurentiu.palcu, Qi.Chen, richard.purdie, sgw
Version: 1.4   
Target Milestone: 1.4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---
Attachments:
Description Flags
log.do_rootfs none

Description Stefan Stanacar 2013-02-20 13:26:15 UTC 
Created attachment 1080 [details]
log.do_rootfs

Build Configuration:
BB_VERSION        = "1.17.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS        = "i586-poky-linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130220"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              
meta-yocto        
meta-yocto-bsp    = "master:6bf55c6e67b371c0467ae1be4d7f713d6a3dcf3b"


Steps to reproduce:
   - clean build dir (no tmp, no sstate)
           bitbake core-image-sato
   - rm tmp (keep your sstate)
           bitbake core-image-sato -c rootfs

From log.do_rootfs

 Executing update_font_cache
WARNING: intercept script "update_font_cache" failed, falling back to running postinstalls at first boot
> Executing update_icon_cache
Failed to create file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache.QYR8SW': Permission denied


Same steps on a F18 didn't lead to failure.
Comment 1 Stefan Stanacar 2013-02-20 14:34:05 UTC 
Ok, so I lied, the steps I used are a bit longer:
   
   - start with a clean build dir and from that build dir:
   - bitbake core-image-sato -c fetchall
   - rm -rf  pseudone tmp bitbake.lock conf/sanity_info
   - rm -rf sstate-cache
   - bitbake core-image-sato
   - bitbake virtual/kernel -c clean
   - bitbake virtual/kernel -c cleansstate
   - bitbake virtual/kernel
   - rm -rf pseudone tmp bitbake.lock conf/sanity_info
   - rm -rf sstate-cache
   (except for conf/local.conf and bblayers.conf and downloads build dir should now be clean)
   - echo "INHERIT += \"rm_work\"" >> conf/local.conf
   - bitbake core-image-sato
   - sed -i 's/INHERIT += \"rm_work\"//' conf/local.conf
   - rm -rf pseudone tmp bitbake.lock conf/sanity_info
   - bitbake core-image-sato -c rootfs
Comment 2 Stefan Stanacar 2013-02-21 15:28:57 UTC 
7d22ef28e64de06b6238d0ef9b664c0bee6efa46

Reproduced again on the same Ubuntu 12.04

 rm -rf tmp bitbake.lock conf/sanity_info sstate-cache && bitbake core-image-sato -c fetchall && rm -rf tmp bitbake.lock conf/sanity_info sstate-cache && echo "INHERIT += \"rm_work\"" >> conf/local.conf && bitbake core-image-sato && sed -i 's/INHERIT += \"rm_work\"//' conf/local.conf && rm -rf tmp bitbake.lock conf/sanity_info && bitbake core-image-sato -c rootfs
Comment 3 Chen Qi 2013-02-22 07:30:02 UTC 
(In reply to comment #2)
> 7d22ef28e64de06b6238d0ef9b664c0bee6efa46
> 
> Reproduced again on the same Ubuntu 12.04
> 
>  rm -rf tmp bitbake.lock conf/sanity_info sstate-cache && bitbake
> core-image-sato -c fetchall && rm -rf tmp bitbake.lock conf/sanity_info
> sstate-cache && echo "INHERIT += \"rm_work\"" >> conf/local.conf && bitbake
> core-image-sato && sed -i 's/INHERIT += \"rm_work\"//' conf/local.conf && rm
> -rf tmp bitbake.lock conf/sanity_info && bitbake core-image-sato -c rootfs

Why do such kind of operations?
And I don't think manually deleting tmp is a reasonable operation.

Cheers,
Chen Qi
Comment 4 Chen Qi 2013-02-22 07:41:02 UTC 
Sorry for my last comment.

It seems that deleting the entire tmp directory *is* supposed to be supported.

Cheers,
Chen Qi
Comment 5 Laurentiu Palcu 2013-02-22 10:28:59 UTC 
I succeeded to reproduce this running the above command. It turns out that the native sysroot is not completely populated... For example, in tmp/sysroots/x86_64-linux/usr/bin, I'm not able to find any qemu binaries, or any gdk-pixbuf-*... That's why the intercepts fail.
Comment 6 Richard Purdie 2013-02-22 17:44:29 UTC 
This is likely due to the optimisations in sstate cutting down the lists of things to install too much. Its likely from setscene_depvalid() in sstate.bbclass.
Comment 8 Stefan Stanacar 2013-03-21 14:15:19 UTC 
Verified.