# Firmware Update auf 2019 über 2018

**URL:** <https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332>\
**Category:** Freifunk Nord\
**Created:** [6. Oktober 2019 um 09:31 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332 "2019-10-06T09:31:07Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [6. Oktober 2019 um 09:31 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/1 "2019-10-06T09:31:07Z")

</div>

Moin,

nach über 3 Jahren sollten wir mal wieder ein Firmware Update durchführen.

Ich baue aus dem Grund gerade die letzte 2018.

Dieser Zwischenschritt ist nötig, damit wir von 2016 sauber auf 2019 migrieren können.

Ich denke nicht das wir da dann lange Tests fahren müssen, da die 2018 u.a. bei mir in den Domänen Steinburg und Plön Ostholstein mehr als gut abgehangen ist.

cc: @rubo77

---

<div class="post-metadata">

**Author:** ![rubo77](https://forum.freifunk.net/user_avatar/forum.freifunk.net/rubo77/32/799_2.png) [@rubo77](https://forum.freifunk.net/u/rubo77)\
**Post date:** [6. Oktober 2019 um 10:06 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/2 "2019-10-06T10:06:43Z")

</div>

Wir sollten die aber schon auf ein paar routern eine woche laufen lassen bevor wir alle updaten. Vor allem der autoupdater muss getestet werden ob der auch nach einem update erneut updaten würde, also:

> Version in ` /lib/gluon/releases` von Hand runter setzen und `autoupdater -f` aufrufen

- direkt am Uplink
- als mesh-only Knoten

vielleicht noch was hieraus?

[https://wiki.freifunk.net/index.php?title=Gluon\_firmware\_testen\_vorm\_Rollout](https://wiki.freifunk.net/index.php?title=Gluon_firmware_testen_vorm_Rollout)

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [6. Oktober 2019 um 10:52 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/3 "2019-10-06T10:52:48Z")

</div>

Klar so war das auch nicht gemeint

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [6. Oktober 2019 um 17:11 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/4 "2019-10-06T17:11:16Z")

</div>

Dank dem Hinweis von adorfer ist zunächst noch ein Update auf die letzte 2016er Version nötig.

Dann springen wir auf die letzte 2018 und dann auf 2019.

Build läuft bereits.

---

<div class="post-metadata">

**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\
**Post date:** [7. Oktober 2019 um 00:52 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/5 "2019-10-07T00:52:54Z")

</div>

> [@anon68922371](#):
>
> Update auf die letzte 2016er

Du meinst damit den git-Stand von v2016.2.x?

> This version changes the flash partition layout on some devices (TP-Link CPE/WBS 210/510). To avoid upgrade failures, make sure to upgrade to Gluon 2017.1.8 or the latest Gluon 2016.2.x (unreleased) before installing Gluon 2018.1.

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [7. Oktober 2019 um 05:28 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/6 "2019-10-07T05:28:21Z")

</div>

> [@wusel](#):
>
> Du meinst damit den git-Stand von v2016.2.x?

Ja genau.

---

<div class="post-metadata">

**Author:** ![tobby](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/t/65b543/32.png) [@tobby](https://forum.freifunk.net/u/tobby)\
**Post date:** [16. Oktober 2019 um 16:17 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/7 "2019-10-16T16:17:48Z")

</div>

> **Note: There is an issue in all Gluon versions before 2016.2.6 that will lead to x86 systems losing their configuration when upgrading to Gluon 2017.1!** Older Gluon versions should be upgraded to 2016.2.6 first before switching to 2017.1.

Quelle: [Gluon 2017.1 — Gluon 2019.1.3 documentation](https://gluon.readthedocs.io/en/v2019.1.x/releases/v2017.1.html)

Also auf jeden Fall erst auf 2016.2.6 oder 2016.2.7 updaten, bevor man neuere Versionen einspielen möchte.

und:

> If you are upgrading from a version prior to v2018.1, please note that the flash layout on some devices (TP-Link CPE/WBS 210/510) was changed. To avoid upgrade failures, make sure to upgrade to Gluon 2017.1.8 or the latest Gluon 2016.2.x (unreleased) before installing Gluon 2018.1, 2018.2 or 2019.1.

Quelle: [Gluon 2019.1 — Gluon 2019.1.3 documentation](https://gluon.readthedocs.io/en/v2019.1.x/releases/v2019.1.html)

Also nach 2016.2.6 bzw. 2016.2.7 dann zunächst auf 2017.1.8 updaten, bevor man ein 2018er oder 2019er Gluon einspielt.

Wer ganz auf Nummer sicher gehen möchte, spielt die Updates vermutlich in folgender Reihenfolge ein:  
2016.x → 2016.2.7 → 2017.1.8 → 2018.1.4 → 2018.2.3 → 2019.1  
Aber auch funktionieren müsste eigentlich die folgende:  
2016.x → 2016.2.7 → 2017.1.8 → 2019.1  
davon sollte (bzw. darf!) man dann aber keine Version auslassen, oder man verliert ggf. Router und Konfigurationen bei den Updates.

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [16. Oktober 2019 um 18:25 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/8 "2019-10-16T18:25:50Z")

</div>

Das Partitionlayout wurde schon im letzten Stand von 2016 backported.

Ein Update auf 2017 sollte in jedem Fall vermieden werden, da dort der Autoupdater defekt ist. Ein Update auf 2017 werden wir daher definitiv NICHT durchführen.

Es bleibt bei der o.g. Prozedur.

---

<div class="post-metadata">

**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\
**Post date:** [17. Oktober 2019 um 04:10 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/9 "2019-10-17T04:10:43Z")

</div>

> [@tobby](#):
>
> Also auf jeden Fall erst auf 2016.2.6 oder 2016.2.7 updaten, bevor man neuere Versionen einspielen möchte.  
> […]  
> Also nach 2016.2.6 bzw. 2016.2.7 dann zunächst auf 2017.1.8 updaten, bevor man ein 2018er oder 2019er Gluon einspielt.

Nope! Wenn man auf dem Stand von »v2016.x Master« ist, kann man direkt mit 2018.x oder 2019.x weitermachen; wer v2017 aus guten Gründen ausgelassen hat, muß es sich auch in diesem Kontext nicht antun.

---

<div class="post-metadata">

**Author:** ![tobby](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/t/65b543/32.png) [@tobby](https://forum.freifunk.net/u/tobby)\
**Post date:** [17. Oktober 2019 um 11:29 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/10 "2019-10-17T11:29:07Z")

</div>

Ah, der Hinweis „2016.2.x (unreleased)“ klingt nicht so, als wenn das schon drin wäre. Hab’ da aber keine weiteren Informationen als die offiziellen Docs, in denen es halt wie oben zitiert steht.

Kann natürlich sein, dass es im 2016er Master drin ist. Wir haben immer nur stable-releases ausgerollt und nie Versionen aus dem Master.

Und wo ist der Autoupdater in der 2017er kaputt? Ich weiß nur von dem Fehler im Autoupdater in 2018.1, der in 2018.1.4 behoben wurde: [Gluon 2018.1.4 — Gluon 2019.1.3 documentation](https://gluon.readthedocs.io/en/v2019.1.x/releases/v2018.1.4.html)

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [17. Oktober 2019 um 11:37 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/11 "2019-10-17T11:37:10Z")

</div>

Ist drin 🙂

Bitte den Thread nicht derailen und 2017 Thematiken in einem anderen Thread diskutieren, danke.

---

<div class="post-metadata">

**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\
**Post date:** [18. Oktober 2019 um 00:02 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/12 "2019-10-18T00:02:24Z")

</div>

> [@tobby](#):
>
> Kann natürlich sein, dass es im 2016er Master drin ist.

Ist es, wurde IIRC $irgendwo mal thematisiert, sollte in der git-Historie nachvollziehbar sein. Kurzum: ist man auf einer v2016-FW, braucht’s für alles nach v2017 als Zwischenschritt eine FW mit v2016-master, haben wir so gemacht und es war fast schmerzfrei (von v2016-master nach v2018.1).

„Fast“, denn [$irgendwann](https://gluon.readthedocs.io/en/v2018.2.x/releases/v2017.1.html#general-changes) hat sich die Größe der x86-Images geändert:

> Another potential issue mostly affects virtual machines: Gluon 2017.1 images are bigger than 2016.2.x images on x86. If your virtual harddisk is based on a 2016.2.x image, it must be resized to 273MB or bigger before upgrading to Gluon 2017.1. Using qemu, the command
> 
> `qemu-img resize $IMAGE 273MB`
> 
> can be used to do this.

Da in unserem Fall wir ggf. auf die VM, aber außer bei eigenen Systemen nie auf die Virtualisierungsebene Zugriff hatten, hat dieses „Feature“ bei unserem Wechsel von v2016 auf v2018 alle Gluon-VMs geschreddert; Hardware-Offloader (Futro, …) hingegen haben’s IIRC überlebt. Corner-Case, sollte man aber auf dem Schirm haben.

---

<div class="post-metadata">

**Author:** ![kevinq](https://forum.freifunk.net/user_avatar/forum.freifunk.net/kevinq/32/1653_2.png) [@kevinq](https://forum.freifunk.net/u/kevinq)\
**Post date:** [25. Oktober 2019 um 09:58 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/13 "2019-10-25T09:58:14Z")

</div>

Hallo, in Pinneberg müssen wir wohl den selben Update Pfad beschreiten, wir sind da aktuell noch auf 2016.2.6

Das bauen von 2019.1 und 2018.2.3 ging soweit ohne größere Schwierigkeiten, aber 2016.2.x will nicht. ([verwendete site.conf](https://github.com/freifunk-pinneberg/firmware/blob/feature/2016.2.8/site.conf)) Ich habe es extra auch noch einmal auf komplett anderer Hardware versucht. Die Fehlermeldungen mit V=ss sind für mich aber nicht sonderlich aussagekräftig.

```
gluon/build/ar71xx-generic/openwrt/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/gcc-linaro-4.8-2014.04/gcc/emit-rtl.c:5914:1:
internal compiler error: Segmentation fault

Makefile:1058: recipe for target 'emit-rtl.o' failed
make[6]: *** [emit-rtl.o] Error 1
make[6]: *** Waiting for unfinished jobs....

Makefile:3892: recipe for target 'all-gcc' failed
make[5]: *** [all-gcc] Error 2
Makefile:71: recipe for target 'all' failed
make: *** [all] Error 2

```

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [25. Oktober 2019 um 10:12 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/14 "2019-10-25T10:12:38Z")

</div>

Ich kann dir gerne mein VBox Image zukommen lassen mit dem es ohne Probleme funktioniert.

Letztendlich ist das aber auch nur ein Debian 8.11 Netinstall + gluon build extras

```auto
apt-get install git subversion python build-essential gawk unzip wget time libcurses5-dev zlib1g-dev libssl-dev
```

---

<div class="post-metadata">

**Author:** ![kevinq](https://forum.freifunk.net/user_avatar/forum.freifunk.net/kevinq/32/1653_2.png) [@kevinq](https://forum.freifunk.net/u/kevinq)\
**Post date:** [25. Oktober 2019 um 11:37 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/15 "2019-10-25T11:37:38Z")

</div>

> E: Paket libcurses5-dev kann nicht gefunden werden.

Der Rest war schon installiert. Ich hatte jetzt beide male ein Ubuntu. Ich versuche es heute abend noch einmal auf einem unserer Gateways, das ist Debian 9.

---

<div class="post-metadata">

**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\
**Post date:** [25. Oktober 2019 um 11:50 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/16 "2019-10-25T11:50:26Z")

</div>

kann sein, dass das Paket libncurses5-dev heißt.

#Edit:  
Jo unter Ubuntu ist es libncurses5-dev

---

<div class="post-metadata">

**Author:** ![kevinq](https://forum.freifunk.net/user_avatar/forum.freifunk.net/kevinq/32/1653_2.png) [@kevinq](https://forum.freifunk.net/u/kevinq)\
**Post date:** [26. Oktober 2019 um 15:47 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/17 "2019-10-26T15:47:59Z")

</div>

auf dem Debian Server hat es nun scheinbar geklappt, satte 8h. Mein PC hat für die anderen Versionen nur 1,5h gebraucht.

---

<div class="post-metadata">

**Author:** ![Matze1](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/m/8797f3/32.png) [@Matze1](https://forum.freifunk.net/u/Matze1)\
**Post date:** [17. November 2019 um 15:28 UTC](https://forum.freifunk.net/t/firmware-update-auf-2019-ueber-2018/21332/18 "2019-11-17T15:28:07Z")

</div>

Also ich konnte problemlos von Gluon 2016.2.7.1 direkt auf 2018.2.1-733 updaten, über die Weboberfläche im Config-Mode per Sysupgrade, ohne die 2017er Version als Zwischenschritt. Ich habe dies auf einem 841er V9 und auf einem 1043er V4 durchgeführt.
