LEDE = a bit over the top with the minimal requirements?

Installing and Using OpenWrt
1

Hi all

longtime user of OpenWRT. All the way back to White Russian.
I have two dozen devices running, as I use them personally, but also to run WiFi over a large campground
This week, I tried LEDE, as it had become "stable", on a spare device

Well, I realize it is not polite to make my first post a negative one, but I may have to.
Basically, almost all package installs I did on an otherwise empty LEDE "jammed" during install. They stuck, usually on one of the required sub-packages, in such a way even a ctrl-c or sighangup did not work, had to sigkill the package. I suspect too little ram. They jammed with both Luci and PuTTY.

Reading up on the rtfm, I found this:
"Your router has at least 8 MBytes of Flash and 64 MBytes of RAM (Why is this important?)"
"If you wish to install LEDE on a device with less than 8/64 MBytes Flash/RAM, please ask for help on the Installing and Using LEDE category of the forum."

WOW !

Actually, in my case, the install went OK, it's the packages that keep jamming, but I suspect it's related. I somewhat understand we have to raise the limits at some point, and a fork is probably a logical point for this. But I am disappointed. Maybe a bit too soon to go all the way to 64M?

And more importantly: why even bother building all those thousands of device distro's inherited from OpenWRT that do not match the requirements. If LEDE is for the future, be honest about it and cull those hardware lists. Don't keep them to impress people.

Actually, I think it could/should all run nicely, after all the free space I have on LEDE in both df and free commands is about the same as on the latest OpenWRT, but I suspect it uses a different place and/or different method download and process the packages. Maybe simply use the older place or method for smaller devices?

Anyway, just some feedback for the team. Its a bit of a pity, because I guess OpenWRT development will now go even slower then before. But OK, such is life.

For reference:
TP-Link TL-WR941ND with 4M/32M

Packages I was trying:
QoS
SQM (without Luci, otherwise it will not fit even in OpenWRT, but it does at least install in OpenWRT)
TC
CoovaChilli

2

Your question is being discussed here already.

3

For reference: https://lede-project.org/meta/infobox/432_warning

4

Without starting to repeat the thread Borromini has already mentioned, it is a fact of life that most upstream software used on a router is not primarily developed for embedded devices (to most upstreams 'embedded' also means RPi3 or smartphone with quadcore, 2 GB RAM and multiple GB of main storage) and that it is slowly getting larger. Unless you want to hard-fork things like kernel, libc, sshd, pppd, ... to an old version, which means neither being able to support newer platforms and devices (which just got support in a recent kernel), nor being able to provide bug- and security fixes (it would be illusion that a very small team of volunteers could even think about keeping (e.g.) kernel 2.6.18 secure 'forever', even disregarding normal bugfixes and adaption for a changing network landscape (e.g. 2015 IPv6 was very rare for normal endusers, today with dualstack, dualstack-lite and cgNAT, having (only) a globally routable IPv6 prefix is common - or dynamic prefixes...).

Spelling out the minimum hardware requirements as 8 MB flash and 64 MB RAM is just being honest - and it's easier/ fairer to do it now, for the first release, than having to acknowledge this fact in the second or third release. Yes, right now, you can still get some decent use out of older devices with less than that, but it usually needs a pretty targetted device- and build config and you will hit the limits rather sooner than later (opkg and sysupgrade being the most affected parts). If you look at the size table for past OpenWrt and LEDE releases I've provided in the other thread, you will notice that LEDE hasn't really grown that much since Chaos Calmer/ 15.05.x, but only this tiny amount of growths (especially in comparison to the much larger size increases for prior releases) in addition to the larger repo size of available packages (it does make a difference for opkg's system requirements if the package indices are smaller (less packages available for installing in the past) or larger like now) means that the situation has gotten a bit too tight for many older devices. On average, bumping the kernel from v4.4.x (old LTS kernel) to v4.9.x (new/ current LTS kernel) means a roughly 10% increase in size for the kernel alone (that's around one year of upstream kernel development), but LTS kernels are only maintained for about 2 years (e.g. kernel v3.18.x has just been dropped), so updating the kernel is not only required to keep security support, but also to gain support for new/ upcoming routers (e.g. the IPQ40xx platform depends on kernel >=4.7).

So yes, as time goes by, newer (interesting) hardware appears with better hardware specifications (router's are just now starting to use SOC variations which were originally developed for smartphones, with an according bump in performance and RAM, rather than being stuck to abonded mips32 designs), changing requirements (the 'internet' is rather different than merely 3-4 years ago, with faster WAN connections, faster wlan standards, more emphasis on security and IPv6) and upstreams not being particularly aware of low-end devices and older gear will slowly fall of the cliff. With LEDE you can delay the inevitable for quite a bit of time, especially if you can build firmware variants configured exactly for your requirements - and long after the original vendor stopped maintaining their firmware (if they ever really did in the first place), but you can't change the inevitable either.

6 Likes
5

@slh Your explanations are perfect.
I added a link to your posting to the 432_warning page.

I like the "being honest". Maybe add a pinch of "being realistic".

1 Like
6

It's not just that existing software gets bigger, it's also that the
expectations of wht should be there by default keep increasing, so the number of
packages keeps climbing as well.

If you compile your own image (or use imagebuilder), you can leave out a lot of
packages for capabilities that didn't exist in White Russian and end up with an
image that will work far better on small devices.

But having multiple images by default for each router, with different subsets of
features, isn't a practical thing for the project to provide. So the project
accepts that the default image is going to require larger devices over time,
while still supporting people who want to use non-default images.

David Lang

7

[quote="cybermaus, post:1, topic:2009, full:true"]almost all package installs I did on an otherwise empty LEDE "jammed" during install. They stuck, usually on one of the required sub-packages, in such a way even a ctrl-c or sighangup did not work, had to sigkill the package. I suspect too little ram. They jammed with both Luci and PuTTY.[/quote]This issue was fixed too late for inclusion in LEDE release, it will get in march's refresh (and is of course in LEDE snapshot/trunk)
See here for the bug and some workarounds and that statement about march. https://bugs.lede-project.org/index.php?do=details&task_id=120

This opkg issue happened because they had to raise the RAM usage for kernel or something like that as it's needed, so opkg had less RAM than before to work with.

The hardware recommendations are there because people came in forums complaining that they had just bought a device with low flash thinking they would be able to fit all they wanted to in it, then we added RAM to that because of this Opkg issue.

1 Like
8

@bobafetthotmail: Thanks, that was the reply I was hoping for.
I already felt it was too silly that even small packages failed.

Mind you, in my case, the opkg just "hangs". Not even a nice memory message like in that thread.

@everyone: As originally stated, I reluctantly understand a new bottom for a new fork in a new decennium. Just wanted/needed to express disappointment. And I guess it is all already being discussed in this thread, as @Borromini replied.