1lann/storage.md

## storage.md

      
    Raw
  

              storage.md
            
          
    2024 UPDATE

This is not necessary anymore on newer versions of OpenWrt. When you flash a sysupgrade firmware on newer versions of OpenWrt via the web interface it will provide you full access to the flash.
Getting more space on UniFi AC Lite/LRs on OpenWrt

If you've used OpenWrt on UniFi AC Lite/LRs, you may know that the overlayfs only provides 3.6 MB of space.
If you think about it, that's kinda weird, because all the hardware docs say that the access point has 16 MB of flash, so where
did all the other 12.4 MBs go? Surely they're not all being taken up by the OS.
Well, have you ever wondered why you needed to flash the firmware twice when you first install OpenWrt on a UniFi Lite/LR? Once to kernel0 and
another to kernel1? That's because we (OpenWrt community/developers) do not know how Ubiquiti's UniFi U-Boot decides which partition to boot
from, as it can boot from either kernel0 or kernel1. Hence we flash to both partitions.
And that's where all that missing space goes, about 7.6 MB goes to kernel0 and 7.6 MB goes to kernel1, the rest goes to the
bootloader and other small housekeeping things.
So about 4 MB is allocated to the read-only firmware (squashfs), and hence you have about 3.6 MB of overlayfs.
What if we could not duplicate the partitions? Then we could get an extra 7.6 MB of storage! And that is what this guide will
tell you how to do.
Wait a second, I thought you needed the image on both partitions? How is this possible

idk lol. Here's a complete guess that you should take with a grain of salt as to why I think this is happening:
I'm guessing that u-boot uses kernel1 as a fallback image, and kernel0 is its primary image. I think it does some
firmware checking to verify the integrity of an image, and if it's bad, it uses the other one. But at the same time, I think
the kernel is always loaded from kernel0, only the rootfs and overlayfs can be loaded from kernel1.
Which is why you need it to write it to both partitions to install OpenWrt.
However after installing OpenWrt, you could corrupt kernel1, and it will not attempt to fallback to kernel1 as it's
"more"(?) corrupt than kernel0, so it will use kernel0 for rootfs and overlayfs. Therefore you could wipe kernel1 and use
it as an extra partition for storing data for free extra space after installing OpenWrt!!!
Obligatory disclaimer

This shit is risky, use at your own discretion!! I'm not responsible if you end up with a round, white $80 brick.
If you do brick your AP, hopefully it would only be a soft-brick and you can re-flash using TFTP:
https://help.ubnt.com/hc/en-us/articles/204910124-UniFi-TFTP-Recovery-for-Bricked-Access-Points
OK cool, spill the beans, how do you do this?!


SSH into your AP.
Install kmod-mtd-rw with opkg install kmod-mtd-rw, you may need to run opkg update first. This kernel mod will allow you to make mtd partitions which are normally read-only, writable.
Run insmod mtd-rw.ko i_want_a_brick=1. You'll need to run this command every time you want make your newly formatted partition writable, before you mount it. You can verify if mtd-rw successfully ran by running dmesg | grep mtd-rw, you should see some messages like [52997.660000] mtd-rw: mtd6: setting writeable flag.
Run cat /proc/mtd, and find the line that has "ubnt-airos" on the right, and note down the mtdX number on the left. The line should look something like: mtd6: 00790000 00010000 "ubnt-airos", where in my case the mtdX number is mtd6. This is the kernel1 partition, the partition we will convert into usable storage.
IF YOU DO NOT USE THE CORRECT mtdX NUMBER IT COULD BRICK YOUR AP. Your mtdX number should never be less than 4, if it is then do not continue and try step 4 again and read more carefully. Run mtd erase /dev/mtdX, replacing mtdX with the mtd number you noted down before (i.e. mtd6 in my case).
(Optional?) Now is a good time to reboot your AP, to see if wiping kernel1 still allows OpenWrt to boot. Remember to do step 3 again.
IF YOU DO NOT USE THE CORRECT mtdX NUMBER IT COULD BRICK YOUR AP. Almost there, all you need to do is mount it now! First make a mountpoint like mkdir /mnt/storage and mount it with mount -t jffs2 /dev/mtdblockX /mnt/storage, replacing mtdblockX with your mtd number like before with mtdX. Mounting it for the first time may take a minute or so, so be patient! You'll need to re-run the mount command every time if you want to mount it, and I don't think you can auto-mount it in fstab because you also need to run the insmod command from step 3, however you can probably throw the two into your /etc/rc.local. You probably need a short sleep after the insmod though.
If step 7 fails, try mtd erase /dev/mtdX and mount -t jffs2 /dev/mtdblockX /mnt/storage again. I'm not exactly sure what fixes it.
You're done! You can now use an extra 7.6 MB or so of space in /mnt/storage, although some of it is occupied by filesystem stuff, you can't get rid of that. So more like 7.2 MB of space, but hey that's still pretty good.

Can I mount this as the overlayfs or combine it with my current overlayfs partition?

I don't know and I don't plan to find out. I didn't need to do this for my use case, so I didn't bother figuring out how to do it, so you're own your own for this one.