| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 | |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| ogra | not sure if sfdisk interprets that any different | 10:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| ogra | i'm not really sure you actually want to run these images in a vm though | 10:43 |
| 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:44 |
| 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:45 |
| ogra | *unless | 10:46 |
| ogra | makes running in in a vm a bit more complex | 10:46 |
| ogra | its nopt that its impossible to use it that way, but its not designed to be run without preparation in a vm | 10:47 |
| lool | ogra: That's ok, I understand | 10:48 |
| ogra | i should probably add a little more spare space like 500M or so, so it can run without resizing too | 10:51 |
| ogra | gzip should just compress it it away for the gzipped image | 10:52 |
| * ogra will play with that | 10:52 | |
| lool | ogra: I personally find it a waste that you'd do that | 10:53 |
| lool | I can deal with this downstream | 10:53 |
| 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:54 |
| lool | ogra: It will affect the time it takes me to unpack and the space it will take unpacked | 10:55 |
| 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) | 10:56 |
| 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:01 |
| * ogra checks | 11:02 | |
| ogra | nearly the same as my change (my option ordering is slightly different) | 11:03 |
| 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:04 | |
| ogra | set to inprogress | 11:05 |
| * ogra goes for food | 11:07 | |
| 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 | 11:21 |
| === NCommander is now known as NC|Alaska | ||
| === NCommander is now known as NC|Alaska | ||
| === bjf is now known as bjf[bjf] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!