OpenWrt wiki says that 80MB of the 128MB flash on Netgear R7800 is available after installing OpenWrt 18.06, but as of 24.10 there is only 18MB available. Significant difference in usability!
Old discussion from 2017 describes how a 70MB Netgear partition was left untouched as it might contain important stuff for reverting to Netgear firmware, but after experimentation it sounds like some solution was found and was committed to master that made 68MB available. (Still not 80MB, so I’m confused about what the wiki says.) In any event, with 24.10 it’s 18MB free.
I’m a bit disappointed as I had plans to use some of that flash space to add packages, but mostly I’m just curious and wonder if anyone knows the story. Like where did the 80MB cited in the wiki come from? Did the 68MB-free commit work out, but for some reason get reversed?
In my R7800 there are (with the current 9 MB package selection in the firmware image rootfs seen as /dev/root) about 73 MB free flash in /overlay. And a few megabytes of that is used by stats and ubifs structures, so that right now there is 69 MB free.
Could the difference somehow be that my device had the bad block problem so I had to first boot initramfs and then sysupgrade? Like for some reason the use-full-flash patch gets bypassed in that case? I’m grasping at straws here …
Well, the DTS defines the area for whole usable flash area for firmware (kernel+rootfs) and user data (/overlay) to be 0x6080000 bytes = 101 187 584 bytes. Just over 101 million... Typical firmware with LuCI and modest package selection is maybe 10-15 MB, (my own factory image is 18 MB and the sysupgrade image is 13 MB). Ubi info shows 81 MB as the size for rootsfs_data = overlay space for user.
root@router78:~# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 2
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 772 (98025472 bytes, 93.4 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
Current maximum erase counter value: 41
Minimum input/output unit size: 2048 bytes
Character device major/minor: 247:0
Present volumes: 0, 1
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 79 LEBs (10031104 bytes, 9.5 MiB)
State: OK
Name: rootfs
Character device major/minor: 247:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 669 LEBs (84946944 bytes, 81.0 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 247:2
root@router78:~#
Yes. You should have mentioned that in the first place...
If you have not used the "factory" OpenWrt image, the partition structure may have been left unmodified, as sysupgrade writes kernel and rootfs separately using the current partitions. Factory image has them concatenated, and the ubi size gets readjusted.
It might be possible to expand via ubirsvol, if there are more LEBs seen by ubi than is currently allocated to the two ubifs volumes.
If not, then it might be need for uniform at /dev/mtd6 with the rootfs image lifted out from the sysupgrade image (which is essentially .tar.gz containing kernel and rootfs separately)
Mtd should show that there mtd6 is the one used for ubi.
root@router78:~# ubi
ubiattach ubidetach ubimkvol ubirename ubiupdatevol
ubiblock ubiformat ubinfo ubirmvol
ubicrc32 ubihealthd ubinize ubirsvol
root@router78:~# ubirsvol -h
ubirsvol version 2.2.1 - a tool to resize UBI volumes.
Usage: ubirsvol <UBI device node file name> [-n <volume id>] [--vol_id=<volume id>]
[-N <volume name>] [--name=<volume name>] [-s <bytes>] [-S <LEBs>] [-h] [--help]
Example: ubirsvol /dev/ubi0 -n 1 -s 1MiB resize UBI volume 1 to 1 MiB on
UBI device corresponding to /dev/ubi0
ubirsvol /dev/ubi0 -N my_vol -s 1MiB - resize UBI volume named "my_vol" to 1 MiB
on UBI device corresponding to /dev/ubi0
-n, --vol_id=<volume id> volume ID to resize
-N, --name=<volume name> volume name to resize
-s, --size=<bytes> volume size volume size in bytes, kilobytes (KiB)
or megabytes (MiB)
-S, --lebs=<LEBs count> alternative way to give volume size in logical
eraseblocks
-h, -?, --help print help message
-V, --version print program version
root@router78:~# ubiformat -h
ubiformat version 2.2.1 - a tool to format MTD devices and flash UBI images
Usage: ubiformat <MTD device node file name> [-s <bytes>] [-O <offs>] [-n]
[-Q <num>] [-f <file>] [-S <bytes>] [-e <value>] [-x <num>] [-y] [-q] [-v] [-h]
[--sub-page-size=<bytes>] [--vid-hdr-offset=<offs>] [--no-volume-table]
[--flash-image=<file>] [--image-size=<bytes>] [--erase-counter=<value>]
[--image-seq=<num>] [--ubi-ver=<num>] [--yes] [--quiet] [--verbose]
[--help] [--version]
Example 1: ubiformat /dev/mtd0 -y - format MTD device number 0 and do
not ask questions.
Example 2: ubiformat /dev/mtd0 -q -e 0 - format MTD device number 0,
be quiet and force erase counter value 0.
-s, --sub-page-size=<bytes> minimum input/output unit used for UBI
headers, e.g. sub-page size in case of NAND
flash (equivalent to the minimum input/output
unit size by default)
-O, --vid-hdr-offset=<offs> offset if the VID header from start of the
physical eraseblock (default is the next
minimum I/O unit or sub-page after the EC
header)
-f, --flash-image=<file> flash image file, or '-' for stdin
-S, --image-size=<bytes> bytes in input, if not reading from file
-e, --erase-counter=<value> use <value> as the erase counter value for all
eraseblocks
-x, --ubi-ver=<num> UBI version number to put to EC headers
(default is 1)
-Q, --image-seq=<num> 32-bit UBI image sequence number to use
(by default a random number is picked)
-y, --yes assume the answer is "yes" for all question
this program would otherwise ask
-q, --quiet suppress progress percentage information
-v, --verbose be verbose
-h, -?, --help print help message
-V, --version print program version
Yes, mtd6 is used for ubi. The rest is rather over my head, I’m afraid. I’m hesitant to keep asking you to hold my hand through this. In case you’ve got nothing better to do, I’ll show my ubinfo output
root@OpenWrt:~# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 10
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 769 (97644544 bytes, 93.1 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 3
Count of reserved physical eraseblocks: 17
Current maximum erase counter value: 400
Minimum input/output unit size: 2048 bytes
Character device major/minor: 246:0
Present volumes: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1 LEBs (126976 bytes, 124.0 KiB)
State: OK
Name: cert
Character device major/minor: 246:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 3 LEBs (380928 bytes, 372.0 KiB)
State: OK
Name: pot.bak
Character device major/minor: 246:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 14 LEBs (1777664 bytes, 1.6 MiB)
State: OK
Name: traffic_meter
Character device major/minor: 246:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 14 LEBs (1777664 bytes, 1.6 MiB)
State: OK
Name: traffic_meter.bak
Character device major/minor: 246:4
-----------------------------------
Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 14 LEBs (1777664 bytes, 1.6 MiB)
State: OK
Name: dongle
Character device major/minor: 246:5
-----------------------------------
Volume ID: 5 (on ubi0)
Type: dynamic
Alignment: 1
Size: 460 LEBs (58408960 bytes, 55.7 MiB)
State: OK
Name: overlay_volume
Character device major/minor: 246:6
-----------------------------------
Volume ID: 6 (on ubi0)
Type: dynamic
Alignment: 1
Size: 25 LEBs (3174400 bytes, 3.0 MiB)
State: OK
Name: vol_ntgrcryptD
Character device major/minor: 246:7
-----------------------------------
Volume ID: 7 (on ubi0)
Type: dynamic
Alignment: 1
Size: 3 LEBs (380928 bytes, 372.0 KiB)
State: OK
Name: vol_ntgrcryptK
Character device major/minor: 246:8
-----------------------------------
Volume ID: 8 (on ubi0)
Type: dynamic
Alignment: 1
Size: 35 LEBs (4444160 bytes, 4.2 MiB)
State: OK
Name: rootfs
Character device major/minor: 246:9
-----------------------------------
Volume ID: 9 (on ubi0)
Type: dynamic
Alignment: 1
Size: 179 LEBs (22728704 bytes, 21.6 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 246:10
root@OpenWrt:~#
Luckily you have the whole mtd6 area visible to ubi:
Total amount of logical eraseblocks: 769 (97644544 bytes, 93.1 MiB)
You have there the unnecessary Netgear volumes intact, as the whole ubi has not been formatted. Normally the factory image has replaced the whole ubi, and those have disappeared.
In OpenWrt only rootfs and rootfs_data are needed. others are not touched at all.
Easiest way could be to erase the large "overlay_volume", which takes 55 MB, and just leave other small Netgear stuff there.
ubirmvol /dev/ubi0 -N overlay_volume
That should leave you with 55 MB more space inside the ubi to be used for volumes.
Likely that would be taken into use in a new sysupgrade.
Info about the command:
root@router78:~# ubirmvol -h
ubirmvol version 2.2.1 - a tool to remove UBI volumes.
Usage: ubirmvol <UBI device node file name> [-n <volume id>] [--vol_id=<volume id>]
[-N <volume name>] [--name=<volume name>] [-h] [--help]
Example: ubirmvol /dev/ubi0 -n 1 - remove UBI volume 1 from UBI device corresponding
to /dev/ubi0
ubirmvol /dev/ubi0 -N my_vol - remove UBI named "my_vol" from UBI device
corresponding to /dev/ubi0
-n, --vol_id=<volume id> volume ID to remove
-N, --name=<volume name> volume name to remove
-h, -?, --help print help message
-V, --version print program version
Excellent, thank you! I was thinking that I’d need to delete the overlay_volume and expand the rootfs_data volume, but I guess I can let sysupgrade take a crack at it first. For that matter, what would have happened if, after I had booted initramfs, I had deleted all the volumes in the UBI partition before running sysupgrade? Would sysupgrade automatically and properly create what it needs? After I’ve gotten things cleaned up on my device I may try to update the R7800 wiki for the benefit of others who confront the bad block thing (probably not too many such people in 2025, but can’t hurt).
Yes, it should have done that. UBI outer container would have been there, and there would have been empty space for the rootfs volume from the image, and then the remaining space would have been allocated to rootfs_data (which would have been empty, or if you would have sysupgraded with "keep settings" then it would have contained the few copied settings files=.
