This article will cover the initial steps I take to use Gentoo in the Rackspace public cloud environment. These steps involve taking the stock Gentoo image that Rackspace provides, updating and customizing it, then creating a personal image for further use.
- Creating the Initial Instance
- Updating and Customizing the Instance
Creating the Initial Instance
Launch an initial instance using the stock Gentoo 13.1 image. If you’re able to afford the cost, I recommend launching an instance type with 4 or more vCPUs. This will cut down on the compile time. This entire process takes around 4 to 5 hours, so running a 4 vCPU instance will cost approximately $2.50.
When the instance is ready to be converted into an image, resize it to the smallest possible size. This way, you’re able to launch the image in as many possible sizes. If you do not resize the instance, you will only be able to launch the instance in sizes greater than or equal to the original size.
Updating and Customizing the Instance
emerge --sync to update the packages in the portage database. One of the packages with an available update was probably Portage itself. Update it by doing:
$ emerge -a --oneshot portage
Next, since the default Gentoo image does not come with a text editor, one should be installed:
$ emerge -a vim
Since this is a remote session, using a terminal manager like
tmux will allow you to resume sessions if you get disconnected:
$ emerge -a tmux
Once installed, switch into
Make some changes to
First, increase the number of jobs defined in
MAKEOPTS. The number should be: (the amount of CPUs that your instance has) + (one):
Second, define version targets for both Python and Ruby:
# Python targets PYTHON_TARGETS="python2_7 python3_2" PYTHON_SINGLE_TARGET="python2_7" USE_PYTHON="2.7" # Ruby RUBY_TARGETS="ruby19"
Finally, set any global USE flags. I only set
vim-syntax for the master image:
I wouldn’t recommend setting values for variables like
MARCH since the CPU could vary from compute node to compute node.
Next, update all packages:
$ emerge -DNua --with-bdeps=y world
This will probably take a few hours – most of the time will be devoted to updating
gcc. On a 4 vCPU instance, the total running time was:
real 82m2.860s user 95m4.966s sys 63m23.733s
Now it’s time to start applying global configurations and packages that will be used for all instances based off of this image. For example:
$ emerge -a git genkernel gentoolkit eix
eix is installed, perform a sync:
I like having Puppet installed on everything:
$ echo "=sys-apps/net-tools-1.60_p20120127084908 old-output" > /etc/portage/package.use $ emerge -a puppet
Next, update the kernel. First, see what kernels are available:
$ eselect kernel list
For example, the output might look like:
Available kernel symlink targets:  linux-3.7.10-gentoo *  linux-3.8.13-gentoo
Select the latest kernel:
$ eselect kernel set 2
This modifies the
/usr/src/linux symlink to the proper
Next, create a
.config file with the currently running kernel’s configuration:
$ cd /usr/src/linux $ zcat /proc/config.gz > .config
$ make oldconfig
You’ll be prompted to answer questions for any new features that were added between the currently running kernel and the new kernel you are configuring. I usually just choose the defaults.
genkernel to build the kernel:
$ genkernel --install --no-mrproper --makeopts="-j5" all
Once the kernel is done building, add an entry to the beginning of
/boot/grub/menu.lst similar to the following:
title Gentoo Linux 3.8.13-gentoo root (hd0,0) kernel /boot/kernel-genkernel-x86_64-3.8.13-gentoo root=/dev/xvda1 ro console=hvc0
Finally, cross your fingers and reboot. While it’s rebooting, ping the IP address in another terminal. If it begins responding to pings, the kernel upgrade worked.
One thing I have noticed is that the instance will successfully boot, but the network interfaces will be down. To fix, log in to the Console via the Rackspace dashboard and:
$ rc-update add net.eth0 boot $ rc-update add net.eth1 boot
This section could also be called “A Growing List of Miscellanous Steps”.
- Instead of relying on the randomly generated password that is issued each time you launch an instance, copy a public SSH key to
- Edit the
/etc/hostsfile and remove the entries of the currently running instance.
- Remove all of the
$ find /etc -name \*.bak~ -delete
- Make sure
/etc/conf.d/nova-agentis empty as it will append UUIDs rather than replace the current one:
$ echo > /etc/conf.d/nova-agent
Finally, use the dashboard to create an image from the running instance.
Some last things to note:
- I’ve had one issue where my instance had two IPv4 addresses: one that was previously assigned to the instance used to build the image and another that was assigned to the instance. I have not been able to continuously reproduce this issue. As a precaution, this is why I document removing the
This article covered the basic steps needed to update and customize the stock Gentoo image found in the Rackspace public cloud. I plan to do further work with this when I get time: such as building an expandable distcc system that builds Gentoo packages or writing a scheduled script that does all of this work on a periodic basis so I always have an up-to-date image available.
I’m interested to hear if any of the above steps can be done in a better way – particularly if there is a better Gentoo-ish way.