On Tue, 2010-11-09 at 17:47 -0600, Paul Larson wrote: > On Tue, Nov 9, 2010 at 5:12 PM, john stultz <johns...@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.wad...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
