- 最新
- 最多得票
- 最多評論
Thank you for reporting this. We are able to reproduce the issue, have identified the root cause, and are working on a fix. We'll update this post when the fix has been deployed.
In the meantime, we suggest creating AMIs on Graviton2 instances (c6g/m6g/r6g) as a workaround. These AMIs can be used on Graviton3 instances without issue.
I'll keep an eye on the post. Thanks!
I just wanted to let you know that the fix for this issue has been deployed. Thank you for bringing the issue to our attention!
While we work on a general fix, you can work around this by executing the following command before creating a AMI on the c7g instance which removes the the EFI Internal Shell from the valid boot options so when the AMI in started on a new instance it will boot via the default media path. After executing the below, either stop your instance and create the image or create the image directly (nominally resulting in an instance reboot). After the reboot you'll have to execute this one-liner again to successfully re-create the image a second time.
sudo efibootmgr -B -b `efibootmgr | grep "EFI Internal Shell" | sed -r 's/Boot0*([0-9]+).*/\1/'`
Does it work with the standard Ubuntu 20.04 AMI for the region? You can find the list of Canonical-published AMIs here (https://cloud-images.ubuntu.com/locator/ec2/) and entering "20.04 arm64" in the search box.
Hi Michael_F. Yes, I can spin up instances (e.g. c7g.medium) and play around. The problem is only when I store the image, and try to spin up another instance from the new AMI.
Hi @afody, thanks for reporting this. I'm able to reproduce your issue and am escalating internally.
@afody Does it work for you if you build your AMI from a c6g.medium instance as the source? Can you then launch that on a c7g.medium instance?
Sorry that I didn't see your comment earlier. I took one of the many AMIs stored in the account (and created with a Graviton2 instance); I had no problem spinning up and connecting to a c7g.medium instance.