Linux.com

Home Linux Community Community Blogs General Linux Creating an EBS backed Debian Squeeze Linux AMI for Amazon EC2

Creating an EBS backed Debian Squeeze Linux AMI for Amazon EC2

Following on from my post on how to create an S3 backed custom AMI for AWS EC2, I thought I would jot down the steps to go through if you wanted to make use of persistent disk storage by using Amazon’s Elastic Block Storage (EBS).

In my recipe I decided to use as a base AMI, the original S3 image that I rolled in my previous post:

After starting up an AWS instance using the S3 custom AMI I created, I went through the following process. – There are better ways to approach this, but this is a good starting point for anyone that is starting to experiment with the AWS platform.

Inside the AWS Dashboard create yourself an EBS volume. – This will be the one that will be used to build your future EBS machine image

Make a note of the block device id that the Dashboard assigns to your EBS volume once it has finished the provisioning process, you will need this in order to mount the EBS volume inside the S3 Instance that you have already booted up (You can find this under ‘Attachment Information’ in the Dashboard). It will be on here that you will run debootstrap,etc to build the EBS image.

Once the EBS volume is available you will see an entry like this in the dash:

Next, click the ‘Attach’ button in the AWS Dashboard as follows:

Upon clicking the Attach button you will be asked which Instance you want to attach the EBS volume to. – You need to select the Instance ID of your S3 backed AMI you just started.

Once everything is attached you will see an entry like:i-aws-instance-id:/dev/sdX. ie: i-a62bc123:/dev/sdf (attached). Notice that the ‘available‘ changes to ‘In Use‘ once you complete the attachment process. ( the ‘sdf’ is the block device id you will need to note down for the next step.)

Now on your running S3 AMI login and execute the following command as root to build an ext3 filesystem on the now attached EBS volume

 

mkfs.ext3 -F /dev/sdX

remember to set your TERM id to something valid before starting the copy_into_chroot, otherwise the LOCALE will fail

 

export TERM=vt220

You need to grab the latest compatible kernel sources from S3 as well. – Which ones you need will depend on if you are rolling a 32-bit or 64-bit AMI.

You can get them by pointing your browser to http://s3.amazonaws.com/ec2-downloads/ (or using curl from your instance) and grep’ing for the required Xenu modules,i.e:ec2-modules-2.6.21.7-2.fc8xen-ec2-v1.0-x86_64.tar, if you are building the 64-bit version.

Next run mkdir /EBSmountpoint

Next run debootstrap to pull down a netinstall of Debian Squeeze into the mountpoint we just created called /EBSmountpoint

debootstrap –arch [i386|amd64] squeeze /EBSmountpoint http://ftp.debian.org

Once this has finished, create a directory to unzip your kernel sources into:

mkdir 64bitmodules

then untar the downloaded source in that directory

cd 64bitmodules

tar xvf ec2-modules-2.6.21.7-2.fc8xen-ec2-v1.0-x86_64.tar

this should create a lib directory inside 64bitmodules, which you can then copy intolib/modules inside your /EBSmountpoint directory

cp -r 64bitmodules/* /EBSmountpoint/lib/modules

Next copy the two ec2 scripts. You’ll recognise these next few steps from my last post on Custom AMI’s, the copy_into_chroot.sh, shellscript contains additional configuration parameters that I have passed to the Debian image before it gets converted into an Amazon Machine Image.

 

cp /etc/init.d/ec2-get-credentials /EBSmountpoint/etc/init.d/

cp /etc/init.d/ec2-ssh-host-key-gen /EBSmountpoint/etc/init.d/

 

 

cp copy_into_chroot.sh /EBSmountpoint/

 

chroot /EBSmountpoint /bin/bash

mount -t proc none /proc

mount -t devpts none /dev/pts

 

 

execute copy_into_chroot.sh from inside your chroot environment.

type ‘exit‘ to leave your chroot

On your S3 Instance umount  your EBS filesystem, as your almost ready to fire it up!!

create snapshot of EBS (make note of the EBS snap id)

Next register your EBS backed image, specifying the id of the snapshot you just took (snap-1ab23c45).

ec2-register –private-key=/ec2_creds/pk-.pem –cert=/ec2_creds/cert-.pem –region=EU-WEST-1 -a x86_64 -b /dev/sda1=snap-1ab23c45:20:false -d “Matts EBS backed Squeeze test” -n “SqueezeEBS” –kernel=”aki-780d250c” –ramdisk=”ari-7f0d250b” (the 20 after the snap id is the volume size, so it must match your AMI image size).

This will send you back an ami-id to use when starting an instance, this is done in the same way as an Instance-store AMI, although you will notice that instead of ‘instance-store‘ it will now display ‘ebs‘.

What you will notice starting and stoping this Instance is that any changes that you make will be preserved and available on start, which might suit some peoples requirements.

Hope someone finds these pointers useful.

Matt Palmer  - 6th June 2011

 

 

Comments

Subscribe to Comments Feed
  • Simon Said:

    Hi Matt, your Article is quite usefull. I am looking for a Debian Wheezy Image. Have you tested if it works with wheezy? Thanks Simon

Upcoming Linux Foundation Courses

  1. LFS426 Linux Performance Tuning
    08 Sep » 11 Sep - New York
    Details
  2. LFS520 OpenStack Cloud Architecture and Deployment
    08 Sep » 11 Sep - Virtual
    Details
  3. LFD320 Linux Kernel Internals and Debugging
    15 Sep » 19 Sep - Virtual
    Details

View All Upcoming Courses


Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board