1940 2012-01-30 09:22:28 +0000 live image failing at do_bootimg 2012-02-03 09:02:00 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED FIXED Path on oe-core list (Jan 31, 2011) Medium normal 1.2 M3 1 bluelightning dvhart dvhart meta.mr.watcher meta.watcher --- --- --- oldest_to_newest 18416 0 bluelightning 2012-01-30 09:22:28 +0000 On the autobuilder live images for nightly and nightly-x86 are failing with a somewhat obtuse error: ----------------------- ERROR: Function failed: build_hddimg (see /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/atom_pc-poky-linux/core-image-minimal-1.0-r0/temp/log.do_bootimg.12839 for further information) ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/atom_pc-poky-linux/core-image-minimal-1.0-r0/temp/log.do_bootimg.12839 Log data follows: | ERROR: Function failed: build_hddimg (see /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/atom_pc-poky-linux/core-image-minimal-1.0-r0/temp/log.do_bootimg.12839 for further information) | mkdosfs 2.11 (12 Mar 2005) | syslinux: zero FAT sectors (FAT12/16) NOTE: package core-image-minimal-1.0-r0: task do_bootimg: Failed ----------------------- Full log from the autobuilder: http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/337/steps/shell_32/logs/stdio 18427 1 sgw 2012-01-30 18:59:57 +0000 More digging seems to point that this is related to the recent size changes in the hddimg code. It's possible we uncovered some other problem with those changes. 18433 2 dvhart 2012-01-31 07:30:31 +0000 It's interesting that it is reporting FAT12/16 as we have also forced the use of FAT32. I don't see anything in the syslinux manual about which FAT filesystem is being used. And indeed, the syslinux sources assume the default FAT size was selected: if (clusters < 0xFFF5) { 92 /* FAT12 or FAT16 */ 93 94 if (!get_16(&sectbuf->bsFATsecs)) 95 return "zero FAT sectors (FAT12/16)"; So it's looking for information in the wrong part of the image on really small images. We have two options: 1) Patch syslinux to detect which FAT size is used rather than assume it based on cluster count. 2) Modify do_bootimg to calculate the FAT overhead for both FAT16 and FAT32. I'm strongly in favor of #1. The other workaround is to ensure minimal images are at least 32MB - but that seems like serious overkill and will pose a real problem for poky-tiny images which should be < 4MB :-) 18434 3 dvhart 2012-01-31 07:44:33 +0000 An alternative workaround is to perform the size calculations for FAT32 but allow mkdosfs to choose the FAT size based on cluster count as it normally would. This would result in more padding than necessary for small images, but would satisfy syslinux's pedantic expectations of the FAT size. Note that for small images, the extra padding is also not likely to be much in terms of absolute bytes anyway. This is the fastest "get it working" fix": diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass index df3ee73..5b320bb 100644 --- a/meta/classes/bootimg.bbclass +++ b/meta/classes/bootimg.bbclass @@ -142,7 +142,7 @@ build_hddimg() { BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16))) IMG=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg - mkdosfs -F 32 -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS} + mkdosfs -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS} # Copy HDDDIR recursively into the image file directly mcopy -i ${IMG} -s ${HDDDIR}/* ::/ 18435 4 dvhart 2012-01-31 08:33:30 +0000 HPA confirms that the cluster count is what determines the proper FAT size according to the MS spec. So, my solution in Comment #3 appears to be the best solution. I'll send a patch. 18436 5 dvhart 2012-01-31 08:53:17 +0000 Patch is under test now. 18475 6 dvhart 2012-02-03 09:02:00 +0000 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=217584211625b1c496fe5b78aa4765ccf605d2b9