- Newest
- Most votes
- Most comments
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
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
Relevant content
asked 2 years ago
asked 9 months ago
asked 3 years ago
