Firmware Update auf 2019 über 2018

Vereine Freifunk Nord
1

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

2

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

3

Klar so war das auch nicht gemeint

4

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.

5

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.

6

Ja genau.

7

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

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

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.

8

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.

1 „Gefällt mir“
9

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.

10

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

11

Ist drin :slight_smile:

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

1 „Gefällt mir“
12

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 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.

1 „Gefällt mir“
13

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) 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
14

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

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

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.

16

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

#Edit:
Jo unter Ubuntu ist es libncurses5-dev

17

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

18

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.