Entschuldigung, auf dem Server ist ein unerwarteter Fehler aufgetreten.
Failed to execute dispatcher target for entry '/wizard'.
The called action terminated with an exception:
...lib/gluon/config-mode/wizard/0010-ffgt-geolocate.lua:1: module 'luci.cbi' not found:
no field package.preload['luci.cbi']
no file './luci/cbi.lua'
no file '/usr/share/lua/luci/cbi.lua'
no file '/usr/share/lua/luci/cbi/init.lua'
no file '/usr/lib/lua/luci/cbi.lua'
no file '/usr/lib/lua/luci/cbi/init.lua'
no file './luci/cbi.so'
no file '/usr/lib/lua/luci/cbi.so'
no file '/usr/lib/lua/loadall.so'
no file './luci.so'
no file '/usr/lib/lua/luci.so'
no file '/usr/lib/lua/loadall.so'
den 841er (33378-freifunk-e894f67835d0) habe ich bewusst auf Rawhide stehen, da er nur noch ein reiner Testknoten ist. Habe ihn gestern getestet per Laptop am LAN Port, sah auf den ersten Blick gut aus. Werde die Tage immer mal wieder probieren. @wusel Danke für deine Arbeit. War ja im letzter Zeit recht ruhig, aber eher aus dem Grunde weil fast immer alles lief. Super Arbeit.
Danke für die Info — habe ich “leider” aber auch bei der Installation auf meiner Fritz!Box 4020 sehen müssen (und dabei relativ gut debuggen und beheben können — der aktuelle Web-Krempel scheint kein wirres Caching mehr zu machen, yeah!) …
Yepp, aller Anfang ist schwer — ein Grund, warum wir so schleppend “der Karavane” folgen (die aktuelle Stable-FW basiert auf einer rund 1 Jahr alten Gluon-Version) ist primär, daß wir uns seinerzeit gewissen Ziele gesetzt haben/Design-Vorgaben von Gluon für unpraktisch hielten (und halten). Heißt im Umkehrschluß, daß wir Nacharbeiten müssen. Und jedes Gluon-Release hält, teils auch bedingt durch Änderungen “Upstream”, d. h. bei OpenWRT/LEDE, “Überaschungen” für uns bereit. Da hier kein OpenWRT-/LEDE-Entwickler sitzt, und die Dokumentation teilweise den Eindruck erweckt, von Insidern für Insider geschrieben worden zu sein, ist das immer eine Sache voller Blut, Schweiß und Tränen — man kann das teilweise den Commit-Nachrichten entnehmen
That said, 1.0.0~34 blendet auch schon wieder unserere Karte ein — aber jetzt sind wieder größere Änderungen notwendig, um den (IMHO vorhandenen) Komfort der 0.7er FW bei der Ersteinrichtung zu kopieren.
In dem Fall: Super! Das hilft prinzipiell viel — aber es bedeutet eben auch, daß das Risiko, daß solch ein Knoten “gebrickt” wird, hoch ist: “rawhide” wird gebaut und auf den Firmware-Server geschoben — niemand weiß vorher, was die FW macht, sie hat vorher nie einen Knoten gesehen. Ich hab’ jetzt den Build-Umfang wieder verkleinert (statt “ziemlich alles” baut derzeit “nur” x86 und ar71xx-generic, statt ~35 Minuten ist der Build jetzt in ~11 Minuten durch), aber in ar71xx-generic sind halt alle Atheros-Kisten mit mehr als 4 MB Flash.
Letztlich kann ich nicht mehr tun als zu warnen “rawhide” ist “frisch vom Knochen” sozusagen, das im Autoupdater zu haben, kann Eure Geräte, auch irreparabel, zum Türstopper machen, bevor irgendwer auch nur die Chance hatte, da reinzugucken. Wer das mit diesem Wissen dennoch tut: (ernstlich) vielen Dank! Nur sagt nicht, es hätte niemand gewarnt
Dient sowieso nur als Türstopper . Denn der C7 wird bei mir wird auch nur noch als Offloader eingesetzt. Habe Unifi APs installiert, da mit meinen eigenen WLAN mit drei verschiedenen APs Probleme hatte.
Aus gegebenem Anlaßnochmal der Hinweis, daß »rawhide« mit Vorsicht zu genießen ist.
Bitte keinesfalls auf Knoten, die per Mesh-on-LAN/WAN mit anderen Knoten verbunden sind, ausprobieren. Stand jetzt hat »rawhide« noch den Bug, daß es die Auswahl, welche Netzkonfiguration der Knoten verwenden soll, von der 0.7er Firmware – die einen FFGT-Eigenbau dafür verwendet – in die 1.0er Firmware – die das neue »Multidomain«-Feature von Gluon v2018.1 nutzen wird –nicht überträgt.
Gluon v2018.1 setzt in dem Fall – keine Infomation (in Gluon-v2018.1-Notation) vorhanden – eine Defaultkonfiguration, in unserem Falle FFGT-alt (bis auf Adressen und Anzahl der Gateways identisch mit FFGT-neu).
Wenn nun also ein Knoten mit Müritz-Konfiguration mit einem anderen Knoten auf Müritz-Konfiguration per Kabel verbunden ist und auf ein aktuelles »rawhide« upgegraded wird, haben wir einen Knoten mit FFGT- und einen mit Müritz-Netz, die per Kabel verbunden sind und damit beide Meshes verbinden.
Gluon v2018.1 bietet Möglichkeiten, daß solche versehentliche Verbindungen zukünftig verhindert werden (VXLAN als Trenner), das können wir aber nicht direkt aktivieren, denn dann würden alle Kabelmeshes mindestens zeitweise zusammenbrechen … Daher auch der bisherige Plan, daß ein sysupgrade (via Autoupdate) nicht angeboten wird; die funktionalen Änderungen zwischen FW 0.7 und 1.0 sind recht groß.
Könnt Ihr bei sowas bitte mit CTRL-U (oder wie auch immer, je nach OS/Browser) den Quelltext laden und davon Screenshot oder Fehlermeldung per cut & waste posten? Da steht nämlich die Zeilennummer, in der, und i. d. R. auch ein Grund, warum der Fehler entstanden ist. Danke!
Hmm, komisch mein 841er hängt sich ca. alle 10-15 Minuten auf sobald auf dem LAN Port nen Raspberry dran hängt.
Gibt es irgendwo Logs die man vor dem Reboot abfangen kann?
Vom Bauchgefühl her würde ich sagen Strommangel. Hängt per POE am Netz. Habe leider gerade kein Netzteil zum testen. Morgen mal eins vom anderen Standort mit bringen.
Es steht derzeit auf der Kippe, ob wir für den 841 eine v1.0 rausbringen oder nicht; Flash ist zu klein, und RAM auch kritisch. Danke für die Info, das klingt eher nach “nicht” …
Wobei …
cron? Da sollte doch micron als Low-Memory-Footprint-Ersatz laufen?
Mal gucken, warum da zwei crons laufen, danke für den Hint!
Auf der WBS210 v1.2 läuft zurzeit ‚gluon-ffggrz-0.9.1-exp20170615-tp-link-wbs210-v1.20.bin‘
und ich möchte gern ‚gluon-4830-1.0.0~34-tp-link-wbs210-v1.20.bin‘ ohne Konfigurationsübernahme. Die Checkbox im zweiten Bild war beim Absenden leer …
Nö … ich hatte bisher in der Vergangenheit keine Probleme auch mal die Factory zu verwenden - vorallem beim Switchen zwischen unterschiedlichen Communities bzw. LEDE/OpenWRT und zurück und bei Wiederbelebungsversuchen. Nun war das hier wirklich der Fehler.
Jau, das sieht nach Tipp-/Syntaxfehler in Zeile 92 der 0400-geo-location.lua aus. Ja, hatte ich schon gefixt, nur noch nicht eingecheckt — es fehlen eine Klammer und ein Hochkomma: