Merge 'main' into 'develop' and update version number to 1.1.0 (Azure…

…#594) * Merge 'develop' into 'main' (Azure#243) Fix issue in reboot/restart flow and race condition in D2C messaging util (Azure#242) - Fix an issue for image-based update scenario where the device doesn't reboot after the new image is installed. - Add ADUC_D2C_Message_Type_Device_Properties to avoid a race condition. Note | These changes passed e2e verification internally. * Update issue templates * Update issue templates * Update issue templates * Patch 1.0.1 Release (Azure#340) * Fix issue in reboot/restart flow and race condition in D2C messaging util (Azure#242) * - Fix an issue for image-based update scenario where the device doesn't reboot after the new image is installed. - Add ADUC_D2C_Message_Type_Device_Properties to avoid a race condition. * Update steps_handler.cpp * Update steps_handler.cpp * Update workflow_utils.c Remove comment * Address PR feedback * Update how-to-build-agent-code.md * Manually integrate PR Azure#58 Co-authored-by: Pierrick Arsenault <[email protected]> * revert clang-format.sh to avoid issues when pipe in staged content * Disable clangformat in precommit hook due to cross ver compat * Fix install-deps issue when --work-folder used on ubuntu 20.04 * Cleanup sandbox on start of deployment processing (Azure#247) * Added README section for Azure CLI (Azure#254) * Merge 'develop' into 'main' (Azure#243) (Azure#262) (Azure#264) Fix issue in reboot/restart flow and race condition in D2C messaging util (Azure#242) - Fix an issue for image-based update scenario where the device doesn't reboot after the new image is installed. - Add ADUC_D2C_Message_Type_Device_Properties to avoid a race condition. Note | These changes passed e2e verification internally. Co-authored-by: Nox-MSFT <[email protected]> Co-authored-by: Nox-MSFT <[email protected]> * Use 'bool' instead of '_Bool' (Azure#268) * sort paths before asserting in systemutils_forEachDir tests (Azure#265) * sort paths before asserting in systemutils_forEachDir tests * Revamp test to fully utilize test fixture instance and have bare minimum test code * clang-format * Remove stale debug trace from main() (Azure#257) * Fix many memory leaks and reenable UT (Azure#283) * fix memleak in workflow_get_workfolder * Fix leak of hash array in workflow_get_update_file * remove unused include in steps_handler * clang-format steps_handler * Remove unused include in file_test_utils * memleak, use workflow_free in AutoWorkflowHandle * split autoopendir impl, throw on opendir failure * make findFilesInDir iterative, guard non-dir arg * uncomment source_update_cache_utils unit tests * Fix many memleaks (valgrind) in MoveToUpdateCache * Remove curl dependency in https_proxy_utils (Bug 42504722) (Azure#282) * Remove curl dependency in https_proxy_utils * PR comments * Remove mallocAndStrcpy_s header * Update encoded test * log result.ResultCode instead of result on nested edge startup failure (Azure#280) * remove do dep packages * fix install_aduc_deps * Handle errors when download handler plugin symbol missing (Azure#284) * Make DH Factory LoadDownloadHandler noexcept * Make DH Plugin noexcept * throw plugin exception, extract DH extmgr helper * Fix ProcessDownloadHandlerExtensibility docs * Add missing Log_Error for caught PluginException * create erc for each dh export and rmv catch in ADUC_DownloadHandlerPlugin_OnUpdateWorkflowCompleted * Bug 42442896: zlog - incorrect threadproc signature (Azure#287) * Removed log message for retrieving connection information from connection string (Azure#292) * Updated doxygen version (Azure#289) * Updated doxygen version * Changed product name to reflect documentation and removed pre-version * Changed install-deps to clean up after itself (Azure#295) * Updated install-deps to remove old files and cleanup after itself * Fixed script errors * one line fix (Azure#297) * use helper for recursive mkdir (Azure#301) * Try to reconnect to IoT Hub on bad credential or expired SAS token (when using AIS) (Azure#298) * Fix undefined references error in adu-shell (Azure#305) * Took Jeff's suggestion for removing the pthread_cancel calls (Azure#302) * Turn d2c_messaging unit tests into functional tests and skipped by default. (Azure#306) * use TestCaseFixture ptr, not void ptr (Azure#308) * fix zlog file handle leak (Azure#310) * fix zlog file handle leak * set ret=1 upfront and ret 1 when RunAsDesiredUser returns false * rmv last ret=1 straggler * CP: Fix up issues with d2c_messaging. Working on WIOT. Needs to be brought to develop. (Azure#314) Co-authored-by: Jeff Miller <[email protected]> * Fix build pipeline by fixing cpp-tidy errors (Azure#313) * Fix deadlock in zlog flush deinit (Azure#315) * Fix deadlock in zlog finish flush * rmv flush thread * use zlog_flush_buffer and init zlog_last_flushed to 0 * Fix regression in ADUC_Logging_Init to allow agent to start (Azure#317) * Update cached workfolder when processing replacement workflow (Azure#322) Fixes issue where replacement workflow processing uses the previous workflow's workfolder sandbox that was in the property cache. * Update README.md (Azure#294) * Moved the output of catch from cout to cerr for all CATCH_CONFIG_RUNNER unit tests (Azure#323) * Mark test case "30 retries - httpStatus 401" as functional - takes 30s to run (Azure#325) Co-authored-by: Jeff Miller <[email protected]> * cherry-pick from wiot-s1 feature branch: GetConnectionInfoFromConnectionString crashes on failure. (Azure#324) (Azure#326) Co-authored-by: Jeff Miller <[email protected]> * Fix overwrite of contract maj ver in downloaders and comp enumerator (Azure#327) * fix contract majVer overwrite with minVer in content downloaders and content enumerator * fix contract comparison logic * Fixes the E2E Pipeline so all tests pass and scenarios are run (Azure#329) * Removing the cppcheck and clang-tidy to see if that is what is causing the pipeline builds to fail * Making linking changes to see if that fixes the build error * Adding debug lines * Added timeout failures * Added call to set device name when configuring agent through config file - fixes diagnostics * Removed output of the connection string during test * Added input params checks to ConnectionStringUtils_IsNestedEdge to prevent test failures (Azure#330) * Added input params check to prevent bad access * Changed null check to IsNullOrEmpty() * Upgraded patch version (Azure#331) * Fix bug in swupdate-handler v2 example (Azure#333) * Solving merge conflicts main to develop (Azure#338) * Merge 'develop' into 'main' (Azure#243) Fix issue in reboot/restart flow and race condition in D2C messaging util (Azure#242) - Fix an issue for image-based update scenario where the device doesn't reboot after the new image is installed. - Add ADUC_D2C_Message_Type_Device_Properties to avoid a race condition. Note | These changes passed e2e verification internally. * Update issue templates * Update issue templates * Update issue templates Co-authored-by: Nox-MSFT <[email protected]> Co-authored-by: Esha Shah <[email protected]> Co-authored-by: Nox-MSFT <[email protected]> Co-authored-by: Takashi Matsuoka <[email protected]> Co-authored-by: jw-msft <[email protected]> Co-authored-by: Pierrick Arsenault <[email protected]> Co-authored-by: Andrew Brown <[email protected]> Co-authored-by: Jeff Miller <[email protected]> Co-authored-by: Shiyi Peng <[email protected]> Co-authored-by: shiyi-peng <[email protected]> Co-authored-by: Esha Shah <[email protected]> * Release Patch 1.0.2 (Azure#376) Co-authored-by: Pierrick Arsenault <[email protected]> Co-authored-by: Nox-MSFT <[email protected]> Co-authored-by: Jeff Miller <[email protected]> Co-authored-by: Esha Shah <[email protected]> Co-authored-by: Takashi Matsuoka <[email protected]> Co-authored-by: jw-msft <[email protected]> Co-authored-by: Andrew Brown <[email protected]> Co-authored-by: Shiyi Peng <[email protected]> Co-authored-by: shiyi-peng <[email protected]> Co-authored-by: Nicholas Hemstreet <[email protected]> Co-authored-by: JoergZeidler <[email protected]> * Update Pipelines Build README.md (Azure#300) Currently says Debian 9 arm32 is a supported pipeline build, but the adu-debian-arm32-build.yml file has the targetOS as Debian 10 - and as far as I am aware this is actually the supported build. Updating to reflect this. * update links (Azure#131) Co-authored-by: Nox-MSFT <[email protected]> * null terminate after strncpy of jws header (Azure#417) (Azure#426) - Cherry-Pick the following commit to main from develop branch: Azure@e40b7e3 - Originally reported by github issue Azure#406 * Update swupdate handler v2 document (Azure#441) * Update DU Agent documents (Azure#433) * Fix broken link in how-to-build-agent-code.md (Azure#501) * chg read count arg to one less-than buf size to avoid nul term write past buffer (Azure#531) * Update agent version to 1.1.0 * Update agent version in build ymls to 1.1.0 Regenerate result.h * Fix bad merge in install-deps.sh Fix bad merge in agent_workflow.c * Fix version number in arm32 build ymls * Fix WinIoT build error --------- Co-authored-by: Esha Shah <[email protected]> Co-authored-by: Nicholas Hemstreet <[email protected]> Co-authored-by: Takashi Matsuoka <[email protected]> Co-authored-by: jw-msft <[email protected]> Co-authored-by: Pierrick Arsenault <[email protected]> Co-authored-by: Andrew Brown <[email protected]> Co-authored-by: Jeff Miller <[email protected]> Co-authored-by: Shiyi Peng <[email protected]> Co-authored-by: shiyi-peng <[email protected]> Co-authored-by: JoergZeidler <[email protected]> Co-authored-by: GeorgeSiggins <[email protected]> Co-authored-by: Dane Walton <[email protected]>
AndreRicardo-Zoetis · Dec 20, 2023 · 85c541e · 85c541e
1 parent 9b088ad
commit 85c541e
Show file tree

Hide file tree

Showing 22 changed files with 55 additions and 90 deletions.
diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -78,10 +78,10 @@ include (aduc_helpers)
 set_cache_with_env_or_default (ADUC_VERSION_MAJOR "1" STRING
                                "The major part of the semantic version")
 
-set_cache_with_env_or_default (ADUC_VERSION_MINOR "0" STRING
+set_cache_with_env_or_default (ADUC_VERSION_MINOR "1" STRING
                                "The minor part of the semantic version")
 
-set_cache_with_env_or_default (ADUC_VERSION_PATCH "2" STRING
+set_cache_with_env_or_default (ADUC_VERSION_PATCH "0" STRING
                                "The patch part of the semantic version")
 
 set_cache_with_env_or_default (ADUC_VERSION_PRERELEASE "" STRING

diff --git a/azurepipelines/build/README.md b/azurepipelines/build/README.md
@@ -34,6 +34,6 @@ Below is a matrix of currently supported pipeline builds
 | Ubuntu 20.04 | amd64 | docker/adu-ubuntu-amd64-build.yml |
 | Ubuntu 18.04 | arm64 | docker/adu-ubuntu-arm64-build.yml |
 | Ubuntu 20.04 | arm64 | docker/adu-ubuntu-arm64-build.yml |
-| Debian 9 | arm32 | docker/adu-debian-arm32-build.yml |
+| Debian 10 | arm32 | docker/adu-debian-arm32-build.yml |
 | Debian 10 | arm64 | docker/adu-debian-arm64-build.yml |
 | Debian 10 | amd64 | docker/adu-debian-amd64-build.yml |
diff --git a/azurepipelines/build/docker/adu-debian-amd64-build.yml b/azurepipelines/build/docker/adu-debian-amd64-build.yml
@@ -1,7 +1,7 @@
 variables:
     version.major: 1
-    version.minor: 0
-    version.patch: 3
+    version.minor: 1
+    version.patch: 0
     version.pre-release: ""
     version.build: $[format('{0:yyyyMMdd}-{0:HHmmss}', pipeline.startTime)]
 

diff --git a/azurepipelines/build/docker/adu-debian-arm32-build.yml b/azurepipelines/build/docker/adu-debian-arm32-build.yml
@@ -1,7 +1,7 @@
 variables:
     version.major: 1
-    version.minor: 0
-    version.patch: 3
+    version.minor: 1
+    version.patch: 0
     version.pre-release: ""
     version.build: $[format('{0:yyyyMMdd}-{0:HHmmss}', pipeline.startTime)]
 

diff --git a/azurepipelines/build/docker/adu-debian-arm64-build.yml b/azurepipelines/build/docker/adu-debian-arm64-build.yml
@@ -1,7 +1,7 @@
 variables:
     version.major: 1
-    version.minor: 0
-    version.patch: 3
+    version.minor: 1
+    version.patch: 0
     version.pre-release: ""
     version.build: $[format('{0:yyyyMMdd}-{0:HHmmss}', pipeline.startTime)]
 

diff --git a/azurepipelines/build/native/adu-ubuntu-amd64-build.yml b/azurepipelines/build/native/adu-ubuntu-amd64-build.yml
@@ -1,7 +1,7 @@
 variables:
     version.major: 1
-    version.minor: 0
-    version.patch: 3
+    version.minor: 1
+    version.patch: 0
     version.pre-release: ""
     version.build: $[format('{0:yyyyMMdd}-{0:HHmmss}', pipeline.startTime)]
 

diff --git a/azurepipelines/build/native/adu-ubuntu-arm64-build.yml b/azurepipelines/build/native/adu-ubuntu-arm64-build.yml
@@ -1,7 +1,7 @@
 variables:
     version.major: 1
-    version.minor: 0
-    version.patch: 3
+    version.minor: 1
+    version.patch: 0
     version.pre-release: ""
     version.build: $[format('{0:yyyyMMdd}-{0:HHmmss}', pipeline.startTime)]
 

diff --git a/docs/agent-reference/goal-state-support.md b/docs/agent-reference/goal-state-support.md
@@ -66,7 +66,7 @@ Here is each workflow step and what it does at a high-level:
     - On failure, it sets the state to `ADUCITF_State_Failed` and reports the failure.
 - `ADUCITF_WorkflowStep_Backup`
     - Sets current state to `ADUCITF_WorkflowStep_Backup`
-    - Kicks off Backup worker thread, which will call the step handler's `Backup()` method to backup the content needed to 
+    - Kicks off Backup worker thread, which will call the step handler's `Backup()` method to backup the content needed to
     be backed up
     - On success, it will set the state to `ADUCITF_State_BackupCompleted` and auto-transitions to `ADUCITF_WorkflowStep_InstallStarted`
     - On failure, it sets the state to `ADUCITF_State_Failed` and reports the failure.
@@ -114,9 +114,9 @@ The states of the state machine are defined in the `ADUCITF_State` enum in [upda
 
 ### State Transitions
 
-A state transition is describe by the `ADUC_WorkflowHandlerMapEntry` struct in [agent_workflow.c](../../src/agent/adu_core_interface/src/agent_workflow.c).
+A state transition is describe by the `ADUC_WorkflowHandlerMapEntry` struct in [agent_workflow.c](../../src/adu_workflow/src/agent_workflow.c).
 
-The state transitions are defined in the `workflowHandlerMap` array in [agent_workflow.c](../../src/agent/adu_core_interface/src/agent_workflow.c).
+The state transitions are defined in the `workflowHandlerMap` array in [agent_workflow.c](../../src/adu_workflow/src/agent_workflow.c).
 
 ### State Machine Diagram
 ![State Machine Diagram](images/goalstate-state-diagram.png)

diff --git a/docs/agent-reference/how-to-build-agent-code.md b/docs/agent-reference/how-to-build-agent-code.md
@@ -4,7 +4,6 @@ Take a look at [dependencies](how-to-build-agent-code.md#dependencies-of-device-
 
 -   [Dependencies](how-to-build-agent-code.md#dependencies-of-device-update-agent)
 -   [As a standalone solution](how-to-build-agent-code.md#as-a-standalone-solution)
--   [Integrate the Device Update agent in your existing application or solution](how-to-build-agent-code.md#integrate-the-device-update-agent-in-your-existing-application-or-solution)
 
 ## Dependencies of Device Update Agent
 
@@ -59,26 +58,6 @@ dependencies. To see the usage info:
 ./scripts/install-deps.sh -h
 ```
 
-#### Build Azure IotHub SDK for C WebSockets static library
-
-By default, both MQTT (`libiothub_client_mqtt_transport.a`) and MQTT over WebSockets(`libiothub_client_mqtt_ws_transport.a`) static libraries are built by `install-deps.sh` via the `use_mqtt` and `use_wsio` -D configs.
-
-```shell
-# Verify mqtt transport static lib exists
-$ locate libiothub_client_mqtt_transport.a | \
-    grep '/usr/local/lib/'
-/usr/local/lib/libiothub_client_mqtt_transport.a
-```
-
-```shell
-# Verify mqtt over websockets static lib exists
-$ locate libiothub_client_mqtt_ws_transport.a | \
-    grep '/usr/local/lib/'
-/usr/local/lib/libiothub_client_mqtt_ws_transport.a
-```
-
-## As a standalone solution
-
 ### Device Update Linux Build System
 
 The Device Update for IoT Hub reference agent code utilizes CMake for building. An example build script is provided at [scripts/build.sh](../../scripts/build.sh).
@@ -234,6 +213,22 @@ set (
 Doing ./build.sh after setting this to `"MQTT_over_WebSockets"` will have the MQTT traffic go over a websocket on port `443`.
 Using `"MQTT"` will use SecureMQTT over port `8883`.
 
+Please note that, by default, both MQTT (`libiothub_client_mqtt_transport.a`) and MQTT over WebSockets(`libiothub_client_mqtt_ws_transport.a`) static libraries are built by `install-deps.sh` via the `use_mqtt` and `use_wsio` -D configs.
+
+```shell
+# Verify mqtt transport static lib exists
+$ locate libiothub_client_mqtt_transport.a | \
+    grep '/usr/local/lib/'
+/usr/local/lib/libiothub_client_mqtt_transport.a
+```
+
+```shell
+# Verify mqtt over websockets static lib exists
+$ locate libiothub_client_mqtt_ws_transport.a | \
+    grep '/usr/local/lib/'
+/usr/local/lib/libiothub_client_mqtt_ws_transport.a
+```
+
 ## Install the Device Update Agent
 
 ### Install the Device Update Agent after building
@@ -287,34 +282,3 @@ tcp        0      0 <LOCAL IP ADDR>:<LOCAL PORT>       <REMOTE IP ADDR>:443
 $ fg
 <ctrl-c>
 ```
-
-## Integrate the Device Update agent in your existing application or solution
-
-### Pre-concepts
-
-Before integrating the Device Update agent in your existing application or solution review the below concepts.
-
--   Learn how the Device Update service will communicate with the device client using IoT Hub Plug and Play properties to orchestrate over-the-air update actions from [here](../../src/adu_workflow/src/agent_workflow.c).
--   Understand the update manifest to be able to write code to [respond to update actions from your client](update-manifest.md).
--   Understand how to implement 'ADU Core' interface for the Device Update service to [communicate with your client on the Device](device-update-plug-and-play.md).
-
-### Steps
-
-1. Create an IoT Hub C-SDK Plug and Play client: Your application needs to support IoT Hub Plug and Play as shown in this [example](https://docs.microsoft.com/en-us/azure/iot-pnp/tutorial-multiple-components?pivots=programming-language-ansi-c) to be used by Device Update for over-the-air updating.
-2. Once you have a IoT Hub Plug and Play enabled device, implement the 'ADU Core' interfaces for your application, see reference code [here](../../src/adu_workflow/src/agent_workflow.c).
-3. Review the below Device Update agent implementation and source code so that you can modify your application to replicate the same behaviors:
-
--   Workflow phases and source code
-
-Download phase:
-![Download phase](images/download-phase.png)
-
-Install phase:
-![Install phase](images/install-phase.png)
-
-Apply phase:
-![Apply phase](images/apply-phase.png)
-
--   [Source code](../../src/adu_workflow/src/agent_workflow.c)
-
-    4.The result reported from your application should be in this format so that the Device Update service can work with your application. Learn more about [plug and play format](https://docs.microsoft.com/azure/iot-hub-device-update/device-update-plug-and-play), and Device Update agent [workflow](../../src/adu_workflow/src/agent_workflow.c).
diff --git a/docs/agent-reference/multi-component-updating.md b/docs/agent-reference/multi-component-updating.md
@@ -1,24 +1,22 @@
 # Proxy Updates and multi-component updating
 
-This document describes how Proxy Updates can support updating multiple **component(s)** on the target IoT device by using the multi-step ordered execution feature introduced in the Public Preview Refresh Release.  
-
-Proxy updates can target over-the-air updates to multiple components on the target IoT device or multiple sensors connected to the target IoT device. Use cases where proxy updates is applicable include:
+This document explains how Proxy Updates, using the multi-step ordered execution (MSOE) feature, can update multiple components on the IoT device or sensors connected to it. The Device Update agent on the main device facilitates the update process for the connected sensors since they cannot connect to the IoT hub directly. Proxy Updates are useful in scenarios where multiple components or sensors require updates. Examples of such scenarios include:
 
 * Targeting specific update files to different partitions on the device.
 * Targeting specific update files to different apps/components on the device  
 * Targeting specific update files to sensors connected to IoT devices over a network protocol (e.g., USB, CANbus etc.).
 
-In order to update a component or components that connected to a IoTHub-Connected target IoT Device (also referred in the documentation as '**Host Device**' from here on), the device builder must register a custom **Component Enumerator Extension** that is built specifically for their IoT devices. This is required so that the Device Update Agent can map a **'child update'** with a specific component, or group of components, which the update is intended for.  
+To update components on an IoT device that is connected to an IoTHub, also known as the **Host Device** in this document, the device builder needs to register a custom **Component Enumerator Extension** designed for their device. This registration is necessary for the Device Update Agent to associate a 'child update' with a specific component or group of components targeted for the update.
 
-> Note: It's important to understand that Device Update service does not know anything about **component(s)** on the target device.
+It's crucial to note that the Device Update service does not have any knowledge of the specific components on the target device since it's designed to be device agnostic. Therefore, the device builder must provide the necessary information to the Device Update Agent. This information includes a collection of components such as root file system partitions, firmware partitions, boot partition, or any applications or group of applications that are modeled virtually as a 'component'. The device builder can provide this information to the Agent by developing a Component Enumerator extension and registering it with the Agent.
 
 > Note: Multi-step ordered execution feature allow for granular update controls including an install order, pre-install, install and post-install steps. Use cases include
 > a required preinstall check that is needed to validate the device state before starting an update, etc. Learn more about [multi-step ordered execution](../agent-reference/update-manifest-v4-schema.md).
 
-## How to register multiple components with the Component Enumerator Extension
+## Implementing the Component Enumerator Extension
 
-See [Contoso Component Enumerator](../../src/extensions/component_enumerators/examples/contoso_component_enumerator/README.md) for example on how to implement and register a custom Component Enumerator extension.
+To provide information about components on the target device to the Device Update Agent, you can refer to the [Contoso Component Enumerator example](../../src/extensions/component_enumerators/examples/contoso_component_enumerator/README.md). This example provides guidance on how to implement and register a custom Component Enumerator extension.
 
-## Example Proxy Update
+## Proxy Update Example
 
 See [tutorial using the Device Update agent to do Proxy Updates](../../src/extensions/component_enumerators/examples/contoso_component_enumerator/demo/README.md) with sample updates for components connected to a Contoso Virtual Vacuum device.
diff --git a/src/adu_workflow/src/agent_workflow.c b/src/adu_workflow/src/agent_workflow.c
@@ -971,6 +971,7 @@ void ADUC_Workflow_WorkCompletionCallback(const void* workCompletionToken, ADUC_
                     // Reset workflow state to process deployment and transfer
                     // the deferred workflow to current.
                     workflow_update_for_replacement(workflowData->WorkflowHandle);
+
                 }
                 else
                 {

diff --git a/src/extensions/shared_lib/inc/aduc/plugin_exception.hpp b/src/extensions/shared_lib/inc/aduc/plugin_exception.hpp
@@ -25,10 +25,10 @@ class PluginException : public std::runtime_error
         std::runtime_error{ msg }, export_symbol{ symbol }
     {
     }
-    
+
     /**
      * @brief Getter for the export_symbol member variable
-     * @returns the string representation of the export_symbol 
+     * @returns the string representation of the export_symbol
      */
     const std::string& Symbol() const
     {

diff --git a/src/extensions/step_handlers/script_handler/README.md b/src/extensions/step_handlers/script_handler/README.md
@@ -349,7 +349,7 @@ InstallUpdate() {
     ret_val=0
 
     #
-    # PLACEHOLDER : Evaluate 'installCriteria' to determine if there is anything to do.
+    # PLACEHOLDER : Evaluate 'installedCriteria' to determine if there is anything to do.
     #               If not, return ADUC_Result_Install_Success (600). Otherwise, continue.
     #
 

diff --git a/src/extensions/step_handlers/script_handler/examples/example-installscript.sh b/src/extensions/step_handlers/script_handler/examples/example-installscript.sh
@@ -634,7 +634,7 @@ InstallUpdate() {
     ret_val=0
 
     #
-    # PLACEHOLDER : Evaluate 'installCriteria' to determine if there is anything to do.
+    # PLACEHOLDER : Evaluate 'installedCriteria' to determine if there is anything to do.
     #               If not, return ADUC_Result_Install_Success (600). Otherwise, continue.
     #
 

diff --git a/src/extensions/step_handlers/simulator_handler/CMakeLists.txt b/src/extensions/step_handlers/simulator_handler/CMakeLists.txt
@@ -4,7 +4,6 @@ include (agentRules)
 set (target_name microsoft_simulator_1)
 
 add_library (${target_name} MODULE)
-
 target_sources (${target_name} PRIVATE src/simulator_handler.cpp)
 
 add_library (aduc::${target_name} ALIAS ${target_name})

diff --git a/src/extensions/step_handlers/swupdate_handler_v2/README.md b/src/extensions/step_handlers/swupdate_handler_v2/README.md
@@ -61,6 +61,8 @@ The SWUpdate Handler support following handler properties (`handlerProperties`)
 
 #### List of SWUpdate runtime options
 
+> NOTE | As part of the update workflow, the underlying script will receive these options. So, there is no need to include them in the `handlerProperties.arguments` section of the step in the import manifest.
+
 | Name | Type | Description |
 |---|---|---|
 |--work-folder| string | Full path to a work (sandbox) folder used by an Agent when performing update-related tasks. |

diff --git a/src/extensions/step_handlers/swupdate_handler_v2/inc/aduc/swupdate_handler_v2.hpp b/src/extensions/step_handlers/swupdate_handler_v2/inc/aduc/swupdate_handler_v2.hpp
@@ -43,14 +43,14 @@ class SWUpdateHandlerImpl : public ContentHandler
     ADUC_Result Cancel(const tagADUC_WorkflowData* workflowData) override;
     ADUC_Result Restore(const tagADUC_WorkflowData* workflowData) override;
     ADUC_Result IsInstalled(const tagADUC_WorkflowData* workflowData) override;
-    
+
     /**
      * @brief Reads a value from the file and returns it in string format
      * @param filePath the file to read from
      * @returns a string representation of the value
      */
     static std::string ReadValueFromFile(const std::string& filePath);
-    
+
     /**
      * @brief Reads the configuration from the @p configFile into @p values
      * @param configFile the path to the config file
@@ -88,7 +88,7 @@ class SWUpdateHandlerImpl : public ContentHandler
     SWUpdateHandlerImpl()
     {
     }
-    
+
     /**
      * @brief Performs @p action for workflow @p workflowData
      * @param action action to perform

diff --git a/src/extensions/step_handlers/swupdate_handler_v2/src/swupdate_handler_v2.cpp b/src/extensions/step_handlers/swupdate_handler_v2/src/swupdate_handler_v2.cpp
@@ -552,7 +552,7 @@ std::string SWUpdateHandlerImpl::ReadValueFromFile(const std::string& filePath)
  *   - Device builder defines the how to evaluate wither the current step can be considered 'completed'.
  *     Note that the term 'IsInstalled' was carried over from the original design where the agent would
  *     ask the handler that "Is an 'update' is currently installed on the device.".
- * @param workflowData workflowData to perform the IsInstalled check on 
+ * @param workflowData workflowData to perform the IsInstalled check on
  * @return ADUC_Result The result based on evaluating the workflow data.
  */
 ADUC_Result SWUpdateHandlerImpl::IsInstalled(const tagADUC_WorkflowData* workflowData)

diff --git a/...testdata/adu-yocto-ab-rootfs-update/create-yocto-ab-rootfs-update-import-manifest-1.0.ps1 b/...testdata/adu-yocto-ab-rootfs-update/create-yocto-ab-rootfs-update-import-manifest-1.0.ps1
@@ -103,14 +103,14 @@ Write-Host "#    $parentFile1"
     #
     #   scriptFile        - Name of the primary script file that implements download, install, apply, cancel and isInstalled logic.
     #                       This update uses 'example-a-b-update.sh' script.
-    #                       The script supports following actions:
+    #                       The script must support following actions:
     #                            --action-download     : No-op. (No additional payloads)
     #                            --action-install      : Invokes swupdate to install the specified 'swuFile'
     #                            --action-apply        : Sets uboot environment variable to switch to the desired rootfs partition after rebooted.
     #                                                    Returns a special (ADUC_Result) result code to instruct DU Agent to reboot the device.
     #                            --action-cancel       : Restore uboot environment variable to the value before '--action-apply' is performed.
     #                            --action-is-installed : Returns (ADUC_Result) result code that indicates whether the current rootfs contains
-    #                                                    software (image) version that match specified 'installCriteria' string.
+    #                                                    software (image) version that match specified 'installedCriteria' string.
     #
     #   installedCriteria - String used to evaluate whether the software is installed on the target.
     #                       When performing '--action-apply', the primary script file compare this value against content of the

diff --git a/src/utils/file_utils/inc/aduc/auto_opendir.hpp b/src/utils/file_utils/inc/aduc/auto_opendir.hpp
@@ -18,7 +18,7 @@ namespace aduc
 /**
  * @brief AutoOpenDir class wraps handling the openning / closing of a directory
  */
-class AutoOpenDir 
+class AutoOpenDir
 {
 public:
     /**
@@ -30,7 +30,7 @@ class AutoOpenDir
      */
     ~AutoOpenDir();
 
-    /** 
+    /**
     * @brief Returns the directory in stream handle form
     * @returns a value of dirEntry in the form of a DIR*
     */

diff --git a/src/utils/process_utils/src/process_utils.cpp b/src/utils/process_utils/src/process_utils.cpp
@@ -140,7 +140,7 @@ static int ADUC_LaunchChildProcessHelper(
     {
         char buffer[1024];
         ssize_t count;
-        count = read(filedes[READ_END], buffer, sizeof(buffer));
+        count = read(filedes[READ_END], buffer, sizeof(buffer) - 1);
 
         if (count == -1)
         {

diff --git a/src/utils/system_utils/src/system_utils.c b/src/utils/system_utils/src/system_utils.c
@@ -19,6 +19,7 @@
 
 #include <aduc/string_c_utils.h>
 #include <azure_c_shared_utility/strings.h>
+#include <aducpal/dirent.h>
 #include <errno.h>
 #include <limits.h> // for PATH_MAX
 #include <stdio.h>
-Original file line number
+Diff line change
@@ Expand Up @@
                         // Reset workflow state to process deployment and transfer
                         // the deferred workflow to current.
                         workflow_update_for_replacement(workflowData->WorkflowHandle);
                     }
                     else
                     {
@@ Expand Down @@