|
|
@@ -0,0 +1,183 @@
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES
|
|
|
+ bool "mender-update-modules"
|
|
|
+ depends on BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS
|
|
|
+ depends on BR2_PACKAGE_MENDER
|
|
|
+ select BR2_PACKAGE_HOST_MENDER_ARTIFACT
|
|
|
+ help
|
|
|
+ community supported Update Modules. An Update Module is an
|
|
|
+ extension to the Mender client for supporting a new type of
|
|
|
+ software update, such as a package manager, container,
|
|
|
+ bootloader or even updates of nearby microcontrollers.
|
|
|
+ An Update Module can be tailored to a specific device or
|
|
|
+ environment (e.g. update a proprietary bootloader), or be
|
|
|
+ more general-purpose (e.g. install a set of .deb packages.).
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules
|
|
|
+
|
|
|
+if BR2_PACKAGE_MENDER_UPDATE_MODULES
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_DFU
|
|
|
+ bool "DFU"
|
|
|
+ depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 # libusb
|
|
|
+ select BR2_PACKAGE_DFU_UTIL
|
|
|
+ help
|
|
|
+ The DFU Update Module is able to update peripheral devices
|
|
|
+ connected to the device running Mender.
|
|
|
+ Example use-cases:
|
|
|
+ - Deploy firmware updates to peripheral devices using the
|
|
|
+ USB Device Firmware Update (DFU) protocol
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/dfu
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_DIR_OVERLAY
|
|
|
+ bool "dir-overlay"
|
|
|
+ help
|
|
|
+ The Directory Overlay Update Module installs a user defined
|
|
|
+ file tree structure into a given destination directory in the
|
|
|
+ target.
|
|
|
+
|
|
|
+ Before the deploy into the destination folder on the device,
|
|
|
+ the Update Module will take a backup copy of the current
|
|
|
+ contents, allowing restore of it using the rollback mechanism
|
|
|
+ of the Mender client if something goes wrong. The Update
|
|
|
+ Module will also delete the current installed content that was
|
|
|
+ previously installed using the same module, this means that
|
|
|
+ each deployment is self contained and there is no residues
|
|
|
+ left on the system from the previous deployment.
|
|
|
+
|
|
|
+ Example use-cases:
|
|
|
+ - Deploy root filesystem overlays
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/dir-overlay
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_DIRTY
|
|
|
+ bool "dirty"
|
|
|
+ help
|
|
|
+ The dirty Update Module: modify your device state without
|
|
|
+ installing an artifact
|
|
|
+ Example use-cases:
|
|
|
+ - You have a specific action on the device that you want to
|
|
|
+ run multiple times
|
|
|
+
|
|
|
+ - You want to avoid re-creating artifacts just for the sake
|
|
|
+ of a new version/name
|
|
|
+
|
|
|
+ - You don't want the artifact the show up in the list of
|
|
|
+ installed artifacts
|
|
|
+
|
|
|
+ - The module will always fail the update process, which
|
|
|
+ means it can never be marked as installed. So it can be
|
|
|
+ attempted any number of times without having to recreate
|
|
|
+ newly versioned artifacts.
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/dirty
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_IPK
|
|
|
+ bool "ipk"
|
|
|
+ select BR2_PACKAGE_OPKG
|
|
|
+ help
|
|
|
+ The IPK Update Module allows opkg-based packages to be
|
|
|
+ installed on a device
|
|
|
+
|
|
|
+ Example use-cases:
|
|
|
+ - Deploy any ipk package
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/ipk
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_PODMAN
|
|
|
+ bool "podman"
|
|
|
+ depends on BR2_USE_MMU # podman
|
|
|
+ depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS # podman
|
|
|
+ depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS # podman
|
|
|
+ depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS # podman
|
|
|
+ depends on BR2_PACKAGE_LIBSECCOMP_ARCH_SUPPORTS # podman
|
|
|
+ depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17 # podman
|
|
|
+ depends on BR2_TOOLCHAIN_HAS_THREADS # podman
|
|
|
+ depends on BR2_USE_WCHAR # podman
|
|
|
+ select BR2_PACKAGE_JQ # runtime
|
|
|
+ select BR2_PACKAGE_PODMAN
|
|
|
+ help
|
|
|
+ The Podman Update Module handles the Podman container images
|
|
|
+ that shall be running on the target device. A deployment with
|
|
|
+ this module will stop all currently running Podman containers
|
|
|
+ on the device and start new containers based on the list of
|
|
|
+ Podman images provided in the Mender Artifact.
|
|
|
+
|
|
|
+ In case of any unforeseen error during the process, the module
|
|
|
+ will trigger the rollback mechanism of the Mender client to
|
|
|
+ restore the previously running Podman containers.
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/podman
|
|
|
+
|
|
|
+comment "podman support needs a toolchain w/ headers >= 3.17, threads, wchar"
|
|
|
+ depends on BR2_USE_MMU
|
|
|
+ depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
|
|
|
+ depends on BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS
|
|
|
+ depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS
|
|
|
+ depends on BR2_PACKAGE_LIBSECCOMP_ARCH_SUPPORTS
|
|
|
+ depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17 \
|
|
|
+ || !BR2_TOOLCHAIN_HAS_THREADS \
|
|
|
+ || !BR2_USE_WCHAR
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_REBOOT
|
|
|
+ bool "reboot"
|
|
|
+ help
|
|
|
+ The reboot Update Module: reboot your device remotely.
|
|
|
+
|
|
|
+ Example use-cases:
|
|
|
+ - Something went wrong and you have to reboot your device
|
|
|
+ remotely, and all access to the device you have is Mender.
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/reboot
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_ROOTFS_VERSION_CHECK
|
|
|
+ bool "rootfs version check"
|
|
|
+ depends on BR2_TOOLCHAIN_HAS_THREADS # python3
|
|
|
+ depends on !BR2_STATIC_LIBS # python3
|
|
|
+ select BR2_PACKAGE_PYTHON3 # runtime
|
|
|
+ help
|
|
|
+ The rootfs-version-check Update Module implements a full image
|
|
|
+ update with additional checks to protect against replay
|
|
|
+ attacks.
|
|
|
+
|
|
|
+ This is functionally equivalent to the built-in full image
|
|
|
+ update with an extra check to ensure the artifact name
|
|
|
+ follows a specific format and that installing "older" images
|
|
|
+ is rejected. For this reference implementaton, we simply use
|
|
|
+ a numeric identifier and ensure that it is larger than the
|
|
|
+ version installed. For actual device fleet use, you may need
|
|
|
+ to customize this based on your artifact naming scheme.
|
|
|
+
|
|
|
+ Example use-cases:
|
|
|
+ - Deploy root filesystem updates and ensure only newer
|
|
|
+ artifacts are installed
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/rootfs-version-check
|
|
|
+
|
|
|
+comment "rootfs version check needs a toolchain w/ threads"
|
|
|
+ depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
|
|
|
+
|
|
|
+config BR2_PACKAGE_MENDER_UPDATE_MODULES_SWU
|
|
|
+ bool "swupdate"
|
|
|
+ depends on !BR2_STATIC_LIBS
|
|
|
+ depends on BR2_TOOLCHAIN_HAS_SYNC_4 # swupdate
|
|
|
+ select BR2_PACKAGE_JQ # runtime
|
|
|
+ select BR2_PACKAGE_SWUPDATE
|
|
|
+ help
|
|
|
+ The SWU Update Module allows deploying an SWUpdate-based
|
|
|
+ artifact to the device.
|
|
|
+
|
|
|
+ Example use-cases:
|
|
|
+ - Extend an existing platform using SWUpdate with OTA.
|
|
|
+
|
|
|
+ https://github.com/mendersoftware/mender-update-modules/tree/master/swu
|
|
|
+
|
|
|
+comment "swupdate support needs a toolchain w/ dynamic library"
|
|
|
+ depends on BR2_TOOLCHAIN_HAS_SYNC_4
|
|
|
+ depends on BR2_STATIC_LIBS
|
|
|
+
|
|
|
+endif
|
|
|
+
|
|
|
+comment "mender-update-modules needs mender"
|
|
|
+ depends on BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS
|
|
|
+ depends on !BR2_PACKAGE_MENDER
|
Adam Duskett