Amazon Linux AMI FAQs

General Questions

Technical Questions

General Answers

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.

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.

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.

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.

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.

Will the Amazon Linux AMI be supported outside of EC2?

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

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.

Technical Answers

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.

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 2012.03 Amazon Linux AMI and running yum update -y will leave you with the same updates as launching a 2012.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 2013.03. Perhaps you want to launch a 2012.03 AMI or a 2012.09 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 2012.09 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: 2012.09

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.

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.

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.

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

What steps do I take to upgrade from PostgreSQL 9.1 to 9.2?

Please note that you can avoid this issue entirely by running the latest Amazon Linux AMI, on which PostgreSQL 9.2 is the default.

PostgreSQL 9.2 offers important new features and performance improvements and it has been included in the Amazon Linux AMI 2012.09 release based on customer requests.

After upgrading PostgreSQL from 9.1 to 9.2, the database service will no longer start. This happens because the 9.1 version of the database format is not immediately usable with the 9.2 server. We have provided the postgresql-upgrade package as an automatic install alongside the latest release of postgresql 9.2. This allows you to perform an in-place upgrade on your database using service postgresql upgrade.

Behind the scenes, this runs pg_upgrade to migrate your database to the new format. Note that the upgrade will reset configuration files such as pg_hba.conf to a clean state. Your old configuration files are stored in /var/lib/pgsql9/data-old, and can be copied over the default files in /var/lib/pgsql9/data after your review.

Once the upgrade is finished and the configuration files are restored, the service should start normally.

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.
©2013, Amazon Web Services, Inc. or its affiliates. All rights reserved.