BananaPi BPI-R4 resize eMMC to use full 8gb

I’ve scoured the forums, yet found no solution, so here’s how i did it.
The problem: flasing from NAND to EMMC does not utilize the full 8gb of storage. Only less than half a GB. /dev/mmcblk0p5is not an F2FS partition, but something that during the boot process becomes /dev/fit0 (a squashfs - /rom) and /dev/fitrw(an F2FS partition - /). I don’t understand how this works, but I figured that the BPI-R3 wiki with resize.f2fs fails. People in this thread also had issues.

Here’s my solution:

SOLVED

What worked for me required an extra step. Here's a detailed guide with all steps explicit for first-timers:

  1. write bananapi_bpi-r4-sdcard.img.gz to an sd card (unzip first) or whatever version is current.
  2. Boot from sdcard (SW3 pins to 1,1).
  3. connect a serial adapter, far easier than manually setting default boot options with fw_setenv commands, and you see the boot process. Also my BPI-R4 came with a serial adapter that's pretty good.
  4. in the boot menu chose "9. Install bootloader, recovery and production to NAND." (@Miles28 calls this step Flash NAND).
  5. boot to NAND (SW3 pins to 0,1) (remove power cable and then change pins)
  6. in the boot menu chose "9. Install bootloader, recovery and production to EMMC." (@Miles28 calls this step Flash EMMC).
  7. then continue to boot in NAND
  8. install cfdisk and cfdisk /dev/mmcblk0 → Resize /dev/mmcblk0p5 to something like 7.2G. This can be done with gdisk, parted, fdisk, yet cfdisk is easiest.
  9. I couldn't make use of resize.f2fs - mmcblk0p5 is not an F2FS partition, but something that becomes /dev/fit0 and /dev/fitrw, the second is an F2FS partition. But the process eludes me, so i don't know how to resize fitrw. My second idea is to hope the first boot on EMMC will resize fitrw automatically.
  10. boot to EMMC (SW3 pins to 1,0) (remove power cable and then change pins)
  11. I expected fitrw to be 7.2G, yet it was 428MB. So the auto resizing fails.
  12. What fixed it for me was to boot in EMMC and then umount /dev/fitrw and firstboot -y. If you don't umount first, fitrw survives, see logs below.

Relevant logs:

unsuccessful attempt

root@OpenWrt:~# firstboot -y
/dev/fitrw is mounted as /overlay, only erasing files

See how it only erases the files. That is not enough - fitrw survives with the old size.

successful attempt:

root@OpenWrt:~# umount /dev/fitrw
root@OpenWrt:~# firstboot -y
/dev/fitrw is not mounted
/dev/fitrw will be erased on next mount

See how fitrw will be erased "on next mount"? This is what makes the resizing work. Note: Of course in all cases you lose all your rw data, but that is expected.

dmesg logs:

[   10.333417] mount_root: overlay filesystem in /dev/fitrw has not been formatted yet
[   11.268669] F2FS-fs (fitrw): Found nat_bits in checkpoint
[   11.302163] F2FS-fs (fitrw): Mounted with checkpoint version = d70cacb
[   11.309183] mount_root: overlay filesystem has not been fully initialized yet
[   11.316582] mount_root: switching to f2fs overlay
[   11.322343] overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off.

I think here fitrw is created.

df -h

Filesystem                Size      Used Available Use% Mounted on
/dev/root                11.0M     11.0M         0 100% /rom
tmpfs                     1.9G    444.0K      1.9G   0% /tmp
/dev/fitrw                7.2G    191.8M      7.0G   3% /overlay
overlayfs:/overlay        7.2G    191.8M      7.0G   3% /
tmpfs                   512.0K         0    512.0K   0% /dev

I still don't understand how this fitrw is created from the partition. If someone can explain, I'd be grateful.

You don't need resize_f2fs, when using squashfs.

I wrote a quick howto for the bpi-r3. The partition layout in the r4 may be different, so you need to figure out yourselve, wich partition needs to be resized. The General procedure should be similar though:

1 Like

The gotcha with BPI-R4 is that you need to umount and firstboot -yafter you resize with cfdisk/parted/gdisk/… when you boot from EMMC. All of those - cfdisk/umount/firstboot - are in multiple tutorials and solutions, yet I never saw them in one consistent manual that worked for me.