Upgrading Firmware Too Big and 18.06 using 4/32 Devices

[lleachii]

I've noticed in the last few days, that as 18.06-SNAPSHOT was released, that users have started experiencing issues with 4/32 devices and images. I'm starting a list of 4 MB Flash devices that have failed to upgrade or be stable with a flash of a newer firmware:

Model	Description of issues	Other Notes
Cisco Linksys Valet M10/ WRT160Nv3/E1000v1	firmware too big	@lleachii could not upgrade from 17.01.4 to 18.06-SNAPSHOT (reported in thread for WRT54GL)
Linksys WNR2000v3	firmware too big	noted here: Can't install package luci-base on WNR2000V3 (a.k.a N150R)
Linksys WRT54GL	v18 firmware too big	per file size on release site
Linksys WRTSL54G (8 MB flash)	other	@lleachii flashed e0363a7, rebooted to previous version without errors on SSH screen
TP-Link TL-WA855RE	other	noted here: Netgear WNR2000v3 not saving settings after reboot with RC2
TP-Link TL-WR743ND-v2	other	noted here: Is it possible temp. increase free space?

Reference:

Should LEDE support devices with only 4MB Flash?

@dgilmour77 wrote the following after discovering that he could not install LuCI on his older router. I don’t know the answer to this, but have some questions: How old is a router that only has 4 MBytes flash? Can anyone say how prevalent are they? How much work is it from a development standpoint to keep developing for these devices? How much work is it to support people who have these old routers? What happens to people who flash LEDE, then try to install LuCI (or other packages) that won’…

[mhoxjwwi]

Where are 18.06-Snapshots beeing released?
I cant either see in the "[SOLVED] Incorrect image file error installing to WRT54GL" thread nor in the "Can't install package luci-base on WNR2000V3 (a.k.a N150R)" thread any reports of not beeing able to install your written "18.06-SNAPSHOT" version.

[lleachii]

Where are 18.06-Snapshots beeing released?

http://downloads.openwrt.org/releases/18.06-SNAPSHOT/

Please be advised, this should be considered Beta software:

Timeline for an 18.x release?

It should be mentioned that there’s a reason that directory is not public: At of now, these are test builds . The devs are still tweaking and modifying these builds pretty hard, it’s really not advisable to grab these builds just yet.

any reports of not beeing able to install your written “18.06-SNAPSHOT” version.

The issue is with 4/32 devices, NOT specifically 18.06. The problem is, the standard packages included in [OpenWRT] 18.06 now make the firmware larger than 4 MB on most devices. This eventual problem is alluded to on the 4_32 warning page. It began for some devices with version 17.01.

[hnyman]

There were already similar problems with 17.01, so there is nothing new (expect it concern now a new router class). Both the firmware size and RAM memory consumption are growing steadily.

To be honest, I don't see much point in such a router list, as the challenge/unsuitability concerns practically all devices with either 32 MB RAM (the more difficult limit) or 4 MB flash.

Just a historical note, once upon the time Openwrt grew too big to run smoothly on devices with 16 MB RAM and outgrew 2 MB flash devices. If I remember right, Backfire 10.03 still worked well with 16 MB RAM, but Attitude Adjustment 12.09 started to choke with that.

[tmomas]

I’m starting a list

Information about support status is generally better placed into the ToH.
That's what it is there for. No need to generate a new manual list.

[macromorgan]

The A5v11 works, but when you try to add Luci it chokes (not enough flash).

Compiled myself I can remove some things and get Luci in there though.

[drbrains]

Most (all) 4/32 devices should be able to still run the 4.4 LTS kernel. I realize it’s at their limit (RAM being the most limiting factor). Since this version had extended 6 years LTS that should keep them running until the hardware itself is “end of life”.

I noticed the “tiny” flag, but does that automatically keep them on an “older” kernel?? I have a few 4/32 devices myself and with the updated security patched like the “Krack” patch, they still run fine as simple AP and/or Range extender.

The alternative would be to drop support, or at least no to have the “buildbot” make automatic snapshots. Users can compile themselves from source or use “community builds”.

What’s the (semi) Long Term Plan from Lede/OpenWRT point of view? Maybe this could be added to the “warning” ?

[slh]

-tiny only affects the image- and kernel configuration, not its version, that is at 4.9 for ar71xx and 4.14 for ath79. Sticking to older kernels past their expiration date is not an option.

[drbrains]

Not sure why that would not be an option. Their expiration date should be based on the LTS dates I think.

So maybe we could combine “tiny” with the older, but still LTS kernel. Sort of make the group of 4/32 routers. Not sure if that’s “do-able” in terms of keeping all the latest patches for 3 versions (at the moment: 4.4 4.9 and 4.14). We might consider doing this since all are LTS versions.

If “Tiny” is not the proper flag, then maybe we need an additional “432” flag. Or like I said: we should decide not to continue support for those devices.

[Borromini]

-tiny only affects the image- and kernel configuration, not its version, that is at 4.9 for ar71xx and 4.14 for ath79. Sticking to older kernels past their expiration date is not an option.

As long as 4.4 is maintained - and it still is, upstream - one could still stick with 17.01.x, as long as that keeps security updates. .5 should be around the corner as well.

[slh]

one could still stick with 17.01.x, as long as that keeps security updates

I was referring to the suggestion to keep older kernels in master or the 18.06 branch, just because it's faster on lowspec devices, creating a maintenance (and security) nightmare for the development.

[mhoxjwwi]

Would be great to see all the ar71xx devices ported to ath79. That would speed up many of the devices and provide modern, secure kernels.
Some of the devices are already beeing ported: Is anybody working on linux 4.14 for ar71xx platform? Porting guide to ath79?

[juppin]

But this would not solve your memory and storage constraint... this would it make much more bad...

[mhoxjwwi]

What is the size difference of the binary after porting it to ath79?
I can recommend to every user to change the Squashfs block size from 256 to 1024. I cant see any real-world issues, just benefits.

[juppin]

Nobody can tell you a exact number for difference in binary size...

You could also remove some debug info...

# CONFIG_KERNEL_CRASHLOG is not set
# CONFIG_KERNEL_DEBUG_FS is not set
# CONFIG_KERNEL_DEBUG_INFO is not set
# CONFIG_KERNEL_DEBUG_KERNEL is not set
# CONFIG_PACKAGE_MAC80211_DEBUGFS is not set

and probably...
CONFIG_STRIP_KERNEL_EXPORTS=y
And probalby pppoe if you dont need it...

# CONFIG_PACKAGE_kmod-ppp is not set
# CONFIG_PACKAGE_ppp is not set

Or you solder a bigger spi flash and ram...
Did this on some of my constrained tplink wr841 devices...
I had payed for 5 x 16MB SPI flash chips only 9 € and for 5 X 64 mb ram chips 11 € from china...

[lucize]

from what I've read, it will use more memory so on long uptime you will see if you encounter oom, if not you're in luck