OK, so I finally think I know what is going on here, and the root cause is FriendlyARM's imaging process:
Have a look at this thread:
https://lists.96boards.org/pipermail/de ... 00715.html
Nicolas Dechesne (Linaro) wrote:we have indeed noticed issues when doing resize2fs on the release images. we are using the Android make_ext4fs utility to create the ext4 images, even for Linux, and it seems to be causing issues when we have 'large' filesystem (e.g. several GBs).
(...)
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.
(...)
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.
So the resize issue is caused by the fact that FriendlyARM, in the same way like people in the thread cited above, seem to use Android's make_ext4fs tool to create ext4 sparse images, when they should rather use mkfs.ext4 plus ext2simg...
My take on this so far is: Due to FriendlyARM having used the "wrong" (i.e., buggy) tool to create the root file system, the root file system of the FriendlyARM Debian image (which I have based my DietPi image on) was already non standard compliant (aka corrupt) from the very beginning, even though fsck.ext4 does not report any issues, but later attempts to resize2fs an image after lots of write accesses clearly uncovered them... Ouch!
I will now try to validate this theory (using fsarchiver to backup and restore FriendlyARM's rootfs.img content into a new partition created by the "real" mkfs.ext4), and then make a sparse image from this, and see whether the resulting ext4 image can be used by resize2fs in both online and offline mode without issues.
Unfortunately, that would mean that most probably, the NanoPi-M2/NanoPC-T2 image is affected by the exact same issue. Have you seen any issues with it during file system resize (resize2fs) before?
Stay tuned - I hope to have a truly valid image by the end of tomorrow...
Have a nice Sunday!
awl