summaryrefslogtreecommitdiff
path: root/meta/classes/rootfs_rpm.bbclass
diff options
context:
space:
mode:
authorDarren Hart <dvhart@linux.intel.com>2012-12-12 14:39:15 -0800
committerRichard Purdie <richard.purdie@linuxfoundation.org>2012-12-13 14:41:47 +0000
commitde808c552d445502bd99f78bb8159d21149f87c1 (patch)
treec4a2a34d91254f3d5ee08d180541c03761fea98b /meta/classes/rootfs_rpm.bbclass
parentfe19d0e01cb1563cf4735ef250f80af20059103b (diff)
downloadopenembedded-core-de808c552d445502bd99f78bb8159d21149f87c1.tar.gz
openembedded-core-de808c552d445502bd99f78bb8159d21149f87c1.tar.bz2
openembedded-core-de808c552d445502bd99f78bb8159d21149f87c1.zip
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 <dvhart@linux.intel.com> Cc: Steve Sakoman <steve@sakoman.com> Cc: Joshua Immanuel <josh@hipro.co.in> Cc: Przemek Czesnowicz <przemyslawx.czesnowicz@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/rootfs_rpm.bbclass')
0 files changed, 0 insertions, 0 deletions