By using AWS re:Post, you agree to the Terms of Use
/Problems with AMIs from Graviton3/

Problems with AMIs from Graviton3


Hello, For the last 4/5 days I've tried to spin up instances from AMIs created with Graviton3. The original OS is Ubuntu 20.04 and the image was created without any apparent problem. However, these AMIs haven't worked yet: the console keeps showing the instance as "initializing" and I cannot log in on the instance. I have completed this process literally hundreds of times with different combinations of instances and OSs, but never ran into this issue. Thanks. P.S. Just for completeness, I launched a c7g.medium with ALinux2 (which is not my usual choice), updated it, created a text file in the home directory, and created the AMI. It doesn't work either, same problem.

  • Does it work with the standard Ubuntu 20.04 AMI for the region? You can find the list of Canonical-published AMIs here ( 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.

asked a month ago82 views
2 Answers

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.

answered a month ago
  • I'll keep an eye on the post. Thanks!


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/'`
answered a month 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.

Guidelines for Answering Questions