g6.xlarge boot-loops in EFI shell — EBS root volume not visible in UEFI device map after stop/start

This appears to be a device mapping issue where the EBS root volume isn't being properly presented to the instance during boot. Here's how to address this:

Immediate Recovery Steps:

1. Stop the instance (which you've already done)

2. Detach the root EBS volume (vol-02252b08739766b05)

3. Launch a rescue instance in the same availability zone (ap-south-1b) - use a working instance type with a similar configuration

4. Attach your root volume to the rescue instance as a secondary volume (e.g., /dev/sdf). This will allow you to access the file system and examine/repair any boot configuration issues.

5. Mount the volume on the rescue instance and check:

• EFI boot configuration files
• /etc/fstab for any device mapping issues
• System logs that might indicate what caused the boot failure

6. Review and fix any device mapping problems in the boot configuration

7. Detach the volume from the rescue instance, reattach it to your original instance as /dev/sda1, and start the instance

Alternative Approach if Recovery Fails:

If the above doesn't resolve the issue, you may need to:

• Create a new AMI from the repaired volume with corrected device mappings
• Launch a fresh g6.xlarge instance from that AMI

This approach effectively forces placement on a different host while preserving your data and configuration. The key is using the rescue instance to access the file system and identify what's preventing the UEFI firmware from recognizing the boot volume.
Sources
Troubleshoot Amazon EC2 Linux instances with failed status checks - Amazon Elastic Compute Cloud
Resolve EC2 connection and startup issues | AWS re:Post

To me the re:Post Agent's response misses the core issue. Because your UEFI mapping table completely lacks a second block device (only showing the ephemeral NVMe as BLK0), the firmware is not seeing the EBS hardware layer at all. Inspecting /etc/fstab or boot configs via a rescue instance won't help if the hypervisor isn't presenting the disk.

This is highly likely a Nitro hypervisor presentation failure or a host-level NVMe initialization timeout. Here is how to force a host migration and resolve it:

1. Force a Host Migration

A standard stop/start often lands your instance back on the same physical host. To force EC2 to schedule you on a completely fresh Nitro host and re-initialize the NVMe mappings:

1. Stop the instance.
2. Change the instance type to a different size or family (e.g., change g6.xlarge to g6.2xlarge or g5.xlarge).
3. Start the instance.
4. If it boots successfully, stop it again and revert back to g6.xlarge.

2. Verify AMI Boot Attributes via CLI

Ensure the volume/AMI descriptor didn't lose its UEFI flag, which is strictly required by G6 instances:

aws ec2 describe-instances --instance-ids i-03c675291f9021089 --query "Reservations[*].Instances[*].{Architecture:Architecture,BootMode:BootMode}" --output json

• • Architecture must be x86_64 (G6 utilizes AMD EPYC).
• • BootMode must be uefi or uefi-preferred. Try the instance type change first. It forces a clean hardware detachment and attachment on a fresh physical host, which usually solves the "invisible to UEFI" loop on modern Nitro generations.