Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20171211 * Gluon-Version: v2017.1.x * Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e * Download: https://firmware.ffnw.de/20171211
Folgende Gluon spezifischen Änderungen gab es unter anderen:
* Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist. Die LEDE basis von Gluon ist nun v17.01.4. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3] v17.01.4 [4].
* Der Kernel wurde von 3.18.x auf v4.4.93 geupgraded.
* Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig waren wurden entfernt.
* das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
* Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
* Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
* Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber verbessert (#605).
* Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [5].
* batman-adv wurde auf Version 2017.1 geupdated [6].
* GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
* Support für tunneldigger mesh VPN
* Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
* batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
* Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
* dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
* Einige security Issues wurden in Paketen behoben die in der regel nicht teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [7]
* Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
* Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
* Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http:// starten (9ab93992d1fc).
* Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock Firmware installiert wird (#1223).
* Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
* Fix ein build issue in kmod-jool [8]
* Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
Folgende Comunnity spezifischen Änderungen gab es: package repo:
* Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht ist entfernt.
* Das Paket ffnw-config-mode-geo-location wurde aktualisiert und nutzt jetzt minified js.
* Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
* Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
* Das Paket hoodselectorctl wurde entfernt.
* Das Paket nodewatcher2 wurde entfernt.
* Das Shell banner wurde von openWRT auf LEDE gewechselt.
* Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche eindeutig ist, Anstelle des hoodnames.
* Der hoodselector prüft im Radiolest Mode ob mesh on lan/wan an ist.
* Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte, diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
* Ein paar patches die den umgang mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
* Das Modul netmon wurde entfernt.
* fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
* Der schlüssel von lethexa wurde entfernt.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
* Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [11] upgraden, bevor diese 20171211 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltest du vor den update auf 20171211 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
die Firmware hat meinen Test bestanden. Der sah so aus: nacheinander alle Hoodsdruchlaufen, vpn-tunnel aufbauen, ip-adressen abwarten, namensauflösnug abwarten. Das einzige, was nicht funktioniert hat, war auf einem raspberry pi (1) der autoupdater:
---------------------8<--------------------- Downloading 'http://autoupdate-lede.ffnw/stable/stable.manifest' Connecting to 2a01:4f8:150:50a2::107:80 Writing to stdout
- 100% |*******************************| 61344 0:00:00 ETA Download completed (61344 bytes) No matching firmware found (model raspberry-pi-model-b-rev-2) No usable mirror found. --------------------->8---------------------
auch dann, wenn ich explizit 20171211 statt stable bei mirror in der /etc/config/autoupdater eingetragen habe. Fehlt hier einfach ein symlink raspberry-pi-model-b-rev-2 auf das entsprechende image, oder müsste man dieses umbenennen?
aber da das nur ein paar Systeme das draussen betrifft: signed
LG Lorenz
Am 12.12.2017 um 00:05 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171211
- Gluon-Version: v2017.1.x
- Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e
- Download: https://firmware.ffnw.de/20171211
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist. Die LEDE basis von Gluon ist nun v17.01.4. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3] v17.01.4 [4].
Der Kernel wurde von 3.18.x auf v4.4.93 geupgraded.
Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig waren wurden entfernt.
das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber verbessert (#605).
Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [5].
batman-adv wurde auf Version 2017.1 geupdated [6].
GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
Support für tunneldigger mesh VPN
Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
Einige security Issues wurden in Paketen behoben die in der regel nicht teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [7]
Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http:// starten (9ab93992d1fc).
Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock Firmware installiert wird (#1223).
Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
Fix ein build issue in kmod-jool [8]
Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht ist entfernt.
Das Paket ffnw-config-mode-geo-location wurde aktualisiert und nutzt jetzt minified js.
Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
Das Paket hoodselectorctl wurde entfernt.
Das Paket nodewatcher2 wurde entfernt.
Das Shell banner wurde von openWRT auf LEDE gewechselt.
Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche eindeutig ist, Anstelle des hoodnames.
Der hoodselector prüft im Radiolest Mode ob mesh on lan/wan an ist.
Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte, diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
Ein paar patches die den umgang mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
Das Modul netmon wurde entfernt.
fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
Der schlüssel von lethexa wurde entfernt.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
- Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [11] upgraden, bevor diese 20171211 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltest du vor den update auf 20171211 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 12/12/17 12:42, lrnzo via Dev wrote:
die Firmware hat meinen Test bestanden. Der sah so aus: nacheinander alle Hoodsdruchlaufen, vpn-tunnel aufbauen, ip-adressen abwarten, namensauflösnug abwarten. Das einzige, was nicht funktioniert hat, war auf einem raspberry pi (1) der autoupdater:
---------------------8<--------------------- Downloading 'http://autoupdate-lede.ffnw/stable/stable.manifest' Connecting to 2a01:4f8:150:50a2::107:80 Writing to stdout
100% |*******************************| 61344 0:00:00 ETA
Download completed (61344 bytes) No matching firmware found (model raspberry-pi-model-b-rev-2) No usable mirror found. --------------------->8---------------------
Betraf das alle hoods? oder ist dir das in einer aufgefallen?
vg Tarek
das alle hoods
Am 12.12.2017 um 12:56 schrieb Jan-Tarek Butt via Dev:
On 12/12/17 12:42, lrnzo via Dev wrote:
die Firmware hat meinen Test bestanden. Der sah so aus: nacheinander alle Hoodsdruchlaufen, vpn-tunnel aufbauen, ip-adressen abwarten, namensauflösnug abwarten. Das einzige, was nicht funktioniert hat, war auf einem raspberry pi (1) der autoupdater:
---------------------8<--------------------- Downloading 'http://autoupdate-lede.ffnw/stable/stable.manifest' Connecting to 2a01:4f8:150:50a2::107:80 Writing to stdout
100% |*******************************| 61344 0:00:00 ETA
Download completed (61344 bytes) No matching firmware found (model raspberry-pi-model-b-rev-2) No usable mirror found. --------------------->8---------------------
Betraf das alle hoods? oder ist dir das in einer aufgefallen?
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
---------------------8<--------------------- Downloading 'http://autoupdate-lede.ffnw/stable/stable.manifest' Connecting to 2a01:4f8:150:50a2::107:80 Writing to stdout
100% |*******************************| 61344 0:00:00 ETA
Download completed (61344 bytes) No matching firmware found (model raspberry-pi-model-b-rev-2) No usable mirror found. --------------------->8---------------------
Hi das scheint nen bug in gluon zu sein.
platform_info.get_image_name() liefert "raspberry-pi-model-b-rev-2"
Magst du mir sagen was für ein raspberry image du genommen hast?
schöne grüße Tarek
ja, das für Version 1:
http://firmware.ffnw.de/20171211/gluon-ffnw-20171211-raspberry-pi.img.gz
LG Lorenz
Am 12.12.2017 um 20:33 schrieb Jan-Tarek Butt via Dev:
Hi,
---------------------8<--------------------- Downloading 'http://autoupdate-lede.ffnw/stable/stable.manifest' Connecting to 2a01:4f8:150:50a2::107:80 Writing to stdout
100% |*******************************| 61344 0:00:00 ETA
Download completed (61344 bytes) No matching firmware found (model raspberry-pi-model-b-rev-2) No usable mirror found. --------------------->8---------------------
Hi das scheint nen bug in gluon zu sein.
platform_info.get_image_name() liefert "raspberry-pi-model-b-rev-2"
Magst du mir sagen was für ein raspberry image du genommen hast?
schöne grüße Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 12/12/17 22:16, lrnzo via Dev wrote:
ja, das für Version 1:
http://firmware.ffnw.de/20171211/gluon-ffnw-20171211-raspberry-pi.img.gz
Ay, ich hab mal nen MR zu gluon erstellt: https://github.com/freifunk-gluon/gluon/pull/1276
Es ist kein Problem in der Firmware sondern lediglich ein fehlender alias im Manifest.
Schöne Grüße Tarek
On 12/13/17 00:15, Jan-Tarek Butt via Dev wrote:
On 12/12/17 22:16, lrnzo via Dev wrote:
ja, das für Version 1:
http://firmware.ffnw.de/20171211/gluon-ffnw-20171211-raspberry-pi.img.gz
Ay, ich hab mal nen MR zu gluon erstellt: https://github.com/freifunk-gluon/gluon/pull/1276
Merged, auch für version 2
vg Tarek
Darf ich was vorschlagen? Dass wir den Blogpost ein paar Stunden _vor_ dem Umbiegen des Symlinks veröffentlichen? sonst war das immer so, dass dort stand, dass wir "in den nächsten Stunden" ein update ausrollen, was aber defacto schon passiert sein dürfte, wenn die Leute es mitbekommen.
Am 13.12.2017 um 12:04 schrieb Johannes Rudolph via Dev:
Signed _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Jop, wäre ich auch für. Ich kann allerdings Freutag erst testen und Signen. Bereite den doch jemand Donnerstag mal vor
Von meinem iPhone gesendet
Am 13.12.2017 um 12:37 schrieb lrnzo via Dev dev@lists.ffnw.de:
Darf ich was vorschlagen? Dass wir den Blogpost ein paar Stunden _vor_ dem Umbiegen des Symlinks veröffentlichen? sonst war das immer so, dass dort stand, dass wir "in den nächsten Stunden" ein update ausrollen, was aber defacto schon passiert sein dürfte, wenn die Leute es mitbekommen.
Am 13.12.2017 um 12:04 schrieb Johannes Rudolph via Dev: Signed _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 12/13/17 12:38, Stefan Dunkel via Dev wrote:
Jop, wäre ich auch für. Ich kann allerdings Freutag erst testen und Signen. Bereite den doch jemand Donnerstag mal vor
Ich bereite einen Artikel vor. Denn muss dann bitte jemand korrigieren. Sonst glaube ich das Ulf mich in Spanien besuchen kommt ;-D
vg Tarek
kannst du den in ein pad tun? oder kannst du folgendes sinngemäß mit einbauen?
--------------------------8<-------------------------- Wichtig für alle, die Setups mit PoE-Passthrough betreiben. Wenn ihr auf Nummer sicher gehen wollt, dass alle eure Geräte das Ausrollen der Firmware heile überstehen, solltet ihr dort, wo PoE-Passthrough aktiviert ist, sicherstellen, dass nicht genau dann vorne in der PoE-Kaskade ein reboot stattfindet, wenn weiter hinten geflasht wird. Mit anderen Worten es sollte genug Zeit nach dem Update der hinteren Router vergangen sein, bevor die vorderen updaten. Die eleganteste Möglichkeit hierzu ist wohl, die Minuten der cronjobs auf den einzelnen Routern entsprechend anzupassen. Hierzu mit vi in der /usr/lib/micron.d/autoupdater die erste Spalte bearbeiten. Danach noch /etc/init.d/micrond reload ausführen.
Alternativ den Autoupdater deaktivieren und das Update zu einem Zeitpunkt händisch ausführen, wenn sicher ist, dass die per PoE-Passthrough betriebenen Geräten das Update bereits installiert haben. Folgender Befehl tut das:
if [ $(uci get system.gpio_switch_poe_passthrough.value) -eq "1" ];then uci set autoupdater.settings.enabled='0'; uci commit autoupdater; fi
Ob und welcher Aufwand sich lohnt muss jede/r selbst entscheiden, denn leider überstehen diese Einstellungen das update nicht und müssen entsprechen vor dem nächsten update wiederholt werden. -------------------------->8--------------------------
stimmt doch, oder?
LG Lorenz
Am 13.12.2017 um 14:55 schrieb Jan-Tarek Butt via Dev:
On 12/13/17 12:38, Stefan Dunkel via Dev wrote:
Jop, wäre ich auch für. Ich kann allerdings Freutag erst testen und Signen. Bereite den doch jemand Donnerstag mal vor
Ich bereite einen Artikel vor. Denn muss dann bitte jemand korrigieren. Sonst glaube ich das Ulf mich in Spanien besuchen kommt ;-D
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 12/13/17 18:05, lrnzo via Dev wrote:
kannst du den in ein pad tun? oder kannst du folgendes sinngemäß mit einbauen?
Ich pack es in ein Pad.
https://pad.mainframe.io/p/20171211
--------------------------8<-------------------------- Wichtig für alle, die Setups mit PoE-Passthrough betreiben. Wenn ihr auf Nummer sicher gehen wollt, dass alle eure Geräte das Ausrollen der Firmware heile überstehen, solltet ihr dort, wo PoE-Passthrough aktiviert ist, sicherstellen, dass nicht genau dann vorne in der PoE-Kaskade ein reboot stattfindet, wenn weiter hinten geflasht wird. Mit anderen Worten es sollte genug Zeit nach dem Update der hinteren Router vergangen sein, bevor die vorderen updaten. Die eleganteste Möglichkeit hierzu ist wohl, die Minuten der cronjobs auf den einzelnen Routern entsprechend anzupassen. Hierzu mit vi in der /usr/lib/micron.d/autoupdater die erste Spalte bearbeiten. Danach noch /etc/init.d/micrond reload ausführen.
Alternativ den Autoupdater deaktivieren und das Update zu einem Zeitpunkt händisch ausführen, wenn sicher ist, dass die per PoE-Passthrough betriebenen Geräten das Update bereits installiert haben. Folgender Befehl tut das:
if [ $(uci get system.gpio_switch_poe_passthrough.value) -eq "1" ];then uci set autoupdater.settings.enabled='0'; uci commit autoupdater; fi
Ob und welcher Aufwand sich lohnt muss jede/r selbst entscheiden, denn leider überstehen diese Einstellungen das update nicht und müssen entsprechen vor dem nächsten update wiederholt werden. -------------------------->8--------------------------
stimmt doch, oder?
hm, die einstellungen sollte den reboot überleben. Abgesehen von der cron Änderung Die Kollision ist theoretisch möglich. Daran wird gerade gearbeitet: https://github.com/freifunk-gluon/gluon/pull/1259
vg Tarek
Hi zusammen,
Ich habe die nginx conf auf
files.ffnw.de und mirror.ffnw.de soweit angepasst das
autoupdater.ffnw/stable autoupdate.ffnw/stable auf das 20170822 dir zeigen.
autoupdate-lede.ffnw arbeitet wie gewohnt.
wir können den blogartikel nun raus hauen.
vg Tarek
finde keine Fehler mehr. von meiner Seite aus: Feuer frei!
Am 14.12.2017 um 14:48 schrieb Jan-Tarek Butt via Dev:
Hi zusammen,
Ich habe die nginx conf auf
files.ffnw.de und mirror.ffnw.de soweit angepasst das
autoupdater.ffnw/stable autoupdate.ffnw/stable auf das 20170822 dir zeigen.
autoupdate-lede.ffnw arbeitet wie gewohnt.
wir können den blogartikel nun raus hauen.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
wenn der letzte dann signiert, den symlink wie gewohnt umlegen?
Von meinem iPhone gesendet
Am 14.12.2017 um 15:45 schrieb lrnzo via Dev dev@lists.ffnw.de:
finde keine Fehler mehr. von meiner Seite aus: Feuer frei!
Am 14.12.2017 um 14:48 schrieb Jan-Tarek Butt via Dev: Hi zusammen,
Ich habe die nginx conf auf
files.ffnw.de und mirror.ffnw.de soweit angepasst das
autoupdater.ffnw/stable autoupdate.ffnw/stable auf das 20170822 dir zeigen.
autoupdate-lede.ffnw arbeitet wie gewohnt.
wir können den blogartikel nun raus hauen.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Okay, also nur Signen und der FW Bot macht das?
Von meinem iPhone gesendet
Am 14.12.2017 um 16:31 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
wenn der letzte dann signiert, den symlink wie gewohnt umlegen?
Ay, der Rest passiert automatisch.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes
stimmt. Gute Idee. Unser blogpost schweigt sich ja leider darüber aus, *wann genau* wir das update ausrollen wollen, also wäre es den Betreibern von virtuellen Offloadern gegenüber nur fair, hier diese Sicherung einzubauen.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Falls wir das irgendwo testen wollen: auf mindestens ein System mit "common KVM processor" habe ich Zugriff.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Ich habe zwei in Proxmox virtualisierte Offloader, ich update diese gleich von Hand. Lorenz hat auch hier Zugriff via Passwort.
Die Idee mit dem "Zwang" zum manuellen Update bei diesen Offloadern find ich gut.
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:04 schrieb lrnzo via Dev:
Falls wir das irgendwo testen wollen: auf mindestens ein System mit "common KVM processor" habe ich Zugriff.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
zufällig FF-IBB-Stadt-AP-Offloader und FF-IBB-Stadt-Router-Offloader ?
Am 15.12.2017 um 09:06 schrieb Sebastian Wolzenburg via Dev:
Ich habe zwei in Proxmox virtualisierte Offloader, ich update diese gleich von Hand. Lorenz hat auch hier Zugriff via Passwort.
Die Idee mit dem "Zwang" zum manuellen Update bei diesen Offloadern find ich gut.
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:04 schrieb lrnzo via Dev:
Falls wir das irgendwo testen wollen: auf mindestens ein System mit "common KVM processor" habe ich Zugriff.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Ja genau, UND https://map.ffnw.de/hood-st/#%21v:m%3Bn:22805337c3c3
FF-LEN-Rathaus-KVM-Offloader
liegt auch unser Key drauf. Kann dir da auch Zugriff geben wenn gewünscht, dann schreib mir bei Telegram :)
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:09 schrieb lrnzo via Dev:
zufällig FF-IBB-Stadt-AP-Offloader und FF-IBB-Stadt-Router-Offloader ?
Am 15.12.2017 um 09:06 schrieb Sebastian Wolzenburg via Dev:
Ich habe zwei in Proxmox virtualisierte Offloader, ich update diese gleich von Hand. Lorenz hat auch hier Zugriff via Passwort.
Die Idee mit dem "Zwang" zum manuellen Update bei diesen Offloadern find ich gut.
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:04 schrieb lrnzo via Dev:
Falls wir das irgendwo testen wollen: auf mindestens ein System mit "common KVM processor" habe ich Zugriff.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 12/15/17 09:10, Sebastian Wolzenburg via Dev wrote:
Ja genau, UND https://map.ffnw.de/hood-st/#%21v:m%3Bn:22805337c3c3
FF-LEN-Rathaus-KVM-Offloader
liegt auch unser Key drauf. Kann dir da auch Zugriff geben wenn gewünscht, dann schreib mir bei Telegram :)
Ay,
ich benenne die images eben um.
vg Tarek
Erster Offloader kam nicht zurück, kein Ping nix, hab dann im Proxmox rebootet. Lede war drauf aber "No Filesystem to mount".
Muss nun zum Termin, probiere es danach erneut. Einen QEMU Resize hatte ich nicht gemacht.
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:10 schrieb Sebastian Wolzenburg via Dev:
Ja genau, UND https://map.ffnw.de/hood-st/#%21v:m%3Bn:22805337c3c3
FF-LEN-Rathaus-KVM-Offloader
liegt auch unser Key drauf. Kann dir da auch Zugriff geben wenn gewünscht, dann schreib mir bei Telegram :)
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net Am 15.12.2017 um 09:09 schrieb lrnzo via Dev:
zufällig FF-IBB-Stadt-AP-Offloader und FF-IBB-Stadt-Router-Offloader ?
Am 15.12.2017 um 09:06 schrieb Sebastian Wolzenburg via Dev:
Ich habe zwei in Proxmox virtualisierte Offloader, ich update diese gleich von Hand. Lorenz hat auch hier Zugriff via Passwort.
Die Idee mit dem "Zwang" zum manuellen Update bei diesen Offloadern find ich gut.
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:04 schrieb lrnzo via Dev:
Falls wir das irgendwo testen wollen: auf mindestens ein System mit "common KVM processor" habe ich Zugriff.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list --dev@lists.ffnw.de To unsubscribe send an email todev-leave@lists.ffnw.de
Dev mailing list --dev@lists.ffnw.de To unsubscribe send an email todev-leave@lists.ffnw.de
Dev mailing list --dev@lists.ffnw.de To unsubscribe send an email todev-leave@lists.ffnw.de
Dev mailing list --dev@lists.ffnw.de To unsubscribe send an email todev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
ist tatsächlich besser wenn wir die erstmal außen vor lassen. Dann kann ich das auch mit meinem Gewissen später vereinbaren ;)
Von meinem iPhone gesendet
Am 15.12.2017 um 09:36 schrieb Sebastian Wolzenburg via Dev dev@lists.ffnw.de:
Erster Offloader kam nicht zurück, kein Ping nix, hab dann im Proxmox rebootet. Lede war drauf aber "No Filesystem to mount".
Muss nun zum Termin, probiere es danach erneut. Einen QEMU Resize hatte ich nicht gemacht. Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:10 schrieb Sebastian Wolzenburg via Dev: Ja genau, UND https://map.ffnw.de/hood-st/#%21v:m%3Bn:22805337c3c3 FF-LEN-Rathaus-KVM-Offloader liegt auch unser Key drauf. Kann dir da auch Zugriff geben wenn gewünscht, dann schreib mir bei Telegram :) Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:09 schrieb lrnzo via Dev: zufällig FF-IBB-Stadt-AP-Offloader und FF-IBB-Stadt-Router-Offloader ?
Am 15.12.2017 um 09:06 schrieb Sebastian Wolzenburg via Dev:
Ich habe zwei in Proxmox virtualisierte Offloader, ich update diese gleich von Hand. Lorenz hat auch hier Zugriff via Passwort.
Die Idee mit dem "Zwang" zum manuellen Update bei diesen Offloadern find ich gut.
Mit freundlichen Grüßen Sebastian Wolzenburg 2. Vorsitzender Freifunk Ibbenbüren e.V. www.freifunk-ibbenbueren.net sebastian@freifunk-ibbenbueren.net
Am 15.12.2017 um 09:04 schrieb lrnzo via Dev:
Falls wir das irgendwo testen wollen: auf mindestens ein System mit "common KVM processor" habe ich Zugriff.
Am 15.12.2017 um 08:29 schrieb Johannes Rudolph via Dev:
Moin
habe gerade mit Stefan telefoniert und er hatte da einen berechtigten "Einwand" Wir sollten die Sysupgrade Images für die Virtuellen Offloader aus dem Verzeichnisumbennen. Damit wir nicht alle Offloader Installationen kaputt machen, sondern vielmehr schauen, dass wir darauf noch mal hinweisen, was zu machen ist.
Wenn wir diese betroffenen Images umbenennen sind sie für jedermann noch zu finden. Allerdings bekommen die Offloader mit Autoupdater einen 404 Fehler und updaten nicht. Dass muss dann halt manuell passieren.
Als idee die betroffenen Image Dateien mit dem Prefix "manuelles_update_" oder ähnliches versehen
Gruß
Johannes _______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Soll ich gleich nochmal testen? Evtl gemeinsam mit einem von euch? Lorenz? Bin in 30min zurück im Büro
Von meinem iPhone gesendet
Am 15.12.2017 um 10:33 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
ist tatsächlich besser wenn wir die erstmal außen vor lassen. Dann kann ich das auch mit meinem Gewissen später vereinbaren ;)
Ich hab die Images um benannt um sicher zu stellen das da nix schief läuft.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
schon erledigt.
root@FF-IBB-Stadt-AP-Offloader:~# autoupdater Connecting to autoupdate-lede.ffnw ([2a01:4f8:150:50a2::107]:80) - 100% |******************************************************************************************************************************************************************| 61602 0:00:00 ETA New version available. Stopping cron... Command failed: Not found Stopping haveged... Stopping micrond... Stopping sysntpd... Command failed: Not found Stopping gluon-radvd... Command failed: Not found Stopping uhttpd... Command failed: Not found Stopping sse-multiplexd... Stopping gluon-respondd... Command failed: Not found vm.drop_caches = 3 Connecting to autoupdate-lede.ffnw ([2a01:4f8:192:832b:8::1]:80) wget: server returned error: HTTP/1.1 404 Not Found Error downloading the image from http://autoupdate-lede.ffnw/20171211 Starting gluon-respondd... Starting sse-multiplexd... Starting uhttpd... Starting gluon-radvd... Starting cron... Starting haveged... Starting micrond... Starting sysntpd... No usable mirror found.
alles im grünen Bereich.
LG Lorenz
Am 15.12.2017 um 10:41 schrieb Sebastian Wolzenburg via Dev:
Soll ich gleich nochmal testen? Evtl gemeinsam mit einem von euch? Lorenz? Bin in 30min zurück im Büro
Von meinem iPhone gesendet
Am 15.12.2017 um 10:33 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
ist tatsächlich besser wenn wir die erstmal außen vor lassen. Dann kann ich das auch mit meinem Gewissen später vereinbaren ;)
Ich hab die Images um benannt um sicher zu stellen das da nix schief läuft.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
schon erledigt.
root@FF-IBB-Stadt-AP-Offloader:~# autoupdater Connecting to autoupdate-lede.ffnw ([2a01:4f8:150:50a2::107]:80)
100% |******************************************************************************************************************************************************************| 61602 0:00:00 ETA
New version available. Stopping cron... Command failed: Not found Stopping haveged... Stopping micrond... Stopping sysntpd... Command failed: Not found Stopping gluon-radvd... Command failed: Not found Stopping uhttpd... Command failed: Not found Stopping sse-multiplexd... Stopping gluon-respondd... Command failed: Not found vm.drop_caches = 3 Connecting to autoupdate-lede.ffnw ([2a01:4f8:192:832b:8::1]:80) wget: server returned error: HTTP/1.1 404 Not Found Error downloading the image from http://autoupdate-lede.ffnw/20171211 Starting gluon-respondd... Starting sse-multiplexd... Starting uhttpd... Starting gluon-radvd... Starting cron... Starting haveged... Starting micrond... Starting sysntpd... No usable mirror found.
alles im grünen Bereich.
Betroffen sind die geräte wo das system irekt auf der hardware aus geführt wird also wo das gluon auf ein image geschrieben wurde.
vg Tarek
Also alle x86 systeme updaten nicht via autoupdater. Die dafür nötigen images sind um benannt.
Ich hab es auch bereits geprüft. Das betrifft sowol den mirror als auch files.
Lorenz hatte es auch gerade noch geprüft.
vg Tarek
öhm, aber die sind noch da. hast du umbenannt oder kopiert?
Am 15.12.2017 um 10:33 schrieb Jan-Tarek Butt via Dev:
ist tatsächlich besser wenn wir die erstmal außen vor lassen. Dann kann ich das auch mit meinem Gewissen später vereinbaren ;)
Ich hab die Images um benannt um sicher zu stellen das da nix schief läuft.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
lrnzo@files ~ % ls -l /var/www/dev/firmware/20171211/*gz -rw-r--r-- 1 root root 7980796 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-raspberry-pi-2.img.gz -rw-r--r-- 1 root root 7980796 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-raspberry-pi-2-sysupgrade.img.gz -rw-r--r-- 1 root root 8636559 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-raspberry-pi.img.gz -rw-r--r-- 1 root root 8636559 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-raspberry-pi-sysupgrade.img.gz -rw-r--r-- 1 root root 7328087 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-x86-64.img.gz -rw-r--r-- 1 root root 8351694 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-x86-generic.img.gz -rw-r--r-- 1 root root 7619791 Dez 11 23:36 /var/www/dev/firmware/20171211/gluon-ffnw-20171211-x86-geode.img.gz -rw-r--r-- 1 root root 7328087 Dez 11 23:36 /var/www/dev/firmware/20171211/manual_gluon-ffnw-20171211-x86-64-sysupgrade.img.gz -rw-r--r-- 1 root root 8351694 Dez 11 23:36 /var/www/dev/firmware/20171211/manual_gluon-ffnw-20171211-x86-generic-sysupgrade.img.gz -rw-r--r-- 1 root root 7619791 Dez 11 23:36 /var/www/dev/firmware/20171211/manual_gluon-ffnw-20171211-x86-geode-sysupgrade.img.gz
Am 15.12.2017 um 11:46 schrieb lrnzo via Dev:
öhm, aber die sind noch da. hast du umbenannt oder kopiert?
Am 15.12.2017 um 10:33 schrieb Jan-Tarek Butt via Dev:
ist tatsächlich besser wenn wir die erstmal außen vor lassen. Dann kann ich das auch mit meinem Gewissen später vereinbaren ;)
Ich hab die Images um benannt um sicher zu stellen das da nix schief läuft.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
stimmt. ich dödel.
Am 15.12.2017 um 11:53 schrieb Jan-Tarek Butt via Dev:
On 12/15/17 11:46, lrnzo via Dev wrote:
öhm, aber die sind noch da. hast du umbenannt oder kopiert?
Ich glaube du bringst gerade die sysupgrade images mit den factory images durch einander? Für den autoupdater sind nur die sysupgarde images relevant.
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi zusammen,
ich habe signiert und den Symlink umgebogen.
Die Router updaten nun :)
Am 15.12.2017 um 11:55 schrieb lrnzo via Dev:
stimmt. ich dödel.
Am 15.12.2017 um 11:53 schrieb Jan-Tarek Butt via Dev:
On 12/15/17 11:46, lrnzo via Dev wrote:
öhm, aber die sind noch da. hast du umbenannt oder kopiert?
Ich glaube du bringst gerade die sysupgrade images mit den factory images durch einander? Für den autoupdater sind nur die sysupgarde images relevant.
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de