4/32警告

对于任何一个操作系统，都需要：

1. 足够的闪存以存放固件镜像
2. 足够的内存以保证系统的稳定运行

内存不足影响运行稳定

• 32MB 内存可以用于基本的路由或AP功能，但可能会经常性的崩溃，取决于您的硬件以及具体用途。
• 64MB 内存可能仍然存在稳定性问题，取决于您的硬件以及具体用途。
• 如果要运行软件来获得基本的路由或AP之外的功能，推荐使用128MB或更大的内存。

需要有足够的闪存来存储OpenWrt固件镜像

• 您至少需要4MB(无法安装luci)，推荐8MB(可以装下luci以及一些其他的应用程序)
• 4MB已经可以工作了，但工作的不算太好。 大于4MB的闪存会让您在使用时感到更为舒畅。
• 4MB的设备几乎无法安装任何重要的软件，除非您使用 Image Builder (Image Generator) (需要使用Linux系统，并且您要有一点使用的经验) 或者使用 Extroot. 对于高级用户来说，他们可以创建自定义固件以节省固件空间, 但部分软件无论用什么方法都无法放入其中。
• 如果您还想要安装一些自定义的软件，那么8MB及以上闪存和64MB及以上内存是必须的。

在多数情况下，如果您只有4MB的闪存，您将无法安装这些(或其他)热门的软件包:

• VPNs 以及其他需要加密的软件
• Samba 文件夹共享
• 3G/4G 上网卡的支持
• 用于Extroot的文件系统的驱动以及格式化和磁盘检查工具

随着时间的发展，小内存和闪存设备将会越来越难得到支持。OpenWrt在不久的将来可能会在无照会的情况下结束对这些设备的支持。

对于非OpenWrt专家用户（即无法自行构造固件的用户），应当考虑： 16M闪存/64M内存是任何设备的配置底线，有可能的话尽量选择128M内存的设备。

用户应当知道这些小于16M储存、64M内存的设备在当前版本(17.x, 18.x)的OpenWrt下已经是不稳定的了，他们应当预料到这些设备在任何时候都可能失去支持，届时包括内核安全更新或补丁、驱动和应用软件更新将不可用。OpenWrt团队并没有对任何设备做出过继续支持的保证，用户应当考虑到设备在停止支持后的安全问题。

之前版本的OpenWrt包含着一些已知的内核、无线驱动和应用软件安全问题。OpenWrt团队不支持在任何条件下继续使用这些包含已知安全问题的软件，“这是我的路由”并不能成为这台路由器变为跳板和攻击设备而影响他人的理由。在多数情况下，这些已知的安全问题将可能会被潜在的黑客甚至是政府机构利用。

以下内容来自论坛用户 slh 的 这个主题帖。

首先，我并不是假装为LEDE团队发言，但是数字却可以让问题显而易见。

以论坛中 “ Why no images generated for default D-Link DIR-600A1?“这个帖为例，显然其他一些4MB闪存设备比这个特定的样品稍好一点，但趋势仍然是一致的。

D-Link DIR-600A1:
Backfire 10.03..............: 2293764 bytes
Backfire 10.03.1............: 2949124 bytes
Attitude Adjustment 12.09...: 2883588 bytes
Barrier Breaker 14.07.......: 3276804 bytes
Chaos Calmer 15.05..........: 3342340 bytes
Chaos Calmer 15.05.1........: 3407876 bytes
LEDE 17.01 release branch...: 3473412 bytes
absolute firmware size......: 3735576 bytes
maximum usable firmware size: 3538944 bytes

（以上数字是包括luci和大致相同的功能集的各发行版本镜像大小）

The erase block size for this (and most other) devices is 64 KB, so you now end up with 256 KB (== 4 erase blocks) free space, compared to 320 KB (== 5 erase blocks before). While this may look comfortable at a first glance, you have to consider that free space can only be assigned in (full) block size chunks, so once you touch the overlay partition at all, you already have one erase block in use (64 KB). Therefore the firmware creation tools used by LEDE enforce at least 3 erase blocks reserve for the overlay filesystem (that's where the maximum usable firmware size comes from, compared to the total size of the firmware partition). In other words, with 17.01 you'll only have 1 erase block (64 KB) before the hard limit, while 15.05.1 still gave you 2 spare erase blocks (128 KB) for your own use. On top of this there is the file system overhead needed for formatting to jffs2 as well (jffs2 does some light compression, but its fs header and log (more or less directory entries) need some space, then there is the hard requirement to keep some free space (in erase block == 64 KB chunks) for the garbage collection to work) at all times, reducing the usable free space even further. Around 25 KB are used by the configuration overlay immediately after firstboot, before you actually get a chance to configure anything.

Assuming pure statistics, what will the situation be in 12 or 24 months[1]?

No one has yet raised the suggestion to actually remove the hardware support for affected devices from LEDE's source repository. If you look deeper, you can still find full support for the Linksys WRT-54GL (4 MB flash, 16 MB RAM) in the repo, although support for devices with just 16 MB RAM had already been discontinued with Attitude Adjustment 12.09 and despite the fact that actually building a working up-to-date firmware for this device today is quite challenging[2].

This thread merely serves as a reminder for 'normal users', who expect to download and flash LEDE under the expectation to use it as a full featured replacement for the vendor firmware (including a webinterface, luci). Also keep in mind that luci is enabled for release builds, which means that it either fits into the firmware image (with the mandatory safety margin of at least 3 erase blocks) or no release images can be created for the affected devices[3], [4]. In my very personal opinion, this needs to be documented quite obviously, avoiding to raise false hope and expectations for (especially new) users.
Advanced users will obviously be able to delay the inevitable by quite some margin - depending on their use-cases and abilities to reduce LEDE's footprint below normal system requirements.

Despite the title, the RAM size is actually a much harder limit, affecting much more than just 4 MB flash devices. If you look through the commit log, you will notice quite some efforts to get opkg to use less RAM, but it's still a problem with just 32 MB RAM (even for normal operations, before touching opkg). Likewise you already are in trouble with sysupgrade and trying to flash a (larger) 6-8 MB firmware on a device with just 32 MB RAM, unless you really clean up services and loaded kernel modules manually beforehand, there is a high risk that you'll oom during the sysupgrade and brick your device for good (requiring bootloader/ tftp assistance to recover in the best case).

[1] switching from mach files to device tree (post 17.01) offers a potential to free up a little space in the kernel, but this isn't a whole lot and will probably be eaten more or less completely by upgrading to kernel 4.9+ (also keep in mind that the FDT file needs to be appended to the kernel image, which might or might not compress as well as the mach files before), so don't expect a significant positive effect from this switch.

[2] no webinterface, better no pppd, quite some custom configurations to get the kernel's runtime memory requirements as small as possible, disabling whatever is humanly possible (definately no IPv6, better no wireless either).

[3] with LEDE's pretty new feature of device specific rootfs images, it would technically be possible to decide between installing luci or omitting it on a per device basis, e.g. based on flash sizes, but support for something like this hasn't been implemented yet and would require quite some attention (both as in source patches and tagging of device classes) from interested parties. As implemented right now, the decision is binary - either the default (release) config (including luci) fits XOR building a firmware image for the affected device fails and no firmware will be available.

[4] I would expect that there already are a couple of 4 MB flash devices in the target list for which no release firmware can be built for 17.01, because of less ideal flash partitioning schemes chosen by the vendor (dropping free space below 3 erase blocks). Those are probably a minority, but given the close numbers, I'd be very suprised if there wouldn't be any affected.

More explanations on this subject by forum user slh.

As originally written in this forum post by jow.

Just providing my rather pragmatic opinion on the topic here:
I do not believe in arbitrarily dropping device support
We usually support devices as long as it is feasible
A device should be considered supported as long as

• it is possible to build bootable images
• small enough images can be produced to still allow configuration persistence
• no patches or other modifications to the source and buildroot are required

Eventually we might need to think about support tiers like:

• Full ⇒ allows for running gui, has working opkg and plenty of space to allow packages
• Medium ⇒ allows for running gui, has working opkg and at least enough space for setting up extroot
• Small ⇒ bootable images can be built when either sacrificing gui or opkg while still having configuration persistence
• Micro ⇒ only choice are heavily tailored custom images that require special measures like pre-shipped configuration, NFS mounts, preconfigured extroot etc.