Paul Spooren de24245e08 build: read full blocks from pipes in image headers ... Many image recipes write header fields with printf or echo piped into dd bs=N count=1 conv=sync. Bash writes the output of both line buffered, so a field holding a 0x0a byte reaches the pipe in two writes. If dd reads between them, it gets a short block, pads it with zeros due to conv=sync and stops due to count=1, so the rest of the field is lost. This depends on the scheduling of the builder, and the rebuilder has caught it in a ZNET header of the Zyxel WSM20: -00000000: 5a4e 4554 80cd 7900 530a 4132 530a 0000 ZNET..y.S.A2S... +00000000: 5a4e 4554 80cd 7900 530a 4132 530a 4132 ZNET..y.S.A2S.A2 Fields holding sizes, CRCs or MD5 sums hit this at random, e.g. in elx-header, iodata-mstc-header2, seil-header or nec-fw. Text fields only hit it if they contain a newline, but they use the same pattern. dongwon-header had the same problem and no longer uses dd since commit f6ef30a35e ("ath79: dongwon-header: don't read the CRC from a pipe with dd"). Pass iflag=fullblock to every dd that reads such a pipe with count= or conv=sync, so dd reads until the block is full or the input ends. dd with bs=1 is left alone, as a read always returns a full block there. iflag=fullblock is supported by GNU and uutils dd, like oflag=seek_bytes already used in ramips. Build dd in tools/coreutils as well, so hosts other than Linux get GNU dd next to the GNU date and stat the images already need. Link: https://github.com/openwrt/openwrt/pull/25897 Signed-off-by: Paul Spooren <mail@aparcar.org>		2026-10-14 18:40:19 +02:00
..
patches	…
Makefile	build: read full blocks from pipes in image headers	2026-10-14 18:40:19 +02:00