From de808c552d445502bd99f78bb8159d21149f87c1 Mon Sep 17 00:00:00 2001 From: Darren Hart Date: Wed, 12 Dec 2012 14:39:15 -0800 Subject: bootimg: Use FAT 32 for images larger than 512MB Fixes [YOCTO #2138] Commit 217584211625b1c496fe5b78aa4765ccf605d2b9 dropped the forced use of FAT32 for the hddimg generation as it broke with very small images (< 32MB). Unfortunately, left to its own devices, mkdosfs appears to select FAT16 even for very large images, resulting in 2.2GB images being generated as FAT16: $ ls -lah core-image-lsb-sdk-atom-pc-20121010233936.hddimg -rw-rw-r-- 1 dvhart dvhart 2.2G 2012-10-17 08:00 core-image-lsb-sdk-atom-pc-20121010233936.hddimg $ file !$ file core-image-lsb-sdk-atom-pc-20121010233936.hddimg core-image-lsb-sdk-atom-pc-20121010233936.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 128, root entries 512, Media descriptor 0xf8, sectors/FAT 138, heads 64, sectors 4502496 (volumes > 32 MB) , serial number 0x50761926, label: "boot ", FAT (16 bit) The result was a runtime boot error from SYSLINUX and a failure to boot live images greater than 1GB in size. While strictly speaking it is the cluster count that determines which FAT size is used, that calculation requires more information than we have readily available (such as sectors per cluster). If we let mkdosfs determine sectors per cluster and just set a sane threshold above which FAT32 is used, we get correct bootable images. With this patch the 2.2GB core-image-lsb-sdk uses FAT32 and the 21 MB core-image-minimal uses FAT16, and both boot in qemu successfully: $ ls -lah tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg -rw-r--r-- 1 dvhart dvhart 2.2G 2012-12-12 14:18 tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg $ file !$ file tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg tmp/deploy/images/core-image-lsb-sdk-atom-pc-20121212220835.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, heads 64, sectors 4470304 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 4357, reserved3 0x800000, serial number 0x50c902b7, label: "boot " $ ls -lah tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg -rw-r--r-- 1 dvhart dvhart 21M 2012-12-12 14:06 tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg $ file !$ file tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg tmp/deploy/images/core-image-minimal-atom-pc-20121212220600.hddimg: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 4, root entries 512, sectors 41408 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 41, heads 64, serial number 0x50c8ffec, label: "boot ", FAT (16 bit) I have tested and booted core-image-minimal and core-image-lsb-sdk for atom-pc with qemu-system-i386 using this patch. Signed-off-by: Darren Hart Cc: Steve Sakoman Cc: Joshua Immanuel Cc: Przemek Czesnowicz Signed-off-by: Richard Purdie --- meta/classes/bootimg.bbclass | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'meta/classes') diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass index 17c329a142..b7ddf42427 100644 --- a/meta/classes/bootimg.bbclass +++ b/meta/classes/bootimg.bbclass @@ -163,8 +163,15 @@ build_hddimg() { # done in blocks, thus the mod by 16 instead of 32. BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16))) + # mkdosfs will sometimes use FAT16 when it is not appropriate, + # resulting in a boot failure from SYSLINUX. Use FAT32 for + # images larger than 512MB, otherwise let mkdosfs decide. + if [ $(expr $BLOCKS / 1024) -gt 512 ]; then + FATSIZE="-F 32" + fi + IMG=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg - mkdosfs -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS} + mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS} # Copy HDDDIR recursively into the image file directly mcopy -i ${IMG} -s ${HDDDIR}/* ::/ -- cgit v1.2.3