[BPI-R3 Mini] How to extend eMMC overlayfs?

frank-w · April 22, 2024, 1:01pm

No…this is the main problem:

stich86:

[    6.550531] mount_root: attempt to access beyond end of device
[    6.550531] fitrw: rw=8192, sector=172104, nr_sectors = 8 limit=168552
[    6.563361] F2FS-fs (fitrw): Failed to initialize F2FS segment manager (-5)
[    6.570959] mount_root: failed to mount -t f2fs /dev/fitrw /tmp/overlay: I/O error

stich86 · April 22, 2024, 1:13pm

and we are again on the my main problem… sysfs done by openwrt it’s trying to mount /dev/fitrw as overlay

stich86 · April 22, 2024, 2:30pm

so any suggestion? Only way to increate it is to compile my own image…

stich86 · April 22, 2024, 4:56pm

i think main problem is fitblk, from the snapshot almost all unit is using this method instead of old one… I’ve tried to build image removing fitblk but nothing to do

@Charles_Brandenburg are you using official snapshot or using one built by you?

stich86 · April 23, 2024, 7:09am

Anyone guys? I’m the only one with this problem?

frank-w · April 23, 2024, 7:19am

can you please stop this spamming?

stich86 · April 23, 2024, 7:27am

sorry frank, I don’t want to spam. I’m just trying to figure out this problem. @Charles_Brandenburg has posted a solution (and also other of you) that doesn’t seem to work with the latest snapshot.

That’s all…

frank-w · April 23, 2024, 7:31am

but i’m no expert in openwrt, so i cannot help here and there are not much experts here (maybe @dangowrt )…but i guess you have better luck in openwrt forum.

stich86 · April 24, 2024, 6:04pm

so at the moment only way to use rootfs_data as overlay is to follow this guide:

https://openwrt.org/docs/guide-user/additional-software/extroot_configuration

using that one I was able to swap all stuf on the rest of the space. I should test firmware upgrade, not sure it will survive…

I’ll update post when i’ve done this step

dangowrt · April 28, 2024, 1:27am

extroot is a possible generic way, but the most easy way on this hardware is to simply modify the partition size of the production partition. This can either be done at runtime when booting into the recovery system and using a partition editor like fdisk or parted. If using this method the change will only have an effect after the next sysupgrade or when otherwise wiping and re-creating, or manually resizing the rootfs_overlay filesystem.

Or it can be done when building the image from source by setting CONFIG_TARGET_ROOTFS_PARTSIZE in .config to a value in megabytes (default is 104MB).

The same can also be done when using the ImageBuilder by using the ROOTFS_PARTSIZE= parameter.

stich86 · April 28, 2024, 10:56am

yes I did it on my first attempt but I had two problems:

cannot use full size of eMMC, lost about 1GB
I need to build image by myself, and I want to avoid this

frank-w · April 28, 2024, 11:27am

your production-partition is later in partition table (there is also a recovery-partition which also needs some space)…and 8G eMMC does not mean it has 8GB it is afair ~7.4GB due to calculation in bytes not having factor 1000 (it uses factor 1024)

dangowrt · April 28, 2024, 11:29am

This is due to F2FS reserved space, making sure there is always enough unallocated space available for relocation by the eMMC internal FTL. You could use ext4fs instead in theory, but filling it up to 100% will very likely lead to a premature death of the eMMC, and the purpose of F2FS is exactly to avoid that.

You don’t need to build yourself. You can edit the partition table on the device once (as described above), it will not be altered by future firmware updates.

stich86 · April 28, 2024, 11:43am

Oh never heard about it. So it’s a sort of fail protection like SSD does for bad cell right?

So if I flash first “custom” build and then an official one the fitrw partition is not resized? Because in one of my attempt, when flashing back stock img, fitrw was back to 80MB

dangowrt · April 28, 2024, 8:59pm

In theory yes, in practice it seems to be a bit worse on eMMC than on most NVMe or SATA SSDs. See here for more details: F2FS - Wikipedia

As long as you are using the sysupgrade tool with the *sysupgrade.itb image the partition table will not change. Ie. custom changes to partition sizes will be preserved across updates.

The partition table is only written once upon initial installation to eMMC.

totkeks · April 28, 2024, 9:25pm

Seeing this discussion here. What is a reasonable size to use for the ROOTFS? Since all the packages included in OpenWrt are very small by default, having 8GB for root doesn’t seem reasonable.

The data on the partition is also overwritten with every sysupgrade, right?

Wouldn’t it then make more sense to use the remaining space on eMMC for a data partition (as suggested in other posts here and on OpenWrt forums) and mount it somewhere like /mnt/data? And then only use a slightly bigger rootfs with 256 or 512MB?

dangowrt · April 30, 2024, 7:44pm

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.

phpaiva · May 27, 2024, 2:44pm

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.

dangowrt · June 4, 2024, 1:48am

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.

phpaiva · June 7, 2024, 9:23pm

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.