In case you are building OpenWrt from source, the size of the production partition can also be defined in menuconfig:
This sets the configuration variable CONFIG_TARGET_ROOTFS_PARTSIZE in .config which you can also edit when using the ImageBuilder.
i can’t get resize.f2fs to work. always get this error.
root@OpenWrt:/# resize.f2fs /dev/mmcblk0p66
Info: Mounted device!
Info: Check FS only on RO mounted device
Error: Failed to open the device!
root@OpenWrt:/# parted
[ 72.615289] mtdblock: MTD device 'reserved' is NAND, please consider using UBI block devices instead.
[ 72.625300] mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead.
[ 72.639108] mtdblock: MTD device 'bl2' is NAND, please consider using UBI block devices instead.
[ 72.648579] mtdblock: MTD device 'fip' is NAND, please consider using UBI block devices instead.
GNU Parted 3.4
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: MMC 008GB0 (sd/mmc)
Disk /dev/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
128 17.4kB 4194kB 4177kB bios_grub
1 4194kB 4719kB 524kB ubootenv hidden, legacy_boot
2 4719kB 6816kB 2097kB factory hidden
3 6816kB 11.0MB 4194kB fip boot, hidden, esp
4 12.6MB 46.1MB 33.6MB recovery boot, hidden, esp
6 46.1MB 67.1MB 21.0MB owrt-volumes lvm
5 67.1MB 835MB 768MB production
(parted)
tried the autopart too, but still only showing 25mb free space.
anyone has a hint on what failed?
You cannot resize /dev/mmcblk0p66 because that’s not really a partition but rather just the remaining space left after the uImage.FIT on /dev/mmcblk0p5, I have explained this in detail just a few posts above.
So i need to use ‘resize.f2fs’ with the ‘dev/mmcblk0p5’ partition which will automatically reflect the changed size in ‘/dev/mmcblk0p66’ partition after reboot?
Sorry, I may not have been fully awake when replying to your post. The partition table looks good, you have successful edited and expanded mmcblk0p5. To use resize.f2fs you need to boot into the recovery firmware or boot from SPI-NAND, so that the partition will not be in use while you are trying to resize it.
command is not included in recovery i assume.
You can install it via opkg. It will be gone after reboot, but good enough for a single use.
Do what it says 
Mount and unmount it first to replay logs before resizing.
okay… i seriously don’t understand whyever that would be needed, but it indeed works… Thanks a lot!
root@OpenWrt:/# mount /dev/mmcblk0p66 /mnt
root@OpenWrt:/# umount /dev/mmcblk0p66
root@OpenWrt:/# resize.f2fs /dev/mmcblk0p66
Info: MKFS version
"Linux version 5.15.80 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r21380-5429411f73) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Fri Dec 2 15:57:48 2022"
Info: FSCK version
from "Linux version 5.15.80 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r21380-5429411f73) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Fri Dec 2 15:57:48 2022"
to "Linux version 5.15.80 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r21380-5429411f73) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Fri Dec 2 15:57:48 2022"
Info: superblock features = 0 :
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
Info: Segments per section = 1
Info: Sections per zone = 1
Info: total FS sectors = 191392 (93 MB)
Info: CKPT version = 351ed6c6
Info: Duplicate valid checkpoint to mirror position 1024 -> 512
Info: Write valid nat_bits in checkpoint
[FIX] (move_one_curseg_info:2857) --> Move curseg[0] 3 -> 4 after 1000
[FIX] (move_one_curseg_info:2857) --> Move curseg[1] 5 -> 9 after 1000
[FIX] (move_one_curseg_info:2857) --> Move curseg[2] 6 -> a after 1000
[FIX] (move_one_curseg_info:2857) --> Move curseg[3] 0 -> b after 1000
[FIX] (move_one_curseg_info:2857) --> Move curseg[4] 1 -> c after 1000
[FIX] (move_one_curseg_info:2857) --> Move curseg[5] 2 -> d after 1000
Info: Write valid nat_bits in checkpoint
Try to do defragement: Done
[migrate_ssa: 270] Info: Done to migrate SSA blocks: sum_blkaddr = 0xe00 -> 0xe00
[migrate_nat: 387] Info: Done to migrate NAT blocks: nat_blkaddr = 0xa00 -> 0xa00
[migrate_sit: 445] Info: Done to restore new SIT blocks: 0x600
Info: Write valid nat_bits in checkpoint
[rebuild_checkpoint: 591] Info: Done to rebuild checkpoint blocks
[update_superblock: 701] Info: Done to update superblock
Done: 0.000000 secs
root@OpenWrt:/#
root@OpenWrt:/# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 5.5M 5.5M 0 100% /rom
tmpfs 997.9M 68.0K 997.8M 0% /tmp
/dev/mmcblk0p66 719.8M 141.6M 578.1M 20% /overlay
overlayfs:/overlay 719.8M 141.6M 578.1M 20% /
tmpfs 512.0K 0 512.0K 0% /dev
root@OpenWrt:/#
for some reason 141 mb is used now… more than full 104mb of available space before… but whatever. it works!
F2FS calculated free space is very conservative and always reserves a large part of the storage volume.
I am also struggling with this problem.
I am using my bpi3 device in emmc mode.
BusyBox v1.35.0 (2022-12-10 16:36:12 UTC) built-in shell (ash) OpenWrt SNAPSHOT, r21438-8327e0fb72
i wrote down all the steps i took to increase Root partition.
if you follow step by step you can easily increase it: [BPI-R3]How to flash Openwrt snapshot on EMMC? Post nr5
Thank you very much! 
Will this partition setting be preserved in the event of a system update?
(Supervised system update)
Yes,
But i think the Mount Points failed, last time i tried.
let me just test that… still on: Currently running: SNAPSHOT - r21432-4c0919839d
Edit. Yeah works fine
Perhaps this value should be set to something a little more reasonable by default? AT 104MiB that only leaves about 20MiB free for the user. For a device like the R3 (and R64 and R2) which you can expect people will install many packages on, this isn’t enough for even some basic added capabilities.
I realize you are against having it larger than RAM. It should be 256MiB at the very least. The average user should not be expected to have to resize the partition/filesystem, compile their own kernel, or use uvol. This is a barrier to wider adoption.
hi, I also have some trouble to rezise the filesystem. Bevor even that I always get the info, that my backup gpt table is corrupted. At first i thought its because I used a snapshot. But its the same with the R3. I repaired the backup table with gdisk. Now I was able to resize the partition. But Unfortunately I still cant resize the file system.
Number Start End Size File system Name Flags
128 17.4kB 4194kB 4177kB bios_grub
1 4194kB 4719kB 524kB ubootenv hidden, legacy_boot
2 4719kB 6816kB 2097kB factory hidden
3 6816kB 12.6MB 5767kB fip boot, hidden, esp
4 12.6MB 67.1MB 54.5MB recovery boot, hidden, esp
5 67.1MB 800MB 733MB production
6 805MB 7818MB 7013MB f2fs
root@OpenWrt:~# resize.f2fs /dev/mmcblk0p66 Info: MKFS version “Linux version 5.15.127 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23389-5deed175a5) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Sat Aug 19 14:01:06 2023” Info: FSCK version from “Linux version 5.15.127 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23389-5deed175a5) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Sat Aug 19 14:01:06 2023” to “Linux version 5.15.127 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23389-5deed175a5) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Sat Aug 19 14:01:06 2023” Info: superblock features = 0 : Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000 Info: Segments per section = 1 Info: Sections per zone = 1 Info: total FS sectors = 192032 (93 MB) Info: CKPT version = 6147d102 [FIX] (move_one_curseg_info:2921) --> Move curseg[0] 16 -> 5 after 1000
[FIX] (move_one_curseg_info:2921) --> Move curseg[1] 15 -> 19 after 1000
[FIX] (move_one_curseg_info:2921) --> Move curseg[2] 3 -> 1a after 1000
[FIX] (move_one_curseg_info:2921) --> Move curseg[3] 0 -> 1b after 1000
[ASSERT] (move_one_curseg_info:2904) ret == 0
Best practice to extend the file system is build your own image and format the remaining space to ext4 and mounting like ’ sd1’, keeping an uniform build help to safely upgrade keeping the ext4 partion untouched, with the OpenWrt imagebuilder is easy to extend the file system ROOTFS PART SIZE=" " , With this example filesystem is extended to 250mb :
wget https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/openwrt-imagebuilder-mediatek-filogic.Linux-x86_64.tar.xz
tar -xf openwrt-imagebuilder-mediatek-filogic.Linux-x86_64.tar.xz
cd openwrt-imagebuilder-mediatek-filogic.Linux-x86_64
make image PROFILE=bananapi_bpi-r3 ROOTFS_PARTSIZE="250" PACKAGES="luci"thanks for the tip. I didn’t know that yet. Once I’ve done that, can I flash regular images afterwards, or do I always have to compile them myself?
I’m actually really interested in what’s considered “best practice” for the eMMC partitioning scheme from @AntonyFl and other posters such as @Haldi since I’m now setting up my BPI-R3 board w/ OpenWRT:
Why wouldn’t I just use all the available space (8GB) on the eMMC by default? I don’t see the immediate benefit of having an additional /extraspace mountpoint. Perhaps to gracefully handle ENOSPC situations for things like logging that might go out of hand and affect the system’s operation?
I’m assuming that your “make image” example is building images on the router itself? Why would you prefer that over getting it done on a faster multi-core (desktop or server) machine and SCP the outputs over? Since the eMMC is soldered into the board, aren’t you concerned about wear of that memory under relatively intensive I/O?
I do see the benefit of having NOR/NAND memories for disaster recovery/failsafe modes: flip the DIP switches and back to work, but partitioning does not help when an entire memory IC dies, for instance… so many options and preferences on this seemingly narrow topic 
You missed to read the link , the Image Builder runs only in x86 64-bit Linux or a VM like github CI , this workflows can generate bpi r3 firmware using the OpenWrt image builder