1. See what the VM sees
az vm boot-diagnostics get-boot-log -g rg-app -n vm-app01 | tail -50 # Linux
az vm boot-diagnostics get-boot-log-uris -g rg-app -n vm-app01 # screenshot URI
| Screen or log shows | Likely cause | Go to |
|---|---|---|
INACCESSIBLE_BOOT_DEVICE, "Boot configuration data is missing" | Windows BCD / driver | 3A |
| "Getting Windows ready", "Undoing changes" loop | Pending update | 3B |
emergency mode, "Dependency failed for /data" | Linux /etc/fstab | 3C |
grub rescue> / kernel panic after update | GRUB / kernel | 3D |
| Boot hangs, disk full messages | Full OS disk | 3E |
2. First, try the serial console
Azure portal → VM → Serial console. Linux emergency mode and the Windows SAC (cmd, ch -si 1) often let you fix it in place, without a repair VM.
3. Repair VM (when in-place doesn't work)
az extension add -n vm-repair
az vm repair create -g rg-app -n vm-app01 --repair-username repairadmin --repair-password '...' --verbose
This snapshots and copies the OS disk and attaches the copy to a new repair VM. The original disk is not modified until you restore.
3A. Windows BCD
bcdedit /store F:\boot\bcd /enum
bcdedit /store F:\boot\bcd /set {bootmgr} device partition=F:
bcdedit /store F:\boot\bcd /set {default} device partition=G:
bcdedit /store F:\boot\bcd /set {default} osdevice partition=G:
(F: = system reserved partition, G: = Windows partition on the attached disk; check letters first.) az vm repair list-scripts shows built-in repair scripts you can run with az vm repair run.
3B. Pending update loop
dism /image:G:\ /get-packages | findstr Pending
dism /image:G:\ /cleanup-image /revertpendingactions
3C. Linux fstab: mount the copied OS disk on the repair VM, edit etc/fstab: comment out the failing line, or add nofail to non-root data disks; use UUID= not /dev/sdX.
3D. GRUB / kernel: chroot into the disk (az vm repair run --run-id linux-alar2 --parameters initrd or kernel handles common cases), regenerate initramfs or set the previous kernel as default.
3E. Full OS disk: delete old logs and package caches on the mounted disk, or expand the disk (see the expand OS disk post).
4. Swap the fixed disk back
az vm repair restore -g rg-app -n vm-app01 --verbose
The VM's OS disk is swapped to the repaired copy. Start the VM and check boot diagnostics. Keep the original disk for a few days in case you need it.
5. If repair isn't possible
Restore from Azure Backup (restore disks or replace existing), or fail over with Site Recovery. Decide this early if the RTO is tight: the backup path is often faster than a long repair.
Tip
Add
nofailto every data disk in/etc/fstaband enable boot diagnostics with a managed storage account on every VM. These two settings turn many Sev1 boot failures into a 5-minute fix.