OMAP pre-installed image uses FAT16 partitions

Bug #609700 reported by Loïc Minier
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
Fix Released
Medium
Oliver Grawert

Bug Description

Hi

While testing the image Ubuntu Netbook pre-installed OMAP image (http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap.img.gz) in QEMU, it wouldn't boot.

QEMU's OMAP ROM emulation would complain about lack of boot data.

Comparing the Ubuntu images with Angstrom images, I saw that the Ubuntu images had the same disk partition type and meta-data, but the filesystem would differ: FAT32 in the case of Angstrom and FAT16 for Ubuntu.

I've loop-mounted an image (with kpartx), copied over the files in the FAT partition, and reformatted it with mkfs.msdos -F 32. This allowed QEMU to boot and start the kernel from the modified image.

Oliver compared with the jasper-initramfs code, which uses -F 32, so it would seem safe to force -F 32 in debian-cd as well (it currently is unspecified, so mkdosfs picks FAT16 according to the size of the partition), however I recommend this to be tested on target hardware configurations.

Thanks.

Revision history for this message
Loïc Minier (lool) wrote :

Proposed change:
=== modified file 'tools/boot/maverick/post-boot-armel+omap'
--- tools/boot/maverick/post-boot-armel+omap 2010-07-06 08:27:47 +0000
+++ tools/boot/maverick/post-boot-armel+omap 2010-07-25 09:57:08 +0000
@@ -195,7 +195,7 @@
 VATSTART=$(parted $IMAGE unit B print|grep "^ 1"|awk '{print $2}')
 VATSIZE=$(LANG=C fdisk -l ${IMAGE} 2>/dev/null|grep W95 |awk '{print $5}')

-mkdosfs -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
+mkdosfs -C -F 32 $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
 mcopy -i $IMAGE.vfat MLO ::MLO
 mcopy -i $IMAGE.vfat u-boot.bin ::u-boot.bin
 mcopy -i $IMAGE.vfat $uboot_kernel ::uImage

Important notes:
* this will also affect OMAP4 (the OMAP4 script is a symlink to the OMAP one)
* this might not fix QEMU entirely, since the behavior of mkdosfs on files might differ from its behavior on devices

When I did this locally I saw:
sudo file -s /dev/mapper/loop1p1
/dev/mapper/loop1p1: x86 boot sector, mkdosfs boot message display, code offset 0x3c, OEM-ID " mkdosfs", sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 141, heads 64, sectors 144522 (volumes > 32 MB) , serial number 0x4c4563c7, label: " ", FAT (16 bit)

sudo mkfs.msdos -F 32 /dev/mapper/loop1p1
mkfs.msdos 3.0.9 (31 Jan 2010)
unable to get drive geometry, using default 255/63

sudo file -s /dev/mapper/loop1p1
/dev/mapper/loop1p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 255, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0x295c1311, label: " "

the drive geometry message might or might not be identical on files and devices (I was using a devmapper device, created by kpartx)

tags: added: armel
Revision history for this message
Oliver Grawert (ogra) wrote :

changed in debian-cd, requires testing of images before closing the bug.

Changed in ubuntu-cdimage:
assignee: nobody → Oliver Grawert (ogra)
importance: Undecided → Medium
status: New → In Progress
Tobin Davis (gruemaster)
tags: added: verification-needed
Revision history for this message
Tobin Davis (gruemaster) wrote :

Loic, can you retest this so we can close or fix as needed? Thanks.

description: updated
Revision history for this message
Tobin Davis (gruemaster) wrote :

Verified with recent Precise images.

tags: added: verification-done
removed: verification-needed
Changed in ubuntu-cdimage:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.