I recently needed to create a clean EC2 AMI using a fairly new linux distro. It has been a while since I’ve needed to create a new AMI so I also wanted to move away from the older pre-packaged AMI and boot using EBS. After taking a look at what was currently available publicly I decided I would just create my own EBS bootable AMI using Fedora 12. It wasn’t all that complicated but there are a decent number of steps so I figured I would document them for anyone else who might want to give it a try.
I’m going to assume you already understand how to do things like create instances, create EBS volumes and ssh into your running instance using key based authentication. I use the AWS management console for a lot of what follows with the exception of needing to register the AMI and for that you will need the Amazon EC2 API Tools and Amazon EC2 AMI Tools
There are two ways to get to a bootable EBS backed Fedora 12 instance and they start off the same. The first thing to do is fire up the AMI named “Basic Fedora Core 8 (AMI Id: ami-84db39ed)” that is provided by Amazon.
Once the Fedora Core 8 EC2 instance is ready ssh into it. Fedora 12 requries a newer version of RPM to install so you now need to upgrade the instance to Fedora 10. This is pretty easy and can be done by following my instructions on upgrading from Fedora 9 to Fedora 10 (don’t worry about skipping 9 it will work). Here are the commands needed to do the upgrade:
[code language=”shell”]
yum clean all
rpm -Uhv http://archive.kernel.org/fedora-archive/releases/10/Fedora/i386/os/Packages/fedora-release-10-1.noarch.rpm http://archive.kernel.org/fedora-archive/releases/10/Fedora/i386/os/Packages/fedora-release-notes-10.0.0-1.noarch.rpm
yum -y update
[/code]
After a few minutes the instance will be upgraded and ready for the next step. This is where the two paths diverge depending on how you want the final product constructed. The options are to install Fedora 12 on a freshly minted volume or continue upgrading the instance you just created.
Upgrade path
I will start with the upgrade path since that is probably the easier of the two although may leave you with a messier instances after it is done. The next step for the upgrade path is to do what I outline in upgrading from Fedora 10 to Fedora 11 and upgrading from Fedora 11 to Fedora 12. Here are the commands all in one place to make it easy:
[code language=”shell”]
yum clean all
rpm -Uvh http://mirrors.usc.edu/pub/linux/distributions/fedora/linux/releases/11/Fedora/i386/os/Packages/fedora-release-11-1.noarch.rpm http://mirrors.usc.edu/pub/linux/distributions/fedora/linux/releases/11/Fedora/i386/os/Packages/fedora-release-notes-11.0.0-2.fc11.noarch.rpm
yum -y update
yum clean all
rpm -Uvh http://mirrors.kernel.org/fedora/releases/12/Fedora/i386/os/Packages/fedora-release-notes-12.0.0-4.fc12.noarch.rpm http://mirrors.kernel.org/fedora/releases/12/Fedora/i386/os/Packages/fedora-release-12-1.noarch.rpm
yum -y update
[/code]
Once you have everything upgraded to Fedora 12 you will have a 15G root partition that has less than 2G used. This may not suite your needs very well if you really don’t need that extra 13G but thankfully if you want to shrink the root EBS partition you can.
I found some instructions in this article on EBS backed AMIs that describes using the following command to copy the entire file system over. Assuming you have created a smaller volume and attached it to the instance as sdh you should be able to do something like the following to copy everything to the new volume:
[code language=”shell”]
mkfs.ext3 /dev/sdh
mount /dev/sdh /mnt
tar cpS / | cpipe -vt -b 1024 | gzip -c | tar zxpS -C /mnt
rm -rf /mnt/mnt/*
rm -rf /mnt/proc/*
umount /mnt
[/code]
One thing to note in the above is that the entire sdh drive is formatted for the file system (you will actually get a prompt asking if that is ok). As far as I can tell this is the way it has to be or the instance will not boot correctly. I assume this is because the root device is hidden behind a partition already as /dev/sda1 and so shouldn’t have a second partition table.
Skip to the common part now to learn how to make the final bootable AMI.
From scratch path
This path is similar to and mostly an update/extension to my post on creating a Fedora 7 AMI setup. I’m going to leave out most of the details and just provide you with a script that will take an empty volume (assumed to be attached as /dev/sdh) and turn it into a bootable EBS backed Fedora 12 volume. Download the script createfedora12bootebs.sh instead of trying to cut and paste the following, it gets formatted in such a way as to lose a newline that is important. Please note that you will need at least 1G of space on the given volume.
[code language=”shell”]
#!/bin/sh
echo "y" | mkfs.ext3 /dev/sdh
mount /dev/sdh /mnt
mkdir /mnt/dev
mkdir /mnt/proc
mkdir /mnt/etc
for i in console null zero ; do /sbin/MAKEDEV -d /mnt/dev -x $i ; done
cat <<EOL > /mnt/etc/fstab
/dev/sda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
/dev/sdc1 /mnt ext3 defaults 0 0
/dev/sdc2 swap swap defaults 0 0
EOL
mount -t proc none /mnt/proc
cat <<EOL > /tmp/yumec2.conf
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
exclude=*-debuginfo
gpgcheck=0
obsoletes=1
reposdir=/dev/null
[base]
name=Fedora 12 – i386 – Base
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-12&arch=i386
enabled=1
[updates-released]
name=Fedora 12 – i386 – Released Updates
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f12&arch=i386
enabled=1
EOL
yum -c /tmp/yumec2.conf –installroot=/mnt -y groupinstall Base
yum -c /tmp/yumec2.conf –installroot=/mnt -y install openssh-server
yum -c /tmp/yumec2.conf –installroot=/mnt -y clean packages
echo "UseDNS no" >> /mnt/etc/ssh/sshd_config
echo "PermitRootLogin without-password" >> /mnt/etc/ssh/sshd_config
cp /etc/rc.local /mnt/etc/
cp /etc/sysconfig/network /mnt/etc/sysconfig/network
cp /etc/sysconfig/network-scripts/ifcfg-eth0 /mnt/etc/sysconfig/network-scripts/ifcfg-eth0
cp /usr/local/sbin/* /mnt/usr/local/sbin/
cp -Rp /lib/modules/2.6.21.7-2.fc8xen/ /mnt/lib/modules/
echo "/sbin/MAKEDEV /dev/urandom" >> /mnt/etc/rc.sysinit
echo "/sbin/MAKEDEV /dev/random" >> /mnt/etc/rc.sysinit
echo "/sbin/MAKEDEV /dev/sdc" >> /mnt/etc/rc.sysinit
echo "/sbin/MAKEDEV /dev/sdc1" >> /mnt/etc/rc.sysinit
echo "/sbin/MAKEDEV /dev/sdc2" >> /mnt/etc/rc.sysinit
cat <<EOF >> /mnt/etc/rc.sysinit
# The following will partition the local drive and set up swap
cat <<EOL | fdisk /dev/sdc
n
p
1
1
+140G
n
p
2
w
EOL
mkswap /dev/sdc2
EOF
mv /mnt/lib/tls /mnt/lib/tls.disabled
echo "hwcap 0 nosegneg" >> /mnt/etc/ld.so.conf.d/kernelcap-2.6.21.7-2.fc8.conf
chroot /mnt chkconfig –level 2345 NetworkManager off
chroot /mnt chkconfig –level 2345 network on
sync
umount /mnt/proc
umount /mnt
[/code]
Common wrap up
At this point you will need to create a snapshot of the volume that was created for one of the paths above. Once the snapshot is available you will need to then register the snapshot as an AMI that is bootable from EBS. To do that you would issue something like the following command substituting the correct data in where it relates to your volume and snapshot.
[code language=”shell”]
ec2-register -n "AMIName" -d "AMI Description" –block-device-mapping /dev/sdc=ephemeral0 –snapshot your-snapname –architecture i386 –kernel aki-a71cf9ce –ramdisk ari-a51cf9cc
[/code]
One thing to note in this command is the –block-device-mapping option. That option is what gives you access to the local drive on your node once it is booted. This gives you extra storage for things you don’t need to keep after the life of the running node. In the from scratch option I’m turning part of the local drive into swap as well as creating a partition that could be used as a large temporary storage. If you want to know more details on the ephermeral storage look at this post
After all that you should have a bootable EBS backed Fedora 12 install to work with.
Thats very helpful, I was able to do the upgrade, however in my case I have some stuff already installed, so I had to uninstall apache httpd before doing that otherwise I was getting some errors.
Also I had to remove kernel-xen and smbios-utils-python
Any chance for for the corresponding links for the x86_64 bit version ?
Pingback: Building HipHop PHP for Fedora 12 on 64 bit and 32 bit Systems
@Mis Actually I needed a 64 bit version recently so I cooked up a script to upgrade Amazon’s Basic 64-bit Fedora Core 8 (AMI Id: ami-86db39ef) to Fedora 12. You can grab it from here: http://www.ioncannon.net/examples/64bitfedora12ec2.sh You don’t need to do much different but there are a few extra packages that have to be removed before the upgrade.
@carson Thanks!
Hi Carson,
Very helpful tutorial. I have been trying to upgrade my FC-8 ami to FC-12 for last two days. I was only successful after following this script. I have taken your second approach that creates a separate volume instead of upgrading the existing one. I had difficulty making the ‘–block-device-mapping’ option to work in my ec2-register command. So, I deleted this option and it worked perfectly. Another thing I noticed is that the FC-8 basic AMI that Amazon supplied has all ec2 commands except the ec2-register. I do not know why! It all worked after I downloaded the EC2 tools from amazon to my local computer and set the environment correctly.
Thank you very much for this helpful tutorial.
-Fazle Rokib
A couple of notes for things I ran into while upgrading an EC2 environment.
Q: Yum gives errors in DeviceKit-disks-*.* after upgrade to Fedora 10
A: You have old kernels lying around. Use
rpm -qa kernel\*to identify andyum erase kernel-old_2.6.2.imgto remove them.Q: Yum gives errors ERR_OUT: : Bad address
A: It’s due to smbios-utils-python. If you’re in an EC2 environment (no bios) it’s likely ok to remove:
yum remove smbios-utils-python. Reference: Mathieu ChateauQ: Apache failed, or libssl.so.* & libcrypto.so.* are missing
A: These versions are mssing the symlinks they require. Easy fix, go symlink them to the newest versions in /lib
Q:MySQL Broke during this process!
A:
mysqlupgrade -pQ: I just screwed the whole thing up!
A: So did I the first time around. I found it useful to reboot the instance after each yum update / before rpm. If anything it slowed me down enough to read, but it can’t hurt. Using
rebootshouldn’t lose your instance, so no worries.Thanks for the write-up Carson, you saved me a lot of hassle.
@stephen Thanks for the extra info.
Which AKI / ARI are you using? I assume the ones that are used with
the Fedora 8 kernel AMI. Then there is a mis-match of the running kernel and
the kernel modules on disk. Anyone know of a plan to sync Fedora 12 AMI/AKI/ARI?
@lukasware the ec2-register command above is where the AKI/ARI are specified. I’ve set it up to use aki-a71cf9ce and ari-a51cf9cc and I believe those were from one of the latest Ubuntu AMIs.
Carson, you should take a look @ https://fedoraproject.org/wiki/Features/FedoraOnEC2
Will not help you ‘right now’ however things are moving in the right direction for up to date FC releases on EC2 and not FC8 kernel + newer rpm.
Thank you very much, Carson! I was able to follow your instructions to upgrade Fedora 8 all the way to Fedora 12 (upgrade path)! Unfortunately, I can’t follow the “shrinking” instructions because of “cpipe: command not found”. (I used the same AKI/ARI). Since I really want to have smaller root, I started again but took “from scratch path” at the second try. However, the script ran until the yum command, where it complains “Error: Missing Dependency: nss-util = 3.12.6 is needed by package nss-3.12.6-1.2.fc12.i686 (updates-released)”. Would you please advise on these two showstopers? Thanks!
I am sorry that the previous post is wrong. The “upgrade path” was successful up to release 11, but didn’t go through release 12 upgrade. It had the same error about missing dependencies for “nspr”, “nss-util”. (“cat /etc/issue” command returned “Fedora release 12”, so I thought the upgrade was successful.)
Somebody had just posted the same problem here on Fedora forum a few minutes back, and a solution was also posted.
To be exact for the solution, you can get nss-util-3.12.6-1.fc12.i686.rpm and nspr-4.8.4-1.2.fc12.i686.rpm from http://mirror2.atrpms.net/fedora/linux/updates/testing/12/i386/
This problem may be a temporary release sync issue (note the “testing” here…), but I have no prior Fedora experience to speak more into this. I do get Fedora upgraded to release 12. Thanks, Carson!
You are a god-send, this is exactly what I”ve been struggling with all day today (trying to take some other paths). Thank you a thousand times over for going to the effort of putting this documentation together for the rest of us.
For me, the upgrade went fine, but I did have a minor snag with the ephemeral storage, which I see others bumped into.
The storage locations for ephemeral devices varies by your machine type (the example assumes one of the larger instances I believe). Here is a link to find the location for your machine type:
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?concepts-amis-and-instances.html#instance-types
Also, I needed to put that command in quotes, here is what worked for me with a m1.small instance:
ec2-register -n “Fedora12Base” -d “Clean Fedora 12 Image on 2GB EBS w/ ephemeral enabled” –block-device-mapping “/dev/sda2=ephemeral0” –snapshot –architecture i386 –kernel aki-a71cf9ce –ramdisk ari-a51cf9cc -K c:\myx509PrivateKeyFile.pem -C c:\myx509Cert.pem
Again, brilliant post, many thanks for removing my feet from this fire they’ve been toasting over all day!
@David thanks for that tip. I never noticed that the ephemeral storage shows up differently for different devices. For anyone trying to figure this out the direct link to the page with each instance type and storage device is: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/instance-storage-concepts.html
Hey, question, what kernel version is that AKI/ARI supposed to be? I went through this process and have a lovely working instance but it claims it’s 2.6.21.7-2.fc8xen – the starter fedora 8 I’m basing this all off of (ami-84db39ed) has 2.6.21.7-2.ec2.v1.2.fc8xen… I thought it would be a higher version?
The instructions have it set up to use aki-a71cf9ce and ari-a51cf9cc from the Ubuntu AMI.
Carson, thanks for the great tips. I made an fc12 x86_64 AMI based on your page but the problem with using the Ubuntu kernel is that you don’t have the Ubuntu kernel modules on disk. There’s no way to load md, for instance, or xfs. Any way around that?
I’m not sure if you could get the modules working under Fedora or not, you could give it a try and see if it boots. Someone mentioned that there is work going on to make the Fedora 13 kernel and ramdisk available on EC2 so that may be worth waiting for.
Hey, I’m having a problem with my instances built this way.
Every time I reboot, /dev/null goes to permissions 600.
udev is set up to do the right thing…
/lib/udev/rules.d/50-udev-default.rules:KERNEL==”null|zero|full|random|urandom”, MODE=”0666″
But I saw some posts about udev + Ubuntu kernels on ec2 not running?
I rm -f /dev/null;mknod -m 0666 /dev/null c 1 3, and then it’s OK, but once I reboot it’s bad again. Any ideas?
Thanks a lot, Carson!
I followed the instructions and got an instance running. The first thing I did was of course to issue the command “uname -a” and expect to see the new kernel version, but it reports “2.6.21.7-2.fc8xen”. I kept thinking that I did something wrong; two comments above asked basically the same question (e.g., “what kernel version is that AKI/ARI supposed to be?”) but the answers did not explain.
In any case, when I do something like “yum install octave,” the FC12 packages are fetched, so IT IS FC12 after all, even though it is not reported so by uname. Anybody cares to enlighten us on this?
Hi. I was very excited about your script and tried it out on my AWS account. However, I get the following message. The only change I made was that i changed the device from /dev/sdh to /dev/sdc. I also tried changing everything to 13 for Fedora 13 and that did not work either – I saw the same errors. Thanks very much for any help with this!
…lots of rpmlib errors…
rpmlib(PayloadIsXz) is needed by glibc-common-2.11.2-1.i686
rpmlib(FileDigests) is needed by grep-2.6.3-1.fc12.i686
rpmlib(PayloadIsXz) is needed by grep-2.6.3-1.fc12.i686
Complete!
(1, [u’Please report this error in http://yum.baseurl.org/report'%5D)
365 package files removed
createfedora12bootebs.sh: line 50: /mnt/etc/ssh/sshd_config: No such file or directory
createfedora12bootebs.sh: line 51: /mnt/etc/ssh/sshd_config: No such file or directory
cp: cannot create regular file `/mnt/etc/sysconfig/network’: No such file or directory
cp: cannot create regular file `/mnt/etc/sysconfig/network-scripts/ifcfg-eth0′: No such file or directory
cp: target `/mnt/usr/local/sbin/’ is not a directory
cp: cannot create directory `/mnt/lib/modules/’: No such file or directory
mv: cannot stat `/mnt/lib/tls’: No such file or directory
createfedora12bootebs.sh: line 84: /mnt/etc/ld.so.conf.d/kernelcap-2.6.21.7-2.fc8.conf: No such file or directory
chroot: cannot run command `chkconfig’: No such file or directory
chroot: cannot run command `chkconfig’: No such file or directory
I followed these instructions and am very pleased to be running FC12 now on EC2! However, I am having trouble trying to launch a new instance created from an ec2-bundle-vol of the instance I ran these instructions agains. ec2-bundle-vol succeeds, as does ec2-upload-bundle and ec2-register. But when I launch the instance, it’s stuck in “Pending” for several minutes, and then goes immediately to “Terminated”. I have no idea why, there is no console output and nothing I can retrieve from EC2 seems to offer any assistance. Has anyone else seen this? Do I need to use non-default options for ec2-bundle-vol or ec2-register? I’m just trying to launch it on ephemeral storage, not ECB.
@Bryan It should all work as described here although a few things have changed recently. I’ll be creating a new post soon on how to use some of the new tools.
@Bryan.
Same problem here.
I’ve been running a cluster of home made F11 instances for a year. Instances are S3 based, and were created using a script very similar to Carson’s.
The same script, apply to F13, produces bootable F13 instances (console output shows couple of problems with udev, requiring adding MAKEDEVs in rc.sysinit).
However when launching a new instance created from an ec2-bundle-vol of the instance, the new instance self terminates (Client.InstanceInitiatedShutdown: Instance initiated shutdown) , the console output is empty, and IPs are not attributed. Note this worked well (and still works well) with the F11 instances.
As my F11 and F13 scripts are identical, and because they still work with F11, I believe this is due to changes made in F12 & F13. But, as the console output is empty I cannot figure out when the problem is. I’ve tried using a F11 rc.sysinit in F13, it made no difference.
Any idea?
Pingback: Installing Cent OS 5.5 on EC2 with the Cent OS 5.5 Kernel
@Tim
yum -y install cpipe
:)