Meine erste Vermutung wäre das du deine site.mk optimieren musst weil aktuell die Images zu groß werden und dann bei manchen Geräten der Flash nicht ausreicht.
Dein Build bricht dann ab wenn ein Image nicht generiert werden konnte weil es größer als maximal erlaubt ist.
Manche von den Geräten haben weniger als 7M nutzbaren Flash aufgrund von einer ungünstigen Partitionierung.
Kannst dir ja mal das folgende Skript anschauen (ggf. musst du einen historischen Commit bzw. den Stand aus dem v2022.1.x Branch nehmen (falls sich das unterscheidet)):
Danke für die Tips! Platte voll kann ich bei >450 GB freiem Platz ausschließen, aber der Hinweis mit den Paketen könnte stimmen. Ich teste das mal und gebe euch dann ein Feedback.
Sicher? Der Versuch des Gluon-Builds auf einer unserer beefigeren Kisten schlug fehl, weil die inodes nicht ausreichten (das System war nicht als Buildhost, sondern Hypervisor, aufgesetzt, das ext4 entsprechend mit »–largefiles« angelegt); Gluon, genauer OpenWrt, produziert Myriaden von Dateien. df -i /var/lib/jenkins/workspace/ffkbu-multihood-stable-wireguard-gluon2022.1 sollte Klarheit bringen
08:51:27 WARNING: Image file /var/lib/jenkins/workspace/ffkbu-multihood-stable-wireguard-gluon2022.1/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp/openwrt-ath79-generic-dlink_dir-825-b1-squashfs-factory.bin is too big: 6291460 > 6291456
08:51:29 ERROR: target/linux failed to build.
08:51:29 make -r world: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
08:51:29 make[1]: *** [/var/lib/jenkins/workspace/ffkbu-multihood-stable-wireguard-gluon2022.1/openwrt/include/toplevel.mk:230: world] Error 1
08:51:29 make[1]: Leaving directory '/var/lib/jenkins/workspace/ffkbu-multihood-stable-wireguard-gluon2022.1/openwrt'
08:51:29 make: *** [Makefile:195: all] Error 2
08:51:29 Build step 'Execute shell' marked build as failure
08:51:29 [WS-CLEANUP] Deleting project workspace...
08:51:29 [WS-CLEANUP] Skipped based on build state FAILURE
08:51:29 Finished: FAILURE
Dies passiert aber z.B. beim x86 Build nicht. Also doch zu viele Module? Ich habe jetzt schon ein paar entfernt, aber scheinbar reicht es noch nicht?!
Edit: Egal, wieviele Module ich entferne, es ist immer der dir-825-b1 welcher rumzickt. Das komische dabei ist, dass das bis vor kurzem noch nicht so passiert ist. Gab es eventuell Änderungen am offiziellen Gluon-Branch oder am gluon-wireguard repo?
Nimm’ mal wireless-encryption-wpa3 raus und bau nur ath79_generic, ob’s dann reicht. Bzw. nimm SSL-Gedöns in GLUON_d-link-dir-825-rev-b1_SITE_PACKAGES raus, fehlen ja nur noch 4 Byte
Klar, Gluon ist auf eine neuere OpenWrt Version gewechselt (22.03.05), da wird Gluon dann insgesamt auch etwas größer (kommt aufs Target an). Es wird ja aktiv am Betriebssystem gearbeitet
In wenigen Monaten kommt OpenWrt 23 und es dürfte nochmal ein Stück größer werden durch Kernel 5.15, denke ich.
Partiell off-topic, aber: wieso eigentlich? Läßt sich da nicht mehr modularisieren oder nötigenfalls raus-#ifdef-en? Letztlich heißt mehr Code ja auch mehr Taktzyklen für dessen Ausführung, nicht das, was man sich für Embedded-Systeme eigentlich wünscht
