<div class="gmail_quote">On Tue, Nov 9, 2010 at 5:12 PM, john stultz <span dir="ltr"><<a href="mailto:johnstul@us.ibm.com">johnstul@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
So I know its not on the testing list, but the qemu instructions on the<br>
wiki page fail, as they don't include an omap3 hwpack.<br>
<br></blockquote><div>Feel free to update the wiki :)<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Further, after providing an omap3 hwpack to build the image, the<br>
resulting image seems to have partition table issues when booted with<br>
qemu:<br>
<br>
[   24.961090] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode<br>
Begin: Running /scripts/local-bottom ... done.<br>
done.<br>
Begin: Running /scripts/init-bottom ... done.<br>
fsck from util-linux-ng 2.17.2<br>
rootfs: The filesystem size (according to the superblock) is 1030168 blocks<br>
The physical size of the device is 1030118 blocks<br>
Either the superblock or the partition table is likely to be corrupt!<br>
<br>
<br>
rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.<br>
        (i.e., without -a or -p options)<br>
mountall: fsck / [224] terminated with status 4<br>
mountall: Filesystem has errors: /<br>
Errors were found while checking the disk drive for /<br>
Press F to attempt to fix the errors, I to ignore, S to skip mounting or M for manual recovery<br><br></blockquote><div>That bug *should* be fixed as of a few weeks ago:<br>------------------------------------------------------------<br>

revno: 141<br>fixes bug(s): <a href="https://launchpad.net/bugs/658511">https://launchpad.net/bugs/658511</a><br>committer: <a href="mailto:matt.waddel@linaro.org">matt.waddel@linaro.org</a><br>branch nick: align-image<br>

timestamp: Wed 2010-10-13 12:35:44 -0600<br>message:<br>  Round the size of the raw disk image up to a multiple of 256K<br>  so it is an exact number of SD card erase blocks in length.<br>  Otherwise Linux under qemu cannot access the last part of the<br>

  card and is likely to complain that the last partition on the<br>  disk has been truncated.<br>------------------------------------------------------------<br>Is your branch up to date?  If so, what are the command line options you are using to create the image?<br>

<br>Thanks,<br>Paul Larson<br></div></div>