Banana Pi R64 Combined

Hi,

Could someone build an combined image for the Banana Pi R64 for me? Need it to resize the root partition on the sdcard but the instructions on how to do it go straight over my head.

Thanks,

Aaron

if you use the ext4, you can simply fire up gparted on another device, and make the modifications.

or (still on another device, running Linux)

in fdisk:
delete the root fs partition (don't w(rite) the change)
create a new partition with the desired size (start sector should match the deleted partitions)
w(rite) the change

run resize2fs on the modified partition

done

can also be done on the device running it, but will require more work.

Yeah, I know but there is no ext4 image avaible on the download site only the sqaush image.

@frollic AS BPi-R64 is using uImage.FIT image including (read-only!) filesystem, there is no ext4 but only squashfs. You can still use the partition editor of your choice to increase the size of the production partition, that will then result in bigger rootfs_data which you can either re-create or resize.

2 Likes

@daniel What editor do you recommend? I have tried Gparted but after resize the pi fails to boot.

@daniel can you tell me if mmcblk0p5 or mmcblk0p6 is the one with the rootfs on it? Mmcblk0p66 seems to be the overlay but if this is your thread

You mention it's on mmcblk0p5.

On the BPi-R64, when running from eMMC, the whole firmware image is stored in /dev/mmcblk0p4. The rootfs is part of this image and split-off as a virtual partition during boot, also the remaining space is split-off for rootfs_data overlay (see all those FIT lines in the bootlog).

To have a larger rootfs_data you will need to enlarge the production partition (/dev/mmcblk0p4 on BPi-R64 eMMC) and then re-create the overlay filesystem. The easiest way to do this is to resize this partition with parted, then reboot, then make sure the rootfs-overlay is being re-created with the new size using wipefs -f -a /dev/mmcblk0p66 ; reboot -f.

I've just done this (in order to be sure I'm not bullshitting you...) on my R64 and ended up with

root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                19.0M     19.0M         0 100% /rom
tmpfs                   496.1M     40.0K    496.0M   0% /tmp
/dev/mmcblk0p66           7.2G    413.9M      6.8G   6% /overlay
overlayfs:/overlay        7.2G    413.9M      6.8G   6% /
tmpfs                   512.0K         0    512.0K   0% /dev

The good thing is that this change is persistent, ie. you never have to do it again and the new size is kept across sysupgrades.

Would that work with the Sqaushfs as well?

The production partition contains a uImage.FIT image which is a container format used by the U-Boot loader. It is used to store the kernel, device tree blob(s) and the squashfs read-only rootfs. The remaining space on the production partition after the uImage.FIT image is then allocated to the read-write overlay (rootfs_data).
Hence, by increasing the size of the production partition you do also you rise the maximum size the uImage.FIT can be and thereby also the maximum size of the squashfs rootfs.

If you want to generate images with larger rootfs partition size out-of-the-box from the build system you can do so by changing CONFIG_TARGET_ROOTFS_PARTSIZE in .config (e.g. using make menuconfig).

I followed the extroot tutorial but am unsure if it work or not.

Daniel's procedure worked for me as well but on a later version, mmcblk0p66 has been renamed to fitrw. Make sure to boot from eMMC otherwise you'll wipe the overlay partition from the SD-Card instead of MMC even if you booted the production system from SD-Card.

opkg update
opkg install parted wipefs
parted /dev/mmcblk0 resizepart 4 7818MB
reboot

wipefs -f -a /dev/fitrw
reboot