Probleme mit manueller Aktualisierung

moin, moin.

mit der Version “0.7.4~118_wrz / gluon-gt-ef15c21” habe ich mit einigen Geräten und der manuellen Aktualisierung mit sysupgrade Probleme. Entweder sie kommen danach nicht mehr online (WR841N V.10) oder “hängen sich ab” (gerade aktuell: http://map.4830.org/mueritz/#!v:m;n:e894f6781ac8).
Im letzten Fall reicht Strom aus/an erstmal aus … bis zum nächten mal.
Ein V.10-Gerät ließ sich mit Configmodus und [Weiter] + [Speichern und Neustart] zum Arbeiten bewegen … an die anderen kann ich nachher ran.

Manuell deswegen, weil über ipv6 zurzeit keine “Mirrors” erreichbar sind. :frowning:
Wo könnte der Wurm drin sein?

Gruß
Matthias

Sind das nur v10er, die vorher 0.7.5~29 drauf hatten?

Da es beim Autoupdater klappt und bislang die Meldungen von Problemen mit manuellem Upgrade sich auf die 841 fokussieren, vermute ich, daß es da im RAM knapp wird und der Reboot nicht mehr sauber klappt. Wobei »sysupgrade« ja auch einige Prozesse killt vor dem Flash; aber es läuft ja noch die SSH-Session, als Unterschied zum Autoupdate-Prozeß.

Wichtig ist in erster Linie IMHO, daß beim automatischen Update alles glatt geht. Ich kann »mtr« wieder rauswerfen aus dem Image, sodaß das kleiner wird; anfangs klappte es IIRC ja auch und »mtr« nahm ich nur rein, um IPv6 besser debuggen zu können.

Was v6 angeht muß ich gucken, wer wieder wo die Route verloren hat :frowning:

Ja genau … die mit 0.7.5~29

der Knoten bei der Feuerwehr sogar mit partiellen Update … neue Teile von 0.7.4~118 und Anzeige von 0.7.5~29
8) … falls das richtig ist --> ff_offline_60e327c79f28

Da’s Euch weniger betrifft (SSID-Change im Kreis GT), bitte mal manuelles Updating stoppen. Backe nacher eine neue FW ohne mtr, dann mit der probieren. Wenn Kuddelmuddel entsteht - was dann wohl Grund für nicht wiederkommende Knoten nach sysupgrade -, ist was massiv karpott :frowning:

Witzig, meine MR3020 zickten nicht, die sind ähnlich mau ausgestattet wie 841.

Sorry for the hassle; werde nachher eig. v10 probieren.

Neuer Firmwarebuild (experimental: 0.7.5~6) steht bereit, bitte zum manuellen Aktualisieren von 0.7.5~29-841v10-Knoten diesen Build probieren — »mtr« ist nicht mehr mit an Bord, damit das Image insgesamt etwas kleiner/der freie Speicher etwas größer.

EDIT: Okay, also hier hat das mit manuellem »Downgrade« von 0.7.5~29 auf 0.7.5~6 gerade problemlos funktioniert:

Fragt sich halt, wie das Verhältnis normalerweise ist, sprich: hattet Ihr 100% Ausfälle bei manuellem Upgrade eines 841v10 von 0.7.5~29 weg?

Danke, jetzt geht’s wieder ohne Aufregung und Herzflattern … ob der Knoten das Update überlebt hat. :wink:

Bei einem von 8 aktualisierten 841v10er-Knoten gab keine Probleme.
Den 9. hatte ich mit Schalter -n selbst ins Nirvana geschickt. Keine Ahnung wo meine Gedanken da waren. :frowning:

Oh, bei 30+% Fehlerquote bitte nächstes Mal lauter/klarer auf den Umstand verweisen. Sorry for that …

Lessons learned: auch wenn noch Luft zu sein scheint, mindestens die 841 sind pingelig, was die Imagegrößen angeht :frowning:

Zu früh gefreut … heute noch ein 841V.10-Gerät mit 0.7.5~6 manuell versenkt. :frowning:
Strom aus/an brachte leider nix.

Kannst Du das Build größer als 0.7.5~29 setzen? Die aktuelle Nummerierung (0.7.5~6) ist für eine automatischen Aktualisierung zu klein. Ich gehe für das Update auch gerne von stable zeitweise zu experimentell.

Zu früh gefreut … heute noch ein 841V.10-Gerät mit 0.7.5~6 manuell versenkt. :frowning:
Strom aus/an brachte leider nix.

Hrmpft. Wenn ich nur wüßte, woran’s liegt … :frowning:

Kannst Du das Build größer als 0.7.5~29 setzen? Die aktuelle Nummerierung (0.7.5~6) ist für eine automatischen Aktualisierung zu klein. Ich gehe für das Update auch gerne von stable zeitweise zu experimentell.

Grobe Richtung kommendes Wochenende ist 0.7.5-0 (-0 ist größer ~xxx) geplant, laß’ die laufenden Knoten auf bis dahin 0.7.5~29, oder brennt was?

Ab 0.7.5~11 sind einige Feature-Backports von Freifunk Celle mit drin, u. a. Uplink per WLAN statt Kabel, außerdem wird man bestimmte »Profile« wählen können (in der Art »gut-ap-ml-ch1« für einen AP auf Kanal 1 mit Mesh-on-LAN in Gütersloh, wo wir normal auf Kanal 9 sind) — damit können größere Standorte sinnvoller konfiguriert werden und das ganze bleibt updatefest.

Technisch machbar wäre es, 0.7.5~6 als 0.7.5~30 neu zu bauen, kost’ ca. 30 Minuten für den geänderten Jenkins-Job und baut ca. 3h — wie groß ist Dein Druck an der Stelle, sprich: lohnt das den Aufwand?

MfG,
-kai

Nein, es ist nicht so dringend.
Ich finde das “ff_offline_xxx”-Feature genial für Bereiche, die lahm angebunden sind, öfters sich abhängen … deswegen wollte ich diese Firmware dort schneller einsetzen. So bekomme ich jetzt von dort schneller Rückmeldung, wenn “Freifunk” mal nicht geht.

Danke für Deinen Einsatz … muss ich mal so ohne Einschränkungen sagen. :wink:

Danke.

Hallo Kai,
jetzt ist der erste 841er nach 0.7.5~6 ‘manuell’ bis zur Reboot-Anzeige ohne Probleme durch … sonst war irgendwie/-wo/-wann vorher schluss.

:smile:

root@17194-Tressow-d208:/tmp# sysupgrade -v gluon-ffgt-0.7.5~72-tp-link-tl-wr841n-nd-v10-sysupgrade.bin
Saving config files…
etc/config/alfred
etc/config/autoupdater
etc/config/batman-adv
etc/config/dhcp
etc/config/dropbear
etc/config/fastd
etc/config/firewall
etc/config/gluon-node-info
etc/config/gluon-setup-mode
etc/config/gluon-simple-tc
etc/config/gluon-wan-dnsmasq
etc/config/luci
etc/config/network
etc/config/siteselect
etc/config/system
etc/config/ucitrack
etc/config/uhttpd
etc/config/wireless
etc/crontabs/root
etc/dropbear/authorized_keys
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
etc/group
etc/hosts
etc/inittab
etc/opkg.conf
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/sysctl.conf
lib/gluon/core/sysconfig/.keep
lib/gluon/core/sysconfig/gluon_version
lib/gluon/core/sysconfig/lan_ifname
lib/gluon/core/sysconfig/primary_mac
lib/gluon/core/sysconfig/setup_ifname
lib/gluon/core/sysconfig/wan_ifname
killall: watchdog: no process killed
Sending TERM to remaining processes … logd haveged netifd crond gluon-crond gluon-radvd uhttpd dnsmasq ntpd alfred batadv-vis dnsmasq respondd ubusd askfirst
Sending KILL to remaining processes … askfirst
Switching to ramdisk…
Performing system upgrade…
Unlocking firmware …

Writing from to firmware …
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware…TRX header not found
Error fixing up TRX header
Upgrade completed
Rebooting system…

… was mich nun aber stutzig macht, ist die das automatische Einschalten von Mesh-VPN.
Das war bei diesem Gerät definitiv aus und m.E. auch im Config-Modus nicht [X] gemarkert, da dies kein LAN sehen sollte.
Bug oder Feature?

VPN status

IPv4 not configured
IPv6 not configured
fastd running for 297.971 seconds

There are 6 peers configured, of which 0 are connected:
mesh_vpn_backbone_peer_gw06: not connected
mesh_vpn_backbone_peer_gw04: not connected
mesh_vpn_backbone_peer_gw03: not connected
mesh_vpn_backbone_peer_gw02: not connected
mesh_vpn_backbone_peer_gw01: not connected
mesh_vpn_backbone_peer_gw05: not connected

Das war bei diesem Gerät definitiv aus und m.E. auch im Config-Modus nicht [X] gemarkert, da dies kein LAN sehen sollte.

Bug. Wobei ich nicht wüßte, warum das erst jetzt auftreten sollte. Sicher, daß das nicht schon immer so war? Lies: hast Du v9er-Knoten mit der Einstellung betrieben und da blieb das erhalten?

BTW, ich nutze einen v10 als Testobjekt und hatte mit der aktuellen (also auf dem älteren OpenWRT basierenden) Firmware keinen einzigen Hänger beim manuellen sysupgrade. Nur der erste Flash ging gründlich in die Hose, von 0.7.5~29 auf die 0.7.4-mit-v10 — da habe ich das erste Mal tftp zur wiederbeleben benutzt …

0.7.3~1 (Mesh-VPN aus) -> Autoupdate auf 0.7.4~118 (Mesh-VPN weiterhin aus) -> manuelles Upgrade auf 0.7.5~72 (Mesh-VPN an).

Okay, Problem gefunde (Flag wird bei Aktualisierung der site.conf gelöscht). Fixing …

1 Like

Mist … da warst du schneller, als ich mit testen:

Flashen des 841er mit 0.7.4~68 im Config-Modus ohne Übernahme alter Daten
’Mesh over VPN’ deaktiviert
’autoupdate’ eingeschaltet

VPN status

IPv4 configured
IPv6 not configured
fastd not running


automatisches update nach reboot auf 0.7.4~118 (stable)

VPN status

IPv4 configured
IPv6 not configured
fastd not running


ssh: Umstellung auf experimental
ssh: Aufruf von ‘autoupdater’ —> 0.7.5~72

VPN status

IPv4 configured via br-wan
IPv6 not configured
fastd running for 177.770 seconds

There are 6 peers configured, of which 1 are connected:
mesh_vpn_backbone_peer_gw06: connected for 117.790 seconds
mesh_vpn_backbone_peer_gw04: not connected
mesh_vpn_backbone_peer_gw03: not connected
mesh_vpn_backbone_peer_gw02: not connected
mesh_vpn_backbone_peer_gw01: not connected
mesh_vpn_backbone_peer_gw05: not connected

Yepp. Ich löschte /etc/config/fastd und baute es neu, da durch eine Racecondition zwar die site.conf geändert wurde, aber die fastd-Konfiguration die alte (die aus der site.conf im Image) blieb. Dummerweise wurde Mesh-VPN ja/nein dort gespeichert …

Ich habe das Pferd jetzt vom Kopf her aufgezäumt, die Routinen, die mit site.conf arbeiten, sind nun ›»site-select«-aware‹, heißt, die initiale Racecondition müßte vom Tisch sein. Bringt einige Vereinfachungen mit sich dieser Ansatz, jetzt muß das nur noch bauen … (Der Gluon-Bauprozeß versucht zu verifizieren, ob die site.conf gültiger Lua-Code ist; mit der Routine im Image (gut), leider mit einem abgespeckten Lua auf dem Build-Host (ganz schlecht).)

Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.