Bug 1940

Summary: live image failing at do_bootimg
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Paul Eggleton <bluelightning>
Component: coreAssignee: Darren Hart <dvhart>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: dvhart, meta.mr.watcher, meta.watcher
Version: unspecified   
Target Milestone: 1.2 M3   
Hardware: x86   
OS: Multiple   
Whiteboard: Path on oe-core list (Jan 31, 2011)
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Paul Eggleton 2012-01-30 09:22:28 UTC 
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
Comment 1 Saul Wold 2012-01-30 18:59:57 UTC 
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.
Comment 2 Darren Hart 2012-01-31 07:30:31 UTC 
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 :-)
Comment 3 Darren Hart 2012-01-31 07:44:33 UTC 
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}/* ::/
Comment 4 Darren Hart 2012-01-31 08:33:30 UTC 
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.
Comment 5 Darren Hart 2012-01-31 08:53:17 UTC 
Patch is under test now.