Minimal /overlay partition size on large flash storage (eMMC/NAND) leading to immediate storage constraint issues

Feature Requests
1

When installing the Official OpenWrt Factory image onto devices with large internal flash storage (e.g., 32 GB eMMC on a device like the NanoPi R6S), the resulting filesystem partition table consistently allocates only a minimal size to the writeable /overlay partition, leaving the vast majority of the 'block' storage (>30 GB) unutilised

Current State:
Total Flash Size:32 GB (e.g., /dev/mmcblk1)
/overlay (Writeable JFFS2/UBIFS) is limited to ≈100 MB.

Constrained to ≈100 MB of storage for package installation, kernel logs, and configuration, leading to rapid storage exhaustion (df -h shows the small size).

To utilise the remaining space, I am forced to perform clunky manual configuration steps post-installation:

  1. Manually format the large, unmounted partition (/dev/mmcblk1p3).
  2. Manually configure the OpenWrt fstab via uci to mount this partition to a secondary location (e.g., /opt).
  3. Manually manage application data, configuration, and packages to use the new /opt mount point.

This requires significant technical knowledge and is error-prone. More importantly, large packages must be installed to /overlay first and then manually transferred or linked to /opt, which is dangerous if the package temporarily exceeds the ≈100 MB /overlay limit, causing installation failure and potential system instability. You also need to adjust opkg.conf

I am aware that some vendor forks, like FriendlyWrt, use a script to automatically mount the partition as /opt, which, while functional, is still a compromise*

The goal is to seamlessly leverage the full storage capacity for package installation and user data immediately after flashing the OpenWrt factory image, just as standard Linux distributions do.

Proposal:
Implement Automated Filesystem Expansion
Could the OpenWrt installation scripts, specifically the image-generation and first-boot routines, be modified to implement one of the following:

  1. Automated Overlay Expansion:During first boot
    Ddetect the presence of the large, unformatted partition (i.e. /dev/mmcblk1p3), format it automatically, and configure it as an expansion of the writable /overlaypartition
  2. Automated Data Partition/Mount:
    If full expansion is deemed too complex, automatically format the partition and configure a persistent /opt` mount point during first boot. This mirrors the successful functionality seen in third-party forks but would be official and consistent.

Implementing such a feature would significantly improve usability high-capacity devices, eliminate the need for tricky manual workarounds, and align OpenWrt's storage utilisation with higher capacity storage.

2

1/ main limitation is that sysupgrade wipes overlay and transfers only backup from previous config
2/ owut can compose sysupgrade image including packages needed for mount and the config will be preserved.

It is a bit tricky in first install (follow usb stick guide except usb and stick part) , but from then on goes just fine.

btw MMC is block storage, not "flash" via mtd.

3

Thanks Brada4

Are you effectively saying use the exroot procedure but do it on the eMMC as its officially block storage?

4

No extroot, it is you running AI chatbot talking points of outrunning storage rapidly. How do you manage that when OpenWrt does not write anything during continuous operation.

5

Isn't this the correct solution?

or

6

Are you running x86 target?

7

owut can create a 1GB rootfs if you ask it to ?

1 Like
8

Hi

I am a relative newbie, so the goal for me was to create the largest possible root file system with squashfs. That said, I didn't appreciate the time and complexities of having a much larger root file system. So if I need to re-image the OpenWRT device, what the recommended way of having a large root file system without the complexities of having to decide where things go and avoiding having to repartition/expand it each time I perform an upgrade, let along the time the upgrade will take during which my router will be down. I like the idea of performing an upgrade and leaving the large overlay intact, but then there is the risk of version creep etc. with unpurged files on the extended root

In reality, I will keep all of my packages on the roofs and there will be no real change data being written. If I install docker, these will not be data creating images, they will be large stateless, like Twingate,

Is the correct or best way to use:

Expand Root first boot script - https://openwrt.org/docs/guide-user/advanced/expand_root

Extroot - https://openwrt.org/docs/guide-user/additional-software/extroot_configuration?s[]=extroot

Or 1GB root? - https://openwrt.org/docs/guide-user/installation/sysupgrade.owut#expanding_root_file_system

Also if I use the image builder, can all the packages be installed using that custom image or will it run out of space before it creates an expanded root partition area to hold the additional packages.

Finally can anyone in layman’s terms explain the difference in squashes and ext4 for root and on embedded device with eMMC? Won’t the eMMC wear out faster if I use ext4?

Please help as I am getting confused and need some expert advice

9

you still haven't answered @brada4 question about platform.

if you won't tell it to generate a larger rootfs, it'll run out of space.

1 Like
10

Sorry is a nanopi rs6 running arm architecture

1 Like
11 
root@R6SOpenWrt:~# ubus call system board

{

	"kernel": "6.6.110",

	"hostname": "R6SOpenWrt",

	"system": "ARMv8 Processor rev 0",

	"model": "FriendlyElec NanoPi R6S",

	"board_name": "friendlyarm,nanopi-r6s",

	"rootfs_type": "squashfs",

	"release": {

		"distribution": "OpenWrt",

		"version": "24.10.4",

		"revision": "r28959-29397011cc",

		"target": "rockchip/armv8",

		"description": "OpenWrt 24.10.4 r28959-29397011cc",

		"builddate": "1760891865"

	}

}
12

OK, x86 guides are not suitable for your device. Best approach is to add additional data partition one gigabyre into emmc.

1 Like
13

Thanks you for all your help - now have a 1GB root using owut. Will mount remaining space as /opt as block storage to use the remainder of eMMC

1 Like
14

Hi, I have a NanoPi R6S and have been struggling the last few days to get OpenWRT up and running on it. I was eventually able to flash it to the emmc via a usb method, but I've now run into the small partition size issue. I've tried following the guide to increase it to 1GB, but can't quite figure it out.

I think I installed owut, and I figured out how to SSH in with Putty, but the example commands in the guide result in "file not found" (or something to the effect), in particular the "uci" stuff. I have very little networking and firmware experience, and part of the point of doing all this is to learn, but I'm also getting a little frustrated and just need it set up properly soon hah. I don't think I've done anything other than flash to emmc via usb method and install owut. If someone could babystep me through the rest of the process of setting this guy up, it'd be a big help. Cheers.

15 
uci set attendedsysupgrade.owut=owut
uci set attendedsysupgrade.owut.rootfs_size=1024
uci commit
: owut check -v
: owut upgrade --force

Commands are slightly d`maged to force you to understand their consequences.
eg last two are commented here.

16

Okay, I got it. I actually hadn't installed owut as I thought, because I hadn't plugged the wan in --- in my mind since the computer I was SSHing from had internet, it had downloaded and installed, but I actually had errors...

After that the commands from the guide worked.

Is there anything else I need to do to make the rest of my emmc available? I'm guess I need to figure out how to make another partition and assign that the rest of the space?

17

Anything else OT to add to hijacked closed thread?

18

OT? Don't know what that means. I figured it was fine to join the thread since it's 3 days since last reply (I've been lurking for a few days) and it says threads close after 10 days.

I'm also a little puzzled in the mismatch between LuCI showing 98.63 MiB as storage space vs the command line showing rootfs_size='1024', even after rebooting the device.

Edit: Finally figured it out. I was trying to rebuild using the "LuCI Attended Sysupgrade app" as suggested in the (i)=bubble on the user guide, but it wouldn't do it since I already have the latest firmware installed. Turned out the thing to do was "owut update" in the command line: there were in fact a couple small updates, the router rebooted and seemed to rebuild (had the flashing sys light), and now LuCI shows 1024mb.

19

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.