Cannot resize my root partition on BPI R3

Banana Pi BPI-R4/BPI-R3 Mini/BPI-R3/BPI-R64/BPI-R2
21

Thank you very much! :star_struck:

image

22

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

(Supervised system update) image

23

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
24

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
25

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

26

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"
27

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?

28

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:

29

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