OE Build Configuration: BB_VERSION = "1.15.0" TARGET_ARCH = "i586" TARGET_OS = "linux" MACHINE = "fri2-noemgd" DISTRO = "poky" DISTRO_VERSION = "1.1+snapshot-20111221" TUNE_FEATURES = "m32 core2" TARGET_FPU = "" meta meta-yocto = "master:f74725baefce1f36d5bfbdec02e93ae761faebf6" meta-intel meta-fri2 = "master:1ab78de49a7d9bfe42942f1d74d4ecf24c69dd01" bootimg fails with the following error when building core-image-sato: ERROR: Function 'build_hddimg' failed (see /build/poky/fri2/tmp/work/fri2_noemgd-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.18914 for further information) ERROR: Logfile of failure stored in: /build/poky/fri2/tmp/work/fri2_noemgd-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.18914 Log data follows: | ERROR: Function 'build_hddimg' failed (see /build/poky/fri2/tmp/work/fri2_noemgd-poky-linux/core-image-sato-1.0-r0/temp/log.do_bootimg.18914 for further information) | mkdosfs 2.11 (12 Mar 2005) | Disk full Changing BOOTIMG_EXTRA_SPACE in bootimg.bbclass from 512 to 2048 resolves the issue, but feels like a bandaid to what is likely a deeper problem. I suspect we need to revisit the BLOCKS calculation in bootimg.bbclass.
The problem appears to be that we are not account for the size of the directory structure in the dosfs image which gets larger with bigger image sizes. For a sato image (~750M) dosfs structure uses 208K, then the current (smaller) directories need another 52K (16K Dir Structs), which brings us to 260K, df reports 176K available which leaves another 76K to overhead somewhere. For a larger image (2.8G) sato-sdk with a 1024 extra size, the dosfs overhead is 256K and the directories require 148K (64K Dir Structs) leaving 192K (from df) and 428 going to overhead somewhere For an 1.5G image the dosfs structure takes 224K and the directories are 32K dir structs, with around 172 going to other overhead. This was with only the EFI/* files so it had half the number of files. So your bandaid is probably correct, we could drop it to 1024 of EXTRA_SPACE or work on sliding scale based on image size. I tried to build a 4G mkdosfs but that failed.
Is it straight forward to calculate a deterministic direntry size in blocks with something like "find ${HDDDIR} | wc -l" ? If so, we could just increase the initial size accordingly prior to the padding being added.
(03:36:15 PM) sgw: dvhart: no, that not determinisc, it's size not direntry (03:36:52 PM) sgw: that dosfs image for sato has the same number of directory entries as sato-sdk, but sato-sdk is 3 times larger in size. In that case, the 512k added for the much larger image could be padded and added to all images. Adding 1MB to the IMAGE size is probably reasonable. There is also the duplication of data due to the EFI boot using EFI/BOOT. I'll test without that duplication and see if things work. If not, we can increase the padding to account for the filesystem overhead.
This was apparently due to using stale sstate for the xf86-input packages. Running the following generated a functional image: $ bitbake -c cleanall xf86-input-evdev xf86-input-keyboard xf86-input-mouse xf86-input-synaptics $ bitbake core-image-sato
Saul, this does not appear to be an fri2 issue, but rather a build issue where stale sstate was used for the xf86-input drivers. I've assigned this to you to either close as is, or hand off to someone to investigate further. It's certainly possible that things have changed enough that nobody will hit this again with sstate generated from now on, so I'm not sure how much more time we should spend on this.
(In reply to comment #5) > Saul, this does not appear to be an fri2 issue, but rather a build issue where > stale sstate was used for the xf86-input drivers. I've assigned this to you to > either close as is, or hand off to someone to investigate further. It's > certainly possible that things have changed enough that nobody will hit this > again with sstate generated from now on, so I'm not sure how much more time we > should spend on this. Apologies, wrong bug :(
Fix in master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1cabda965d0ec7c76f2fe57ce751154b9fc5e500