24.10.4 - expanding filesystem (BananaPi BPI-R3)

Installing and Using OpenWrt
1

Hey there,

I'm new to OpenWRT and still figuring things out. I bought a BananaPi BPI-R3 to use for my home internet access. Flashing OpenWRT and playing around with the basics (while I am still waiting for the activation of my Fiber Connection that has ETA end of next week) seems quite intuitive to me.

However I am struggling to expand the filesystem of my installation.

I tried following the installation Process via the devices wiki page here

I did not yet decide to really install it on the eMMC. I have some bad experience with eMMC on another SBC and rather will try to keep backups of the SD Card and replace that once in a while.

I installed the 24.10.4 Factory Image (https://downloads.openwrt.org/releases/24.10.4/targets/mediatek/filogic/openwrt-24.10.4-mediatek-filogic-bananapi_bpi-r3-sdcard.img.gz)

I can witness the boot process fine with one of the Serial2USB i had lying around, very handy.

However, when i want to follow this process here, to expand the filesystem to offer me more than default 1GB (the SD card has 64GB), i struggle

After downloading the script and running
sh /etc/uci-defaults/70-rootpt-resize

There is some error message, which i could only screenshot:

openwrt_error
openwrt_error1026Ă—186 30.5 KB

Error could not stat device /dev/block - No such file or directory

The

ROOT_DISK: /dev/block , ROOT_PART = 0

Is some debug output that i had added to the script when i tried to reproduce the error message.

I know some Linux things, but I am not yet familiar enough with "embedded linux" and the OpenWRT Architecture and way of things to figure out how to debug the script.

Is there something wrong with my install?
Is the script in the Wiki not up to date with the way 24.10.4 works?

Did I forget some crucial step in between flashing, booting and trying to expand the file system?

Any hint is very much appreciated, thanks in advance!

2

Instead of doing it all manually, you could take the easy way out:

2 Likes
3

Thanks for your reply, but I'm afraid I am still not fully understanding.

The default value varies depending on target, but is often 104 MB and the --rootfs-size option allow you to increase that up to 1024 MB (see note below)

Am I mixing things here? I thought I'd expand the storage to the maximum capacity of the SD Card (which is 64GB currently, I ordered a 128GB one).

Is the remaining capacity then not the rootfs, but some ofter fs that exists in parallel for other storage (like when running Docker on OpenWRT)?

4

Yes, it is true. The remaining capacity is not the rootfs.

A few key points for you to research for better understanding.
OpenWrt has a historical main focus of providing router software for embedded devices with limited ram and storage.
The normal upgrade process builds an image with an amount of free space that fits on most of these resource limited devices.
The image with free space is built on the build servers. That is why the max space for the newer image building process is limited to 1024Mb, to limit server side resource usage.
Your device copies the image to the raw storage device defining the partition table and one or more partitions. This wipes out any existing partition table for any additional partitions you may have manually added.
Existing data to restore to the upgraded system is stored in RAM, or maybe on storage device after the standard partition, during the image flashing process, so it is limited to available RAM, or assumed free space on storage. Owut: OpenWrt Upgrade Tool - #975 by efahl . See note above about the focus on limited resource devices.
squash fs vs ext4 or other formats adds complexity. Squash fs is compressed and immutable so changing files requires an overlay fs to write to.
It looks like there is no easy way to do an in-place upgrade and use large amounts of storage. You could run your own imagebuilder system and do it. Transferring all the added data is up to you though.
And there are more issues to consider.

1 Like
5

The user guide for Expanding root partition and filesystem that you linked is specific to x86 and likely needs adaptation to work with other x86 variants as well as other platforms / device types / specific device models. I think that one is designed specifically to be included in a custom built image to run automatically on first boot. Other scripts to install and run manually work well and my need the same tools installed. Info on some can be found in the user guides.

I expanded the storage on my sd-card(s) for my FriendlyElec R4S which is a “pi” type device with an Arm based Rockchip processor and using sqashfs and an overlay filesystem. See this topic for lots of info: Resizing the hidden overlay filesystem when it is ext4 and not f2fs

Additionally, search the forum for more info if that topic doesn’t suit you.

In attempting to assist others with a BPI-R3 it came to light that there were several partitions which prohibited being able to expand the root filesystem. That might have been on the eMMC though.

While running your BPI-R3 from your sd-card, the command block info should show you the block storage partitions on the sd-card. They may be under a path something like /dev/mmcblk1p1 or it might have 0 before the p.
Mine:

root@R4S-wrt:~# block info
/dev/loop0: UUID="990fdb02-1784-41f2-9e93-6309aa4043d1" LABEL="rootfs_data" VERSION="1.0" MOUNT="/overlay" TYPE="ext4"
/dev/mmcblk1p1: UUID="84173db5-fa99-e35a-95c6-28613cc79ea9" LABEL="kernel" VERSION="1.0" TYPE="ext4"
/dev/mmcblk1p2: UUID="e3c74bfd-081c4550-52536fdd-7a3f08e3" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/sda1: UUID="811E-1A0A" LABEL="RDATA" VERSION="FAT32" MOUNT="/usb-stor/usb1p1" TYPE="vfat"
/dev/sda2: UUID="69A8-19E8" LABEL="P2" VERSION="FAT32" TYPE="vfat"

I am using squashfs so my writable overlay is on loop0
sda1 and sda2 are partitions on a usb flash drive and are used for "data" I do not have a lot of large additional executables so I don't expand my root filesystem. I did that to learn and help others.

If you just have two partitions, the first will be the kernel and the second the boot filesystem. If you have 2 partitions and a loop0 filesystem, my link above should help you proceed. Once your router has gone through firstboot, the scripted tasks I linked to ca be run on a live running OpenWrt device or offline with a linux system/pc.

I'd be willing to try to help more if you like. Just reply here and we can continue.

Last but not least, I ask you to consider why you want a larger root filesystem. If it is "just because" or you want lots of services and everything on one simple to manage filesystem, then with OpenWrt alternative approaches may serve you better. OpenWrt is not like mainstream desktop linux distros.

My approach: I use 2 sd-cards and rotate them. I back up my config and a list of installed packages and build a custom image with https://firmware-selector.openwrt.org and burn it to my "old" version sd-card, insert it to my R4S and boot. I connect to it and restore my config and reboot. Done. :slight_smile:
I save configs, collectd stats, scripts etc on the usb flash drive formatted as ext4.
This way allows me to quickly swap back to a known good system for a while after upgrading simply by swapping the sd-card, assuming the data formats of info saved to the usb flash drive are the same as they have been.
I use squashfs so that I can factory reset if my software and configs get messed up. Backing up every time I am done editing my config.

This has been reliable for a few years so far.

6

TL;DR: thanks for your post, i will need to read it again later and check with the BPI once I am at home.

Yeah thanks for the offer, very much appreciated.

I am well aware OpenWRT is not a Distro like the Debians of the world. My first priority is to have the BananaPi running OpenWRT and maybe Wireguard on top. Wireguard runs in an LXC on another server right now, but I thought it would be nice to have it running on the Router directly when it is supported.

Other - low foot print - services would be nice to have too. E.g. right now I run an additional Raspberry Pi4 that serves mostly as a Fallback SSH Gateway (that i can use to ssh into and do things from remote). This Pi4 also runs my dnsmasq for the Split-DNS setup i have and as a DHCP Server. If I - in the long run - can replace this extra Pi4 by offloading it onto the OpenWRT, that would be nice. But not required. I have this setup because my old router was very basic in features and would either allow being DHCP+DNS Server for everything, or disable DHCP completely. So i decided to run my own to be able to configure dns resolution to my needs.

1 Like