[BPI-R3] Change or add partion to /overlay

[VA1DER (Kurt Fitzner)]

I don’t know what version of OpenWrt is being shipped on the R3s. Can you go to the initial status page and let me know what the firmware version is?

I will add for any OpenWrt devs who might come across this, that every official build of OpenWrt should be set up to use all the available eMMc space in a given platform. This whole 100MB partition that every release uses is a bad idea - it does nobody any good.

Now, as as dangort said, a few options:

1: Use extroot to change the overlay partition. Do a search for “OpenWrt extroot”. With this method you can use your nvme drive as extra space.

2: Increase the size of the boot filesystem. To do this you have to:

1. Boot onto an external sdcard, because you can’t resize the partition when you are booted into it.
2. Use parted /dev/mmcblk0p5 to first increase the size of /dev/mmcblk0p5 - this is the physical partition that the virtual root partition mmcblk0p66 lives on
3. Use resize.f2fs /dev/mmvblk0p66 to resize the root filesystem

Unfortunately, it looks like there is another physical partition, mmcblk0p6, a 20MB partition, right after it in the way. I don’t know why this is there. Did you make it? If the system made it, then you might have to move it out of the way first to resize /dev/mmvblk0p5. If you don’t already know enough about partitions and partition editors to do this, then I’m hesitant to try and step you through this.

3: You can make your own OpenWrt build that sets the size of the root partition to something sane. Or have someone make one for you. At this point, this might be the easiest option.

[Bigsmoke002 (Léon Döring)]

unfortunately no one of these works

[dangowrt (Daniel Golle)]

This whole 100MB partition that every release uses is a bad idea

Having a rootfs-overlay as large as the eMMC hardly makes much sense, as it would be larger than the tmpfs used to backup configuration. Just use additional partitions for large amounts of data, as everything else will anyway have to be backed-up and restored on every sysupgrade, and that only works if it fits into /tmp.

[Bigsmoke002 (Léon Döring)]

I have figured out how to mount the remaining 7gb

to extend the /overlay do the following

install cfdisk

cfdisk /dev/mmcblk0

format the FREE space (7,1GB)

save and exit

then

mkfs.ext4 /dev/mmcblk0p6

mount /dev/mmcblk0p6 /overlay/

now the 7GB are mounted

[VA1DER (Kurt Fitzner)]

it would be larger than the tmpfs used to backup configuration

LUCI only supports backups of /etc/config and a few other files in /etc. Having a larger rootfs has no impact on the amount of data someone stores in /etc/config. For the vast majority of users there would be no impact to they way they do business having a large rootfs.

For the others, it’s not an unreasonable expectation that those who are performing manual sysupgrades who want to preserve everything that they have other means, as I do.

Just use additional partitions for…

Not everyone, as this thread shows, is technically adept enough to work out how to do this nor should they have to be. How many computers come with a terrabyte hard drive, and then only provide the end user with small fraction of that for C:? And then just expect people that if they want more will mount it in, or expand C:?

[dangowrt (Daniel Golle)]

LUCI only supports backups of /etc/config and a few other files in /etc. Having a larger rootfs has no impact on the amount of data someone stores in /etc/config. For the vast majority of users there would be no impact to they way they do business having a large rootfs.

Preservation is configurable and many package automatically add files to be preserved, it’s not just /etc/config…

For the others, it’s not an unreasonable expectation that those who are performing manual sysupgrades who want to preserve everything that they have other means, as I do.

What do you mean by “manual”? Any kind of sysupgrade (which is also the only way to update the Linux kernel and modules) always wipes rootfs_data. Expecting that users will backup their data (or whatever it is they want to store there) onto some external media before performing sysupgrade is more complicated than asking them to installing uvol and autopart which allows to easily manage additional filesystem volumes, e.g. for container images or any kind of data, which will survive sysupgrade. Also note that many application hungry for disk-space don’t like running on top of overlayfs, e.g. Docker won’t work in that way.

Not everyone, as this thread shows, is technically adept enough to work out how to do this nor should they have to be . How many computers come with a terrabyte hard drive, and then only provide the end user with small fraction of that for C:? And then just expect people that if they want more will mount it in, or expand C:?

Well, OpenWrt is not a general purpose OS like, let’s say Debian/GNU Linux or Microsoft Windows. It’s a firmware meant for special purpose embedded devices and has a quite different idea about e.g. software lifecycle. Inviting users to fill up the rootfs overlay is not a good idea, as that will either make them loose everything every time they update the firmware or they just won’t update. Both is a bad result.

For end-users who need space for additional data, e.g. to be served via HTTP or adguard lists or whatever, I’d recommend:

opkg update
opkg install uvol autopart
uvol create userdata $(uvol free) rw

This will provide a read-write filesystem volume using all remaining space which is mounted to /tmp/run/uvol/userdata by default. The mountpoint can be adjusted, if needed.

[Haldi]

So what would be the best option?

Increasing the 104MB mmcblk0p5 is not possible. Adding another 100-500mb partition for packages.

Then adding the rest via uvol for Userdata from docker and other stuff?

[Haldi]

how exactly did you manage to get the mounted partition to show up in software? Did pretty much the same as you. Can see the “mounted” partition in the faile systems menu. But Software is still not any bigger

[Boysa22]

Hi Haldi,

Increasing mmcblk0p5 is posible. I actually booted from NAND and then used the “Install to EMMC option”. This creates the partitions on EMMC. Then I used parted to resize mmcblk05 before booting from EMMC. Then set the switches to boot from MMC. Check the post dragowrt here:

Cannot resize my root partition on BPI R3

On the R3 the /dev/mmcblk0p66 device is automatically mapped as the remaining space on /dev/mmcblk0p5 after parsing the uImage.FIT for kernel, device tree and read-only squashfs rootfs (squashfs filesystem is mapped as /dev/mmcblk0p65). So those p65 and p66 partitions are not actual GPT partitions but rather p65 is the filesystem sub-image of the uImage.FIT stored in p5 and p66 is the remaining space on p5 after the uImage.FIT. Hence you only need to edit the size of /dev/mmcblk0p5, then reboot…

[Haldi]

does that not cause issues with Updates?

[dangowrt (Daniel Golle)]

It will not prevent you from updating, just be aware that any data stored on the rootfs will be wiped, apart from configuration files and what ever else you put into /etc/sysupgrade.conf (and all that together needs to fit into /tmp which is tmpfs, ie. RAM-backed during the upgrade process, so cannot be very huge).

Hence, for any kind of persistent data other than software packages and their configuration, it is advisable to resort to additional storage volumes instead of using the root filesystem. Esp. in case you are planning to use Docker or podman, be aware that these do not work on overlayfs, and OpenWrt’s rootfs is overlayfs – so for those space-hungry things like container images you will anyway always need an additional storage volume as the rootfs cannot be used for that.

[Haldi]

Okay… So increasing mmcblk0p5 should work and persist in updates? Only when you install a new image from MicroSD would that be overwritten.

Currently Tempfs is around 1gb (as shown in Mounts) but we do have 2gb RAM. So isn’t that too small? Or does the router need more ram during the update and 50% of RAM is the optimal size?

Going by that we could increase the size of mmcblk0p5 untill all together reaches 1gb aka Tempfs size. I’ll do the math when I’m back home… And try it out.

Then the rest of the 8gb eMMC can be mounted separately.

[dangowrt (Daniel Golle)]

So increasing mmcblk0p5 should work and persist in updates?

The size itself will persist, ie. you will not have to make the change of partition size again after upgrade. But the content will be wiped, unless you register files to be kept across updates in /etc/sysupgrade.conf – and there you are limited to the size of tmpfs in RAM.

Only when you install a new image from MicroSD would that be overwritten.

Exactly. The partition table is created only when installing from eMMC.

Going by that we could increase the size of mmcblk0p5 untill all together reaches 1gb aka Tempfs size. I’ll do the math when I’m back home… And try it out.

That can work, but affect both, the partition table on the microSD and eMMC. However, most microSD cards as of today are also 1GiB or larger. When adding support for eMMC on MT7622 and MT7986 targets I’ve basically just copied the existing default in OpenWrt, but maybe this should be re-considered and instead of 104MiB default we can increase it globally to 768MiB (still leaving enough space for kernel and bootloader on a 1GiB medium).

[FerrumMaster (Zigmars Henzels)]

Well it would be great that the partition would be at least 256MB, we have a really powerful device here.

Python3 takes a lot of space, and I would like to run DIYHUE emulator on it for example.

[Haldi]

the 104MiB default come from the NAND version? As there is only 128mb Nand and 32mb NOR. or is that separate from the emmC image/config?

I think 768MiB would help a lot as current Snapshot builds only have around 30mb Free space. Especially since most OPKG packages tell WAY to low values for Storage they need.

[sulaco]

I haven’t seen any mention of it, but is it possible to boot from m.2/NVME or can it only be used for additional storage?

[frank-w]

You cannot directly boot from it,but you can have rootfs from it. Uboot does not yet support pcie controller. If this is supported,kernel can be loaded from there too

[lu_zero (Luca Barbato)]

Is the nvme support in uboot working better now? I saw https://u-boot.readthedocs.io/en/latest/develop/driver-model/nvme.html

[frank-w]

Uboot still misses pcie driver for mt798x as i’ve wrote above

[yohru]

Extend software free space, about 100MB to eMMC 8GB.

Completed environment:
・Boot from SPI-Nand
・eMMC 8GB or nvme for “/overlay” area.
・If expand using this method, there is no problem even if restart the BPI-R3.

Extroot configuration => https://openwrt.org/docs/guide-user/additional-software/extroot_configuration

Note: Change the target device, in to the eMMC.

It now allocate eMMC(8GB) to the “/overlay” area.
DEVICE="/dev/mmcblk0"

Can also allocate nvme instead of eMMC.
DEVICE="/dev/nvme0n1"