OMAP pre-installed image uses FAT16 partitions

Bug #609700 reported by Loïc Minier on 2010-07-25
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
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.

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
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) on 2010-08-04
tags: added: verification-needed
Tobin Davis (gruemaster) wrote :

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

description: updated
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  Edit
Everyone can see this information.

Other bug subscribers