Skip to content

Azure VM imported to AWS – OS Disk not Booting (UEFI/GRUB Issue)

0

I migrated a virtual machine from Microsoft Azure to AWS EC2. Both the OS and data disks were imported as EBS volumes, but after attaching the imported OS volume to a new EC2 instance, it fails to boot.

Details:

  • Instance ID: i-095c20b6aad4f6f27
  • Region: us-east-2 (Ohio)
  • OS Volume ID: vol-044c3c62c7af7297c (128 GiB)
  • Data Volume ID: vol-0f1285814ad8be9d9 (64 GiB)
  • Boot mode: UEFI
  • Current instance: Ubuntu 24.04 (AMI ami-0cfde0ea8edd312d4)

The instance does not detect a bootable partition or enters recovery mode.
Can someone guide how to make the imported OS disk bootable in AWS (GRUB / fstab / driver fixes)?

Account ID: 073987695811

1 Answer
0

These kinds of Azure-to-AWS boot issues are quite common, especially when the OS disk is imported directly. The fact that your disk is UEFI-based, and AWS is failing to detect a bootable partition, tells me you’re most likely running into a GRUB or EFI System Partition (ESP) problem

You're importing an Ubuntu 24.04 VM from Azure into AWS EC2, with both OS and data disks coming over as EBS volumes. You're attaching the OS volume to a new EC2 instance (based on AMI ami-0cfde0ea8edd312d4), but the instance does not boot.

This typically means either:

The GRUB bootloader or EFI partition is missing or not correctly configured

The boot mode used for the instance does not match the OS disk's expected mode (UEFI vs BIOS)

The OS lacks necessary AWS drivers (ENA for networking, NVMe for disk)

There are errors in fstab or initramfs

Step 1: Check Volume Partition Structure

Attach the OS volume to a healthy Ubuntu EC2 instance as a secondary disk. Use lsblk, fdisk -l, or parted to confirm:

The disk uses GPT partitioning (required for UEFI boot)

There is an EFI System Partition (usually 100-500 MB, vfat format, type "EFI System")

The root partition (likely ext4) is intact

If the EFI partition is missing, you’ll need to recreate it and reinstall the bootloader. If it's present but unmounted or empty, that’s also a red flag.

Step 2: Mount and Chroot into the OS Disk

Once you've attached the disk to a helper instance:

sudo mkdir /mnt/os sudo mount /dev/nvme1n1p2 /mnt/os # Adjust to your root partition sudo mount /dev/nvme1n1p1 /mnt/os/boot/efi # Mount the EFI partition if available sudo mount --bind /dev /mnt/os/dev sudo mount --bind /proc /mnt/os/proc sudo mount --bind /sys /mnt/os/sysStep 4: Validate fstab and Initramfs

Check that /etc/fstab references the correct UUIDs for root and EFI partitions using blkid

Regenerate initramfs:

sudo chroot /mnt/os

Step 3: Reinstall GRUB for UEFI

Inside the chroot:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck update-grub

Then exit the chroot and unmount everything:

exit sudo umount /mnt/os/boot/efi sudo umount /mnt/os/{dev,proc,sys} sudo umount /mnt/os

Step 4: Validate fstab and Initramfs

Check that /etc/fstab references the correct UUIDs for root and EFI partitions using blkid

Regenerate initramfs:

update-initramfs -u -k all

This ensures the correct modules (e.g., NVMe, ENA) are included for AWS.

Step 5: Confirm Instance Boot Mode and Type

Since the imported disk uses UEFI, the EC2 instance must be launched in UEFI mode. AWS only supports UEFI boot on certain instance types that use the Nitro hypervisor (e.g., m5, c5, t3, etc). Also, ensure that the instance is launched without a pre-attached root volume so that your imported OS disk is treated as the root device.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/uefi.html

Step 6: Launch and Test

Now that the disk is prepped:

Detach it from the helper instance

Attach it as /dev/xvda or /dev/nvme0n1 to a Nitro-based instance

Boot and monitor the system log from EC2 Console > Instance Settings > Get System Log

If it boots, you're in. If it drops to recovery mode, check logs like /var/log/boot.log or dmesg for errors related to root volume or missing drivers.

Troubleshooting Scenarios

If GRUB says it can’t find the root filesystem, verify UUIDs in /etc/fstab and /boot/grub/grub.cfg

If the system boots into emergency mode, it often means missing or incorrect drivers in initramfs

If you see "no bootable disk found", it usually points to either no valid ESP, or wrong instance boot mode

Pro Tips for Repeatable Success

Always ensure UEFI boot mode is explicitly specified when using VM Import/Export. If not, AWS may default to BIOS

Keep a known-good Ubuntu AMI on AWS and use it to chroot and fix imported disks

For future imports, consider using cloud-init compatible images or baking an image with the AWS CLI, Packer, or EC2 Image Builder

Automate your fixes (GRUB reinstall, initramfs regen, etc.) as a shell script for consistency

Resources

VM Import/Export Prerequisites : https://docs.aws.amazon.com/vm-import/latest/userguide/prerequisites.html

https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html

https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-troubleshooting.html

https://aws.amazon.com/about-aws/whats-new/2021/03/amazon-ec2-now-supports-uefi-boot-when-migrating-virtual-machines-to-ec2/

f you’re planning more of these migrations, it may be worth designing a migration flow that includes pre-conversion of disks, automated compatibility fixes, and validation scripts. That way, every VM import becomes repeatable and reliable.

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.