[10:28] <lool> ogra: Around?
[10:28] <ogra> partially
[10:28] <ogra> whats up ?
[10:28] <lool> ogra: I grabed the latest preinstalled image for omap
[10:28] <lool> and tried to run it under qemu
[10:28] <lool> it failed as usual
[10:29] <lool> but I found a way to get it working
[10:29] <ogra> likely broken due to kernel out of syncness
[10:29] <lool> it's related to the fat filesystem in the first partition
[10:29] <ogra> oh ?
[10:29] <lool> ogra: I compared with a working Angstrom image, and while the disk partitioning was okay, the fat looked different
[10:29] <ogra> the only thing that might differ from angstrom wrt first partition could be the mkdosfs binary or sfdisk
[10:30] <lool> 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] <lool> 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] <lool> 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] <ogra>     echo ,9,0x0C,*
[10:32] <ogra> thats from the sfdisk scripts from tools/boot/maverick/post-boot-armel+omap
[10:32] <ogra> copied from the angstrom build script
[10:32]  * lool bzr upgrading his debian-cd checkout
[10:33] <ogra> i'm fine switching to anything you like as long as it doesnt break
[10:33] <ogra> we just need to keep jasper in sync
[10:33] <ogra> since it recreates the first partition on first boot
[10:34] <lool> 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] <lool> ogra: So I think the issue is with: mkdosfs -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
[10:35] <lool> 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] <ogra> hmm, jasper uses "/sbin/mkdosfs -n "SERVICEV001" -F 32 /dev/${DISK}${SEP}1"
[10:36] <ogra> seems debian-cd is just behind here
[10:37] <ogra> i need to sync the commands
[10:37] <ogra> jasper also uses ",$SIZE_P1,c,*" in sfdisk
[10:37] <ogra> instead of capitalized C
[10:38] <ogra> not sure if sfdisk interprets that any different
[10:40] <lool> 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] <lool> e.g. with a "create-boot-vfat" script and such
[10:41] <ogra> hmm
[10:41] <ogra> i would rather tie it to jasper than to the subarch
[10:41] <ogra> but yes, that sounds like a good idea
[10:41] <lool> ogra: Clearly the concept of special vfat partitions is specific to OMAP
[10:42] <lool> but you could have a jasper-utils package which has an omap-create-boot-vfat script  :-)
[10:42] <lool> ogra: I'll open an ubuntu-cdimage bug to track the above issue
[10:42] <ogra> something like that
[10:42] <ogra> assign it to me
[10:43] <ogra> i'm not really sure you actually want to run these images in a vm though
[10:44] <ogra> since you have no actual disk hardware that at least requires some extra preparation
[10:44] <lool> ogra: Why wouldn't I have disk hardware?
[10:44] <ogra> i.e. making sure to create the image file big enough
[10:45] <ogra> 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] <ogra> *unless
[10:46] <ogra> makes running in in a vm a bit more complex
[10:47] <ogra> its nopt that its impossible to use it that way, but its not designed to be run without preparation in a vm
[10:48] <lool> ogra: That's ok, I understand
[10:51] <ogra> i should probably add a little more spare space like 500M or so, so it can run without resizing too
[10:52] <ogra> gzip should just compress it it away for the gzipped image
[10:52]  * ogra will play with that
[10:53] <lool> ogra: I personally find it a waste that you'd do that
[10:53] <lool> I can deal with this downstream
[10:54] <ogra> 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] <lool> ogra: It will affect the time it takes me to unpack and the space it will take unpacked
[10:56] <ogra> 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] <lool> ogra: So, I've posted a bug with a proposed (untested) patch; it affects OMAP4
[11:01] <ogra> change implemented on antimony
[11:01] <lool> LP #609700
[11:01] <ubot2`> 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] <ogra> oh, you added a patch ?
[11:02]  * ogra checks
[11:03] <ogra> nearly the same as my change (my option ordering is slightly different)
[11:04] <lool> ogra: Would you assign yourself to the bug and close it if you merged that already?
[11:04] <ogra> lool, if the archive ever gets in sync again, please test the next image in qemu, i'll test panda and beagle
[11:04] <ogra> i dont want to close it before we tested it both
[11:04]  * ogra mentions the change 
[11:05] <ogra> set to inprogress
[11:07]  * ogra goes for food
[11:21] <lool> I've filed LP #609706 for the qemu counterpart of this issue
[11:21] <ubot2`> 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