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>
Paul Spooren
de24245e08