Diesen Bug kenne ich nicht. Hast Du mal einen Github/Issue-Link dazu?
Ich habe mich im Detail auch nicht damit beschäftigt. Hatte das mal angefragt, scheint wohl in der aktuellen Version erledigt zu sein: Autoupdater läuft als Zombie · Issue #1212 · freifunk-gluon/gluon · GitHub
Gibt es hier schon neue Informationen wie es mit dem Update der Router weitergehen soll?
Wenn gar nix will, dann müsste es zumindest auf einem Knoten per ssh-Login gebugt werden.
Die Möglichkeiten, warum ein Autoupdate nicht ausgeführt wird.
(am besten wirklcih auf der Console schauen.)
ich bin verwirrt. Die letzte Aussage von Stefan war das der Autoupdate garnicht geht.
Ist das immer noch so? Oder geht er wieder und wir müssen jetzt das Problem auf den Nodes fixen?
Gruß
Hagen
Das war im August 2017.
Schau mal hier:
(Das klingt für mich auch nach „Rhein Sieg“. Oder gibt es da mehrere Domains diesen Namens?)
Hallo Hagen,
wir bekommen auf jeden fall ein Autoupdate hin. Wie ich aber gerade gesehen habe wurde das ursprüngliche Site Git gelöscht bzw. ersetzt. Ich gehe mal auf die suche wieso und kümmere mich darum, das in den nächsten tagen ein Update gebaut wird.
Grüße
Stefan
Hallo Stefan, ich danke dir für die Antwort. Das wäre wirklich cool. Ich wollte morgen auf meinem Router mal per ssh prüfen ob ich da eine Fehlermeldung finde. Aber wie gesagt es sind alle Meckenheimer Router betroffen und da glaube ich nicht das es ein individuelles Problem ist.
@adorfer Für mich bedeutet die Meldung das es eine neue Version gibt nicht gleichzeitig das das autoupdate gefixt. ist.
Gruß Hagen
Wie per PN geschrieben, müsst ihr über ein 2016.2.6 gehen um auf 2017.1.x zu kommen.
Ist das Rhein Sieg spezifisch und weist du den Grund, für ein Zwischenupdate? Zumindest, wenn im Knoten nichts individuell verstellt wurde, wüsste ich jetzt keinen generellen Grund.
LG Stefan
RTFM. 
Die Begründung habe ich zwar auch nicht verstanden, aber dort steht es:
http://gluon.readthedocs.io/en/v2017.1.x/releases/v2016.2.6.html
Selber RTFM!
Waren das da oben etwa Futros oder andere x86/x64-Geräte?
Nur diese brauchen unbedingt das Zwischenupdate, weil anders nicht gewährleistet ist, dass das Partitionslayout des Images rechtzeitig vergrößert wird vorm finalen Update auf LEDE?
Hallo Stephan,
auf github habe ich keine site.conf für Meckenheim gefunden. Da die (noch) verfügbaren aber ähnlich sein sollten, hier ein paar Anmerkungen zu
https://github.com/Freifunk-Rhein-Sieg/ffrsk-site/blob/v2016_2.x_Altenkirchen/site.conf:
opkg_repo = ‚http://downloads.openwrt.org/chaos_calmer/15.05.1/%S/packages‘,
Wird nicht funktionieren, weil
- die DNS Auflösung nicht funktioniert,
- die speziell mit dem Release gebauten Module im - Verzeichnis packages in output - genutzt werden müssen. Der Kernel Gluon ist nicht kompatibel mit dem normalen openwrt / LEDE.
Dies ist aber nur wichtig, wenn man Module auf eienm Router selbst nachinstallieren will. Diese Änderungen gehen jedoch mit Update verloren.
ntp_servers = { ‚2a03:2260:3017:1100::2‘, ‚1.de.pool.ntp.org‘, ‚2.de.pool.ntp.org‘, ‚3.de.pool.ntp.org‘ },
Funktioniert nicht, weil
- es den Server 2a03:2260:3017:1100::2 scheinbar nicht gibt,
- die DNS Auflösung der anderen Server nicht funktioniert.
Lösung: Einen eigenen Router zum Zeitserver machen oder IPV6 Adressen angeben. Feste Adressen sind blöde , aber die DNS Einstellungen auch.
mirrors = {
‚http://firmware.ffsu/altenkirchen/stable/sysupgrade‘,
‚Index of /altenkirchen/stable/sysupgrade‘,
‚http://[2a03:2260:3017:100::2]/altenkirchen/stable/sysupgrade‘,
Funktioniert nicht, weil
- DNS nicht funktioniert,
- [2a03:2260:3017:100::2] nicht existiert.
Lösung: Der Server [2a03:2260:3017:100::2] muss wieder in Betrieb. Nur von ihm können Update gezogen werden, wenn kein Root-Zugang eingerichtet ist und man nicht jeden Router neu installieren will.
Der Autouploader funktioniert richtig, wenn auch die Zeitserver funktionieren. Andernfalls hängt der Router über Tage oder Monate hinter der tatsächlichen Zeit udn der Autouploader nimmt die Updates schon beim ersten Versuch. Wäre nicht schlimm, aber wenn alle Knoten gleichzeitig eine Aktualisierung wünschen, wird die Last erheblich.
Ich habe doch geschrieben, dass ich die Erklärung nicht verstanden habe. War diese Aussage so schwer zu verstehen?
Der 1043n-v5 ist am 21. Januar wahrscheinlich nicht mit autoupdate installiert worden. Eine Unterstützung und funktionierendes Autoupdate für den 1043n-v5 gibt es erst seit dem 17. Januar im gluon 2017.1.4
Für die 6 RSK Domains
- Siegburg
- Lohmar
- Soziale Netze
- Sankt Augustin/Menden/Hangelar
- Altenkirchen
- Niederkassel
ist die config in bezug auf Pakete nicht aktualisiert, da die kompilierten Kernelmodule auf dem Updateserver wechselnde Positionen haben und dieser wie der Lede Packagetree eh manuell eingetragen werden muss.
Für die 6 Domains, die über die Siegburger Supernodes zu FFRL ausgeleitet werden, funktioniert autoupdate, wie man auch unschwer an den ausgerollten stable-2.9.10 updates der letzten 48 Stunden ablesen kann.
DNS funktioniert auf IPv6 des Updateservers innerhalb der Domains - die ReserveURLs sind eingebaut, um Alternativen zu haben.
Die Firmwarefiles / Packages/Module liegen physikalisch zusammen mit auf dem Updateserver von Troisdorf, der von Roman betrieben wird.
Glücklicherweise muss ich mich etwas korrigieren: Ich habe mir ein Image von Lohmar (stable 2.9.10) auf einen Router gespielt. (Per sysupgrade auf einem Router mit meiner Firmware. Das ergibt einen kleinen Mix, sollte aber nicht stören.)
In diesem Image funktioniert - im Gegensatz zu den Rheinbacher Knoten - die Namensauflösung und die Uhrzeit. Der Router ist allerdings der Router mit dem WAN-Port ans Internet angeschlossen. Zu ‚wlan mesh only‘ Nodes gibt es noch kleine Unterschiede, will ich jetzt nicht ausprobieren. Einen autoupdate konnte ich durch ändern der /lib/gluon/release erfolgreich provozieren.
Soweit ich es im Moment überblicke nutzt „lohmar“ andere Firewallregeln.
Die anderen Server: http://firmware.ffsu und http://[2a03:2260:3017:100::2] funktionieren nicht. Fehlermeldung:
- Failed to establish connection bzw.
- Connection error: Connection failed
Unter Index of /meckenheim/stable hat sich jedoch seit fast einem Jahr nichts getan.
Aber: Die 11 Nodes mit stable.2.5 müssten sich längst aktualisiert haben. Es sei denn, dort ist ein andere Updateserver drin.
Leider finde ich kein stable-2.5 mehr. Also habe ich mir ein stable 2.6 von Meckenheim auf einem 842nd v2 installiert: Als Updateserver ist [fda0:747e:ab29:2241::22] eingetragen, den es aber nicht gibt.
root@su-rhb-test-wr842ndv2-1:~# autoupdater
Connecting to [fda0:747e:ab29:2241::22] ([fda0:747e:ab29:2241::22]:80)
wget: can't connect to remote host: No route to host
There seems to have gone something wrong downloading the manifest from http://[fda0:747e:ab29:2241::22]/meckenheim/stable/sysupgrade
No usable mirror found.
Um nicht jeden Router anzufassen müsste also der Server [fda0:747e:ab29:2241::22] wieder her.
So. Schluss für heute.
Wir reden hier über Meckenheim.
Auf dem Server http://firmware.freifunk-rhein-sieg.net/ gibt es etwas mehr „Domains“ als nur 6. Alles was nicht in der obigen Liste steht, scheint verweist zu sein.
- altenkirchen
- hennef
- königswinter
- lohmar
- meckenheim
- much
- neunkirchen
- niederkassel
- rheinbach
- ruppichteroth
- sanktaugustin
- siegburg
- sozialenetze
- sozialenetzwerke
- troisdorf
- wachtberg
Unter den Waisen ist auch Meckenheim. Die Frage ist nun, wie kommt man von 2.6 oder früher auf 2.9.10?
Firmware für Meckenheim auswählen im Downloader:
Firmware Downloader Webfrontend
Troisdorf baut die meisten Firmware-Versionen ohne eigene Community - die leiten ihren Traffic dann über die Wuppertaler Supernodes aus, benutzen Fastd.
Für seine eigenen Domains baut Troisdorf die Firmware und leitet über tunneldigger auf eigene Supernodes.
Für die 6 oben gelisteten RSK-Domains bauen wir die Firmware selbst und leiten den Traffic über tunneldigger an die Siegburger Supernodes aus. Die Firmware-Versionssteigerungen bei diesen Domains ist migrationsmässig hochgezählt worden - der Sprung von openwrt zu LEDE dann mit 2.8 auf 2.9. Doku dazu in eigenen Threads hier im Forum.
Rheinbach baut auch selbst - war fastd über Wuppertal - keine Ahnung, wie jetziger Stand.
Alle nodes mit lediglich einer fda0… Ipv6 Adresse in der map deuten auf fastd und Standard Wuppertal Supernodes. - betreiben keine eigene Infrastruktur für die Ausleitung des Traffic.