Hi Maximillian, thanks for the information. I followed your directions and could make it work. It's not as simple as it should be, mainly for the ones like me that aren't unix specialists.
Thank you very much!
The problem is the overlay scheme - when you make changes, you don't actually replace the existing files in the same storage blocks, rather you use additional blocks to store the updated files, with the overlay system then hiding the original versions as they continue to take up space.
The only real fixes are to
not replace as many existing files
put the versions you need in the read only partition; technically this can be done by skilled use of uImage and squashfs tools without the rebuild from source that would normally be used to generate a custom disk image (over a year in, building from source still doesn't yield a system with working wifi), but it would be a fairly tricky process to figure out
use some other storage media, though beware that SD cards tolerate unprepared power cycling and even usage for Linux type filesystems relatively poorly.
Changing the size of the tmpfs partitions won't help, as those are ramdisks, and only really use memory to the extent that they are utilized, which the 1% and 0% numbers indicate they are not.
With the /overlay having almost the same size as /rom, I would guess something in the update/reset process has duplicated most of the firmware into the overlay, for some reason, instead of completely emptying it.
I would have a look into /overlay, that's where you can see the files which occupy those 7.3M.
@Neil-Kolban as "None None" mentioned, much memory the onion1 not has. The image will be loaded from the rom into ram ... so ... you can duplicate this value and it makes almost this 16MB you mentioned.