Fix boot on certain QCA955x-based devices (e.g. OpenMesh OM5P AC v2) (#965)
This issue was a regression in Gluon v2016.2.1.
Build: Fix git downloads from git.kernel.org on Debian Wheezy (#919)
We’ve switched back from HTTPS to the git protocol for now to avoid using the old GnuTLS version of Debian Wheezy which can’t establish a HTTPS connection with git.kernel.org anymore.
This issue was a regression in Gluon v2016.2.
Fix RX filter of Ubiquiti UAP Outdoor+ (d43147a8e03d)
This issue was a regression in Gluon v2016.2.
Fix switched WAN/LAN interface assignment on CPE210 (59deb2064d54)
This issue was a regression in Gluon v2016.2.
Significantly reduce CPU load used by signal strength LEDs (#897)
Fix ethernet port of the Ubiquiti UAP AC Lite (#911)
Build: Don’t use host /tmp directory (f9072a36411b)
Fixes build when /tmp is mounted with noexec.
Fix mesh interface type respondd/alfred announcements when using VLANs over IBSS (#941)
Fix next-node ebtables rules without next_node.ip4 (9dbe9f785d2b)
Gluon v2016.2 added support for using the next-node feature without specifying an IPv4 address. Some scripts had not been adjusted, making the next-node unreliable when no IPv4 address was specified.
Other changes
x86-generic and x86-64 images now have PATA and MMC support to allow using them on various devices that were previously unsupported.
Clean up opkg postinst scripts up on image generation.
OpenWrt does this by default to save a little space.
Known Issues
Default TX power on many Ubiquiti devices is too high, correct offsets are unknown (#94)
Reducing the TX power in the Advanced Settings is recommended.
The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (#496)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
Inconsistent respondd API (#522)
The current API is inconsistent and will be replaced eventually. The old API will still be supported for a while.
Hat schon jemand mit „Futro&Co“, der von SD-Karte oder USB-Stick startet einen „Folge-Sysupgrade“ probiert?
Also von einer 2016.2.2-> (neuere) 2016.2.2?
Zumindest lese ich es so, dass das evtl. Probleme geben könnte.
Das ist keine „komische Vermutung“, sondern eine Frage, ob hier jemand ist, der oder die das schon getestet hat.
Das würde die Sache egal in welcher Rückmeldung) vereinfachen.
direkt unter dem Release zu posten erweckt aber den Eindruck, als wäre es ein Problem in diesem neuen Release - was es nicht ist.
USB-Sticks dürften übrigens nicht betroffen sein, die wurden bei mir bisher immer als /dev/sda oder ähnliches erkannt, was sysupgrade dann ganz normal behandelt.
o.k. die Einschränkung also wirklich:
Es betrifft ausschließlich Bootmedien, die NICHT auf /dev/sdaX oder /dev/hdaX vom Kernel erkannt werden.
Also dann wirklich nur solches, was als /dev/mblck im System auftaucht.
(Was bei USB-SD-Adaptern nicht der Fall sein dürfte.)
Fehlalarm:
TLTR: Sorry, wir haben hier ein Problem selber verursacht. Gluon 2016.2.2 ist nicht betroffen.
Sorry, es handelt sich um einen Fehlalarm. Das unten beschrieben Problem tauch nur bei uns auf. Es wurde verursacht, weil aus $Gründen mal das OpenWrt Package dnsmasq in unsere lokalen Packages kopiert wurde. Zwar unter einem anderen Namen, aber es ist dnsmasq in Version 2.76 gewesen. Obwohl das Package nicht in der in der site.mk eingebunden wird, wird es offensichtlich generell erstmal mitgebaut. Und wenn dnsmasq sowieso verwendet wird, dann eben auch in der vorliegenden problemverursachenden neueren Version.
Sorry wegen der Störung
Jason
ACHTUNG:
Wir haben hier in Frankfurt ein kleines Problem mit Gluon 2016.2.2
Bei Knoten mit aktivem Mesh-VPN (fastd) starten nicht alle dnsmasq-Instanzen auf. Bemerkbar macht es sich z.B. auf Up-Link-Knoten, dass auf einer SSH-Console kein 'ping www.google.de' funktioniert.
Dieses führt dazu, dass auf den Knoten auch keine Auflösung der Domainnamen unserer Autoupdateserver durchgeführt werden kann. Ein Autoupdate ist also nicht mehr möglich.
Vermutete Ursache:
Eine der dnsmasq-Instanzen möchte unter dem User und der Goupe ‚dnsmasq‘ gestartet werden ( das liegt evtl. an der neueren v2.76 von dnsmasq). Das klappt aber nicht. Bei uns liegt es an dem Fehlen des Users „dnsmasq“ und der Group ‚dnsmasq‘
Sichtbarmachen können wir es, wenn wir uns auf einem Knoten Logs mit 'logread -f' ansehen und dann „’/etc/init.d/fastd restart’“ aufrufen. Es taucht dann ein dnsmasq: unknown user or group: dnsmasq
in den Logs auf.
Befor Ihr dieses Release in die freie Wildbahn lasst, so testet bitte vorher ob Ihr noch erfolgreich ein 'autoupdater' absetzen könnt.
Es kann sein, dass es nur an unserer Firmware liegt, aber bevor es da einige nicht mehr updatebare Knoten im Feld gibt, wollte ich das hier dringend los werden. Falls es also ein Fehlalarm sein sollte, so haut bitte nicht so feste zu
Frohes Fest
Jason
P.S.
Prüfen könnt Ihr es auch recht schnell, wenn Ihr ein
ps | grep dnsmasq
absetzt.Es müssen dann zwei dnsmasq Instanzen aufgeführt werden. Dann ist alles gut.
1177 root 1076 S /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo -p 54 -h -r /var/gluon/wan-dnsmasq/resolv.conf
1881 dnsmasq 1372 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
