Das angekündigte »Zwischenupdate« als Vorbereitung auf Firmware 1.0 rollt durchs Netz.
Wie im alten Jahr angekündigt, updaten sich derzeit auch alle auf den Firmwarestand »stable« konfigurierten Freifunkknoten nach erfolgreicher »testing«-Phase über den Jahreswechsel — bzw. sollten sich mit der Veröffentlichung dieses Beitrags aktualisiert haben:
Um auf Nummer Sicher zu gehen, gibt es, quasi als Weihnachtsgeschenk, eine neue Version der 0.7.9er Firmware, die die letzten Patches der Gluon-v2016.2.7er-Reihe beinhaltet und somit als Brückenbauer u. a. für die CPE dienen kann.
Ein Problem können wir aber leider nicht per Firmwareupdate fixen:
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 273MBcan be used to do this.
Sprich, alle VMs benötigen eine größere virtuelle Festplatte für eine Version jenseits Firmware 0.7.9 (Gluon v2016.2), und dieser Schritt muß lokal und manuell vollzogen werden! (Inwieweit dies Hardware-Offloader betrifft, also z. B. einen Futro, ist gerade nicht ganz klar; das testen wir derzeit noch, gehen aber von vergleichbaren Problemen aus!)
Da wir in 1-2 Wochen Firmware 1.0 ausrollen wollen, hiermit also der dringende Aufruf an alle, die im Kreis GT, der Müritz-Region oder der Feldberger Seenlandschaft virtuelle oder physische Offloader auf x86-Basis betreiben, kurzfristig selbst kontrolliert ein Upgrade auf eine »experimental«-Version von Firmware 1.0 vorzunehmen; im Falle von VMs definitiv erst nach einem Shutdown & qemu-img-resize-Aufruf.
Vielleicht ist es Zufall, aber mein Knoten ist seit ein paar Stunden offline (SSID). Soll ich etwas nachschauen bevor ich reboote?
SSH geht. Ping vom Knoten nach nach IP geht. Namensauflösung (nslookup) geht nicht (no servers could be reached).
Nützt eher nix, die Frage ist ja, warum kein Server erreichbar war (und welche überhaupt kommuniziert würden). Mal gucken, IIRC gibt’s 'n Watchdog-Paket, welches nach n Stunden ohne Verbindung rebooten kann …
Nächstes mal bitte
cat /tmp/gluon/wan-dnsmasq/resolv.conf
machen und gucken, welche DNS-Server vom DHCP-Server des WANs kamen und ob diese erreichbar sind.Nachdem mein Knoten wieder offline und ein nslookup wieder fehlgeschlagen ist, habe ich mehr Informationen.
Und ein nslookup über meine Haupt FritzBox:
Verstehe ich leider nicht
Warum gehen beide Nameserver, aber nicht die Abfrage ohne Angabe des NS?
/etc/init.d/network restart
hat leider nichct ausgereicht. Ich musste rebooten.Habe gerade mal bei meinem 0.7 er Knoten geschaut. Der hat einen lokalen DNS Server
scheinbar hängt sich der DNSMasq Dienst dann auf. Kannst ja beim nächsten mal einmal prüfen.
bei nem 1.x er Knoten sieht das ganze bei mir so aus: