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

Hey guys after getting my pi flashed on the emmc, i noticed that i have just 30mb to install packages on top of it (see screenshot)

I have an additional 250gb samsung nvme installed, which is also displayed, how can I mount this? because mount unfortunately does not work <— I would like to install adguard home with on the Pi, however this requires significantly more memory

image image image

Why are 70MiB out of total 90MiB already occupied just after installing the image?

You have lots of additional space on the eMMC as well, it’s 8 GiB total, just not assigned to any partition.

So you have plenty of options. You can create additional partitions which are not managed by OpenWrt (and hence survive sysupgrade). Or you can either increase the size of /dev/mmcblk0p5. Or you can use the extroot feature of OpenWrt to use either an additional partition on the eMMC or NVMe SSD as rootfs overlay.

You should add board (r3?) and os (i guess openwrt) to title and the image you flashed (bpi/mainline openwrt sd/emmc) and error message for mount to text.

how do I expand the memory? is there any documentation for this ?

Which BPI do you have, what version of OpenWrt do you have flashed?

BPI R3 and latest version of R3

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.

1 Like

unfortunately no one of these works

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.

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

image

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.

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:?

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

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.

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.