AWS systems-manager documentation change
Summary
Removed documentation about Zypper package lock dependency failures on SLES and excluded Raspberry Pi OS from Python 3 requirements
Security assessment
The changes remove troubleshooting guidance for zypper package locks and narrow OS support scope. While patching issues could indirectly impact security, there's no explicit evidence this change addresses a specific vulnerability. The removal of Raspberry Pi OS references appears to be a documentation correction rather than security-related.
Diff
diff --git a/systems-manager/latest/userguide/patch-manager-troubleshooting.md b/systems-manager/latest/userguide/patch-manager-troubleshooting.md index b59959bc5..08a171c74 100644 --- a//systems-manager/latest/userguide/patch-manager-troubleshooting.md +++ b//systems-manager/latest/userguide/patch-manager-troubleshooting.md @@ -153,2 +152,0 @@ When a `Scan` operation runs, it overwrites the compliance details from the most - * Issue: Zypper package lock dependency failures on SLES managed nodes - @@ -226 +224 @@ When a `Scan` operation runs, it overwrites the compliance details from the most -**Cause** : A supported version of python3 isn't installed on the Debian Server, Raspberry Pi OS, or Ubuntu Server instance. +**Cause** : A supported version of python3 isn't installed on the Debian Server or Ubuntu Server instance. @@ -228 +226 @@ When a `Scan` operation runs, it overwrites the compliance details from the most -**Solution** : Install a supported version of python3 (3.0 - 3.10) on the server, which is required for Debian Server, Raspberry Pi OS, and Ubuntu Server managed nodes. +**Solution** : Install a supported version of python3 (3.0 - 3.10) on the server, which is required for Debian Server and Ubuntu Server managed nodes. @@ -473,109 +470,0 @@ After you run this command, run another patching operation. -### Issue: Zypper package lock dependency failures on SLES managed nodes - -**Problem** : When you run `AWS-RunPatchBaseline` with the `Install` operation on SUSE Linux Enterprise Server instances, patching fails with dependency check errors related to package locks. You might see error messages similar to the following: - - - Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided - uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo] - Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo] - Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch - Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies - - Choose from above solutions by number or cancel [1/2/3/c] (c): c - -In this example, the package `mock-pkg-standalone` is locked, which you could verify by running `sudo zypper locks` and looking for this package name in the output. - -Or you might see log entries indicating dependency check failures: - - - Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4') - -###### Note - -This issue only occurs during `Install` operations. `Scan` operations do not apply package locks and are not affected by existing locks." - -**Cause** : This error occurs when zypper package locks prevent the installation or update of packages due to dependency conflicts. Package locks can be present for several reasons: - - * **Customer-applied locks** : You or your system administrator manually locked packages using zypper commands such as `zypper addlock`. - - * **Patch Manager rejected patches** : Patch Manager automatically applies package locks when you specify packages in the **Rejected patches** list of your patch baseline to prevent their installation. - - * **Residual locks from interrupted operations** : In rare cases, if a patch operation was interrupted (such as by a system reboot) before Patch Manager could clean up temporary locks, residual package locks might remain on your managed node. - - - - -**Solution** : To resolve zypper package lock issues, follow these steps based on the cause: - -**Step 1: Identify locked packages** - -Connect to your SLES managed node and run the following command to list all currently locked packages: - - - sudo zypper locks - -**Step 2: Determine the source of locks** - - * If the locked packages are ones you intentionally locked for system stability, consider whether they need to remain locked or if they can be temporarily unlocked for patching. - - * If the locked packages match entries in your patch baseline's **Rejected patches** list, these are likely residual locks from an interrupted patch operation. During normal operations, Patch Manager applies these locks temporarily and removes them automatically when the operation completes. You can either remove the packages from the rejected list or modify your patch baseline rules. - - * If you don't recognize the locked packages and they weren't intentionally locked, they might be residual locks from a previous interrupted patch operation. - - - - -**Step 3: Remove locks as appropriate** - -To remove specific package locks, use the following command: - - - sudo zypper removelock package-name - -To remove all package locks (use with caution), run: - - - sudo zypper cleanlocks - -**Step 4: Update your patch baseline (if applicable)** - -If the locks were caused by rejected patches in your patch baseline: - - 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). - - 2. In the navigation pane, choose **Patch Manager**. - - 3. Choose the **Patch baselines** tab, and then choose your custom patch baseline. - - 4. Choose **Actions** , **Modify patch baseline**. - - 5. In the **Rejected patches** section, review the listed packages and remove any that should be allowed to install. - - 6. Choose **Save changes**. - - - - -**Step 5: Retry the patch operation** - -After removing the problematic locks and updating your patch baseline if necessary, run the `AWS-RunPatchBaseline` document again. - -###### Note - -When Patch Manager applies locks for rejected patches during `Install` operations, it's designed to clean up these locks automatically after the patch operation completes. If you see these locks when running `sudo zypper locks`, it indicates a previous patch operation was interrupted before cleanup could occur. However, if a patch operation is interrupted, manual cleanup might be required as described in this procedure. - -**Prevention** : To avoid future zypper lock conflicts: - - * Carefully review your patch baseline's rejected patches list to ensure it only includes packages you truly want to exclude. - - * Avoid manually locking packages that might be required as dependencies for security updates. - - * If you must lock packages manually, document the reasons and review the locks periodically. - - * Ensure patch operations complete successfully and aren't interrupted by system reboots or other factors. - - * Monitor patch operations to completion and avoid interrupting them with system reboots or other actions that could prevent proper cleanup of temporary locks. - - - -