On Tue, 2010-11-09 at 17:47 -0600, Paul Larson wrote:

On Tue, Nov 9, 2010 at 5:12 PM, john stultz johnstul@us.ibm.com wrote: So I know its not on the testing list, but the qemu instructions on the wiki page fail, as they don't include an omap3 hwpack. Feel free to update the wiki :)

Sure, if the bug below doesn't warrant removing it.

    Further, after providing an omap3 hwpack to build the image,
    the
    resulting image seems to have partition table issues when
    booted with
    qemu:
    
    [   24.961090] EXT3-fs (mmcblk0p2): mounted filesystem with
    ordered data mode
    Begin: Running /scripts/local-bottom ... done.
    done.
    Begin: Running /scripts/init-bottom ... done.
    fsck from util-linux-ng 2.17.2
    rootfs: The filesystem size (according to the superblock) is
    1030168 blocks
    The physical size of the device is 1030118 blocks
    Either the superblock or the partition table is likely to be
    corrupt!
    
    
    rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
           (i.e., without -a or -p options)
    mountall: fsck / [224] terminated with status 4
    mountall: Filesystem has errors: /
    Errors were found while checking the disk drive for /
    Press F to attempt to fix the errors, I to ignore, S to skip
    mounting or M for manual recovery
    

That bug *should* be fixed as of a few weeks ago:

revno: 141 fixes bug(s): https://launchpad.net/bugs/658511 committer: matt.waddel@linaro.org branch nick: align-image timestamp: Wed 2010-10-13 12:35:44 -0600 message: Round the size of the raw disk image up to a multiple of 256K so it is an exact number of SD card erase blocks in length. Otherwise Linux under qemu cannot access the last part of the card and is likely to complain that the last partition on the disk has been truncated.

---

Is your branch up to date? If so, what are the command line options you are using to create the image?

Yep. bzr pulled today. I'm on rev 165.

I've just gone back testing older images and hwpacks I've used in the past and am seeing the same issue there, so it does seem like its connected to the linaro-media-create scripts.

Here's the command I'm using, just as listed on the wiki: #linaro-media-create --image_file beagle_sd.img --image_size 4G --swap_file 200 --dev beagle --binary linaro-images/linaro-m-headless-tar-20101108-2.tar.gz --hwpack linaro-images/hwpack_linaro-omap3_20101109-1_armel_supported.tar.gz

Per our irc discussion, I tried reproducing this by omitting the "--image_size 4G" portion, and indeed it seems that worked and the resulting image boots fine. Similarly it works fine using 8G. Something just seems off using 4G.

Looking at linaro-media-create to see if I can narrow anything down.

thanks -john