Cannot resize my root partition on BPI R3

Thank you very much! :star_struck:

image

Will this partition setting be preserved in the event of a system update?

(Supervised system update) image

Yes,

But i think the Mount Points failed, last time i tried. image image

let me just test that… still on: Currently running: SNAPSHOT - r21432-4c0919839d

Edit. Yeah works fine :wink:

1 Like

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.

1 Like

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 :wink:

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

1 Like