I know, best practice is to not use LEDE on 32 MB RAM. So I guess I really mean to ask about second best practices for those stubborn ones that want to run LEDE regardless.
It makes sense to schedule a reboot every night, to prevent memory leaks and such from piling up, right?
Does it make sense to configure swap on USB, even though that requires additional packages? Or zram?
Is it possible for non-guru users to identify packages that can be removed or modules that can be unloaded?
See https://lede-project.org/faq/before_installation#which_packages_can_i_safely_remove_to_save_space
Ah, thanks tmomas, hadn't found that previously.
If the device has 32MB of RAM you just need to:
- disable IPv6
+ add LUCI
+ add zram
- remove opkg - not needed after making these adjustments
Haven't found any real instructions for adding zram ... which package; any configuration needed?
Not finding a simple guide to disabling IPv6 either ... found the following; is this appropriate ... or rather to unload ipv6 module(s)?
uci del network.lan.ip6assign
uci set network.lan.delegate='0'
uci del dhcp.lan.dhcpv6
uci del dhcp.lan.ra
uci del dhcp.odhcpd
/etc/init.d/odhcpd disable
/etc/init.d/odhcpd stop
Okay, zram-swap seems to be the package, and since it describes itself as a script to configure zram, I'm guessing that no further configuration is needed. Though it doesn't appear to actually mount the new zram0 swap, so I did that via Mount Points in Luci.
Zram-swap doesn't seem to be worth the trouble if you read on the link from this post:
Thanks DjiPi, took a look at that ... all I take from it is that zram-swap may not be sufficient if you want to run Tor on a low-RAM LEDE router, and zram-swap can't fix a 16 MB RAM router. I'm not trying to run Tor or anything other than a basic router, and I've got 32 MB RAM, however, so I'm not sure how much I can learn from it. FWIW, with zram-swap enabled, I can now run okpg update, which previously failed due to insufficient memory. That's actually not something that I really need to do, but I take it as an indication that zram-swap is doing something of value. Other than that, I don't know how to determine if it's helpful. I've got a cron job rebooting every night, and things seem to be running stable. I have not yet figured out how to disable IPv6 as previously suggested.
You have not actually stated what device you are running or if you built your own. Flash size is more of an issue, but the standard images will fit on 8mb. I would not buy this or a similar sized unit again,
I have a HooToo TM02 which is 16\32 and run a Release 17.0.1 version image with additional USB packages, no issues that I see.
Also know that you can not actually delete packages from the flashed image to free space.
I think it would be a better idea to get a second hand pi and to use it for tor or any other small piece of software not needing an entire rig. A pi cost something like 10€ in electricity per year. Thats how im doing it since 2 years because im not willing to pay expensiv bills for electricity here in germany. Same way, less trouble. Tipp: Use a minimal Debian Stretch with f2fs.
About 32mb devices: Depending where you are from, you can still use them for projects like Freifunk.
The post I linked indeed talks about Tor, but the link inside that post doesn't even refers to it, it's just plain simple test on zram-swap (I've linked the post to give credits to the OP). It is however effectively a test with a 16MB ram device, but not Tor related AFAIK.
The fact that it does something of value for your 32MB device is quite interesting by the way. Thanks for sharing your experience!
fyi, I'm running openvpn client on TP 703n (4M/32M) device. I have to use the imagebuilder to remove luci/pppoe packages. The openvpn/ssl packages would not fit into the 4M of flash, so on startup it sideload the packages from the repo into /tmp. As the device only have one ethernet, I created vlan (eth1, dhcp client/ eth2 dhcp server). During the first 15 secs of bootup if eth1 receives and ip address, wifi become AP. If after 15 secs, eth1 does not receive an ip address. It is shutdown and eth2 (dhcp server) starts. At this stage wifi is scanning against saved profiles and if it cannot connect, it becomes an AP, hence I never be locked out of the wifi.
It's a TPLink WR842ND v2 with 8 MB flash and 32 MB RAM. The flash hasn't been a problem, the stock images install fine and I don't want or need to install any additional packages (other than zram-swap). It's just the 32 MB RAM that seems like a limitation.
I'm a little bit confused here: do you have multiple devices or just tough it was 32?
@mc510
It is a bit of a misconception that "best practice" is to keep clear of 32MB ram devices. This came about originally as a result of OPKG having a bug that meant it used large amounts of ram and would therefore not work on a 32MB device. This has been fixed.
I run LEDE 17.01.2 on Ubiquiti airGateway hardware (32MB device) along with Lighttpd, PHP7 and sftp server (amongst numerous other things) with no problem whatsoever.
Where problems arise is where people become confused between RAM and FLASH.
I use ImageBuilder to leave out unnecessary code on FLASH as deleting it from SQUASHFS does not save any space.
On the other hand, installing on /tmp WILL use RAM, as /tmp is a "ramdisk".
You can typically leave out the following in your build:
-ip6tables
-kmod-ip6tables
-kmod-nf-conntrack6
-kmod-ppp
-kmod-pppoe
-kmod-pppox
-kmod-usb-core
-kmod-usb-ohci
-kmod-usb2
-libip6tc
-libmbedtls
-odhcp6c
-odhcpd
-ppp
-ppp-mod-pppoe
plus more, all depending on what you want or don't need. It just takes minutes to build your image so trial and error is good as long as you have tftp reflash enabled on your device so you can in the worst case de-brick it.
opkg's memory was (still is) one of the reasons for this strong recommendation, but by far not the only one. Even if you don't use opkg at all (up to the point of not having it installed in the first place/ custom build), 32 MB RAM is somewhere between marginal and beyond the edge. Sure, you can find use cases where this might not be an issue yet, but most users will feel memory pressure and "unexplainable" crashes sooner than later. Keep in mind that especially sysupgrade also needs quite a bit of free RAM (flash size plus some safety margin, with devices sporting more than 4 MB flash this is already a serious problem) to operate, with quite fatal consequences if RAM runs out while flashing. PPP, dnsmasq, wlan drivers (hostapd/ wpad) and the webinterface (uhttpd/ lua/ luci) plus eventual tls providers (mbedtls, cyassl, openssl) also need their share of free memory, combined this is hard at (or slightly beyond) the limits 32 MB RAM impose in many of the most common use cases.
Contrary to your very hand waving suggestion, PPPoE is a hard requirement for pretty much all ADSL or VDSL users, many fibre setups also depend on it (the same for all kinds of mobile-/ cell data in the form of pure ppp) - the only users which basically don't require any kind of ppp are cable based or use the LEDE device behind another (ISP-) router. The situation is pretty similar for IPv6 support, with many ISPs switching to dual-stack and particularly various DS-lite variants,because they've run out of IPv4 addresses (this is common for many cable and fibre users in europe already).
Btw. problems (OOM) and crashes caused by low RAM on 32 MB RAM devices are reported quite often in LEDE's support channels, in the real world on actual enduser systems, even without any fancy packages installed. It really is an actual problem now, not for every setup or every user, but common enough to be noticable.
While there is quite some effort spent on taming the bloat (taking one random example, by making dhcp-script hooks conditional - which shouldn't have had an effect on actual RAM usage, but still pushed several 32 MB devices over the cliff), it does reaffirm that the life cycle of these affected devices is approaching the end of their usable lifespan.
build your image to jffs2 filesystem instead of squashfs
Wow! Water under the bridge..... even 64MB is very close to the edge these days! How things change 
True. 64MB of RAM is already way too short if you have ath10k for example.