projects::arch linux on ec2

Arch Linux
Amazon Web Services

summary

Arch Linux's minimalistic philosophy and high degree of customizability makes it a great choice for compute cloud deployment. It's light, fast, and scalable.

I am doing releases of Arch Linux as Amazon EC2 AMIs roughly twice per month.

contact

IRC Join us on irc.freenode.net in #archlinux-ec2!

If you find a bug or have any other comments, please send me an email, or ping me on twitter.

NOTE: This project is not run, sponsored, or endorsed by my employer.

current releases

Release 2014.04.10

HVM Images

region ebs
hvm
x86_64
s3
hvm
x86_64
ebs
hvm gpu
x86_64
s3
hvm gpu
x86_64
us-east-1 ami-9d8b97f4 ami-9b8b97f2 ami-4d8f9324 ami-4b8f9322
us-west-1 ami-1eba835b ami-1cba8359 ami-caba838f ami-c8ba838d
us-west-2 ami-9a244eaa ami-98244ea8 ami-e2244ed2 ami-fe244ece
eu-west-1 ami-bf1be0c8 ami-b11be0c6 ami-a71be0d0 ami-b91be0ce
ap-southeast-1 ami-080d5e5a ami-0a0d5e58
ap-southeast-2 ami-574ad26d ami-514ad26b
ap-northeast-1 ami-b9542db8 ami-b7542db6
sa-east-1 ami-ab5cfeb6 ami-a95cfeb4

Paravirtual Images

region ebs
paravirtual
x86_64
s3
paravirtual
x86_64
ebs
paravirtual
i386
s3
paravirtual
i386
us-east-1 ami-338c905a ami-318c9058 ami-2f859946 ami-2b859942
us-west-1 ami-cebb828b ami-ccbb8289 ami-2abb826f ami-28bb826d
us-west-2 ami-b8254f88 ami-b6254f86 ami-963e54a6 ami-943e54a4
eu-west-1 ami-1b19e26c ami-1f19e268 ami-2319e254 ami-2519e252
ap-southeast-1 ami-dc0d5e8e ami-de0d5e8c ami-c00d5e92 ami-c20d5e90
ap-southeast-2 ami-934ad2a9 ami-9f4ad2a5 ami-954ad2af ami-974ad2ad
ap-northeast-1 ami-99572e98 ami-97572e96 ami-8b572e8a ami-89572e88
sa-east-1 ami-315dff2c ami-375dff2a

Release 2014.04.04

HVM Images

region ebs
hvm
x86_64
s3
hvm
x86_64
ebs
hvm gpu
x86_64
s3
hvm gpu
x86_64
us-east-1 ami-f3a5b69a ami-f1a5b698 ami-6ba5b602 ami-69a5b600
us-west-1 ami-f02811b5 ami-f62811b3 ami-fc2811b9 ami-f22811b7
us-west-2 ami-586d0668 ami-566d0666 ami-7e6d064e ami-7c6d064c
eu-west-1 ami-ab3ac2dc ami-ad3ac2da ami-c33ac2b4 ami-c53ac2b2
ap-southeast-1 ami-3acd9d68 ami-34cd9d66
ap-southeast-2 ami-edb921d7 ami-efb921d5
ap-northeast-1 ami-81364880 ami-7f36487e
sa-east-1 ami-3d72d020 ami-0372d01e

Paravirtual Images

region ebs
paravirtual
x86_64
s3
paravirtual
x86_64
ebs
paravirtual
i386
s3
paravirtual
i386
us-east-1 ami-93a4b7fa ami-91a4b7f8 ami-31a4b758 ami-3fa4b756
us-west-1 ami-1c2b1259 ami-122b1257 ami-582b121d ami-5e2b121b
us-west-2 ami-186c0728 ami-166c0726 ami-566c0766 ami-546c0764
eu-west-1 ami-0f3cc478 ami-013cc476 ami-4b3cc43c ami-4d3cc43a
ap-southeast-1 ami-2acd9d78 ami-24cd9d76 ami-22cd9d70 ami-3ccd9d6e
ap-southeast-2 ami-3bba2201 ami-c5b921ff ami-cdb921f7 ami-cfb921f5
ap-northeast-1 ami-61374960 ami-5f37495e ami-0d37490c ami-0b37490a
sa-east-1 ami-5d72d040 ami-2372d03e ami-2972d034 ami-2f72d032

tools

The EC2 image build process is public, but the AMI registration portion is not. Here are the necessary tools to create an image file, but see the 2013-05-26 news post for information on how to register the images in EC2.

  • ami-build-backend - These files are held on the PXE server, and fetched when the guest boots.
  • ami-builder-image - This is a fork of archiso with some changes to automatically pull down my install script and do a few other things.
  • ec2-packages - These are the sources for all the packages contained in the 'ec2' Pacman repository.

recent changes and news

  • 2014-03-24

    We're up to Linux 3.13.7 for the ec2 kernel and 3.10.34 for the ec2-lts kernel. I didn't make a news post earlier, but kernels are now built with 'debug' and 'strip' options, which will create split-out debug information packages (i.e. linux-ec2-debug, linux-ec2-lts-debug). This is useful for tools like perf, oprofile, and systemtap. Note that the -debug packages are compressed with 'lrzip'. New AMI builds have lrzip preinstalled, but if you're running an instance based on one of the older AMIs, you will need to install lrzip before you can make use of the -debug packages.

  • 2013-11-28

    New AMIs are being built right now and contain a couple changes:

    • EBS root volumes are now automatically resized to fill the block device. You can take advantage of this feature by launching an instance with a root volume size larger than the snapshot.
    • The resolv.conf file permissions are now 0644, allowing non-root users to resolve hostnames.

  • 2013-11-26

    Geoff H. and David B. both reported an issue with the current AMI release. The /etc/resolv.conf permissions are set to 0600 rather than 0644, which means that non-root users cannot resolve hostnames to IP addresses. This is an unintentional regression, most likely caused by a default 'umask' change in some package (systemd?). dhclient will create a new resolv.conf and copy it over any existing file, which preserves the target file's permissions. But if no such file exists, then the permissions of the source file are copied. Previously, this worked fine because the file was generated with 0644 permissions, but now it's being generated with 0600. I've implemented a fix for future AMI builds. In the meantime, if non-root users need to perform DNS requests in your instances, be sure to do 'chmod 0644 /etc/resolv.conf'.

  • 2013-11-06

    A new ec2-pacman-mirrors package is available, and will provide your instances with optimal Arch Linux mirrors for your EC2 region. The upgrade path is as follows:

    1. Edit /etc/pacman.conf, change 'ec2' mirror URL to https://s3.amazonaws.com/arch-linux-ami/repo/$arch
    2. Run 'pacman -Sy ec2-pacman-mirrors'

    New AMIs will be published very shortly which use the new mirror list and point to the new EC2 package repository.

  • 2013-10-29

    The in-EC2 mirrors are currently offline, and may not be up again anytime soon. I've received offers from people to host package mirrors for the EC2-specific packages, and I will update this page as needed. Users should migrate to one of the official public Arch Linux mirrors for every repository except 'ec2'.

  • 2013-05-26

    I've added some links to this page, which are the complete set of files needed to do an EC2 image build. This does not include the AMI registration process, however. The tools Amazon provides for HVM AMI registration are still under NDA at the moment, and the bits necessary to do that are included in my AMI registration tools. So I can't make those public right now. The process itself can be replicated relatively easily, though:

    1. Build your VM image using the build-backend and builder-image repos above. PXE is what I use, but you could just as easily make it into an ISO or something. If you intend to do an S3-backed AMI, you will need to make the image no larger than 10GB (I use 8GB).
    2. Trim the image down (I do a 'mount -o loop,discard' on the image, then 'fstrim' the mount point, making the image into a sparse file).
    3. Tarball the image (tar cSzf, S to preserve the sparseness).
    4. Upload the tarball to S3.
    5. In each region, launch an instance and attach an empty 8GB EBS volume to them.
    6. On each of those instances, download the tarball and extract with 'tar xSf'.
    7. Use 'ddpt', an enhanced dd which pays attention to the sparseness of the image, to copy the raw image file into the EBS device. I use "ddpt if=<imagefile> of=/dev/xvdf bs=512 conv=sparse oflag=sparse,fsync". The sparseness aspect is important, because otherwise you're copying empty blocks onto the EBS device, which makes the snapshot take much longer, and is really just a waste of time. EBS volumes already read-as-zero, so there's no sense copying zero blocks.
    8. Detach the EBS volume and terminate the instances.
    9. Snapshot the EBS volume.
    10. Delete the volume (not needed now).
    11. Use ec2-register to create an AMI from the snapshotted volume.

  • 2013-03-22

    I've started creating AMIs which have CUDA preinstalled. These are for the cg1.4xlarge instance type.

  • 2013-02-05

    Nothing too exciting lately. Today's release has Linux 3.7.6.

    I have also built some Debian stable and testing AMIs for x86_64 in each region. You can find them with the EC2 API tools: ec2-describe-images -o 460511294004 -F "name=debian-*"

  • 2012-11-22

    New AMI releases, now with cloud-init. Thanks to Jeremy D for contributing his time and effort to making cloud-init work well on Arch Linux.

  • 2012-11-12

    Released new AMIs, primarily for the new AWS region in Sydney, Australia (ap-southeast-2). This new build also includes EC2-hosted Arch Linux mirrors for packages, local to each region.

  • 2012-11-08

    Today's AMIs are released. Nothing too fancy in this build: just updated packages, including linux-ec2 3.6.6-1.

  • 2012-10-21

    I've added a new linux-ec2 package which contains a patched v3.6.2 kernel. There are a few major differences between this kernel and the Arch Linux stock kernel:

    • Hangs on Xen fixed (patches from 3.6.3 stable-queue).
    • CONFIG_PREEMPT_VOLUNTARY instead of CONFIG_PREEMPT, this will allow for better scheduling as a domU.
    • CONFIG_HZ=100 instead of CONFIG_HZ=300, this allows for better performance on many-CPU instances, as there are fewer timer interrupts to preempt other tasks.
    • Many drivers removed, particularly those that didn't make sense for running in an EC2 instance. I've left drivers for my own hardware so I can experiment with it as a dom0 kernel as well. The kernel size is roughly half the stock Arch Linux kernel due to the stripped drivers.

    I am also building new AMIs right now, and am beating the i386 AMIs into working order. Once done I'll publish the next release (which should be 2012.10.21). Once it's available, it will show in the tables above.

  • 2012-10-16

    Do not upgrade HVM instance kernels to anything between 3.6.0 and 3.6.2 inclusive. You must wait for 3.6.3 or else your instance will not boot. We're currently waiting on this patch to be integrated into the mainline stable tree. This is also why I am probably not doing an AMI release this week, as the HVM AMIs would be totally broken.

    I've also taken a look at building i386 (well, i686) AMIs. I'm not really sure that it's worth the effort. Nobody really uses 32-bit AMIs anymore, and we'd need to fork the kernel just to make it happen. For now, i686 is on ice.

release notes

These AMIs are as close to a "vanilla" install as I can make them without making them functionally impaired on EC2. But here's the complete list of differences between the EC2 builds and a stock install:

  • High performance kernel specifically for EC2, including paravirtualization support on i386 and x86_64 AMIs, and more Xen-friendly process scheduling.

  • Kernel modules included in initrd, some of which are relevant outside of EC2 contexts (e.g. if you want to run the image in a non-EC2 environment such as KVM or Hyper-V):

    • KVM: virtio virtio-blk virtio-net virtio-pci virtio-ring
    • Xen: xen-blkfront xen-fbfront xen-kbdfront xen-netfront xen-pcifront xen-privcmd
    • Hyper-V: hv_storvsc hv_balloon hv_vmbus hv_utils hv_netvsc
    • IPMI (e.g. EC2 reboot request): button ipmi-msghandler ipmi-poweroff
    • EC2 enhanced networking SR-IOV driver: ixgbevf
  • Extra packages installed: audit, cloud-init, dhclient, ec2-keyring, ec2-pacman-mirrors, irqbalance, lrzip, netctl, ntp, openssh, rng-tools, rsync, systemd-sysvcompat

  • Added an extra package source for ec2-specific packages. The repository currently contains numerous packages useful on EC2. You can view the list of packages by doing 'pacman -Sy; pacman -Ss | grep ^ec2'

  • Additional services enabled at boot: rngd, sshd, netctl, cloud-init, irqbalance, auditd, ntpd

  • User's public key is pulled from the EC2 instance metadata service at startup, and added to /root/.ssh/authorized_keys

  • SSH configured with 'PasswordAuthentication no', enforcing public key authentication

  • pacman loads (and automatically lsigns) the 'archlinux' and 'ec2' keyrings on the first boot (the latter keyring contains my public key used for package signing in the ec2 repo).

  • pacman mirror list is automatically selected at boot based on a list I created (based on rankmirrors run on instances in each region). These lists are provided by the package ec2-pacman-mirrors, which is in the ec2 repo.

  • dhclient is used instead of dhcpcd for robustness reasons. I found that dhcpcd gave up too quickly if it tried to do a DHCPREQUEST when the vif wasn't completely up, making the EC2 instance inaccessible.

  • dhclient is configured to retry forever, and request the following dhcp options: subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, interface-mtu, fqdn

  • /usr/bin/pinentry is symlinked to /usr/bin/pinentry-curses instead of the default pinentry-gtk, since gtk isn't available in this install and the primary access method is SSH.