On Thu, Jan 28, 2016 at 10:43 AM, Daniel Thompson daniel.thompson@linaro.org wrote:
On 28/01/16 09:36, Nicolas Dechesne wrote:
It can in theory be replaced by:
- mkfs.ext4 (standard linux tool)
- img2simg tool from Android that creates a sparse image
However we have noticed some slight differences in the sparse images produced by the 2 processes: while make_ext4fs produces image with 'DONTCARE' blocks, img2simg uses FILL blocks (see sparse_format for details). And that change was breaking the tools we use to create the SD image that flashes images on the DragonBoard.. Well i understand this is not a good excuse to not pursue.. and I think we should get back to this topic, and use mkfs.ext4fs instead of make_ext4fs tool to create our Linux images. But that involves quite a bit of changes in many of our jobs.. Many we can start with Hikey builds for now, and in the mean time i can look at fixing the problems with the SD image tools for DragonBoard...
What type of blocks does ext2simg produce?
On other platforms Paul Lui has reported some interesting differences between images from img2simg and images from ext2img .
to follow up on that.. after a bit of discussion (on irc) and testing, it looks like we should be able to replace make_ext4fs by mkfs.ext4 + ext2simg. And we would get images built properly: the filesystem would be created with linux standard tools, and the resulting sparse image has DONTCARE blocks which is better too.
I did a quick test on my dragonboard, and I could flash the resulting image fine, and resize-helper.sh could do its job properly too.
can someone try on hikey the following:
1. download the latest debian rootfs 2. simg2img <rootfs> <rootfs.raw> 3. dd if=/dev/zero of=image.img xxx 4. mkfs.ext4 image.img 5. mount image.img and <rootfs.raw> 6. cp -a <rootfs.raw mount> --> <image.img mount> 7. ext2simg <image.img> <s_image.img>
and then flash the resulting image on hikey and test if the resize works?