TL;DR What would be a workable plan to reconcile mfgr_specific-board-name at image-generation time with mfgr,specific-board-name at run time?
With the apparent tree-wide changes in progress to canonicalize board naming of TARGET_DEVICES to mfgr_specific-board-name, there becomes a disconnect between the board name at image generation and run time. This results in a "disconnect" between what is used in the tar file as the directory name and CONTROL contents by `scripts/sysupgrade-tar.sh` mkdir -p "${tmpdir}/sysupgrade-${board}" echo "BOARD=${board}" > "${tmpdir}/sysupgrade-${board}/CONTROL" [ -z "${rootfs}" ] || cp "${rootfs}" "${tmpdir}/sysupgrade-${board}/root" [ -z "${kernel}" ] || cp "${kernel}" "${tmpdir}/sysupgrade-${board}/kernel" where ${board} is, for example, `glinet_gl-ar750s-nand` and what is checked (or should be checked) by nand_do_platform_check() in `package/base-files/files/lib/upgrade/nand.sh` tar xf $tar_file sysupgrade-$board_name/CONTROL where $(board_name) returns the comma-delimited form, `glinet,gl-ar750s-nand` (The contents of CONTROL are not checked at this time, but would suffer from the same mismatch issues.) The metadata commonly attached to the sysupgrade bundle often uses the run-time, comma-delimited form in "supported_devices", yet the build-time, underscore-delimited form in "board". At this time, there appear to be very few boards that actually call nand_do_platform_check(). Many still have board names that don't appear to be what I believe is canonical: * layerscape * pistachio * imx6 * ar71xx While most either explicitly set the board name in the call or have comma-less board names, `sysupgrade-img,pistachio-marduk` makes a global, `tr ',' '_'` an unacceptable work-around. I can see a few paths forward on this, but don't have the project history and insight to properly evaluate them. Of the options out there that I've considered, transitioning scripts/sysupgrade-tar to use the run-time, comma-delimited form that is returned by $(board_name) seems the cleanest, at least to me. I can work around this for now with a device-specific workaround, but it seems to be something that should be considered going forward, perhaps before v19 is "cut" to reduce future upgrade issues. Jeff
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel