staging/pepe2k/include/image.mk, branch v19.07.7

build/json: add filesystem information

2020-12-17T21:16:36Z

Some images are created using different filesystems, most popular squashfs and ext4. To allow downstream projects to distinguesh between those, add the `filesystem` information to created json files. Signed-off-by: Paul Spooren (cherry picked from commit bc0ffff36a0bd8043e958913f574cb8d2a79e93d)

build: store default/device packages in JSON

2020-07-13T20:24:30Z

With this commit the `profiles.json` contain both the target specific `default_packages` as well as the device specific `device_packages` as a array of strings. This information is required for downstream projects like the various web-based interactive firmware generators. Signed-off-by: Daniel Golle Signed-off-by: Paul Spooren (cherry picked from commit 263f7e5bbd119ebed1f514c16f659a2e2a2b132c)

build: refactor JSON info files to `profiles.json`

2020-06-30T20:12:58Z

JSON info files contain machine readable information of built profiles and resulting images. These files were added in commit 881ed09ee6e2 ("build: create JSON files containing image info"). They are useful for firmware wizards and script checking for reproducibility. Currently all JSON files are stored next to the built images, resulting in up to 168 individual files for the ath79/generic target. This patch refactors the JSON creation to store individual per image (not per profile) files in $(BUILD_DIR)/json_info_files and create an single overview file called `profiles.json` in the target directory. Storing per image files and not per profile solves the problem of parallel file writes. If a profiles sysupgrade and factory image are finished at the same time both processes would write to the same JSON file, resulting in randomly broken outputs. Some target like x86/64 do not use the image code yet, resulting in missing JSON files. If no JSON info files were created, no `profiles.json` files is created as it would be empty anyway. As before, this creation is enabled by default only if `BUILDBOT` is set. Tested via buildroot & ImageBuilder on ath79/generic, imx6 and x86/64. Signed-off-by: Paul Spooren [json_info_files dir handling in Make, if case refactoring] Signed-off-by: Petr Štetiar (backported from commit 07449f692ce4c4525e946401f4c3ed0cbbc8c4df) Signed-off-by: Adrian Schmutzler

build: image: fix build breakage of some images

2020-06-30T20:12:50Z

Commit 881ed09ee6e2 ("build: create JSON files containing image info") has removed the crucial empty new line from the image copy step resulting in the following errors during make function expansion: GZ_SUFFIX := bash: GZ_SUFFIX: command not found Makefile:86: recipe for target 'openwrt-ath79-generic-tplink_archer-c7-v5-squashfs-sysupgrade.bin' failed Fixes: 881ed09ee6e2 ("build: create JSON files containing image info") Signed-off-by: Petr Štetiar (cherry picked from commit 0fb23d67f00a18c3f9e712ca97cfc34b38071f4a)

build: create JSON files containing image info

2020-06-30T20:12:39Z

The JSON info files contain details about the created firmware images per device and are stored next to the created images. The JSON files are stored as "$(IMAGE_PREFIX).json" and contain some device/image meta data as well as a list of created firmware images. An example of openwrt-ramips-rt305x-aztech_hw550-3g.json { "id": "aztech_hw550-3g", "image_prefix": "openwrt-ramips-rt305x-aztech_hw550-3g", "images": [ { "name": "openwrt-ramips-rt305x-aztech_hw550-3g-squashfs-sysupgrade.bin", "sha256": "db2b34b0ec4a83d9bf612cf66fab0dc3722b191cb9bedf111e5627a4298baf20", "type": "sysupgrade" } ], "metadata_version": 1, "supported_devices": [ "aztech,hw550-3g", "hw550-3g" ], "target": "ramips/rt305x", "titles": [ { "model": "HW550-3G", "vendor": "Aztech" }, { "model": "ALL0239-3G", "vendor": "Allnet" } ], "version_commit": "r10920+123-0cc87b3bac", "version_number": "SNAPSHOT" } Signed-off-by: Paul Spooren (backported from commit 881ed09ee6e23f6c224184bb7493253c4624fb9f) Signed-off-by: Adrian Schmutzler

Revert "build: remove harmful -nopad option from mksquashfs"

2019-09-08T16:50:11Z

This reverts commit 1c0290c5cc6258c48b8ba46b4f9c85a21de4f875. Dropping the nopad can make the padding overflow into the next erase block on devices using a non-aligned rootfs start. This breaks the jffs2 overlay partition with the following messages: [ 30.343877] jffs2_scan_eraseblock(): End of filesystem marker found at 0x10000 [ 30.376512] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes [ 30.385253] jffs2: empty_blocks 196, bad_blocks 0, c->nr_blocks 197 Signed-off-by: Jonas Gorski (cherry picked from commit f11d90a76b719106336b94d85b166b4ebf19dbb0)

build: remove harmful -nopad option from mksquashfs

2019-09-04T11:44:20Z

While the -nopad option prevents mksquashfs from padding the image to an arbitrary 4k. It does not take into consideration that squashfs is programmed to have this 4k padding when it's being used on on a block device... which is its main "use-case". Now, after a week long discussion on the ML that included a back-and-forth between some of the possible options. But this is likely the best KISS patch to deal with the issue right away given the limited resources. From squashfs code point of view, be warned. The 4k padding is not enough when dealing with devices that have a PAGE_SIZE bigger than 4k. if it turns out to be affecting you, then please look-up either: "FS#2460 - kernel panic reading squashfs from ubi volume" bug Or the discussion on the OpenWrt-Devel ML in "amp821xx: use newly added pad-squashfs for Meraki MR24" and "Squashfs breakage lottery with UBI..." before making an educated guess. Note: This will not affect the "tiny"/small flash devices as much as it seems at first. This is because the the rootfs_data partition that follows uses jffs2. And it requires to be aligned to the flash block-size in order to work at all. So either the involved FSes will meet in the middle as before, or not at all. But in that latter case the image was already hoping for the "undefined behaviour" gamble to turn out in its favour and this is probably why this was unnoticed for so long. Fixes: FS#2460 Reported-by: Russell Senior Signed-off-by: Christian Lamparter (cherry picked from commit 1c0290c5cc6258c48b8ba46b4f9c85a21de4f875)

build: allow overriding default selection state for devices

2019-09-04T11:39:37Z

Allow overriding the default selection state for Devices, similar to setting a default for packages. E.g. by setting DEFAULT to n, they won't be selected by default anymore when enabling all device in the multi device profile. This allows preventing images being built by the default config for known broken devices, devices without enough RAM/flash, or devices not working with a certain kernel versions. This does not prevent the devices from being manually selected or images being built by the ImageBuilder. These devices often still have worth with a reduced package-set, or as a device for regression testing, when no better device is available. Signed-off-by: Jonas Gorski (cherry picked from commit 7546be60074e452751ba2a48eddbc13910bec708)

build: add UBOOT_PATH to DEFAULT_DEVICE_VARS and set a default

2019-05-18T14:37:30Z

The helper shared Build/append-uboot in include/image-commands.mk uses it, so include this variable in DEFAULT_DEVICE_VARS. Signed-off-by: Christian Lamparter

build: remove sgid permission from tar

2019-04-06T17:14:06Z

Otherwise tar will keep the sgid bit when running from a sgid-set directory, resulting in a different file being generated. Signed-off-by: Eneas U de Queiroz Signed-off-by: Christian Lamparter [reworked commit message, removed DMARC]