Q: What is the Amazon Linux AMI?

The Amazon Linux AMI is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2). It is designed to provide a stable, secure, and high performance execution environment for applications running on Amazon EC2. It also includes packages that enable easy integration with AWS, including launch configuration tools and many popular AWS libraries and tools. Amazon Web Services provides ongoing security and maintenance updates to all instances running the Amazon Linux AMI. The Amazon Linux AMI is provided at no additional charge to Amazon EC2 users.

Q: Can I view the source code to the Amazon Linux AMI?

Yes. The get_reference_source command line tool provided in the Amazon Linux AMI enables viewing of source code inside of Amazon EC2.

Q: Where can I get updates for the Amazon Linux AMI?

Updates are provided via a pre-configured yum repository hosted in each Amazon EC2 region. Security updates are automatically applied on the initial boot of the AMI. Upon login, the Message of the Day (/etc/motd) indicates whether or not any additional updates are available.

Q: How often will updates for the Amazon Linux AMI be available?

The Amazon Linux AMI image is updated to include the latest components on a regular basis, and these updates are also made available in the yum repositories for installation on running instances.

Q: Does Amazon provide support for the Amazon Linux AMI?

Yes. The Amazon Linux AMI is supported through subscriptions to AWS Support. More details can be found on the AWS Support page.

Q: Will the Amazon Linux AMI be supported outside of EC2?

No. The Amazon Linux AMI is only available for use inside of Amazon EC2.

Q: How do I report bugs or make feature and package requests?

We use the Amazon EC2 Discussion Forum for bug reports, feature requests, and package requests. These forums are monitored by AWS Developer Support as well as the Amazon Linux AMI engineering team.

Q: How do I enable the Extra Packages for Enterprise Linux (EPEL) repository?

Modify /etc/yum.repos.d/epel.repo. Under the section marked [epel], change enabled=0 to enabled=1.

To temporarily enable the EPEL 6 repository, use the yum command line option --enablerepo=epel.

Please note that the Amazon Linux AMI repositories are configured with a higher priority than any third-party repositories. The reason for this is because there are several packages that are part of the Amazon Linux AMI that are also in third-party repositories, and we want to make sure that the Amazon Linux AMI version is installed in the default case.

Q: How do I lock my AMI to a specific version?

Beginning with the 2011.09 release of the Amazon Linux AMI, the repository structure is configured to deliver a continuous flow of updates that allow you to roll from one version of the Amazon Linux AMI to the next.

For instance, launching the 2014.03 Amazon Linux AMI and running yum update -y will leave you with the same updates as launching a 2014.09 AMI and running yum update -y.

In other words, Amazon Linux AMIs are treated as snapshots in time, with a repository and update structure that gives you the latest packages that we have built and pushed into the repository.

That said, some of you may not want this functionality immediately, until you are ready to upgrade to 2014.09. Perhaps you want to launch a 2013.09 AMI or a 2014.03 AMI and have it only receive the updates that were released during the time that AMI was the latest version.

The feature that we call lock-on-launch takes advantage of cloud-init to implement this use case.

To enable this feature in new instances, launch (for example) a 2014.03 Amazon Linux AMI with the following user data passed to cloud-init, either via the EC2 console or via ec2-run-instances with the the -f flag.

#cloud-config
repo_releasever: 2014.03

To lock existing instances to their current version (indicated in /etc/system-release), edit /etc/yum.conf. Comment out the line that reads releasever=latest and run yum clean all to clear the cache.

Q: How do I disable the automatic installation of critical and important security updates on initial launch?

On first boot, the Amazon Linux AMI installs from the package repositories any user space security updates that are rated critical or important, and it does so before before services, such as SSH, start.

If the AMI cannot access the yum repositories, it will timeout and retry multiple times before completing the boot procedure. Possible reasons for this are restrictive firewall settings or VPC settings, which prevent access to the Amazon Linux AMI package repositories.

If you encounter this issue you can either modify your environment so that the Amazon Linux AMI can connect to its package repositories or you can disable the security update on boot.

To disable the security update on boot from the AWS EC2 Console:

On the "Advanced Instance Options" page in the Request Instances Wizard, there is a text field for sending the Amazon Linux AMI user-data. This data can be entered as text, or uploaded as a file. In either case, the data should be:

#cloud-config
repo_upgrade: none

To disable the security update on boot from the command line:

Create a text file with the preceding user-data, and pass it to ec2-run-instances with the -f flag. The cloud-init user data can also be base64-encoded and then passed in on the command line with the -d flag.

To disable the security update on boot when rebundling the Amazon Linux AMI:

Modify /etc/cloud/cloud.cfg and change repo_upgrade: security to repo_upgrade: none.

Q: Why does it take a long time for SSH to start up when running in a Virtual Private Cloud (VPC) without an Internet Gateway or NAT instance?

See the answer to the previous question.

Q: Why do my RAID arrays start at /dev/md127 instead of /dev/md0?

Newer versions of mdadm create RAID arrays with version 1.2 superblocks, which do not automatically assemble with a numbered device. Reference partitions by setting a label for the file system. Most file system creation tools use the -L flag to set the label. Once set, the label is referenced by mount or in /etc/fstab with LABEL=[NAME].

Example: Creating a RAID0 array with a label.

mdadm --create --verbose /dev/md0 --level=0 --name=0 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 -L RAID0 /dev/md0
mkdir -p /mnt/RAID0
mount LABEL=RAID0 /mnt/RAID0

Example: Setting the label of an existing ext[2-4] file system.

e2label /dev/md127 RAID
mkdir -p /mnt/RAID
mount LABEL=RAID /mnt/RAID

Q: Why was the wheel group disabled from /etc/sudoers and how do I re-enable it?

Linux operating systems have different defaults in terms of whether or not wheel is enabled for sudo. We believe that having wheel disabled from sudo by default is a more sensible security posture for the Amazon Linux AMI.

There are two workarounds to this issue, which differ depending on whether or not you have the ability to SSH into your instances as the default ec2-user, and whether or not you have altered that user's ability to use sudo.

Option #1: For users who have not changed any of the defaults, you should still be able to ssh into your instance as ec2-user and from there invoke sudo to gain root, at which point you can modify the sudoers file to re-enable wheel.

Option #2: For users who have changed the defaults or who don’t have the ability to sudo from ec2-user to root, we recommend the following steps:

  • Stop the affected instance (do not terminate).
  • Detach the root EBS volume, using either the EC2 Console or the EC2 API tools.
  • Attach the volume to another EC2 instance to which you have remote root access.
  • Login into that instance.
  • Mount the newly attached volume.
    sudo mount /dev/xvdf /mnt
  • Modify the sudoers file in the attached volume and uncomment the wheel group.
    sudo sed -i.bak 's,# \(%wheel\s\+ALL=(ALL)\s\+ALL\),\1,' /mnt/etc/sudoers
  • Unmount the volume.
    sudo umount -d /dev/xvdf
  • Detatch the volume
  • Reattach the volume to your stopped instance (make sure that the device is the same as it was before the detachment, usually: /dev/sda1).
  • Start the affected instance.

Q: Why do I see strange characters like � or â when talking to the Amazon Linux AMI via a terminal?

The Amazon Linux AMI uses the UTF-8 character encoding by default. Client terminals not using the UTF-8 encoding will not always translate UTF-8 characters correctly. To fix this, set your client terminal encoding to UTF-8:

  • Gnome Terminal: From the Terminal menu choose Set Character Encoding and select UTF-8.
  • PuTTY: Right click on the title bar to bring up the menu. Then choose Change Settings. Under Window → Translation → Remote Character Set choose UTF-8.

Q: I see an option report_instanceid in /etc/yum.repos.d/amzn*.repo. What does this do?

The Amazon Linux AMI repositories are S3 buckets in each region. When the yum process on your instance downloads packages from those buckets, information about that S3 connection is logged.

Within the context of the Amazon Linux AMI, the report_instanceid=yes setting allows the Amazon Linux AMI repositories to also log the instance id (i-xxxxxxxx) and region (e.g. us-west-2) of an instance downloading a package. This enables the Amazon Linux AMI team to provide more focused and specific customer support to individual instances.

report_instanceid=yes is enabled by default only for the Amazon Linux AMI repositories.

Q: Why are the /etc/yum.repos.d/amzn*.repo yum repository configuration files overwritten when the system-release package is upgraded?

These repository configuration files are overwritten when the system-release package is upgraded to ensure that instances always see changes to the Amazon Linux AMI yum repository configuration.

For Amazon Linux AMI versions before 2014.09:

These files are generated by cloud-init from templates located at /etc/cloud/templates/amzn-*.repo.tmpl. Changes made to these template files will persist.

For Amazon Linux AMI 2014.09 and later:

/etc/yum.repos.d/amzn*.repo files now use yum variables to help instances reach the geographically-closest repositories, so we no longer use cloud-init templates. Any edits to these files will be preserved as /etc/yum.repos.d/amzn*.repo.rpmsave when system-release is upgraded.

Users upgrading to 2014.09 will see any edits made to /etc/yum.repos.d/amzn*.repo files saved as /etc/yum.repos.d/amzn*.repo.rpmsave.

Q: How can I change or turn off man page colors?

Man page colors are configured in /etc/profile.d/less.sh (bash and zsh) and /etc/profile.d/less.csh (csh). To turn them off, remove all lines starting with export LESS_ (bash, zsh) and/or setenv LESS_ (csh).