The LEDE Community is proud to announce the second release candidate of
the upcoming LEDE 17.01 stable version series.
Main scope of this RC version is backporting important fixes and
addressing critical bugs to further refine the code base for the final
v17.01.0 version.
Some selected highlights since the 17.01.0-rc1 release candidate are:
Properly handle Curl download errors during compilation
Update to musl libc version 1.1.16
Update kernel to version 4.4.47
Improve Mikrotik device support on ar71xx
Support configuring static route protocols
Prevent swconfig related kernel panics on ar83x7 switches
Update tcpdump to address several security vulnerabilities
There is an incompatible libubus ABI change between rc1 and rc2
so do not upgrade packages with opkg on rc1 but sysupgrade to rc2
instead
Available space on devices with only 4MB flash is very low,
users requiring extra packages might want to consider using the
image builder to repack custom images
The available memory on devices with 16MB RAM might be too low to
reliably run opkg or sysupgrade operations, especially in
conjunction with LuCI
WARNING: Image file /build/lede-17.01/slaves/phase1/ramips_rt288x/build/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_rt288x/tmp/lede-17.01.0-rc2-r3131-42f3c1f-ramips-rt288x-ar725w-squashfs-factory.bin is too big
Sounds strange, as there has been no change to the login related stuff.
The only thing that comes into mind is that if you use luci-ssl-openssl, now it uses openssl to generate the SSL keys for uhttpd at the first boot (instead of using px5g). That is a change between rc1 and rc2. (but if you use luci-ssl or plain luci, there is no change.)
What router? Can you reproduce the spike at each login?
I also have problems with a couple of TL-WR1043NDv1 routers (hw rev 1.8):
The ImageBuilder of rc2 produces apparently valid images, but flashing from these builds from within lede often fails. I had much the same problem with OpenWRT 15.05.1, too.
Serial console shows that it ended up in an unaccessible jffs2-fs. It makes no difference whether I use factory or sysupgrade. I suspect, that the flash process somehow gets interrupted (tried with kmod-zram and zram-swap, too). Flashing the same .bin or minimally altered .bin files (with differences in INCLUDE_FILES) sometimes work. That problem is driving my nuts.
BTW: without zram even the ram for opkg is not suffiencient.
uhttpd and luci are quite CPU/ RAM intensive, at least when you actually use it (log in, changing pages, applying changes), it's normal that you'll see a significant CPU usage spike (on pretty much fully loaded firmware (VPN et al) running luci on a tl-wr1043ndv1 can be pretty difficult, there is no such problem if you keep your firmware smaller, comparable to the vendor's feature set).
I would agree if it where normal circumstances: I stopped and disabled all these extra services in my builds (a firstrun script, triggered, if a certain file is present). So all that's left is dropbear, uhttp and the usual system services. Even killed dnsmasq and stopped ntpd before. BTW: v1 has 32MB of RAM.
What I don't get is, that a flashing procedure gets interrupted w/o a warning, which is more or less reproducible.
Furthermore lede's factory .bin cannot be flashed directly from the original firmware - "not a valid firmware file"). I always have to flash to OpenWRT AA first, before upgrading to lede.
And than the bricking happens, when I update a minor change through sysupgrade.
That's unusable. I can send you the manifest-file, if you wish to debug this.
Don't forget to remove (/etc/modules.d/) 'unnecessary' kernel modules, which easily take up quite some RAM. And yes, I do know the problem - 32 MB RAM is tight, if your firmware is large(r than ~4-5 MB) and you have services installed requiring additional kernel modules (e.g. strongswan/ IPsec), then you easily run into problems with sysupgrade (oom --> killed by watchdog).
While sysupgrade does already kill all non-essential dæmons, it can't unload kernel modules (wireless, ipsec, netfilter, etc.) - and those do need RAM as well. RAM that is also required to hold the firmware image (on tmpfs, which is non-evictable under memory pressue), so the larger your firmware image gets, the more likely you are to run out of RAM. I do own a tl-wr1043nd v1 myself and with a rather full featured firmware (strongswan-full), I regularly run into those problems (sysupgrade being killed, uhttpd/ luci spiking CPU/ RAM and thereby becoming unusable) - while I have no such problems on a tl-wr941nd v2.4 (only 4 MB flash, so the firmware is really stripped down to the minimum), with luci and sysupgrade working just fine (otherwise almost identical hardware). In these cases it really helps to remove anything non-essential from /etc/modules.d/ (followed by a reboot), to free up some more RAM (then sysupgrade completes just fine and luci also works nicely).
Devices with just 32 MB RAM are having quite some problems to keep up with modern software (not just LEDE, but anything using current kernels and upstream software), you can still use them, but you do have to sacrifice some features (even if there'd be some space left on the flash) which go beyond a "normal" (vendor-like) feature set.
Are you sure, it's a memory problem? The serial terminal (I just flashed a factory.bin created with imagebuilder (it´s size is obviously 7,8 MB [7,75] and the sysupgrade.bin is around 5,2MB, root-squashfs 4,2MB) said:
[ 9.180833] jffs2: Old JFFS2 bitmask found at 0x0038ed1c
[ 9.186170] jffs2: You cannot use older JFFS2 filesystems with newer kernels
[ 9.195505] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00390000: 0x177b instead
The difference between this build and the previous one was a config.system entry added by an individual init script (uci set system.system[0].zram_size_mb=24) in includes files...
Before that I flashed five firmwares of this kind - w/o problem.
And now I flashed the very same factory.bin through ethernet-tftp (via serial command line) ... and it boots well. md5sum were the same.
I am not going to join the "too small, too slow" discussion again - just a proposal:
Can we make sure, that LuCI based flash procedures have optimum /memory?) conditions, so they won't fail that often? I didn't try sysupgrade from the command line this time, but I had a very similar issue with an O/CC 15.05.1-rc on a couple of wr1043nds... I didn't yet see that on the v2, but that's not a negative conclusion leading to a low memory problem... what's that "old jffs2 bitmask" message about?