Thanks a lot to all involved developers and maintainers!
I really appreciate the effort towards a stable and supported release branch that users can rely on. If this effort can be kept up, I think this is a strong advantage over OpenWrt from a user perspective.
Hi, ran into some bumps doing a sysupgrade using keep-config but then I lost internet access twice over to all devices which remained lost even after downgrading to previous version and restoring backup of conf. Now that I have an understanding of what happened, here is how to fix it or avoid it.
Ensure you have a SSH client installed on your computer so you can connect to the router through the terminal and that it works before you proceed because you will need it! This will let you edit conf files and also check from the router if you're able to ping the internet.
In /etc/dnsmasq.conf I had dnsmasq listening on 2 interfaces with bind-interfaces on due to an openvpn setup but this isn't going to work at first for whatever reason which might be related to the openvpn package not being currently present even though the interface is still defined? Sysupgrades do not keep packages, you have to reinstall them. I had to use SSH and then the vi editor (can't just install nano, because lede's software suite depends on resolving a domain name not an IP address) and comment out those lines, at which time DNS services started working again and I was able to properly access the internet. This brings us to item 3 below.
Because there was no functioning DNS being served by the router as a result of my dnsmasq settings in item 2 until they were commented out, the computer in turn could not connect to the router because it was not receiving a DHCP 192.168.1.x IP address. I had to set the computer to a static IP address so it could connect to the router, do the cleanup in item 2, at which time changing the computer back to dynamic DHCP worked fine and internet access was present.
If I had not selected 'keep settings' I'm fairly certain everything would have been just fine, but I wanted to keep them so I wouldn't have to reconfigure everything at this time of night. So a lesson learned is that if you have been installing packages and editing conf files, best to do this upgrade on the weekend not a weeknight!
The problem is that it would tend to dominate a log with its repetition, obscuring more important things.
I saw a comment a few months ago saying that it was fixed in 17.01.1 though (the commenter was talking about the prerelease of that at the time), but I can't find any mention of it in the release notes.
Nothing to do with LEDE 17.01.1, uhttpd, LuCI or even Openwrt itself...
That is a generic error that is typically coming from a package's init script or hotplug script, where an uninitialised (or empty) variable is used. Typically e.g. a config option has no default value and if the option is missing from the config file, the variable remains empty. When that shell variable is then used in a comparison like "is it greater than", the shell complains about empty value, and uhttpd passes the error.
Such errors have been seen in the last few years e.g. in ddns-scripts, mwan3 etc. packages. If the package has a status component on the LuCI overview page and that is refreshed every 5 seconds, the log spam gets visible.
Nothing to do with LEDE 17.01.1, uhttpd, LuCI or even Openwrt itself...
Ah, OK, thanks for the explanation and context. I recall now that it was triggered by errant scripts, but I was hoping/assuming that it could be compensated for by putting in some kind of rate-limiting or maybe some other functionality that drops duplicates.
Great work to all the contributors! I really like these frequent updates to the stable branch. It keeps my router up to date and secure. Huge props to everybody making this happen
In the "LEDE v17.01.1 Changelog", there is a section "Kernel (9 changes)" which ends with "6ca5ccc kernel: update kernel 4.4 to 4.4.61 (+9,-117)". But then, further down, there are SoC specific sections that specify, for instance, "0dcc4d2 kernel: update kernel 4.4 to 4.4.59 (+135,-527)", for the brcm2708.
Which kernel version, then, is being used in the brcm2708, "4.4.59", or "4.4.61"?
I'm confused. Does the firmware for these different devices contain different versions of the kernel? Why is there a "kernel" changelog section if those changes do not apply globally?
The same (4.4.61) version is used for all arches. The SoC specific sections mention the .59 commit explicitely because this bump commit happened to touch patches specific to these SoCs.
The ar7 target is still stuck on kernel 3.18, which was EOLed upstream in january, therefore 17.0.x only includes architectures using the upstream supported LTS kernel 4.4.x.
There are 3 targets on the list stuck on 3.18 which I care about (adm5120, adm8668 and ar7). What can I do to ensure these are available in the next LEDE release?
Those targets would need updating to kernel 4.9.x, urgently - and some continued care. Just treat it like any other patch for lede, either by filing a pull request on the github mirror or mailing the corresponding patch series to the mailing list (given the expected patch size, the pull request is probably a better option).
[quote="RaylynnKnight, post:15, topic:3134"]
There are 3 targets on the list stuck on 3.18 which I care about (adm5120, adm8668 and ar7). What can I do to ensure these are available in the next LEDE release?
[/quote]Create the needed patches to bring those targets to kernel 4.9...
Looks like no core developer has been interested enough in those targets to upgrade them.
Given that the affected platforms are rather old and typically very low-end, the problem isn't 'just' updating them to kernel 4.9.x, but also getting kernel and defconfigs small enough to actually result in a working image small enough to fit. This is a problem the more modern targets like mvebu or ipq40xx/ ipq806x don't have (as those devices ship with >= 16 MB flash and >= 128 MB RAM, while all software -including the kernel- has a tendency to grow over time/ with new versions).
Congratulations on this milestone! I must say however, LEDE is acceptable stable for a while already. I'm running it on linksys wrt, linksys Exxx, Netgear, TP-Link and comiled it to intel x64 running in virtualBox on Windows and everything is stable. no connection drops or reboots or hangups on any of the devices since december 2016.
Of course more needs to be done, but once it's setup and running. Very stable!