Automated Stage3 Gentoo Install Using Ansible


The objective is to, as far as possible, fully automate a stage3 Gentoo build. While we're at it, we'd like to add some flexibility in building different kernel configurations or passing in different parameters like the initial username, passwords, etc.

Ansible fits the bill for this task nicely.

As a bonus, Ansible is capable of performing this taks on N number of targets asynchronously. So taking this method and extending it to an environment where 10, 15, or 100 minimal iso's are deployed over pxe and then concurrently bootstrapping a new Gentoo install should be trivial!


Gentoo is obviously a tweakers OS. This is not meant to be the One True Way (TM) to configure Gentoo. It's rather a demonstration on how you can use ansible to configure Gentoo your way, automated, and repeatable.

Getting the Roles

First, we'll need to grab the ansible-sandbox project that includes an example playbook using the ansible-gentoo role.

% git clone
% librarian-ansible install

Preparing the target environment.

Next, the target environment needs to be prepared. This entails booting to a Gentoo minimal disk, ensuring that there's networking available, setting a root password, and enabling ssh. For this tutorial, we'll assume you have a dhcp server running. If you don't, you'll need to configure networking manually.


When booting in vmware, I found the minimal Gentoo CD often had issues getting an ip address on boot.


The target system can be bare metal or a virtual machine. The kernel included in the ansible-gentoo role as the default includes support for VMWare Fusion/Workstation/Desktop v6.

It also had issues restarting the dhcpcd daemon with /etc/init.d/dhcpcd restart. I worked around this by issuing the following commands

# kill `ps aux | grep dhcpcd | grep -v grep | awk '{print $2}'`
# /etc/init.d/dhcpcd restart
* Stopping DHCP Client Daemon ...
* Starting DHCP Client Daemon ...

Setting a root password

As with any *nix, once your logged into the machine it would look something like this

# passwd
New password:
Retype new password:
passwd: password updated successfully

Enable sshd

# /etc/init.d/sshd start
ssh-keygen: generating new host keys: RSA1 RSA DSA ED25519
* Starting sshd ...

Wipe Any Previous Configurations

Ansible doesn't perform operations that have already completed. While normally a good thing, if you had a previous system setup on the target ansible has no way of knowing if the configurations were from older installs.

I found issues sometimes arose if the partition tables on the main disks had been wiped, but some lvm volume labels were still lurking around. Wiping everything ensures a clean build. The main partitions created by these scripts are

primary 'boot' partition.
primary main partition for volume group
volume group which includes the /dev/sda2 physical volume
swap logical volume
root logical volume
# parted /dev/sda -s -- mklabel gpt
# lvremove root
# lvremove  swap
# vgremove main

Building Out Gentoo

The rest is short and sweet. As automation should be. You'll find an example inventory in inventories/Gentoo. Couple of notes,

  • the new system will get its hostname from the inventory_hostname. In the example this is 'too1'.
  • The Gentoo install cd has python 3 as the default, but ansible needs 2.7. So make sure your ansible_python_interpretor path is set in your inventory.
% ansible-playbook -i inventories/gentoo \
                   -u root \
                   --ask-pass \

I Don't Like the Way You Configured Gentoo

There's a good chance you don't want Gentoo configured the way the role does. The individual tasks are broken down into components for easy tweaking of each individual stage of the deploy. You can also drop in your own kernel configuration or templates, etc. Think of this as a PoC and tweak away!

Share on: TwitterFacebookGoogle+Email

Comments !