Ext2simg is corrupting custom rootfs

Products Support DragonBoard410c
#1

Hello,

With the previous Stretch release for the Dragonboard, I took it and created a custom rootfs. I had a series of scripts that would create the custom rootfs. I am updating those scripts to work with the latest Buster release but I am having issues with the board not booting correctly with the custom image.
I am taking the linaro-buster-developer-dragonboard-410c-528.img.gz image then doing a simg2img, resize on it before using Qemu to customize it.

simg2img linaro-*.img martha-linaro-developer-dragonboard-410c.img.raw
resize2fs martha-linaro-developer-dragonboard-410c.img.raw 3G

After completing the customization, I change the image back to a sparse image with:
ext2simg martha-linaro-developer-dragonboard-410c.img.raw martha-linaro-developer-dragonboard-410c.img

The newly created image is not booting correctly on the DragonBoard. Suspiciously the sparse image has shrunk to smaller than the original image.

1.6G Sep 15 20:14 linaro-buster-developer-dragonboard-410c-528.img
3.0G Sep 15 21:00 martha-linaro-developer-dragonboard-410c.img.raw
1.5G Sep 15 21:37 martha-linaro-developer-dragonboard-410c.img

I have fastboot flash the *.img.raw to the DragonBoard and that has booted correctly so I am confident that my customization is not the issue.

I have put the logs from the serial console in a gist:
https://gist.github.com/ukBaz/473923b7b48e2a2d67f670c30a1ad221
good_boot.log is for martha-linaro-developer-dragonboard-410c.img.raw
bad_boot.log is for martha-linaro-developer-dragonboard-410c.img

I am struggling to see what the issue is as this worked previously. Anyone have any suggestions?

#2

Both logs seem to boot into systemd login fine without dropping into emergency ramdisk, am i missing something, can you truncate the log?

#3

hi,

i have noticed weird issues with ext2simg some time ago. I have stopped using it. I tried to engage upstream but didn’t go too far.

https://lore.kernel.org/linux-ext4/CAP71WjzSUxbK1mpv_bTuZd6W4xV2zNEEQN0GtmEp7iMTyhi9zA@mail.gmail.com/

#4

Thank you for the quick replies.

@ric96: How would you like the logs truncated?
It is true that I do get to the prompt with this customization, although as I’ve been experimenting with different customization’s, how the system comes up seems to change.

@anon91830841: Your experience sounds similar. It does seem to be the ext2simg step that is the issue. You say you have stopped using ext2simg. What are you using instead?
Is the only downside of not using ext2simg, size?

Thanks,
Barry

#5

yes, we stopped using ext2simg for the debian images that we publish, and we use img2simg instead. the only downside is indeed size, since img2simg uses a ‘dumb’ sparse algorithm, e.g. it looks at bytes in the file without knowing what they really are. While ext2simg is supposed to use ext4 data structure , so it does a ‘smart’ sparsing…

if you have large holes or unused data in your ext4 image, then ext2simg was supposed to compress the file more than img2simg. However since we also create file system images which are as small as possible, the downside of using img2simg aren’t problematic (and we enlarge the file system size on first boot).