* [PATCH 1/1] bootimg: Use FAT 32 for images larger than 512MB
2012-12-12 22:39 [PATCH 0/1] bootimg: Use FAT 32 for images larger than 512MB Darren Hart
@ 2012-12-12 22:39 ` Darren Hart
0 siblings, 0 replies; 2+ messages in thread
From: Darren Hart @ 2012-12-12 22:39 UTC (permalink / raw)
To: openembedded-core
Cc: Przemek Czesnowicz, Darren Hart, Joshua Immanuel, Steve Sakoman
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 <dvhart@linux.intel.com>
Cc: Steve Sakoman <steve@sakoman.com>
Cc: Joshua Immanuel <josh@hipro.co.in>
Cc: Przemek Czesnowicz <przemyslawx.czesnowicz@intel.com>
---
meta/classes/bootimg.bbclass | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 17c329a..b7ddf42 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}/* ::/
--
1.7.5.4
^ permalink raw reply related [flat|nested] 2+ messages in thread