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:
Next, since the default Gentoo image does not come with a text editor, one should be installed:
Since this is a remote session, using a terminal manager like
tmux will allow you to resume sessions if you get disconnected:
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:
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:
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:
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:
eix is installed, perform a sync:
I like having Puppet installed on everything:
Next, update the kernel. First, see what kernels are available:
For example, the output might look like:
Select the latest kernel:
This modifies the
/usr/src/linux symlink to the proper
Next, create a
.config file with the currently running kernel's configuration:
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:
Once the kernel is done building, add an entry to the beginning of
/boot/grub/menu.lst similar to the following:
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:
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
- Make sure
/etc/conf.d/nova-agentis empty as it will append UUIDs rather than replace the current one:
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.