Das wäre dann fast schon die nächste Frage: Bei den Leuten, bei denen die Build corrupted herausfallen, was passiert wenn die gleiche Maschine nicht 2018.1 oder 2018.2, sondern vom master baut? Da liegt dann ja auch wieder ein anderes Openwrt drin.
(Ich kann hier lediglich Builds mit Ubuntu16.04LTS anbieten. Falls jemand images zum Testen haben möchte, kann ich sie anführen. Leider keine Geräte hier in den Communities davon bislang.)
Sowohl Gluon v2018.2, als auch v2019.1 verwenden OpenWrt 18.06, das Verhalten ist also absehbar gleich.
Bei uns kam das kaputte Image aus einer Hetzner-Cloud-VM (CX51). Könnte man recht leicht reproduzieren. Ich glaube, das ist Ubuntu 18.04.
unser v2018.2.2 build ließ sich gerade erfolgreich auf eine frische 4040 flashen… der build wurde auf Debian Stretch gemacht. 
es war aber kein clean build, einen solchen hole ich soeben nach zum nachprüfen.
Es kamen bei mir aber Fehlermeldungen in openwrt/logs/package/boot/uboot-fritz4040/fritz4040/compile.txt
1-29-6946ebba/.pkgdir/u-boot-fritz4040 >/dev/null 2>/dev/null
Makefile:55: recipe for target 'install-bin-u-boot-fritz4040' failed
make[5]: [install-bin-u-boot-fritz4040] Error 1 (ignored)
auch mit einem clean build war das flashen im 1. Versuch erfolgreich, ich kann die Probleme also nicht nachvollziehen, „could not reproduce“
Sowohl beim Freifunk Saar als auch beim Freifunk Münster geht das Image mit Gluon 2018.2, und es geht nicht mehr mit Gluon 2018.2.1. Das ist also ziemlich sicher eine Regression zwischen diesen beiden Versionen.
dem entgegen steht, dass es bei uns (Freifunk Altdorf) funktioniert.
Habt ihr den build mal auf einem komplett anderen Server from scratch neu gemacht?
Habt ihr nach Fehlermeldung im Build Log gesucht? (bauen mit BUILD_LOG=1 und V=s)
EDIT: und es wäre hilfreich, wenn wir diese diskussion nicht hier sondern faktenbasiert im zugehörigen Gluon Issue führen 
Das steht doch schon im Issue, dass der Build geht wenn man ihn „anders“ macht. Bisher dachten wir das sei Stretch vs Buster. Neue Infos bitte in den Issue. Da gibts übrigens auch ein Docker-Image mit dem man den Fehler reproduzieren kann.
Habt ihr nach Fehlermeldung im Build Log gesucht? (bauen mit BUILD_LOG=1 und V=s)
Das wären wohl viele viele Megabytes an Logs, da irgendwas zu finden dürfte etwa unmöglich sein.
Man muss erwähnen, dass es verschiedene Buildumgebungen waren. Das ist uns erst letztens aufgefallen. Unser Buildserver lief zwischendurch mal nicht.
Ist das ernst gemeint? Natürlich liest man das nicht manuell durch, sondern sucht danach, siehe Troubleshooting · freifunk-gluon/gluon Wiki · GitHub
Wer keine Logs erzeugen & lesen will, braucht keine Fehler melden.
Wir können uns jetzt um die Definnition von „viele viele“ streiten.
Ich will sagen: Du übertreibst.
Konkret sind es rund 5MB pro Target (=mehrere Devices), unkomprimiert.
(rund 35MB wenn man sämtliche Targets baut und zudem noch einen Haufen zusätzliche Packages einbaut, siehe z.B. Freifunk Düsseldorf Flingern Firmware Seite )
Ich weiss nicht, was dagegen spricht, das Buildlog sowieso mitlaufen zu lassen.
Verglichen mit den Images kostet es es fast nichts.
Das Ding ist, der Build schlägt ja nicht fehl. Nur das Resultat ist kaputt. Offensichtliche „Error“ Einträge wird es also kaum geben.
Die Wiki-Seite passt also nicht ganz.
Aber gut, ich kann die Variablen beim nächsten Build ja mal setzen und euch den Log irgendwo hin tun – wenn jemand gute Ideen hat, wonach man da suchen könne, möge er/sie das tun. Mit Ubuntu 18.04 oder so kann ich jedoch nicht dienen, wir nutzen Stretch. Und eigentlich wollte ich demnächst auf Buster aktualisieren.
Ich habe die Praktikabilität in Frage gestellt, das ist was anderes. Dieser Kommentar war völlig unangemessen.
Ich befürchte mal dass es die üblichen stdout/stderr-Limits der CI sprengen wird, sodass man im Webfrontend gar nichts mehr vom Build sieht. Oder man packt es in eine Datei, dann sieht man ebenda aber auch nicht mehr. Daher spricht im Regelbetrieb da m.E. schon etwas gegen. Für einen Debug-Build jedoch sollte es passen.
Das FB4040-Image-Problem ist wohl geklärt.
Da hat jemand bei OpenWRT schlicht ein ziemliches Vertrauen in die Leistungsfähigkeit von Shells der Buildumgebungen…
printf "%0.s\0" {1..65536} >> $UBOOT_FRITZ"
Je nach bash-version kann das klappen, muss aber nicht… 65k Parameter/Argumente übergeben…
Zeile 95 FritzBox-4040-UBOOT/fritz/fritzcreator.sh at master · chunkeey/FritzBox-4040-UBOOT · GitHub
Hat sich dieses Script geändert zwischen Gluon 2018.2 und 2018.2.1?
Der Teil nicht.
Es hängt halt unter anderem davon ab wie viel Platz als Environment vom Kernel bekommst. Daher kann es nach Kernelupdate plötzlich anders aussehen. Und da hilft dann auch kein Docker gegen, weil ja auch dort der Wirtskernel durchschlägt.
Das Script ist so wie es ist wirklich unschön und gehört gefixt.
Bitte testet den Branch mit einem möglichen Fix:
https://github.com/freifunk-gluon/gluon/tree/wip/fritz4040
und, wer testet schon, wie sieht’s aus?
Ich habe derzeit keine 4040 zur Hand, bekomme die Tage vermutlich wieder eine. Dann werde ich testen.
Leider mit aktuellem Build 2018.2.2 immer noch gleiches Problem.
Das ist ein Problem des Buildsystems. Bitte auf Ubuntu16.04LTS (mit bash) bauen. Mit einem Standard-Kernel. Das funktioniert reproduzierbar.