Here are some interesting outcomes from my tests today, and you can rely on the results.
I took a look at your owtu repository and noticed that it uses the same API as the firmware selector. To rule out owtu as a potential cause of issues, I modified the firmware selector's JavaScript by adding rootfs_size_mb: 512. The results are as follows:
- If you do not provide a custom
rootfs_size_mb, theSquashFSoption includes theext4overlay. - Conversely, if you do provide a custom
rootfs_size_mb, the firmware uses thef2fsoverlay.
I have bricked my Raspberry Pi 4 several times when I first ran owtu, particularly when switching from ext4 to f2fs. We need to examine the Python-based asu backend code more closely to identify the cause of this inconsistency.
I checked the POST /api/v1/build method for any parameters that might affect the custom /overlay, but I found nothing relevant.
Another drawback of owtu is that sometimes, during the initial run when migrating from ext4 to f2fs, the /overlay size does not change as expected. In contrast, LuCi's "Flash new firmware image" option seems to work more reliably; I used the sysupgrade image in this instance.
Please take a look at the inconsistency. The output from cfdisk /dev/mmcblk0 and df -hT is as follows after the very first owut usage:
Here is 512 MB
But here still ext4 and 84 MB
Any other OpenWrt Gurus here to help us?