[10:28] ogra: Around? [10:28] partially [10:28] whats up ? [10:28] ogra: I grabed the latest preinstalled image for omap [10:28] and tried to run it under qemu [10:28] it failed as usual [10:29] but I found a way to get it working [10:29] likely broken due to kernel out of syncness [10:29] it's related to the fat filesystem in the first partition [10:29] oh ? [10:29] ogra: I compared with a working Angstrom image, and while the disk partitioning was okay, the fat looked different [10:29] the only thing that might differ from angstrom wrt first partition could be the mkdosfs binary or sfdisk [10:30] ogra: First, note that the disk partitioning says it's a fat32 (type 0xc), but your images actually contain a fat16 [10:30] * ogra checks debian-cd [10:30] ogra: Second, I'm not entirely sure that just setting things to fat32 is enough; mkfs.dosfs apparently has a concept of heads, and I strongly suspects it might behave differently on real devices versus files [10:31] ogra: If that is an option, I'd like if we could switch the omap3 images to fat32 to start with, but that will require testing again on all target hardware platforms [10:31] echo ,9,0x0C,* [10:32] thats from the sfdisk scripts from tools/boot/maverick/post-boot-armel+omap [10:32] copied from the angstrom build script [10:32] * lool bzr upgrading his debian-cd checkout [10:33] i'm fine switching to anything you like as long as it doesnt break [10:33] we just need to keep jasper in sync [10:33] since it recreates the first partition on first boot [10:34] ogra: if we discover the format is not the only one you need to support, it might make sense to have jasper read the current format to create a new one [10:34] ogra: So I think the issue is with: mkdosfs -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1 [10:35] ogra: this needs -F 32, otherwise the format is selected automatically depending on the size of the fs, and ends up being FAT16 here [10:36] hmm, jasper uses "/sbin/mkdosfs -n "SERVICEV001" -F 32 /dev/${DISK}${SEP}1" [10:36] seems debian-cd is just behind here [10:37] i need to sync the commands [10:37] jasper also uses ",$SIZE_P1,c,*" in sfdisk [10:37] instead of capitalized C [10:38] not sure if sfdisk interprets that any different [10:40] ogra: Perhaps what would make sense is an omap-utils package which we would eventually be able to install in initramfs + on antimony, and then call exactly the same commands? [10:40] e.g. with a "create-boot-vfat" script and such [10:41] hmm [10:41] i would rather tie it to jasper than to the subarch [10:41] but yes, that sounds like a good idea [10:41] ogra: Clearly the concept of special vfat partitions is specific to OMAP [10:42] but you could have a jasper-utils package which has an omap-create-boot-vfat script :-) [10:42] ogra: I'll open an ubuntu-cdimage bug to track the above issue [10:42] something like that [10:42] assign it to me [10:43] i'm not really sure you actually want to run these images in a vm though [10:44] since you have no actual disk hardware that at least requires some extra preparation [10:44] ogra: Why wouldn't I have disk hardware? [10:44] i.e. making sure to create the image file big enough [10:45] the image is self expanding, there is nothing you can resize to unells you first create a bigger image into which you dd the downloaded .img file [10:46] *unless [10:46] makes running in in a vm a bit more complex [10:47] its nopt that its impossible to use it that way, but its not designed to be run without preparation in a vm [10:48] ogra: That's ok, I understand [10:51] i should probably add a little more spare space like 500M or so, so it can run without resizing too [10:52] gzip should just compress it it away for the gzipped image [10:52] * ogra will play with that [10:53] ogra: I personally find it a waste that you'd do that [10:53] I can deal with this downstream [10:54] well, it wont affect the download size, likely speed up the ultra slow resizing and make it possible to actually run oem-config even if resizing failed [10:55] ogra: It will affect the time it takes me to unpack and the space it will take unpacked [10:56] thats true, though it would also be a good way to enforce minimal specs like using 4G cards (by adding enough empty space to not fit on a 2g card anymore) [11:01] ogra: So, I've posted a bug with a proposed (untested) patch; it affects OMAP4 [11:01] change implemented on antimony [11:01] LP #609700 [11:01] Launchpad bug 609700 in ubuntu-cdimage "OMAP pre-installed image uses FAT16 partitions (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/609700 [11:01] oh, you added a patch ? [11:02] * ogra checks [11:03] nearly the same as my change (my option ordering is slightly different) [11:04] ogra: Would you assign yourself to the bug and close it if you merged that already? [11:04] lool, if the archive ever gets in sync again, please test the next image in qemu, i'll test panda and beagle [11:04] i dont want to close it before we tested it both [11:04] * ogra mentions the change [11:05] set to inprogress [11:07] * ogra goes for food [11:21] I've filed LP #609706 for the qemu counterpart of this issue [11:21] Launchpad bug 609706 in qemu-maemo "QEMU ROM emulation code doesn't cope with FAT16 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/609706 === NCommander is now known as NC|Alaska === NCommander is now known as NC|Alaska === bjf is now known as bjf[bjf]