I fully agree. That’s why I didn’t touch the default size and always prefer to have the additional space for additional partitions or LVM volumes. I wrote a simplified management tool called uvol for that purpose which can work on both, eMMC with LVM2 and SPI-NAND with UBI.
Exactly.
Yes, absolutely.
Increasing from 104 MiB to 488 MiB sounds reasonable. Buying any storage media smaller than 1 GiB anyway became kinda difficult.
Hi buddy, can you give more detail about this, because I did the same and the firmware stills being ~84 MB . You compiled modifiying CONFIG_TARGET_ROOTFS_PARTSIZE in .config, then sysupgrade? Anything else?
Thanks.
The partition table is written once when you carry out initial installation to the eMMC. The current default in OpenWrt snapshots has also been increased to use 448 MiB partition size instead of the previous default of 104 MiB, so to avoid this being the most popular topic discussed among users…
In order to increase the size on an existing installation, either boot from SPI-NAND or boot into the recovery system. Then use parted or fdisk to edit the partition table and increase the size of the production partition. After a subsequent sysupgrade you will then see the new size applied.
You should not need more than the new default of 448 MiB as rootfs_overlay. If you think you do, you are probably not aware of how OpenWrt’s upgrade mechanism works and you are about to hit a wall.
It’s important to note that using the whole size of the eMMC as rootfs overlay is a dead-end, as the overlay is re-created on every sysupgrade, so at least every time you want to update the kernel. OpenWrt creates a backup of the configuration files (and other files listed in /etc/sysupgrade.conf) which has to be kept in RAM during the update. It hence doesn’t make sense to have a rootfs overlay which is larger than what can fit in tmpfs.
Instead, I would strongly recommend you to install autopart and uvol instead. In this way you can have meaningful persistent storage in additional volumes which will also always survive sysupgrade. If you are planning to store any user data like databases or media content, or things like Docker container images, that would be the way to go.
Thank you very much for your response Daniel, it is a privilege to receive a response from you.
My confusion had to do with the partition table issue, now it is clear.
I disagree a little about the overlay size limit, I think that there are cases where the overlay could be bigger without issues, the limit in facts goes about how big is the information you need to preserve between sysupgrades VS available RAM, and I am aware of that.
Thank you very much for your complete response and your enormous collaboration in the development of OpenWRT.