Petr Novák <pe...@me.com> [2020-01-01 21:11:30]: > But how come the workaround was to use an older libubox and ubus - was there > any new check which was not there before?
I don't have definitive answer, as I would need RPi-4 (or any other real hardware with Cortex-A72 core) to find the actual bit in the libubox which caused this change in the behavior, but here is a part of the commit description[1] which might help answering that: It seems like the recent fixes in the libubox library, particulary in the jshn sub-component (which empowers json_dump used in the shell script executed by the child process) made the execution somehow faster, thus exposing this racy behaviour in the validate_firmware_image_call at least on RPi-4 (Cortex-A72) target. As I was unable to trigger this issue even in the QEMU/Cortex-A72 I assume, that it was simply some kind of race, needed specific timing, provided preciously only by that RPi-4 hardware. > actually, it may be visible on the HDMI output - not as flexible as a serial > console (not so easy to copy paste) but that would allow to see what is > going on better than the ssh I was using up to now. I've prepared a commit[2] which is going to output that error into the syslog instead, together with more verbose error message[3] so it's easier to track it down next time. 1. https://gitlab.com/ynezz/openwrt-procd/commit/8904b34203055bdc619cd95581a19b307b91e362 2. https://gitlab.com/ynezz/openwrt-procd/commit/e87ccf2b7ae17faa2dfda470484279c1bfb51328 3. https://gitlab.com/ynezz/openwrt-procd/commit/9e45a44859e81cc84dbc39c42c9dacef30b96429 -- ynezz _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
