Merge pull request #10075 from pagienge/patch-9

ryanberg-aquent · web-flow · commit d70b9f748067 · 2025-11-03T07:19:36.000-10:00
AB#8079: adding sudo and general doc updates
diff --git a/support/azure/virtual-machines/linux/repair-linux-vm-using-ALAR.md b/support/azure/virtual-machines/linux/repair-linux-vm-using-ALAR.md
@@ -1,10 +1,9 @@
 ---
 title: Repair a Linux VM automatically with the help of ALAR
-description: This article describes how to automatically repair a non bootable VM with the Azure Linux Auto Repair (ALAR) scripts.
+description: This article describes how to automatically repair a non-bootable VM with the Azure Linux Auto Repair (ALAR) scripts.
 services: virtual-machines-linux
 documentationcenter: ''
-author: malachma
-manager: noambi
+author: pagienge
 editor: v-jsitser
 tags: virtual-machines
 ms.custom: sap:VM Admin - Linux (Guest OS), linux-related-content
@@ -13,8 +12,8 @@ ms.topic: troubleshooting
 ms.workload: infrastructure-services
 ms.tgt_pltfrm: vm-linux
 ms.devlang: azurecli
-ms.date: 09/24/2024
-ms.author: malachma
+ms.date: 10/31/2025
+ms.author: pagienge
 ---
 
 # Use Azure Linux Auto Repair (ALAR) to fix a Linux VM
@@ -27,13 +26,61 @@ ALAR utilizes the VM repair extension that's described in [Repair a Linux VM by
 
 ALAR covers the following repair scenarios:
 
-- Malformed /etc/fstab
-    syntax error
-    missing disk
-- Damaged initrd or missing initrd line in the /boot/grub/grub.cfg
-- Last installed kernel isn't bootable
-- Serial console and GRUB serial are incorrectly configured or are missing
-- GRUB/EFI installation or configuration damaged
+- No-boot scenarios
+  - Malformed */etc/fstab*
+      - syntax error
+      - missing disk
+  - Damaged initrd or missing initrd line in the */boot/grub/grub.cfg*
+  - Last installed kernel isn't bootable
+  - GRUB/EFI installation or configuration damaged
+  - Disk space/auditd forced shutdowns
+- Configuration issues
+  - Serial console and GRUB serial are incorrectly configured or are missing
+  - Sudo misconfiguration
+
+## How to use ALAR
+
+The ALAR scripts use the [az vm repair](/cli/azure/vm/repair) extension, `run` command, and its `--run-id` option. The value of the `--run-id` option for the automated recovery is `linux-alar2`. To fix a Linux VM by using an ALAR script, follow these steps:
+
+> [!NOTE]
+> The VM Contributor role doesn't provide enough permissions to run these scripted operations, as they require permissions to read, write, and delete resources in the resource group that includes the target VM. Therefore roles such as Contributor or Owner at the resource group level is required.
+
+1. Create a rescue VM:
+
+    ```azurecli-interactive
+    az vm repair create --verbose --resource-group <RG-NAME> --name <VM-NAME>
+    ```
+
+    - There are currently three parameters that prompt for values if they aren't given on the command line. Add these parameters and values to the command for a non-interactive execution 
+      - `--repair-username <RESCUE-USERNAME>`
+      - `--repair-password <RESCUE-PASS>`
+      - `--associate-public-ip`
+    - See the [az vm repair](/cli/azure/vm/repair) documentation for more options that can be used to control the creation of the repair VM
+ 
+2. Run the `linux-alar2` script, along with parameters for one or more of the ALAR actions on the rescue VM:
+
+    ```azurecli-interactive
+    az vm repair run --verbose --resource-group <RG-NAME> --name <VM-NAME> --run-id linux-alar2 --parameters <action1,action2,...> --run-on-repair
+    ```
+    
+    See the following for valid action names.
+
+3. Swap the copy of the OS disk back to the original VM and delete the temporary resources:
+
+    ```azurecli-interactive
+    az vm repair restore --verbose --resource-group <RG-NAME> --name <VM-NAME> 
+    ```
+    
+    > [!NOTE]
+    > The original and new disks aren't deleted during the `restore` phase.
+
+In all of the example commands these are the parameters shown:
+
+- `RG-NAME`: The name of the resource group containing the broken VM.
+- `VM-NAME`: The name of the broken VM.
+- `RESCUE-USERNAME`: The user created on the repair VM for login. It's the equivalent of the user created on a new VM in the Azure portal.
+- `RESCUE-PASS`: The password for `RESCUE-USERNAME`, enclosed in single quotes. For example: `'password!234'`.
+- `action1,action2`, etc.: One or more of the defined actions available to apply to the broken VM. See the following for a complete list of actions and in the [ALAR GitHub ReadMe](https://github.com/Azure/ALAR). You can pass one or more actions that are run consecutively. For multiple operations, delineate them using commas without spaces, like `fstab,sudo`.
 
 ## The ALAR actions
 
@@ -43,11 +90,13 @@ This action strips off any lines in the */etc/fstab* file that aren't needed to
 
 For more information about issues with a malformed */etc/fstab* file, see [Troubleshoot Linux VM starting issues because fstab errors](./linux-virtual-machine-cannot-start-fstab-errors.md).
 
-### kernel
+### efifix
 
-This action changes the default kernel. The script replaces the broken kernel with the previously installed version.
+This action can be used to reinstall the required software to boot from a GEN2 VM. The *grub.cfg* file is also regenerated.
 
-For more information about messages that might be logged on the serial console for kernel-related startup events, see [How to recover an Azure Linux virtual machine from kernel-related boot issues](kernel-related-boot-issues.md).
+### grubfix
+
+This action can be used to reinstall GRUB and regenerate the *grub.cfg* file.
 
 ### initrd
 
@@ -64,63 +113,30 @@ In both cases, the following information is logged before the error entries are
 
 ![Unpacking failed](media/repair-linux-vm-using-ALAR/unpacking-failed.png)
 
+### kernel
+
+This action changes the default kernel by replacing the default/broken kernel with a previously installed version.
+
+For more information about messages that might be logged on the serial console for kernel-related startup events, see [How to recover an Azure Linux virtual machine from kernel-related boot issues](kernel-related-boot-issues.md).
+
 ### serialconsole
 
 This action corrects an incorrect or malformed serial console configuration for the Linux kernel or GRUB. We recommend that you run this action in the following cases:
 
 - No GRUB menu is displayed at VM startup.
 - No operating system related information is written to the serial console.
 
-### grubfix
-
-This action can be used to reinstall GRUB and regenerate the *grub.cfg* file.
-
-### efifix
+### sudo
 
-This action can be used to reinstall the required software to boot from a GEN2 VM. The *grub.cfg* file is also regenerated.
+The `sudo` action resets the permissions on the */etc/sudoers* file and all files in */etc/sudoers.d* to the required 0440 modes and check other best practices. A basic check is run to detect and report on duplicate user entries and move only the */etc/sudoers.d/waagent* file if it's found to conflict with other files.
 
 ### auditd
 
-If your VM shuts down immediately upon startup due to the audit daemon configuration, use this action. This action modifies the audit daemon configuration (in the */etc/audit/auditd.conf* file) by changing the `HALT` value configured for any `action` parameters to `SYSLOG`, which doesn't force the system to shut down. In a Logical Volume Manager (LVM) environment, if the logical volume that contains the audit logs is full and there's available space in the volume group, the logical volume will also be extended by 10% of the current size. However, if you're not using an LVM environment or there's no available space, only the configuration file is altered.
+If your VM shuts down immediately upon startup due to the audit daemon configuration, use this action. This action modifies the audit daemon configuration (in the */etc/audit/auditd.conf* file) by changing the `HALT` value configured for any `action` parameters to `SYSLOG`, which doesn't force the system to shut down. In a Logical Volume Manager (LVM) environment, if the logical volume that contains the audit logs is full and there's available space in the volume group, the logical volume can be extended by 10% of the current size. However, if you're not using an LVM environment or there's no available space, only the `auditd` configuration file is altered.
 
 > [!IMPORTANT]
-> This action will change the VM's security posture by altering the audit daemon configuration so that the VM shutdown issue can be resolved. Once the VM is running and accessible, you need to revert the audit daemon configuration to the original state. For this purpose, a backup of the *auditd.conf* file is created in */etc/audit* by the ALAR action.
-
-## How to use ALAR
-
-The ALAR scripts use the repair extension `run` command and its `--run-id` option. The value of the `--run-id` option for the automated recovery is `linux-alar2`. To fix a Linux VM by using an ALAR script, follow these steps:
-
-> [!NOTE]
-> The VM Contributor role doesn't provide enough permissions to run the scripts, as they require permissions to read, write, and delete resources in the resource group that includes the target VM. Therefore roles such as Contributor or Owner at the resource group level is required.
-
-1. Create a rescue VM:
-
-    ```azurecli-interactive
-    az vm repair create --verbose -g RG-NAME -n VM-NAME --repair-username RESCUE-UID --repair-password RESCUE-PASS --copy-disk-name DISK-COPY
-    ```
-2. Run a script with one of the ALAR actions on the rescue VM:
-
-    ```azurecli-interactive
-    az vm repair run --verbose -g RG-NAME -n VM-NAME --run-id linux-alar2 --parameters ACTION --run-on-repair
-    ```
-3. Swap the OS disks and delete the temporary resources:
-
-    ```azurecli-interactive
-    az vm repair restore --verbose -g RG-NAME -n VM-NAME 
-    ```
-    
-    > [!NOTE]
-    > The original and new disks won't be deleted.
+> This action changes the VM's security posture by altering the audit daemon configuration so that the VM shutdown issue can be resolved. Once the VM is running and accessible, you need to evaluate the configuration and potentially revert it to the original state. For this purpose, a backup of the *auditd.conf* file is created in */etc/audit* by the ALAR action.
 
-Here are explanations for the parameters in the commands above:
-
-- `RG-NAME`: The name of the resource group containing the broken VM.
-- `VM-NAME`: The name of the broken VM.
-- `RESCUE-UID`: The user created on the repair VM for login. It's the equivalent of the user created on a new VM in the Azure portal.
-- `RESCUE-PASS`: The password for `RESCUE-UID`, enclosed in single quotes. For example: `'password!234'`.
-- `DISK-COPY`: The name of the OS disk copy that will be created from the broken VM.
-- `ACTION`: A scripted task to run, such as `initrd` or `fstab`.
-    You can pass over single or multiple recovery operations. For multiple operations, delineate them using commas without spaces, such as `fstab,initrd`.
 
 ## Limitation
 
@@ -133,3 +149,5 @@ If you experience a bug or want to request an enhancement to the ALAR tool, post
 You can also find the latest information about the ALAR tool on [GitHub](https://github.com/Azure/ALAR).
 
 [!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)]
+
+[!INCLUDE [Third-party contact disclaimer](~/includes/third-party-contact-disclaimer.md)]
