adding sudo and general doc updates

Adding the sudo action, reorg doc for clarity and to address comments

Author: pagienge

support/azure/virtual-machines/linux/repair-linux-vm-using-ALAR.md

@@ -3,8 +3,7 @@ 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.
 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 3 parameters which will prompt for values if they are not 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
+    ```
+    
+    valid action names will be given below.
+
+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 won't be deleted.
+
+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-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'`.
+- `action1,action2`, etc.: One or more of the defined actions available to apply to the broken VM.  See the complete list of actions below, and in the [ALAR github ReadMe](https://github.com/Azure/ALAR). You can pass one or more actions which will be run consecutively. For multiple operations, delineate them using commas without spaces, such as `fstab,sudo`.
 
 ## The ALAR actions
 
@@ -43,12 +90,6 @@ 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
-
-This action changes the default kernel. The script replaces the broken kernel with the 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).
-
 ### initrd
 
 This action can be used to fix an initrd or initramfs that is either corrupted or incorrectly created.
@@ -64,6 +105,12 @@ 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:
@@ -81,46 +128,11 @@ This action can be used to reinstall the required software to boot from a GEN2 V
 
 ### 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 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 `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.
+> 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 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.
 
-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.
-
-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