Gentoo Logo

Disclaimer : This handbook has been replaced by a newer version and is not maintained anymore.

Gentoo Linux 2008.0 PPC Networkless Handbook


  • Installing Gentoo
    In this part you learn how to install Gentoo on your system.
    1. About the Gentoo Linux Installation
      Users not familiar with Gentoo do not always know that choice is what Gentoo is all about.
    2. Booting the Universal Installation CD
      Using our Universal Installation CD you can boot up your system into a running environment that allows you to install Gentoo.
    3. Configuring your Network
      If you need networking, this is the place where the network (and Internet connection) is configured.
    4. Preparing the Disks
      To be able to install Gentoo, you must create the necessary partitions. This chapter describes how to partition a disk for future usage.
    5. Installing the Gentoo Installation Files
      In this chapter we describe how you extract a stage3 file and how to configure Portage.
    6. Chrooting into the Gentoo Base System
      Now that the stage3 file is extracted, we chroot into the new system and modify the USE variable.
    7. Configuring the Kernel
      The Linux kernel is the core of every distribution. This chapter explains how to configure your kernel.
    8. Configuring your System
      You need to edit some important configuration files. In this chapter you receive an overview of these files and an explanation on how to proceed.
    9. Installing Necessary System Tools
      As mentioned before, Gentoo is about customization. In this chapter we help you choose and install some important tools.
    10. Configuring the Bootloader
      Several bootloaders exist. Each one of them has its own way of configuration. In this chapter we'll describe all possibilities for you and step you through the process of configuring a bootloader to your needs.
    11. Finalizing your Gentoo Installation
      You're almost done. We'll just create one (or more) users for your system and (optionally) install prebuilt packages.
    12. Where to go from here?
      Now you have your Gentoo system, but what's next?
  • Working with Gentoo
    Learn how to work with Gentoo: installing software, altering variables, changing Portage behaviour etc.
    1. A Portage Introduction
      This chapter explains the "simple" steps a user definitely needs to know to maintain the software on his system.
    2. USE flags
      USE flags are a very important aspect of Gentoo. In this chapter, you learn to work with USE flags and understand how USE flags interact with your system.
    3. Portage Features
      Discover the features Portage has, such as support for distributed compiling, ccache and more.
    4. Initscripts
      Gentoo uses a special initscript format which, amongst other features, allows dependency-driven decisions and virtual initscripts. This chapter explains all these aspects and explains how to deal with these scripts.
    5. Environment Variables
      With Gentoo you can easily manage the environment variables for your system. This chapter explains how you do that, and also describes frequently used variables.
  • Working with Portage
    "Working with Portage" provides an in-depth coverage of Portage, Gentoo's Software Management Tool.
    1. Files and Directories
      Once you want to know Portage in-depth you need to know where it stores its files and data.
    2. Configuring through Variables
      Portage is completely configurable through various variables you can set in the configuration file or as environment variable.
    3. Mixing Software Branches
      Gentoo provides software separated in several branches, depending on stability and architectural support. "Mixing Software Branches" inform you how these branches can be configured and how you can override this separation individually.
    4. Additional Portage Tools
      Portage comes with a few extra tools that might make your Gentoo experience even better. Read on to discover how to use dispatch-conf and other tools.
    5. Diverting from the Official Tree
      "Diverting from the Official Tree" gives you some tips and tricks on how to use your own Portage tree, how to synchronise only the categories you want, inject packages and more.
  • Gentoo Network Configuration
    A comprehensive guide to Networking in Gentoo.
    1. Getting Started
      A guide to quickly get your network interface up and running in most common environments.
    2. Advanced Configuration
      Here we learn about how the configuration works - you need to know this before we learn about modular networking.
    3. Modular Networking
      Gentoo provides you flexible networking - here you are told about choosing different DHCP clients, setting up bonding, bridging, VLANs and more.
    4. Wireless Networking
      Wireless isn't straight-forward. Hopefully we'll get you working!
    5. Adding Functionality
      If you're feeling adventurous, you can add your own functions to networking.
    6. Network Management
      For laptop users or people who move their computer around different networks.

A. Installing Gentoo

1. About the Gentoo Linux Installation

1.a. Introduction


First of all, welcome to Gentoo. You are about to enter the world of customization and performance. When installing Gentoo, this is made clear to you several times -- you can choose how much you want to compile yourself, how to install Gentoo, what system logger you want, etc.

Gentoo is a fast, modern meta-distribution with a clean and flexible design. Gentoo is built around free software and doesn't hide from its users what is beneath the hood. Portage, the package maintenance system which Gentoo uses, is written in Python, meaning you can easily view and modify the source code. Gentoo's packaging system uses source code (although support for precompiled packages is included too) and configuring Gentoo happens through regular text files. In other words, openness everywhere.

It is very important that you understand that empowerment is what makes Gentoo run. We try not to force anything on our users and try our best to empower you to make the choices you wish. If you feel a change should be made, please file a bug report about it.

How is the Installation Structured?

The Gentoo Installation can be seen as a 10-step procedure, corresponding to chapters 2 - 11. Every step results in a certain state:

  • After step 1, you are in a working environment ready to install Gentoo
  • After step 2, your internet connection is prepared in case you need it (this is however optional)
  • After step 3, your hard disks are initialized to house your Gentoo installation
  • After step 4, your installation environment is prepared and you are ready to chroot into the new environment
  • After step 5, core packages, which are the same on all Gentoo installations, are installed
  • After step 6, you have compiled your Linux kernel
  • After step 7, you have written most of your Gentoo system configuration files
  • After step 8, necessary system tools (which you can choose from a nice list) are installed
  • After step 9, your choice of bootloader has been installed and configured and you are logged in into your new Gentoo installation
  • After step 10, your Gentoo Linux environment is ready to be explored

When you are given a certain choice, we try our best to explain what the pros and cons are. We will continue then with a default choice, identified by "Default: " in the title. The other possibilities are marked by "Alternative: ". Do not think that the default is what we recommend. It is however what we believe most users will use.

Sometimes you can pursue an optional step. Such steps are marked as "Optional: " and are therefore not needed to install Gentoo. However, some optional steps are dependant on a previous decision you made. We will inform you when this happens, both when you make the decision, and right before the optional step is described.

What are my Options?

You can install Gentoo in many different ways. You can download and install from one of our Installation CDs, from a distribution already installed, from a bootable CD (such as Knoppix), from a netbooted environment, from a rescue floppy, etc.

This document covers the installation using a Gentoo Linux Installation CD, a bootable CD that contains everything you need to get Gentoo Linux up and running. There are two types of Installation CDs, the InstallCD and the Installer LiveCD. The InstallCD is a minimal environment which contains only those packages necessary for installing Gentoo Linux. The LiveCD is a complete Gentoo Linux environment and can be used for multiple tasks, one of which is installing Gentoo Linux. The LiveCD is not available on all architectures at this time. If your architecture does not have a LiveCD, then this document will refer to the Universal InstallCD for you.

This installation approach however does not immediately use the latest version of the available packages; if you want this you should check out the Installation Instructions inside our Gentoo Linux Handbooks.

For help on the other installation approaches, please read our Alternative Installation Guide. We also provide a Gentoo Installation Tips & Tricks document that might be useful to read as well. If you feel that the current installation instructions are too elaborate, feel free to use our Quick Installation Guide available from our Documentation Resources if your architecture has such a document available.


If you find a problem in the installation (or in the installation documentation), please check the errata from our Gentoo Release Engineering Project, visit our bug tracking system and check if the bug is known. If not, please create a bug report for it so we can take care of it. Do not be afraid of the developers who are assigned to (your) bugs -- they generally don't eat people.

Note though that, although the document you are now reading is architecture-specific, it will contain references to other architectures as well. This is due to the fact that large parts of the Gentoo Handbook use source code that is common for all architectures (to avoid duplication of efforts and starvation of development resources). We will try to keep this to a minimum to avoid confusion.

If you are uncertain if the problem is a user-problem (some error you made despite having read the documentation carefully) or a software-problem (some error we made despite having tested the installation/documentation carefully) you are free to join #gentoo on Of course, you are welcome otherwise too :)

If you have a question regarding Gentoo, check out our Frequently Asked Questions, available from the Gentoo Documentation. You can also view the FAQs on our forums. If you can't find the answer there ask on #gentoo, our IRC-channel on Yes, several of us are freaks who sit on IRC :-)

1.b. Fast Installation using the Gentoo Reference Platform

What is the Gentoo Reference Platform?

The Gentoo Reference Platform, from now on abbreviated to GRP, is a snapshot of prebuilt packages users (that means you!) can install during the installation of Gentoo to speed up the installation process. The GRP consists of all packages required to have a fully functional Gentoo installation. They are not just the ones you need to have a base installation up to speed in no time, but all lengthier builds (such as xorg-x11, GNOME, OpenOffice, Mozilla, ...) are available as GRP packages too.

However, these prebuilt packages aren't maintained during the lifetime of the Gentoo distribution. They are snapshots released at every Gentoo release and make it possible to have a functional environment in a short amount of time. You can then upgrade your system in the background while working in your Gentoo environment.

How Portage Handles GRP Packages

Your Portage tree - the collection of ebuilds (files that contain all information about a package, such as its description, homepage, sourcecode URLs, compilation instructions, dependencies, etc.) - must be synchronised with the GRP set: the versions of the available ebuilds and their accompanying GRP packages must match.

For this reason you can only benefit from the GRP packages Gentoo provides while performing the current installation approach. GRP is not available for those interested in performing an installation using the latest versions of all available packages.

Is GRP Available?

Not all architectures provide GRP packages. That doesn't mean GRP isn't supported on the other architectures, but it means that we don't have the resources to build and test the GRP packages.

At present we provide GRP packages for the following architectures:

  • The amd64 architecture (amd64). Note: The packages are available on the Installer LiveCD.
  • The ppc architecture (ppc32)
  • The sparc architecture (sparc64)
  • The x86 architecture (athlon, athlon-xp, athlon-mp, pentium-pro, pentium2, pentium3, pentium4 and pentium-m) Note: The packages are for i686 and are available on the Installer LiveCD.

If your architecture (or subarchitecture) isn't on this list, you are not able to opt for a GRP installation.

Now that this introduction is over, let's continue with Booting the Universal InstallCD/Installer LiveCD.

2. Booting the Universal Installation CD

2.a. Hardware Requirements


Before we start, we first list what hardware requirements you need to successfully install Gentoo on your box.

Hardware Requirements

Apple NewWorld Machines Power/PowerPC microprocessors (G3, G4, G5) such as iMac, eMac, iBook PowerBook, Xserver, PowerMac
Apple OldWorld machines Apple Machines with an Open Firmware revision less than 3, such as the Beige G3s, PCI PowerMacs and PCI PowerBooks. PCI based Apple Clones should also be supported.
Genesi Pegasos I/II, Open Desktop Workstation, Efika
IBM RS/6000, iSeries, pSeries
Memory At least 64 MB
Diskspace 1.5 GB (excluding swap space)
Swap space At least 256 MB

Be sure to read the Gentoo PPC FAQ for help with some common installation related issues or if you're unsure as to just what's in that PowerPC machine you've got sitting on your desk right now.

2.b. The Gentoo Universal Installation CD


Gentoo Linux can be installed using a stage3 tarball file. Such a tarball is an archive that contains a minimal environment from which you can succesfully install Gentoo Linux onto your system.

Installations using a stage1 or stage2 tarball file are not documented in the Gentoo Handbook - please read the Gentoo FAQ on these matters.

Gentoo Universal Installation CD

An Installation CD is a bootable medium which contains a self-sustained Gentoo environment. It allows you to boot Linux from the CD. During the boot process your hardware is detected and the appropriate drivers are loaded. The Gentoo Installation CDs are maintained by Gentoo developers.

There currently are two Installation CDs available:

  • The Universal Installation CD contains everything you need to install Gentoo. It provides stage3 files for common architectures, source code for the extra applications you need to choose from and, of course, the installation instructions for your architecture.
  • The Minimal Installation CD contains only a minimal environment that allows you to boot up and configure your network so you can connect to the Internet. It does not contain any additional files and cannot be used during the current installation approach.

Gentoo also provides a Package CD. This is not an Installation CD but an additional resource that you can exploit during the installation of your Gentoo system. It contains prebuilt packages (also known as the GRP set) that allow you to easily and quickly install additional applications (such as, KDE, GNOME, ...) immediately after the Gentoo installation and right before you update your Portage tree.

The use of the Package CD is covered later in this document.

2.c. Download, Burn and Boot the Gentoo Universal Installation CD

Downloading and Burning the Installation CD

You can download the Universal Installation CD (and, if you want to, the Packages CD as well) from one of our mirrors. The Installation CDs are located in the releases/ppc/2008.0/installcd directory; the Package CDs are located in the releases/ppc/2008.0/packagecd directory.

Inside those directories you'll find ISO files. Those are full CD images which you can write on a CD-R.

After downloading the file, you can verify its integrity to see if it is corrupted or not:

  • You can check its MD5 checksum and compare it with the MD5 checksum we provide (for instance with the md5sum tool under Linux/Unix or md5sum for Windows). Verifying MD5 checksums with Mac OS X is described in the Gentoo PPC FAQ.
  • You can verify the cryptographic signature that we provide. You need to obtain the public key we use (0x17072058) before you proceed though.

To fetch our public key using the GnuPG application, run the following command:

Code Listing 3.1: Obtaining the public key

$ gpg --keyserver --recv-keys 0x17072058

Now verify the signature:

Code Listing 3.2: Verify the cryptographic signature

$ gpg --verify <signature file> <downloaded iso>

To burn the downloaded ISO(s), you have to select raw-burning. How you do this is highly program-dependent. We will discuss cdrecord and K3B here; more information can be found in our Gentoo FAQ.

  • With cdrecord, you simply type cdrecord dev=/dev/hdc <downloaded iso file> (replace /dev/hdc with your CD-RW drive's device path).
  • With K3B, select Tools > Burn CD Image. Then you can locate your ISO file within the 'Image to Burn' area. Finally click Start.

Default: Booting the Installation CD with Yaboot

On NewWorld machines place the Installation CD in the CD-ROM and reboot the system. When the system-start-bell sounds, simply hold down the 'C' until the CD loads.

After the Installation CD loaded, you will be greeted by a friendly welcome message and a boot: prompt at the bottom of the screen.

We provide one generic kernel, apple. This kernel is built with support for multiple CPUs, but it will boot on single processor machines as well.

You can tweak some kernel options at this prompt. The following table lists some of the available boot options you can add:

Boot Option Description
video This option takes one of the following vendor-specific tags: nvidiafb, radeonfb, rivafb, atyfb, aty128 or ofonly. You can follow this tag with the resolution refresh rate and color depth you want to use. For instance, video=radeonfb:1280x1024@75-32 will select the ATI Radeon frame buffer at a resolution of 1280x1024 with a refresh rate of 75Hz and a color depth of 32 bits. If you are uncertain what to choose, and the default doesn't work, video=ofonly will most certainly work.
nol3 Disables level 3 cache on some PowerBooks (needed for at least the 17")
dofirewire Enables support for IEEE1394 (FireWire) devices, like external harddisks.
dopcmcia If you want to use PCMCIA devices during your installation (like PCMCIA network cards) you have to enable this option.

To use the above options, at the boot: prompt, type apple followed by the desired option. In the example below, we'll force the kernel to use the Open Firmware framebuffer instead of the device specific driver.

Code Listing 3.3: Force the use of the Open Firmware framebuffer

boot: apple video=ofonly

If you don't need to add any options, just hit enter at this prompt, and a complete Gentoo Linux environment will be loaded from the CD. Continue with And When You're Booted....

Alternative: Booting the Installation CD on a Pegasos

On the Pegasos simply insert the CD and at the SmartFirmware boot-prompt type boot cd /boot/menu. This will open a small bootmenu where you can choose between several preconfigured video configs. If you need any special boot options you can append them to the command-line just like with Yaboot above. For example: boot cd /boot/pegasos video=radeonfb:1280x1024@75 mem=256M. The default kernel options (in case something goes wrong and you need it) are preconfigured with console=ttyS0,115200 console=tty0 init=/linuxrc looptype=squashfs loop=/image.squashfs cdroot root=/dev/ram0.

Alternative: Booting the Installation CD with BootX

If you have an OldWorld Mac the bootable portion of the livecd can't be used. The most simple solution is to use MacOS 9 or earlier to bootstrap into a Linux environment with a tool called BootX.

First, download BootX and unpack the archive. Copy the the BootX Extension from the unpacked archive into Extensions Folder and the BootX App Control Panel into Control Panels, both of which are located in your MacOS System Folder. Next, create a folder called "Linux Kernels" in your System folder and copy the apple kernel from the CD to this folder. Finally, copy apple.igz from the Installation CD boot folder into the MacOS System Folder.

To prepare BootX, start the BootX App Control Panel. First select the Options dialog and check Use Specified RAM Disk and select apple.igz from your System Folder. Continue back to the initial screen and ensure that the ramdisk size is at least 32000. Finally, set the kernel arguments as shown below:

Code Listing 3.4: BootX kernel arguments

cdroot root=/dev/ram0 init=linuxrc loop=image.squashfs looptype=squashfs console=tty0 

Note: The kernel parameters in the yaboot section above are also applicable here. You can append any of those options to the kernel arguments above.

Check once more to make sure the settings are correct and then save the configuration. This saves typing just in case it doesn't boot or something is missing. Press the Linux button at the top of the window. If everything goes correctly, it should boot into the Installation CD. Continue with And When You're Booted...

And When You're Booted...

You will be greeted by a root ("#") prompt on the current console. You can also switch to other consoles by pressing Alt-F2, Alt-F3 and Alt-F4. Get back to the one you started on by pressing Alt-F1. Due to the keyboard layout, you may need to press Alt-fn-Fx on Apple machines.

If you are installing Gentoo on a system with a non-US keyboard, use loadkeys to load the keymap for your keyboard. To list the available keymaps, execute ls /usr/share/keymaps/i386.

Code Listing 3.5: Listing available keymaps

(PPC uses x86 keymaps on most systems)
# ls /usr/share/keymaps/i386

Now load the keymap of your choice:

Code Listing 3.6: Loading a keymap

# loadkeys be-latin1

Now continue with Extra Hardware Configuration.

Extra Hardware Configuration

When the Installation CD boots, it tries to detect all your hardware devices and loads the appropriate kernel modules to support your hardware. In the vast majority of cases, it does a very good job. However, in some cases it may not auto-load the kernel modules you need. If the PCI auto-detection missed some of your system's hardware, you will have to load the appropriate kernel modules manually.

In the next example we try to load the 8139too module (support for certain kinds of network interfaces):

Code Listing 3.7: Loading kernel modules

# modprobe 8139too

Optional: User Accounts

If you plan on giving other people access to your installation environment or you want to chat using irssi without root privileges (for security reasons), you need to create the necessary user accounts and change the root password.

To change the root password, use the passwd utility:

Code Listing 3.8: Changing the root password

# passwd
New password: (Enter your new password)
Re-enter password: (Re-enter your password)

To create a user account, we first enter their credentials, followed by its password. We use useradd and passwd for these tasks. In the next example, we create a user called "john".

Code Listing 3.9: Creating a user account

# useradd -m -G users john
# passwd john
New password: (Enter john's password)
Re-enter password: (Re-enter john's password)

You can change your user id from root to the newly created user by using su:

Code Listing 3.10: Changing user id

# su - john

Optional: Viewing Documentation while Installing

If you want to view the Gentoo Handbook during the installation, make sure you have created a user account (see Optional: User Accounts). Then press Alt-F2 to go to a new terminal.

You can view the handbook using links, once you have completed the Configuring your Network chapter (otherwise you won't be able to go on the Internet to view the document):

Code Listing 3.11: Viewing the Online Documentation

# links

You can go back to your original terminal by pressing Alt-F1.

Optional: Starting the SSH Daemon

If you want to allow other users to access your computer during the Gentoo installation (perhaps because those users are going to help you install Gentoo, or even do it for you), you need to create a user account for them and perhaps even provide them with your root password (only do that if you fully trust that user).

To fire up the SSH daemon, execute the following command:

Code Listing 3.12: Starting the SSH daemon

# /etc/init.d/sshd start

Note: If you (or other users) log on to the system, they will get a message that the host key for this system needs to be confirmed (through what is called a fingerprint). This is to be expected as it is the first time people log on to the system. However, later when your system is set up and you log on to the newly created system, your SSH client will warn you that the host key has been changed. This is because you now log on to - for SSH - a different server (namely your freshly installed Gentoo system rather than the live environment you are on right now). When you hit that warning, follow the instructions given on the screen then to replace the host key on the client system.

To be able to use sshd, you first need to set up your networking. Continue with the chapter on Configuring your Network.

3. Configuring your Network

3.a. Do you need Networking?

Who can do without?

Generally, you don't need a working network connection to install Gentoo using either the Universal InstallCD or the Installer LiveCD. However, there are some circumstances where you do want to have a working Internet connection:

  • The stage3 files that are stored in the Universal InstallCD do not match your architecture and you need to download the correct stage3 file
  • The stage3 file that is generated by the Installer LiveCD does not match your architecture and you need to download the correct stage3 file
  • You need to install a specific networking application that will allow you to connect to the Internet which isn't available on the Universal InstallCD or the Installer LiveCD, but is supported by the CD (i.e. you can connect to the Internet using the CD but the necessary sources are not available on the CD)
  • You want remote assistance during the installation (using SSH or through direct conversations using IRC)

Do I need Networking?

To find out if the stage3 file for your architecture is available and you are using a Universal InstallCD, take a look inside /mnt/cdrom/stages and check if one of the available stages matches your architecture. If not, you can still opt for a stage3 file of an architecture compatible with yours.

If you, on the other hand, want to use a stage3 file optimized for your architecture and the stage3 file of your choice is not available, then you will need networking to download the appropriate stage3 file.

So, if you don't need networking, you can skip the rest of this chapter and continue with Preparing the Disks. Otherwise, continue with the networking configuration sections below.

3.b. Automatic Network Detection

Maybe it just works?

If your system is plugged into an Ethernet network with a DHCP server, it is very likely that your networking configuration has already been set up automatically for you. If so, you should be able to take advantage of the many included network-aware commands on the Installation CD such as ssh, scp, ping, irssi, wget and links, among others.

If networking has been configured for you, the /sbin/ifconfig command should list some network interfaces besides lo, such as eth0:

Code Listing 2.1: /sbin/ifconfig for a working network configuration

# /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:BA:8F:61:7A
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
          RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1984 txqueuelen:100
          RX bytes:485691215 (463.1 Mb)  TX bytes:123951388 (118.2 Mb)
          Interrupt:11 Base address:0xe800 

Optional: Configure any Proxies

If you access the Internet through a proxy, you might need to set up proxy information during the installation. It is very easy to define a proxy: you just need to define a variable which contains the proxy server information.

In most cases, you can just define the variables using the server hostname. As an example, we assume the proxy is called and the port is 8080.

Code Listing 2.2: Defining proxy servers

(If the proxy filters HTTP traffic)
# export http_proxy=""
(If the proxy filters FTP traffic)
# export ftp_proxy=""
(If the proxy filters RSYNC traffic)
# export RSYNC_PROXY=""

If your proxy requires a username and password, you should use the following syntax for the variable:

Code Listing 2.3: Adding username/password to the proxy variable

Testing the Network

You may want to try pinging your ISP's DNS server (found in /etc/resolv.conf) and a Web site of your choice, just to make sure that your packets are reaching the net, DNS name resolution is working correctly, etc.

Code Listing 2.4: Further network testing

# ping -c 3

If you are now able to use your network, you can skip the rest of this section and continue with Preparing the Disks. If not, read on.

3.c. Automatic Network Configuration

If the network doesn't work immediately, some installation media allow you to use net-setup (for regular or wireless networks), pppoe-setup (for ADSL-users) or pptp (for PPTP-users - only available on x86).

If your installation medium does not contain any of these tools or your network doesn't function yet, continue with Manual Network Configuration.

Default: Using net-setup

The simplest way to set up networking if it didn't get configured automatically is to run the net-setup script:

Code Listing 3.1: Running the net-setup script

# net-setup eth0

net-setup will ask you some questions about your network environment. When all is done, you should have a working network connection. Test your network connection as stated before. If the tests are positive, congratulations! You are now ready to install Gentoo. Skip the rest of this section and continue with Preparing the Disks.

If your network still doesn't work, continue with Manual Network Configuration.

Alternative: Using PPP

Assuming you need PPPoE to connect to the internet, the Installation CD (any version) has made things easy for you by including ppp. Use the provided pppoe-setup script to configure your connection. You will be prompted for the ethernet device that is connected to your adsl modem, your username and password, the IPs of your DNS servers and if you need a basic firewall or not.

Code Listing 3.2: Using ppp

# pppoe-setup
# pppoe-start

If something goes wrong, double-check that you correctly typed your username and password by looking at /etc/ppp/pap-secrets or /etc/ppp/chap-secrets and make sure you are using the right ethernet device. If your ethernet device doesn't exist, you will have to load the appropriate network modules. In that case you should continue with Manual Network Configuration as we explain how to load the appropriate network modules there.

If everything worked, continue with Preparing the Disks.

Alternative: Using PPTP

Note: PPTP support is only available for x86

If you need PPTP support, you can use pptpclient which is provided by our Installation CDs. But first you need to make sure that your configuration is correct. Edit /etc/ppp/pap-secrets or /etc/ppp/chap-secrets so it contains the correct username/password combination:

Code Listing 3.3: Editing /etc/ppp/chap-secrets

# nano -w /etc/ppp/chap-secrets

Then adjust /etc/ppp/options.pptp if necessary:

Code Listing 3.4: Editing /etc/ppp/options.pptp

# nano -w /etc/ppp/options.pptp

When all that is done, just run pptp (along with the options you couldn't set in options.pptp) to connect the server:

Code Listing 3.5: Connection to a dial-in server

# pptp <server ip>

Now continue with Preparing the Disks.

3.d. Manual Network Configuration

Loading the Appropriate Network Modules

When the Installation CD boots, it tries to detect all your hardware devices and loads the appropriate kernel modules (drivers) to support your hardware. In the vast majority of cases, it does a very good job. However, in some cases, it may not auto-load the kernel modules you need.

If net-setup or pppoe-setup failed, then it is possible that your network card wasn't found immediately. This means you may have to load the appropriate kernel modules manually.

To find out what kernel modules we provide for networking, use ls:

Code Listing 4.1: Searching for provided modules

# ls /lib/modules/`uname -r`/kernel/drivers/net

If you find a driver for your network card, use modprobe to load the kernel module:

Code Listing 4.2: Using modprobe to load a kernel module

(As an example, we load the pcnet32 module)
# modprobe pcnet32

To check if your network card is now detected, use ifconfig. A detected network card would result in something like this:

Code Listing 4.3: Testing availability of your network card, successful

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr FE:FD:00:00:00:00  
          BROADCAST NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

If however you receive the following error, the network card is not detected:

Code Listing 4.4: Testing availability of your network card, failed

# ifconfig eth0
eth0: error fetching interface information: Device not found

If you have multiple network cards in your system they are named eth0, eth1, etc. Make sure that the network card you want to use works well and remember to use the correct naming throughout this document. We will assume that the network card eth0 is used.

Assuming that you now have a detected network card, you can retry net-setup or pppoe-setup again (which should work now), but for the hardcore people amongst you we explain how to configure your network manually.

Select one of the following sections based on your network setup:

Using DHCP

DHCP (Dynamic Host Configuration Protocol) makes it possible to automatically receive networking information (IP address, netmask, broadcast address, gateway, nameservers etc.). This only works if you have a DHCP server in your network (or if your provider provides a DHCP service). To have a network interface receive this information automatically, use dhcpcd:

Code Listing 4.5: Using dhcpcd

# dhcpcd eth0
Some network admins require that you use the
hostname and domainname provided by the DHCP server.
In that case, use
# dhcpcd -HD eth0

If this works (try pinging some internet server, like Google), then you are all set and ready to continue. Skip the rest of this section and continue with Preparing the Disks.

Preparing for Wireless Access

Note: Support for the iwconfig command is only available on x86, amd64 and ppc Installation CDs. You can still get the extensions working otherwise by following the instructions of the linux-wlan-ng project.

If you are using a wireless (802.11) card, you may need to configure your wireless settings before going any further. To see the current wireless settings on your card, you can use iwconfig. Running iwconfig might show something like:

Code Listing 4.6: Showing the current wireless settings

# iwconfig eth0
eth0      IEEE 802.11-DS  ESSID:"GentooNode"                                   
          Mode:Managed  Frequency:2.442GHz  Access Point: 00:09:5B:11:CC:F2    
          Bit Rate:11Mb/s   Tx-Power=20 dBm   Sensitivity=0/65535               
          Retry limit:16   RTS thr:off   Fragment thr:off                       
          Power Management:off                                                  
          Link Quality:25/10  Signal level:-51 dBm  Noise level:-102 dBm        
          Rx invalid nwid:5901 Rx invalid crypt:0 Rx invalid frag:0 Tx          
          excessive retries:237 Invalid misc:350282 Missed beacon:84            

Note: Some wireless cards may have a device name of wlan0 or ra0 instead of eth0. Run iwconfig without any command-line parameters to determine the correct device name.

For most users, there are only two settings that might be important to change, the ESSID (aka wireless network name) or the WEP key. If the ESSID and Access Point address listed are already that of your access point and you are not using WEP, then your wireless is working. If you need to change your ESSID, or add a WEP key, you can issue the following commands:

Code Listing 4.7: Changing ESSID and/or adding WEP key

(This sets the network name to "GentooNode")
# iwconfig eth0 essid GentooNode

(This sets a hex WEP key)
# iwconfig eth0 key 1234123412341234abcd

(This sets an ASCII key - prefix it with "s:")
# iwconfig eth0 key s:some-password

You can then confirm your wireless settings again by using iwconfig. Once you have wireless working, you can continue configuring the IP level networking options as described in the next section (Understanding Network Terminology) or use the net-setup tool as described previously.

Understanding Network Terminology

Note: If you know your IP address, broadcast address, netmask and nameservers, then you can skip this subsection and continue with Using ifconfig and route.

If all of the above fails, you will have to configure your network manually. This is not difficult at all. However, you need to be familiar with some network terminology, as you will need it to be able to configure your network to your satisfaction. After reading this, you will know what a gateway is, what a netmask serves for, how a broadcast address is formed and why you need nameservers.

In a network, hosts are identified by their IP address (Internet Protocol address). Such an address is a combination of four numbers between 0 and 255. Well, at least that is how we perceive it. In reality, such an IP address consists of 32 bits (ones and zeros). Let's view an example:

Code Listing 4.8: Example of an IP address

IP Address (numbers):
IP Address (bits):      11000000 10101000 00000000 00000010
                        -------- -------- -------- --------
                           192      168       0        2

Such an IP address is unique to a host as far as all accessible networks are concerned (i.e. every host that you are able to reach must have a unique IP address). In order to distinguish between hosts inside and outside a network, the IP address is divided in two parts: the network part and the host part.

The separation is written down with the netmask, a collection of ones followed by a collection of zeros. The part of the IP that can be mapped on the ones is the network-part, the other one is the host-part. As usual, the netmask can be written down as an IP-address.

Code Listing 4.9: Example of network/host separation

IP-address:    192      168      0         2
            11000000 10101000 00000000 00000010
Netmask:    11111111 11111111 11111111 00000000
               255      255     255        0
                    Network              Host

In other words, is still part of our example network, but is not.

The broadcast address is an IP-address with the same network-part as your network, but with only ones as host-part. Every host on your network listens to this IP address. It is truly meant for broadcasting packets.

Code Listing 4.10: Broadcast address

IP-address:    192      168      0         2
            11000000 10101000 00000000 00000010
Broadcast:  11000000 10101000 00000000 11111111
               192      168      0        255
                     Network             Host

To be able to surf on the internet, you must know which host shares the Internet connection. This host is called the gateway. Since it is a regular host, it has a regular IP address (for instance

We previously stated that every host has its own IP address. To be able to reach this host by a name (instead of an IP address) you need a service that translates a name (such as to an IP address (such as Such a service is called a name service. To use such a service, you must define the necessary name servers in /etc/resolv.conf.

In some cases, your gateway also serves as nameserver. Otherwise you will have to enter the nameservers provided by your ISP.

To summarise, you will need the following information before continuing:

Network Item Example
Your IP address

Using ifconfig and route

Setting up your network consists of three steps. First we assign ourselves an IP address using ifconfig. Then we set up routing to the gateway using route. Then we finish up by placing the nameserver IPs in /etc/resolv.conf.

To assign an IP address, you will need your IP address, broadcast address and netmask. Then execute the following command, substituting ${IP_ADDR} with your IP address, ${BROADCAST} with your broadcast address and ${NETMASK} with your netmask:

Code Listing 4.11: Using ifconfig

# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up

Now set up routing using route. Substitute ${GATEWAY} with your gateway IP address:

Code Listing 4.12: Using route

# route add default gw ${GATEWAY}

Now open /etc/resolv.conf with your favorite editor (in our example, we use nano):

Code Listing 4.13: Creating /etc/resolv.conf

# nano -w /etc/resolv.conf

Now fill in your nameserver(s) using the following as a template. Make sure you substitute ${NAMESERVER1} and ${NAMESERVER2} with the appropriate nameserver addresses:

Code Listing 4.14: /etc/resolv.conf template

nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}

That's it. Now test your network by pinging some Internet server (like Google). If this works, congratulations then. You are now ready to install Gentoo. Continue with Preparing the Disks.

4. Preparing the Disks

4.a. Introduction to Block Devices

Block Devices

We'll take a good look at disk-oriented aspects of Gentoo Linux and Linux in general, including Linux filesystems, partitions and block devices. Then, once you're familiar with the ins and outs of disks and filesystems, you'll be guided through the process of setting up partitions and filesystems for your Gentoo Linux installation.

To begin, we'll introduce block devices. The most famous block device is probably the one that represents the first drive in a Linux system, namely /dev/sda. SCSI and Serial ATA drives are both labeled /dev/sd*; even IDE drives are labeled /dev/sd* with the new libata framework in the kernel. If you're using the old device framework, then your first IDE drive is /dev/hda.

The block devices above represent an abstract interface to the disk. User programs can use these block devices to interact with your disk without worrying about whether your drives are IDE, SCSI or something else. The program can simply address the storage on the disk as a bunch of contiguous, randomly-accessible 512-byte blocks.


Although it is theoretically possible to use a full disk to house your Linux system, this is almost never done in practice. Instead, full disk block devices are split up in smaller, more manageable block devices. On most systems, these are called partitions.

4.b. Designing a Partitioning Scheme

Default Partitioning Scheme

If you are not interested in drawing up a partitioning scheme for your system, you can use the partitioning scheme we use throughout this book. Choose the filesystem layout that best matches the type of PowerPC system you are installing on.

Apple New World

Apple New World machines are fairly straightforward to configure. The first partition is always an Apple Partition Map. This partition keeps track of the layout of the disk. You cannot remove this partition. The next partition should always be a bootstrap partition. This partition contains a small (800k) HFS filesystem that holds a copy of the bootloader Yaboot and its configuration file. This partition is not the same as a /boot partition as found on other architectures. After the boot partition, the usual Linux filesystems are placed, according to the scheme below. The swap partition is a temporary storage place for when your system runs out of physical memory. The root partition will contain the filesystem that Gentoo is installed on. If you wish to dual boot, the OSX partition can go anywhere after the bootstrap partition to insure that yaboot starts first.

Note: There may be "Disk Driver" partitions on your disk such as Apple_Driver63, Apple_Driver_ATA, Apple_FWDriver, Apple_Driver_IOKit, and Apple_Patches. These are used to boot MacOS, so if you have no need for this, you can remove them by initializing the disk with mac-fdisk's i option. This will completely erase the disk! If you are in doubt, just let them be.

Note: If you partitioned this disk with Apple's Disk Utility, there may be 128Mb spaces between partitions which Apple reserves for "future use". You can safely remove these.

Partition Size Filesystem Description
/dev/sda1 32k None Apple Partition Map
/dev/sda2 800k HFS Apple Bootstrap
/dev/sda3 512Mb Swap Linux Swap
/dev/sda4 Rest of Disk ext3, reiserfs, xfs Linux Root

Apple Old World

Apple Old World machines are a bit more complicated to configure. The first partition is always an Apple Partition Map. This partition keeps track of the layout of the disk. You cannot remove this partition. If you are using BootX, the configuration below assumes that MacOS is installed on a seperate disk. If this is not the case, there will be additional partitions for "Apple Disk Drivers" such as Apple_Driver63, Apple_Driver_ATA, Apple_FWDriver, Apple_Driver_IOKit, Apple_Patches and the MacOS install. If you are using Quik, you will need to create a boot partition to hold the kernel, unlike other Apple boot methods. After the boot partition, the usual Linux filesystems are placed, according to the scheme below. The swap partition is a temporary storage place for when your system runs out of physical memory. The root partition will contain the filesystem that Gentoo is installed on.

Note: If you are using an OldWorld machine, you will need to keep MacOS available. The layout here assumes MacOS is installed on a separate drive.

Partition Size Filesystem Description
/dev/sda1 32k None Apple Partition Map
/dev/sda2 32Mb ext2 Quik Boot Partition (quik only)
/dev/sda3 512Mb Swap Linux Swap
/dev/sda4 Rest of Disk ext3, reiserfs, xfs Linux Root


The Pegasos partition layout is quite simple compared to the Apple layouts. The first partition is a Boot Partition, which contains kernels to be booted, along with an Open Firmware script that presents a menu on boot. After the boot partition, the usual Linux filesystems are placed, according to the scheme below. The swap partition is a temporary storage place for when your system runs out of physical memory. The root partition will contain the filesystem that Gentoo is installed on.

Partition Size Filesystem Description
/dev/sda1 32Mb affs1 or ext2 Boot Partition
/dev/sda2 512Mb Swap Linux Swap
/dev/sda3 Rest of Disk ext3, reiserfs, xfs Linux Root

IBM PReP (RS/6000)

The IBM PowerPC Reference Platform (PReP) requires a small PReP boot partition on the disk's first partition, followed by the swap and root partitions.

Partition Size Filesystem Description
/dev/sda1 800k None PReP Boot Partition (Type 0x41)
/dev/sda2 512Mb Swap Linux Swap (Type 0x82)
/dev/sda3 Rest of Disk ext3, reiserfs, xfs Linux Root (Type 0x83)

Warning: parted is able to resize partitions including HFS+. Unfortunately there may be issues with resizing HFS+ journaled filesystems, so, for the best results, switch off journaling in Mac OS X before resizing. Remember that any resizing operation is dangerous, so attempt at your own risk! Be sure to always have a backup of your data before resizing!

If you are interested in knowing how big a partition should be, or even how many partitions you need, read on. Otherwise continue now with Default: Using mac-fdisk (Apple) to Partition your Disk or Alternative: Using parted (IBM/Pegasos) to Partition your Disk.

How Many and How Big?

The number of partitions is highly dependent on your environment. For instance, if you have lots of users, you will most likely want to have your /home separate as it increases security and makes backups easier. If you are installing Gentoo to perform as a mailserver, your /var should be separate as all received mail is stored in /var. A good choice of filesystem will then maximise your performance. Game servers should have a separate /opt as most game servers are installed there. The reason is similar for /home: security and backups. Whatever layout you chose, you will definitely want to keep /usr large: not only will it contain the majority of applications, the Portage tree alone takes more than 500Mb excluding the various sources that are stored in it.

As you can see, it very much depends on what you want to achieve. Separate partitions or volumes have the following advantages:

  • You can choose the best performing filesystem for each partition or volume
  • Your entire system cannot run out of free space if one defunct tool is continuously writing files to a partition or volume
  • If necessary, file system checks are reduced in time, as multiple checks can be done in parallel (although this advantage is more with multiple disks than it is with multiple partitions)
  • Security can be enhanced by mounting some partitions or volumes read-only, nosuid (setuid bits are ignored), noexec (executable bits are ignored) etc.

However, multiple partitions have one big disadvantage: if not configured properly, you might result in having a system with lots of free space on one partition and none on another. There is also a 15-partition limit for SCSI and SATA.

4.c. Default: Using mac-fdisk (Apple) Partition your Disk

At this point, create your partitions using mac-fdisk:

Code Listing 3.1: Starting mac-fdisk

# mac-fdisk /dev/sda

If you used Apple's Disk Utility to leave space for Linux, first delete the partitions you have created previously to make room for your new install. Use d in mac-fdisk to delete those partition(s). It will ask for the partition number to delete. Usually the first partition on NewWorld machines (Apple_partition_map) could not be deleted. If you would like to start with a clean disk, you can simply initialize the disk by pressing i. This will completely erase the disk, so use this with caution.

Second, create an Apple_Bootstrap partition by using b. It will ask for what block you want to start. Enter the number of your first free partition, followed by a p. For instance this is 2p.

Note: This partition is not a /boot partition. It is not used by Linux at all; you don't have to place any filesystem on it and you should never mount it. Apple users don't need an extra partition for /boot.

Now create a swap partition by pressing c. Again mac-fdisk will ask for what block you want to start this partition from. As we used 2 before to create the Apple_Bootstrap partition, you now have to enter 3p. When you're asked for the size, enter 512M (or whatever size you want -- a minimum of 512MB is recommended, but 2 times your physical memory is the generally accepted size). When asked for a name, enter swap.

To create the root partition, enter c, followed by 4p to select from what block the root partition should start. When asked for the size, enter 4p again. mac-fdisk will interpret this as "Use all available space". When asked for the name, enter root.

To finish up, write the partition to the disk using w and q to quit mac-fdisk.

Note: To make sure everything is ok, you should run mac-fdisk -l and check whether all the partitions are there. If you don't see any of the partitions you created, or the changes you made, you should reinitialize your partitions by pressing "i" in mac-fdisk. Note that this will recreate the partition map and thus remove all your partitions.

Now that your partitions are created, you can continue with Creating Filesystems.

4.d. Using parted to Partition your Disk (Pegasos and RS/6000)

parted, the Partition Editor, can now handle HFS+ partitions used by Mac OS and Mac OS X. With this tool you can resize your Mac-partitions and create space for your Linux partitions. Nevertheless, the example below describes partitioning for Pegasos machines only.

To begin let's fire up parted:

Code Listing 4.1: Starting parted

# parted /dev/sda

If the drive is unpartitioned, run mklabel amiga to create a new disklabel for the drive.

You can type print at any time in parted to display the current partition table. If at any time you change your mind or made a mistake you can press Ctrl-c to abort parted.

If you intend to also install MorphOS on your Pegasos create an affs1 filesystem at the start of the drive. 32MB should be more than enough to store the MorphOS kernel. If you have a Pegasos I or intend to use any filesystem besides ext2 or ext3, you will also have to store your Linux kernel on this partition (the Pegasos II can only boot from ext2/ext3 or affs1 partitions). To create the partition run mkpart primary affs1 START END where START and END should be replaced with the megabyte range (e.g. 0 32) which creates a 32 MB partition starting at 0MB and ending at 32MB. If you chose to create an ext2 or ext3 partition instead, substitute ext2 or ext3 for affs1 in the mkpart command.

You will need to create two partitions for Linux, one root filesystem and one swap partition. Run mkpart primary START END to create each partition, replacing START and END with the desired megabyte boundries.

It is generally recommended that you create a swap partition that is two times bigger than the amount of RAM in your computer, but at least 512Mb is recommended. To create the swap partition, run mkpart primary linux-swap START END with START and END again denoting the partition boundries.

When you are done in parted simply type quit.

4.e. Creating Filesystems


Now that your partitions are created, it is time to place a filesystem on them. If you're not sure which filesystems to choose and are happy with our defaults, continue with Applying a Filesystem to a Partition. Otherwise, read on to learn about the available filesystems.


Several filesystems are available for use on the PowerPC architecture including ext2, ext3, ext4, ReiserFS and XFS, each with their strengths and faults.

ext2 is the tried and true Linux filesystem but doesn't have metadata journaling, which means that routine ext2 filesystem checks at startup time can be quite time-consuming. There is now quite a selection of newer-generation journaled filesystems that can be checked for consistency very quickly and are thus generally preferred over their non-journaled counterparts. Journaled filesystems prevent long delays when you boot your system and your filesystem happens to be in an inconsistent state.

ext3 is the journaled version of the ext2 filesystem, providing metadata journaling for fast recovery in addition to other enhanced journaling modes like full data and ordered data journaling. It uses an HTree index that enables high performance in almost all situations. In short, ext3 is a very good and reliable filesystem.

ext4 is a filesystem created as a fork of ext3 bringing new features, performance improvements and removal of size limits with moderate changes to the on-disk format. It can span volumes up to 1 EB and with maximum file size of 16 TB. Instead of the classic ext2/3 bitmap block allocation ext4 uses extents, which improve large file performance and reduce fragmentation. Ext4 also provides more sophisticated block allocation algorithms (delayed allocation and multiblock allocation) giving the filesystem driver more ways to optimise the layout of data on the disk. The ext4 filesystem is a compromise between production-grade code stability and the desire to introduce extensions to an almost decade old filesystem. Ext4 is the recommended all-purpose all-platform filesystem.

If you intend to install Gentoo on a small partition (less than 8GB), then you'll need to tell ext2, ext3 or ext4 (if available) to reserve enough inodes when you create the filesystem. The mke2fs application uses the "bytes-per-inode" setting to calculate how many inodes a file system should have. By running mke2fs -T small /dev/<device> (ext2) or mke2fs -j -T small /dev/<device> (ext3/ext4) the number of inodes will generally quadruple for a given file system as its "bytes-per-inode" reduces from one every 16kB to one every 4kB. You can tune this even further by using mke2fs -i <ratio> /dev/<device> (ext2) or mke2fs -j -i <ratio> /dev/<device> (ext3/ext4).

ReiserFS is a B+tree-based journaled filesystem that has good overall performance, especially when dealing with many tiny files at the cost of more CPU cycles. ReiserFS appears to be less maintained than other filesystems.

XFS is a filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. XFS seems to be less forgiving to various hardware problems.

Activating the Swap Partition

mkswap is the command that is used to initialize swap partitions:

Code Listing 5.1: Creating a swap signature

# mkswap /dev/sda3

To activate the swap partition, use swapon:

Code Listing 5.2: Activating the swap partition

# swapon /dev/sda3

Create and activate the swap now before creating other filesystems.

Applying a Filesystem to a Partition

To create a filesystem on a partition or volume, there are tools available for each possible filesystem:

Filesystem Creation Command
ext2 mke2fs
ext3 mke2fs -j
reiserfs mkreiserfs
xfs mkfs.xfs

For instance, to make an ext3 filesystem on the root partition (/dev/sda4 in our example), you would use:

Code Listing 5.3: Applying a filesystem on a partition

# mke2fs -j /dev/sda4

Now create the filesystems on your newly created partitions (or logical volumes).

Important: If you choose to use ReiserFS for /, do not change its default block size if you will also be using yaboot as your bootloader, as explained in Configuring the Bootloader.

Note: On the PegasosII your partition which holds the kernel must be ext2, ext3 or affs1. NewWorld machines can boot from any of ext2, ext3, XFS, ReiserFS or even HFS/HFS+ filesystems. On OldWorld machines booting with BootX, the kernel must be placed on an HFS partition, but this will be completed when you configure your bootloader.

4.f. Mounting

Now that your partitions are initialized and are housing a filesystem, it is time to mount those partitions. Use the mount command. As an example we mount the root partition:

Code Listing 6.1: Mounting partitions

# mount /dev/sda4 /mnt/gentoo

Note: If you want your /tmp to reside on a separate partition, be sure to change its permissions after mounting and unpacking with chmod 1777 /mnt/gentoo/tmp. This is also true for /var/tmp.

Continue with Installing the Gentoo Installation Files.

5. Installing the Gentoo Installation Files

5.a. Installing a Stage Tarball

Setting the Date/Time Right

Before you continue you need to check your date/time and update it. A misconfigured clock may lead to strange results in the future!

To verify the current date/time, run date:

Code Listing 1.1: Verifying the date/time

# date
Fri Mar 29 16:21:18 UTC 2005

If the date/time displayed is wrong, update it using the date MMDDhhmmYYYY syntax (Month, Day, hour, minute and Year). At this stage, you should use UTC time. You will be able to define your timezone later on. For instance, to set the date to March 29th, 16:21 in the year 2005:

Code Listing 1.2: Setting the UTC date/time

# date 032916212005

5.b. Default: Using a Stage from the Installation CD

Extracting the Stage Tarball

The stages on the CD reside in the /mnt/cdrom/stages directory. To see a listing of available stages, use ls:

Code Listing 2.1: List all available stages

# ls /mnt/cdrom/stages

If the system replies with an error, you may need to mount the CD-ROM first:

Code Listing 2.2: Mounting the CD-ROM

# ls /mnt/cdrom/stages
ls: /mnt/cdrom/stages: No such file or directory
# mount /dev/cdroms/cdrom0 /mnt/cdrom
# ls /mnt/cdrom/stages

Now go into your Gentoo mountpoint (usually /mnt/gentoo):

Code Listing 2.3: Changing directory to /mnt/gentoo

# cd /mnt/gentoo

We will now extract the stage tarball of your choice. We will do this with the tar tool. Make sure you use the same options (xvjpf)! The x stands for Extract, the v for Verbose to see what happens during the extraction process (this one is optional), the j for Decompress with bzip2, the p for Preserve permissions and the f to denote that we want to extract a file, not standard input. In the next example, we extract the stage tarball stage3-ppc-2008.0.tar.bz2. Be sure to substitute the tarball filename with your stage.

Code Listing 2.4: Extracting the stage tarball

# tar xvjpf /mnt/cdrom/stages/stage3-ppc-2008.0.tar.bz2

Now that the stage is installed, continue with Installing Portage.

5.c. Installing Portage

Unpacking a Portage Snapshot

You now have to install a Portage snapshot, a collection of files that inform Portage what software titles you can install, which profiles are available, etc.

Unpack the Snapshot from the Installation CD

To install the snapshot, take a look inside /mnt/cdrom/snapshots/ to see what snapshot is available:

Code Listing 3.1: Checking the /mnt/cdrom/snapshots content

# ls /mnt/cdrom/snapshots

Now extract the snapshot using the following construct. Again, make sure you use the correct options with tar. Also, the -C is with a capital C, not c. In the next example we use portage-<date>.tar.bz2 as the snapshot filename. Be sure to substitute with the name of the snapshot that is on your Installation CD.

Code Listing 3.2: Extracting a Portage snapshot

# tar xvjf /mnt/cdrom/snapshots/portage-<date>.tar.bz2 -C /mnt/gentoo/usr

Copy Source Code Archives

You also need to copy over all source code from the Universal Installation CD.

Code Listing 3.3: Copy over source code

# mkdir /mnt/gentoo/usr/portage/distfiles
# cp /mnt/cdrom/distfiles/* /mnt/gentoo/usr/portage/distfiles/

5.d. Configuring the Compile Options


To optimize Gentoo, you can set a couple of variables which impact Portage behaviour. All those variables can be set as environment variables (using export) but that isn't permanent. To keep your settings, Portage provides you with /etc/make.conf, a configuration file for Portage. It is this file we will edit now.

Note: A commented listing of all possible variables can be found in /mnt/gentoo/etc/make.conf.example. For a successful Gentoo installation you'll only need to set the variables which are mentioned beneath.

Fire up your favorite editor (in this guide we use nano) so we can alter the optimization variables we will discuss hereafter.

Code Listing 4.1: Opening /etc/make.conf

# nano -w /mnt/gentoo/etc/make.conf

As you probably noticed, the make.conf.example file is structured in a generic way: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. The make.conf file uses the same syntax. Several of those variables are discussed next.

Warning: Do not make any modifications to the USE variable if you are performing a stage3 with GRP installation. You can alter the USE variable after having installed the packages you want. Gremlins are known to attack your system if you ignore this warning!


The CHOST variable declares the target build host for your system. This variable should already be set to the correct value. Do not edit it as that might break your system. If the CHOST variable does not look correct to you, you might be using the wrong stage3 tarball.


The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although we define those generally here, you will only have maximum performance if you optimize these flags for each program separately. The reason for this is because every program is different.

In make.conf you should define the optimization flags you think will make your system the most responsive generally. Don't place experimental settings in this variable; too much optimization can make programs behave bad (crash, or even worse, malfunction).

We cannot explain all possible optimization options here, but if you want to investigate them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system). For common optimizations and architecture specific settings, please read /etc/make.conf.example. This file also contains lots of examples and information; don't forget to read it too.

A first setting is the -march= or -mcpu= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments).

A second one is the -O flag (that is a capital O, not a zero), which specifies the gcc optimization class flag. Possible classes are s (for size-optimized), 0 (zero - for no optimizations), 1, 2 or even 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). -O2 is the recommended default. -O3 is known to cause problems when used system-wide, so we recommend that you stick to -O2.

Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation). It has no impact on the generated code.

Using -fomit-frame-pointer (which doesn't keep the frame pointer in a register for functions that don't need one) might have serious repercussions on the debugging of applications.

When you define the CFLAGS and CXXFLAGS, you should combine several optimization flags. The default values contained in the stage3 archive you unpacked should be good enough. The following example is just an example:

Code Listing 4.2: Defining the CFLAGS and CXXFLAGS variable

CFLAGS="-O2 -mcpu=powerpc -mtune=powerpc -fno-strict-aliasing -pipe"
# Use the same settings for both variables

Note: You may also want to view the Compilation Optimization Guide for more information on how the various compilation options can affect your system.


With MAKEOPTS you define how many parallel compilations should occur when you install a package. A good choice is the number of CPUs in your system plus one, but this guideline isn't always perfect.

Code Listing 4.3: MAKEOPTS for a regular, 1-CPU system


Ready, Set, Go!

Update your /mnt/gentoo/etc/make.conf to your own preference and save (nano users would hit Ctrl-X). You are now ready to continue with Chrooting into the Gentoo Base System.

6. Chrooting into the Gentoo Base System

6.a. Chrooting

Mounting the /proc and /dev Filesystems

Mount the /proc filesystem on /mnt/gentoo/proc to allow the installation to use the kernel-provided information within the chrooted environment, and then mount-bind the /dev filesystem.

Code Listing 1.1: Mounting /proc and /dev

# mount -t proc none /mnt/gentoo/proc
# mount -o bind /dev /mnt/gentoo/dev

Entering the new Environment

Now that all partitions are initialized and the base environment installed, it is time to enter our new installation environment by chrooting into it. This means that we change from the current installation environment to your installation system (namely the initialized partitions).

This chrooting is done in three steps. First we will change the root from / (on the installation medium) to /mnt/gentoo (on your partitions) using chroot. Then we will create a new environment using env-update, which essentially creates environment variables. Finally, we load those variables into memory using source.

Code Listing 1.2: Chrooting into the new environment

# chroot /mnt/gentoo /bin/bash
# env-update
>>> Regenerating /etc/
# source /etc/profile
# export PS1="(chroot) $PS1"

Congratulations! You are now inside your own Gentoo Linux environment. Of course it is far from finished, which is why the installation still has some sections left :-)

Creating the Portage cache

You have already installed the Portage tree, but you should now build the Portage cache to speed up future emerges. emerge --metadata does this for you.

Code Listing 1.3: Creating the Portage cache

# emerge --metadata

6.b. Configuring the USE Variable

What is the USE Variable?

USE is one of the most powerful variables Gentoo provides to its users. Several programs can be compiled with or without optional support for certain items. For instance, some programs can be compiled with gtk-support, or with qt-support. Others can be compiled with or without SSL support. Some programs can even be compiled with framebuffer support (svgalib) instead of X11 support (X-server).

Most distributions compile their packages with support for as much as possible, increasing the size of the programs and startup time, not to mention an enormous amount of dependencies. With Gentoo you can define what options a package should be compiled with. This is where USE comes into play.

In the USE variable you define keywords which are mapped onto compile-options. For instance, ssl will compile ssl-support in the programs that support it. -X will remove X-server support (note the minus sign in front). gnome gtk -kde -qt4 will compile your programs with gnome (and gtk) support, and not with kde (and qt) support, making your system fully tweaked for GNOME.

Modifying the USE Variable

Warning: Do not make any modifications to the USE variable yet if you plan to use our prebuilt packages (GRP set). You can alter the USE variable after having installed the packages you want. Gremlins are known to attack your system if you ignore this warning!

The default USE settings are placed in /etc/make.profile/make.defaults. What you place in /etc/make.conf is calculated against these defaults settings. If you add something to the USE setting, it is added to the default list. If you remove something from the USE setting (by placing a minus sign in front of it) it is removed from the default list (if it was in the default list at all). Never alter anything inside the /etc/make.profile directory; it gets overwritten when you update Portage!

A full description on USE can be found in the second part of the Gentoo Handbook, USE flags. A full description on the available USE flags can be found on your system in /usr/portage/profiles/use.desc.

Code Listing 2.1: Viewing available USE flags

# less /usr/portage/profiles/use.desc
(You can scroll using your arrow keys, exit by pressing 'q')

As an example we show a USE setting for a KDE-based system with DVD, ALSA and CD Recording support:

Code Listing 2.2: Opening /etc/make.conf

# nano -w /etc/make.conf

Code Listing 2.3: USE setting

USE="-gtk -gnome qt4 kde dvd alsa cdr"

7. Configuring the Kernel

7.a. Timezone

You first need to select your timezone so that your system knows where it is located. Look for your timezone in /usr/share/zoneinfo, then copy it to /etc/localtime. Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8.

Code Listing 1.1: Setting the timezone information

# ls /usr/share/zoneinfo
(Suppose you want to use GMT)
# cp /usr/share/zoneinfo/GMT /etc/localtime

7.b. Installing the Kernel Sources

Choosing a Kernel

The core around which all distributions are built is the Linux kernel. It is the layer between the user programs and your system hardware. Gentoo provides its users several possible kernels to choose from. A full listing with description is available at the Gentoo Kernel Guide.

We suggest using gentoo-sources on PPC, which is a recent 2.6 kernel.

Code Listing 2.1: Installing a kernel source

# emerge --usepkg gentoo-sources

If you take a look in /usr/src you should see a symlink named linux pointing to your current kernel source. In this case, the installed kernel source points to gentoo-sources-2.6.24-r5. Your version may be different, so keep this in mind.

Code Listing 2.2: Viewing the kernel source symlink

# ls -l /usr/src/linux
lrwxrwxrwx    1 root     root           22  Mar 18 16:23 /usr/src/linux -> linux-2.6.24-gentoo-r5

Now it is time to configure and compile your kernel source. You can use genkernel for this, which will build a generic kernel as used by the Installation CD. We explain the "manual" configuration first though, as it is a more efficient configuration.

If you want to manually configure your kernel, continue now with Default: Manual Configuration. If you want to use genkernel you should read Alternative: Using genkernel instead.

7.c. Default: Manual Configuration


Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a few kernels you won't even remember that it was difficult ;)

However, one thing is true: you must know your system when you start configuring a kernel manually. Most information can be gathered by emerging pciutils (emerge --usepkg pciutils) which contains the program lspci. You will now be able to use lspci within the chrooted environment. You may safely ignore any pcilib warnings (such as pcilib: cannot open /sys/bus/pci/devices) that lspci throws out. Alternatively, you can run lspci from a non-chrooted environment. The results are the same. You can also run lsmod to see what kernel modules the Installation CD uses (it might provide you with a nice hint on what to enable). Another place to look for clues as to what components to enable is to check the kernel message logs from the successful boot that got you this far. Type dmesg to see these kernel messages.

Now, go to your kernel source directory, it's time to configure your kernel. Start by configuring a kernel that will boot on most 32 Bit PowerPC machines by first running make pmac32_defconfig. After the default configuration has been generated, run make menuconfig to start an ncurses-based configuration menu.

Code Listing 3.1: Invoking menuconfig

# cd /usr/src/linux
# make pmac32_defconfig
# make menuconfig

You will be greeted with several configuration sections. We'll first list some options you must activate (otherwise Gentoo will not function, or not function properly without additional tweaks).

Activating Required Options

First go to File Systems and select support for the filesystems you use. Don't compile them as modules, otherwise your Gentoo system will not be able to mount your partitions. Also select the /proc file system and Virtual memory. Make sure that you also enable support for Amiga partitions if you are using a Pegasos, or Macintosh partitions if you are using an Apple computer.

Code Listing 3.2: Selecting necessary file systems

File systems --->
  Pseudo Filesystems --->
(/proc may already be forced on by your configuration, if so, you'll see --- instead)
    [*] /proc file system support
    [*] Virtual memory file system support (former shm fs)
  Partition Types --->
    [*] Advanced partition support
    [*]   Amiga partition table support
    [*]   Macintosh partition map support

(Select one or more of the following options as needed by your system)
  <*> Reiserfs support
  <*> Ext3 journalling file system support
  <*> Second extended fs support
  <*> XFS filesystem support

Users of NewWorld and OldWorld machines will want HFS support as well. OldWorld users require it for copying compiled kernels to the MacOS partition. NewWorld users require it for configuring the special Apple_Bootstrap partition:

Code Listing 3.3: Activating HFS support

File Systems --->
  Miscellaneous filesystems --->
    <M> Apple Macintosh file system support
    <M> Apple Extended HFS file system support

If you are using PPPoE to connect to the Internet or you are using a dial-up modem, you will need the following options in the kernel:

Code Listing 3.4: Selecting PPPoE necessary drivers

Device Drivers --->
  Network device support --->
    <*> PPP (point-to-point protocol) support
    <*>   PPP support for async serial ports
    <*>   PPP support for sync tty ports

The two compression options won't harm but are not always needed. The PPP over Ethernet option might only be used by ppp when configured to perform kernel mode PPPoE.

Don't forget to include support in the kernel for your ethernet card! Most newer Apple computers use the SunGEM ethernet driver. Older iMacs commonly use the BMAC driver.

Code Listing 3.5: Selecting the network driver

Device Drivers --->
  Network device support --->
    Ethernet (10 or 100Mbit) --->
      [*] Ethernet (10 or 100Mbit)
      <*>   Generic Media Independent Interface device support
      <*>   MACE (Power Mac ethernet) support
      <*>   BMAC (G3 ethernet) support
      <*>   Sun GEM support

At this time, full kernel preemption may still be unstable on PPC and may cause compilation failures and random segfaults. It is strongly suggested that you do not use this feature. Both Voluntary Preemption and No Forced Preemption should be safe.

Code Listing 3.6: Ensure the Preemptible Kernel Option is Off

Kernel options --->
(Select One)
  Preemption Model 
    (X) No Forced Preemption (Server)
    (X) Voluntary Kernel Preemption (Desktop)

If you're booting from Firewire, you'll need to enable these options. If you do not want to compile in support, you'll need to include these modules and their dependencies in an initrd.

Code Listing 3.7: Enable support for firewire devices on boot

Device Drivers --->
  IEEE 1394 (FireWire) support --->
    <*> IEEE 1394 (FireWire) support
    <*>   OHCI-1394 support
    <*>   SBP-2 support (Harddisks etc.)

If you're booting from USB, you'll need to enable these options. If you do not want to compile in support, you'll need to include these modules and their dependencies in an initrd.

Code Listing 3.8: Enable support for USB devices on boot

Device Drivers --->
  USB support --->
    <*> Support for Host-side USB
    <*>   OHCI HCD support
    <*>   USB Mass Storage support

Do not turn off kernel framebuffer support as it is required for a successful boot. If you are using an NVIDIA based chipset, you should use the Open Firmware framebuffer. If you are using an ATI based chipset, you should select the framebuffer driver based upon your chipset (Mach64, Rage128 or Radeon).

Code Listing 3.9: Choosing a Framebuffer Driver

Device Drivers --->
  Graphics support --->
    <*> Support for frame buffer devices
    [*] Open Firmware frame buffer device support
    <*> ATI Radeon display support
    <*> ATI Rage128 display support
    <*> ATI Mach64 display support
    Console display driver support --->
      <*> Framebuffer Console support

Note: If you select more than one framebuffer device, it may default to a less than optimal driver. Either use only one framebuffer device or specify which to use by passing the driver to use to the kernel on boot by appending a video line such as: video=radeonfb.

When you're done configuring your kernel, continue with Compiling and Installing.

Compiling and Installing

Now that your kernel is configured, it is time to compile and install it. Exit the configuration menu and run the following commands:

Code Listing 3.10: Compiling the kernel

# make && make modules_install

When the kernel has finished compiling, copy the kernel image to /boot as shown below. If you have a separate boot partition, as on Pegasos computers, be sure that it is mounted properly. If you are using BootX to boot, we'll copy the kernel later.

Yaboot and BootX expect to use an uncompressed kernel unlike many other bootloaders. The uncompressed kernel is called vmlinux and it is placed in /usr/src/linux after the kernel has finished compiling. If you are using a Pegasos machine, the Pegasos firmware requires a compressed kernel called zImage which can be found in /usr/src/linux/arch/powerpc/boot/images.

Code Listing 3.11: Installing the kernel

# cd /usr/src/linux
Note, your kernel version might be different
# cp vmlinux /boot/kernel-2.6.24-gentoo-r5
# cp arch/powerpc/boot/images/zImage /boot/kernel-2.6.24-gentoo-r5 

Now continue with Installing Separate Kernel Modules.

7.d. Installing Separate Kernel Modules

Configuring the Modules

You should list the modules you want automatically loaded in /etc/modules.autoload.d/kernel-2.6. You can add extra options to the modules if required.

To view all available modules, run the following find command. Don't forget to substitute "<kernel version>" with the version of the kernel you just compiled:

Code Listing 4.1: Viewing all available modules

# find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko'

For instance, to automatically load the 3c59x module, edit the kernel-2.6 file and add the module to it, one module on a line.

Code Listing 4.2: Editing /etc/modules.autoload.d/kernel-2.6

# nano -w /etc/modules.autoload.d/kernel-2.6

Code Listing 4.3: /etc/modules.autoload.d/kernel-2.6


Continue the installation with Configuring your System.

7.e. Alternative: Using genkernel

Now that your kernel source tree is installed, it's now time to compile your kernel by using our genkernel script to automatically build a kernel for you. genkernel works by configuring a kernel nearly identically to the way our Installation CD kernel is configured. This means that when you use genkernel to build your kernel, your system will generally detect all your hardware at boot-time, just like our Installation CD does. Because genkernel doesn't require any manual kernel configuration, it is an ideal solution for those users who may not be comfortable compiling their own kernels.

Now, let's see how to use genkernel. First, emerge the genkernel ebuild:

Code Listing 5.1: Emerging genkernel

# emerge --usepkg genkernel

Next, copy over the kernel configuration used by the Installation CD to the location where genkernel looks for the default kernel configuration:

Code Listing 5.2: Copying over the Installation CD kernel config

# zcat /proc/config.gz > /usr/share/genkernel/ppc/kernel-config-2.6

If you are using firewire or USB to boot, you'll need to add modules to the initrd. Edit /usr/share/genkernel/ppc/modules_load and change MODULES_FIREWIRE="ieee1394 ohci1394 sbp2" for firewire support or MODULES_USB="usbcore ohci-hcd ehci-hcd usb-storage" for USB support.

Before compiling your sources, the fstab needs a slight adjustment. The rest of the fstab will be completed during a later step, so don't worry about the details now. If you did not create a separate boot partition (NOT bootstrap, that's different), remove the line referencing /boot from /etc/fstab. This will need to be done on most Apple computers.

Code Listing 5.3: Removing /boot from /etc/fstab on machines without a boot partition

# nano -w /etc/fstab
Remove this line
/dev/BOOT		/boot		ext2		noauto,noatime	1 2

Now, compile your kernel sources by running genkernel --genzimage all. For Pegasos, we will need to use a different config and create a zImage instead of the vmlinux kernel used on Apple machines. Be aware, as genkernel compiles a kernel that supports almost all hardware, this compilation can take quite a while to finish!

Note that, if your partition where the kernel should be located doesn't use ext2 or ext3 as filesystem you might need to manually configure your kernel using genkernel --menuconfig all and add support for your filesystem in the kernel (i.e. not as a module). Users of EVMS2 or LVM2 will probably want to add --evms2 or --lvm2 as an argument as well.

Code Listing 5.4: Running genkernel

# genkernel all

Code Listing 5.5: Running genkernel on the Pegasos

# genkernel --genzimage --kernel-config=/usr/share/genkernel/ppc/Pegasos all

Once genkernel completes, a kernel, full set of modules and initial root disk (initrd) will be created. We will use the kernel and initrd when configuring a boot loader later in this document. Write down the names of the kernel and initrd as you will need them when writing the bootloader configuration file. The initrd will be started immediately after booting to perform hardware autodetection (just like on the Installation CD) before your "real" system starts up. Be sure to also copy down the required boot arguments, these are required for a successful boot with genkernel.

Code Listing 5.6: Checking the created kernel image name and initrd

Note, your kernel version might be different
# ls /boot/kernel-genkernel-ppc-2.6.24-gentoo-r5 /boot/initramfs-genkernel-ppc-2.6.24-gentoo-r5

Now continue with Configuring your System.

8. Configuring your System

8.a. Filesystem Information

What is fstab?

Under Linux, all partitions used by the system must be listed in /etc/fstab. This file contains the mountpoints of those partitions (where they are seen in the file system structure), how they should be mounted and with what special options (automatically or not, whether users can mount them or not, etc.)

Creating /etc/fstab

/etc/fstab uses a special syntax. Every line consists of six fields, separated by whitespace (space(s), tabs or a mixture). Each field has its own meaning:

  • The first field shows the partition described (the path to the device file)
  • The second field shows the mountpoint at which the partition should be mounted
  • The third field shows the filesystem used by the partition
  • The fourth field shows the mountoptions used by mount when it wants to mount the partition. As every filesystem has its own mountoptions, you are encouraged to read the mount man page (man mount) for a full listing. Multiple mountoptions are comma-separated.
  • The fifth field is used by dump to determine if the partition needs to be dumped or not. You can generally leave this as 0 (zero).
  • The sixth field is used by fsck to determine the order in which filesystems should be checked if the system wasn't shut down properly. The root filesystem should have 1 while the rest should have 2 (or 0 if a filesystem check isn't necessary).

Important: The default /etc/fstab file provided by Gentoo is not a valid fstab file. You have to create your own /etc/fstab.

Code Listing 1.1: Opening /etc/fstab

# nano -w /etc/fstab

Add the rules that match your partitioning scheme and append rules for your CD-ROM drive(s), and of course, if you have other partitions or drives, for those too.

Now use the example below to create your /etc/fstab:

Code Listing 1.2: A full /etc/fstab example

/dev/sda4   /            ext3    noatime              0 1
/dev/sda3   none         swap    sw                   0 0

/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

proc        /proc        proc    defaults             0 0
shm         /dev/shm     tmpfs   nodev,nosuid,noexec  0 0

auto makes mount guess for the filesystem (recommended for removable media as they can be created with one of many filesystems) and user makes it possible for non-root users to mount the CD.

To improve performance, most users would want to add the noatime mount option, which results in a faster system since access times aren't registered (you don't need those generally anyway).

Double-check your /etc/fstab, save and quit to continue.

8.b. Networking Information

Hostname, Domainname etc.

One of the choices the user has to make is name his/her PC. This seems to be quite easy, but lots of users are having difficulties finding the appropriate name for their Linux-pc. To speed things up, know that any name you choose can be changed afterwards. For all we care, you can just call your system tux and domain homenetwork.

We use these values in the next examples. First we set the hostname:

Code Listing 2.1: Setting the hostname

# nano -w /etc/conf.d/hostname

(Set the HOSTNAME variable to your hostname)

Second, if you need a domainname, set it in /etc/conf.d/net. You only need a domain if your ISP or network administrator says so, or if you have a DNS server but not a DHCP server. You don't need to worry about DNS or domainnames if your networking is setup for DHCP.

Code Listing 2.2: Setting the domainname

# nano -w /etc/conf.d/net

(Set the dns_domain variable to your domain name)

Note: If you choose not to set a domainname, you can get rid of the "This is hostname.(none)" messages at your login screen by editing /etc/issue. Just delete the string .\O from that file.

If you have a NIS domain (if you don't know what that is, then you don't have one), you need to define that one too:

Code Listing 2.3: Setting the NIS domainname

# nano -w /etc/conf.d/net

(Set the nis_domain variable to your NIS domain name)

Note: For more information on configuring DNS and NIS, please read the examples provided in /etc/conf.d/net.example. Also, you may want to emerge openresolv to help manage your DNS/NIS setup.

Configuring your Network

Before you get that "Hey, we've had that already"-feeling, you should remember that the networking you set up in the beginning of the Gentoo installation was just for the installation. Right now you are going to configure networking for your Gentoo system permanently.

Note: More detailed information about networking, including advanced topics like bonding, bridging, 802.1Q VLANs or wireless networking is covered in the Gentoo Network Configuration section.

All networking information is gathered in /etc/conf.d/net. It uses a straightforward yet not intuitive syntax if you don't know how to set up networking manually. But don't fear, we'll explain everything. A fully commented example that covers many different configurations is available in /etc/conf.d/net.example.

DHCP is used by default and does not require any further configuration.

If you need to configure your network connection either because you need specific DHCP options or because you do not use DHCP at all, open /etc/conf.d/net with your favorite editor (nano is used in this example):

Code Listing 2.4: Opening /etc/conf.d/net for editing

# nano -w /etc/conf.d/net

You will see the following file:

Code Listing 2.5: Default /etc/conf.d/net

# This blank configuration will automatically use DHCP for any net.*
# scripts in /etc/init.d.  To create a more complete configuration,
# please review /etc/conf.d/net.example and save your configuration
# in /etc/conf.d/net (this file :]!).

To enter your own IP address, netmask and gateway, you need to set both config_eth0 and routes_eth0:

Code Listing 2.6: Manually setting IP information for eth0

config_eth0=( " netmask brd" )
routes_eth0=( "default via" )

To use DHCP, define config_eth0:

Code Listing 2.7: Automatically obtaining an IP address for eth0

config_eth0=( "dhcp" )

Please read /etc/conf.d/net.example for a list of all available options. Be sure to also read your DHCP client manpage if you need to set specific DHCP options.

If you have several network interfaces repeat the above steps for config_eth1, config_eth2, etc.

Now save the configuration and exit to continue.

Automatically Start Networking at Boot

To have your network interfaces activated at boot, you need to add them to the default runlevel.

Code Listing 2.8: Adding net.eth0 to the default runlevel

# rc-update add net.eth0 default

If you have several network interfaces, you need to create the appropriate net.eth1, net.eth2 etc. initscripts for those. You can use ln to do this:

Code Listing 2.9: Creating extra initscripts

# cd /etc/init.d
# ln -s net.lo net.eth1
# rc-update add net.eth1 default

Writing Down Network Information

You now need to inform Linux about your network. This is defined in /etc/hosts and helps in resolving hostnames to IP addresses for hosts that aren't resolved by your nameserver. You need to define your system. You may also want to define other systems on your network if you don't want to set up your own internal DNS system.

Code Listing 2.10: Opening /etc/hosts

# nano -w /etc/hosts

Code Listing 2.11: Filling in the networking information

(This defines the current system)     tux.homenetwork tux localhost

(Define extra systems on your network,
they need to have a static IP to be defined this way.)   jenny.homenetwork jenny   benny.homenetwork benny

Save and exit the editor to continue.

If you don't have PCMCIA, you can now continue with System Information. PCMCIA-users should read the following topic on PCMCIA.

Optional: Get PCMCIA Working

PCMCIA users should first install the pcmciautils package.

Code Listing 2.12: Installing pcmciautils

# emerge pcmciautils

8.c. System Information

Root Password

First we set the root password by typing:

Code Listing 3.1: Setting the root password

# passwd

If you want root to be able to log on through the serial console, add tts/0 to /etc/securetty:

Code Listing 3.2: Adding tts/0 to /etc/securetty

# echo "tts/0" >> /etc/securetty

System Information

Gentoo uses /etc/rc.conf for general, system-wide configuration. Open up /etc/rc.conf and enjoy all the comments in that file :)

Code Listing 3.3: Opening /etc/rc.conf

# nano -w /etc/rc.conf

When you're finished configuring /etc/rc.conf, save and exit.

As you can see, this file is well commented to help you set up the necessary configuration variables. You can configure your system to use unicode and define your default editor and your display manager (like gdm or kdm).

Gentoo uses /etc/conf.d/keymaps to handle keyboard configuration. Edit it to configure your keyboard.

Code Listing 3.4: Opening /etc/conf.d/keymaps

# nano -w /etc/conf.d/keymaps

Take special care with the KEYMAP variable. If you select the wrong KEYMAP, you will get weird results when typing on your keyboard.

Note: PPC uses x86 keymaps on most systems.

When you're finished configuring /etc/conf.d/keymaps, save and exit.

Gentoo uses /etc/conf.d/clock to set clock options. Edit it according to your needs.

Code Listing 3.5: Opening /etc/conf.d/clock

# nano -w /etc/conf.d/clock

If your hardware clock is not using UTC, you need to add CLOCK="local" to the file. Otherwise you will notice some clock skew.

You should define the timezone that you previously copied to /etc/localtime so that further upgrades of the sys-libs/timezone-data package can update /etc/localtime automatically. For instance, if you used the GMT timezone, you would add TIMEZONE="GMT".

When you're finished configuring /etc/conf.d/clock, save and exit.

Please continue with Installing Necessary System Tools.

9. Installing Necessary System Tools

9.a. System Logger

Some tools are missing from the stage3 archive because several packages provide the same functionality. It is now up to you to choose which ones you want to install.

The first tool you need to decide on has to provide logging facilities for your system. Unix and Linux have an excellent history of logging capabilities -- if you want you can log everything that happens on your system in logfiles. This happens through the system logger.

Gentoo offers several system loggers to choose from. There are sysklogd, which is the traditional set of system logging daemons, syslog-ng, an advanced system logger, and metalog which is a highly-configurable system logger. Others might be available through Portage as well - our number of available packages increases on a daily basis.

If you plan on using sysklogd or syslog-ng you might want to install logrotate afterwards as those system loggers don't provide any rotation mechanism for the log files.

To install the system logger of your choice, emerge it and have it added to the default runlevel using rc-update. The following example installs syslog-ng. Of course substitute with your system logger:

Code Listing 1.1: Installing a system logger

# emerge syslog-ng
# rc-update add syslog-ng default

9.b. Optional: Cron Daemon

Next is the cron daemon. Although it is optional and not required for your system, it is wise to install one. But what is a cron daemon? A cron daemon executes scheduled commands. It is very handy if you need to execute some command regularly (for instance daily, weekly or monthly).

We only provide vixie-cron for networkless installations. If you want another cron daemon you can wait and install it later on.

Code Listing 2.1: Installing a cron daemon

# emerge vixie-cron
# rc-update add vixie-cron default

9.c. Optional: File Indexing

If you want to index your system's files so you are able to quickly locate them using the locate tool, you need to install sys-apps/slocate.

Code Listing 3.1: Installing slocate

# emerge slocate

9.d. File System Tools

Depending on what file systems you are using, you need to install the necessary file system utilities (for checking the filesystem integrity, creating additional file systems etc.).

The following table lists the tools you need to install if you use a certain file system. Not all filesystems are available for each and every architecture though.

File System Tool Install Command
XFS xfsprogs emerge xfsprogs
ReiserFS reiserfsprogs emerge reiserfsprogs
JFS jfsutils emerge jfsutils

If you are an EVMS user, you need to install emvs:

Code Listing 4.1: Installing EVMS utilities

# USE="-gtk" emerge evms

The USE="-gtk" will prevent the installation of dependencies. If you want to enable the evms graphical tools, you can recompile evms later on.

Optional: RAID utilities for IBM hardware

If you are using SCSI RAID on a POWER5-based system, you should consider installing the iprutils which will allow you to work with the RAID disk array, get status on the disks in the arrays, and update microcode among other functions.

Code Listing 4.2: Installing iprutils

# emerge iprutils

9.e. Networking Tools

If you don't require any additional networking-related tools (such as ppp or a dhcp client) continue with Configuring the Bootloader.

Optional: Installing a DHCP Client

If you require Gentoo to automatically obtain an IP address for your network interface(s), you need to install dhcpcd (or any other DHCP Client) on your system. If you don't do this now, you might not be able to connect to the internet after the installation!

Code Listing 5.1: Installing dhcpcd

# emerge dhcpcd

Optional: Installing a PPPoE Client

If you need ppp to connect to the net, you need to install it.

Code Listing 5.2: Installing ppp

# emerge ppp

Now continue with Configuring the Bootloader.

10. Configuring the Bootloader

10.a. Choosing a Bootloader


Now that the kernel is configured and compiled, you'll need a bootloader to start your new linux installation. The bootloader that you use will depend upon the type of PPC machine you have.

If you are using a NewWorld Apple or IBM machine, you need to use yaboot. OldWorld Apple machines have two options, BootX (recommended) and quik. The Pegasos does not require a bootloader, but you will need to emerge bootcreator to create SmartFirmware boot menus.

10.b. Default: Using yaboot


Important: yaboot can only be used on NewWorld Apple and IBM systems!

In order to find the boot devices, yaboot needs access to the device nodes created by udev on startup and the sysfs filesystem. These two filesystems are found at /dev and sys respectively. To do this, you will need to "bind mount" these filesystems from the Installation CD's root to the /dev and /sys mount points inside the chroot. If you have already bind mounted these filesystems, there is no need to do it again.

Code Listing 2.1: Bind-mounting the device and sysfs filesystems

# exit  # this will exit the chroot
# mount -o bind /dev /mnt/gentoo/dev
# mount -o bind /sys /mnt/gentoo/sys
# chroot /mnt/gentoo /bin/bash
# /usr/sbin/env-update && source /etc/profile 

To set up yaboot, you can use yabootconfig to automatically create a configuration file for you. If you are installing Gentoo on a G5 (where yabootconfig does not always work), or you plan to boot from firewire or USB, you will need to manually configure yaboot.

Note: You will need to manually edit the yaboot.conf when using genkernel, even if yabootconfig is used. The kernel image section of yaboot.conf should be modified as follows (using vmlinux and initrd as the name of kernel and initrd image):

Code Listing 2.2: Adding genkernel boot arguments to yaboot.conf

## This section can be duplicated if you have more than one
## kernel or set of boot options - replace the image and initrd
## with the exact filename of your kernel and initrd image.
  # You can add additional kernel arguments to append such as 
  # rootdelay=10 for a USB/Firewire Boot
  append="real_root=/dev/sda3 init=/linuxrc"  

Default: Using yabootconfig

yabootconfig will auto-detect the partitions on your machine and will set up dual and triple boot combinations with Linux, Mac OS, and Mac OS X.

To use yabootconfig, your drive must have an Apple_Bootstrap partition, and /etc/fstab must be configured to reflect your Linux partitions (note that the Bootstrap partition should not be in your fstab). These steps should have already been completed before, but check /etc/fstab before proceeding. Now, install yaboot.

Code Listing 2.3: Installing yaboot from GRP

# emerge --usepkg yaboot

Now exit the chroot and run yabootconfig --chroot /mnt/gentoo. First, the program will confirm the location of the bootstrap partition. If you are using the suggested disk partitioning scheme, your bootstrap partition should be /dev/sda2. Type Y if the output is correct. If not, double check your /etc/fstab. yabootconfig will then scan your system setup, create /etc/yaboot.conf and run mkofboot for you. mkofboot is used to format the Apple_Bootstrap partition, and install the yaboot configuration file into it. After this enter the chroot again.

Code Listing 2.4: Re-enter the chroot

# chroot /mnt/gentoo /bin/bash
# /usr/sbin/env-update && source /etc/profile

You should verify the contents of /etc/yaboot.conf. If you make changes to /etc/yaboot.conf (like setting the default/boot OS), make sure to rerun ybin -v to apply changes to the Apple_Bootstrap partition. Whenever you make a change to yaboot.conf, like when testing a new kernel, always remember to run ybin -v to update the bootstrap partition.

Now continue with Rebooting the System.

Alternative: Manual yaboot Configuration

First, install yaboot on your system:

Code Listing 2.5: Installing yaboot from GRP

# emerge --usepkg yaboot

An example yaboot.conf file is given below, but you will need to alter it to fit your needs.

Code Listing 2.6: /etc/yaboot.conf

## /etc/yaboot.conf
## run: "man yaboot.conf" for details. Do not make changes until you have!!
## see also: /usr/share/doc/yaboot/examples for example configurations.
## For a dual-boot menu, add one or more of:
## bsd=/dev/sdaX, macos=/dev/sdaY, macosx=/dev/sdaZ

## The bootstrap partition:


## ofboot is the Open Firmware way to specify the bootstrap partition.
## If this isn't defined, yaboot fails on the G5 and some G4s (unless 
## you pass the necessary arguments to the mkofboot/ybin program).
## hd:X means /dev/sdaX.
## G5 users should uncomment this line!!


## Users booting from firewire should use something like this line:
# ofboot=fw/node/sbp-2/disk@0:

## Users booting from USB should use something like this line:
# ofboot=usb/disk@0:

## hd: is shorthand for the first hard drive Open Firmware sees

## Firewire and USB users will need to specify the whole OF device name
## This can be found using ofpath, which is included with yaboot.

# device=fw/node@0001d200e00d0207/sbp-2@c000/disk@0:


## This section can be duplicated if you have more than one
## kernel or set of boot options - replace the image variable
## with the exact filename of your kernel.
#  append="rootdelay=10"  # Required for booting USB/Firewire

## G5 users and some G4 users should set 
##   macos=hd:13
##   macosx=hd:12
## instead of the example values.

Once yaboot.conf is configured, run mkofboot -v to format the Apple_bootstrap partition and install the settings. If you change yaboot.conf after the Apple_bootstrap partition has been created, you can update the settings by running ybin -v

Code Listing 2.7: Setting up the bootstrap partition

# mkofboot -v

For more information on yaboot, take a look at the yaboot project. For now, continue the installation with Rebooting the System.

10.c. Alternative: BootX

Important: BootX can only be used on OldWorld Apple systems with MacOS 9 or earlier!

Since BootX boots Linux from within MacOS, the kernel will need to be copied from the Linux Partition to the MacOS partition. First, mount the MacOS partition from outside of the chroot. Use mac-fdisk -l to find the MacOS partition number, sda6 is used as an example here. Once the partition is mounted, we'll copy the kernel to the system folder so BootX can find it.

Code Listing 3.1: Copying the kernel to the MacOS partition

# exit
cdimage ~# mkdir /mnt/mac
cdimage ~# mount /dev/sda6 /mnt/mac -t hfs
cdimage ~# cp /mnt/gentoo/usr/src/linux/vmlinux "/mnt/mac/System Folder/Linux Kernels/kernel-2.6.24-gentoo-r5"

If genkernel is used, both the kernel and initrd will need to be copied to the MacOS partition.

Code Listing 3.2: Copying the Genkernel kernel and initrd to the MacOS partition

# exit
cdimage ~# mkdir /mnt/mac
cdimage ~# mount /dev/sda6 /mnt/mac -t hfs
cdimage ~# cp /mnt/gentoo/boot/kernel-genkernel-ppc-2.6.24-gentoo-r5 "/mnt/mac/System Folder/Linux Kernels"
cdimage ~# cp /mnt/gentoo/boot/initramfs-genkernel-ppc-2.6.24-gentoo-r5 "/mnt/mac/System Folder"

Now that the kernel is copied over, we'll need to reboot to set up BootX.

Code Listing 3.3: Unmounting all partitions and rebooting

cdimage ~# cd /
cdimage ~# umount /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo/sys /mnt/gentoo /mnt/mac
cdimage ~# reboot

Of course, don't forget to remove the bootable CD, otherwise the CD will be booted again instead of MacOS.

Once the machine has booted into MacOS, open the BootX control panel. If you're not using genkernel, select Options and uncheck Use specified RAM disk. If you are using genkernel, ensure that the genkernel initrd is selected instead of the Installation CD initrd. If not using genkernel, there is now an option to specify the machine's Linux root disk and partition. Fill these in with the appropriate values. Depending upon the kernel configuration, additional boot arguments may need to be applied.

BootX can be configured to start Linux upon boot. If you do this, you will first see your machine boot into MacOS then, during startup, BootX will load and start Linux. See the BootX home page for more information.

Important: Make sure that you have support for HFS and HFS+ filesystems in your kernel, otherwise you will not be able to upgrade or change the kernel on your MacOS partition.

Now reboot again and boot into Linux, then continue with Finalizing your Gentoo Installation.

10.d. Alternative: quik

quik allows OldWorld Macs to boot without MacOS. However, it isn't well supported and has a number of quirks. If you have the option, it is recommended that you use BootX instead since it is much more reliable and easier to set up than quik.

First, we'll need to install quik:

Code Listing 4.1: Emerge quik from GRP

# emerge --usepkg quik

Next, we'll need to set it up. Edit /etc/quik.conf and set your image to the kernel that we copied to your boot partition.

Code Listing 4.2: Configuring quik.conf

# Example of quik.conf
init-message = "Gentoo 2008.0\n"
# This is the boot partition
partition = 2
root = /dev/sda4
timeout = 30
default = gentoo
# This is your kernel
image = /kernel-2.6.24-gentoo-r5
  label = gentoo

Your quik.conf file must be on the same disk as the quik boot images, however it can be on a different partition on the same disk, although it is recommended to move it to your boot partition.

Code Listing 4.3: Moving quik.conf to /boot

# mv /etc/quik.conf /boot/quik.conf

We will now set your boot variables so that quik loads on boot. To do this, we'll use a program called nvsetenv. The variables that you want to set vary from machine to machine, it's best to find your machine's quirks before attempting this.

Code Listing 4.4: Setting the boot variables

# nvsetenv auto-boot true # Set to false if you want to boot into OF, not all models can display the OF output
# nvsetenv output-device video # Check the quirks page, there are many variations here
# nvsetenv input-device kbd
# nvsetenv boot-device scsi/sd@1:0 # For SCSI
# nvsetenv boot-device ata/ata-disk@0:0 # For ATA
# nvsetenv boot-file /boot/kernel-2.6.24-gentoo-r5 root=/dev/sda4 First item is the path to the kernel, the second is the root partition.  You may append any kernel options to the end of this line.
# nvsetenv boot-command boot # Set this to bye for MacOS and boot for Linux

Note: It is also possible to change your boot variables from MacOS. Depending upon the model, either bootvars or Apple System Disk should be used. Please see the quik quirks page above for more information.

Now that we've set up our machine to boot, we'll need to make sure the boot images are installed correctly. Run quik -v -C /boot/quik.conf. It should tell you that it has installed the first stage QUIK boot block.

Note: If something has gone wrong, you can always reset your PRAM back to the default values by holding down command + option + p + r before powering on your machine. This will clear the values you set with nvsetenv and should allow you to boot either a MacOS bootdisk or a Linux bootdisk.

Now, continue the installation with Rebooting the System.

10.e. Alternative: BootCreator

Important: BootCreator will build a nice SmartFirmware bootmenu written in Forth for the Pegasos.

First make sure you have bootcreator installed on your system:

Code Listing 5.1: Installing bootcreator from GRP

# emerge --usepkg bootcreator

Now copy the file /etc/bootmenu.example into /etc/bootmenu and edit it to suit your needs:

Code Listing 5.2: Edit the bootcreator config file

# cp /etc/bootmenu.example /etc/bootmenu
# nano -w /etc/bootmenu

Below is a complete /etc/bootmenu config file. vmlinux and initrd should be replaced by your kernel and initrd image names.

Code Listing 5.3: bootcreator config file

# Example description file for bootcreator 1.1


Boot Menu

AbortOnKey = false
Timeout    = 9
Default    = 1

Local HD -> Morphos      (Normal)
ide:0 boot2.img ramdebug edebugflags="logkprintf"

Local HD -> Linux (Normal)
ide:0 kernel-2.6.24-gentoo-r5 video=radeonfb:1024x768@70 root=/dev/sda3

Local HD -> Genkernel (Normal)
ide:0 kernel-genkernel-ppc-2.6.24-gentoo-r5 root=/dev/ram0 real_root=/dev/sda3 init=/linuxrc initrd=initramfs-genkernel-ppc-2.6.24-gentoo-r5

Finally the bootmenu must be transferred into Forth and copied to your boot partition, so that the SmartFirmware can read it. Therefore you have to call bootcreator:

Code Listing 5.4: Install the bootmenu

# bootcreator /etc/bootmenu /boot/menu

Note: Be sure to have a look into the SmartFirmware's settings when you reboot, that menu is the file that will be loaded by default.

For now, continue the installation with Rebooting the System.

10.f. Rebooting the System

Exit the chrooted environment and unmount all mounted partitions. Then type in that one magical command you have been waiting for: reboot.

Code Listing 6.1: Exiting the chroot, unmounting all partitions and rebooting

# exit
livecd ~# umount /mnt/gentoo/proc /mnt/gentoo/dev /mnt/gentoo/sys /mnt/gentoo
livecd ~# reboot

Once rebooted in your Gentoo installation, finish up with Finalizing your Gentoo Installation.

11. Finalizing your Gentoo Installation

11.a. User Administration

Adding a User for Daily Use

Working as root on a Unix/Linux system is dangerous and should be avoided as much as possible. Therefore it is strongly recommended to add a user for day-to-day use.

The groups the user is member of define what activities the user can perform. The following table lists a number of important groups you might wish to use:

Group Description
audio be able to access the audio devices
cdrom be able to directly access optical devices
floppy be able to directly access floppy devices
games be able to play games
portage be able to use emerge --pretend as a normal user
usb be able to access USB devices
plugdev be able to mount and use pluggable devices such as cameras and USB sticks
video be able to access video capturing hardware and doing hardware acceleration
wheel be able to use su

For instance, to create a user called john who is member of the wheel, users and audio groups, log in as root first (only root can create users) and run useradd:

Code Listing 1.1: Adding a user for day-to-day use

Login: root
Password: (Your root password)

# useradd -m -G users,wheel,audio -s /bin/bash john
# passwd john
Password: (Enter the password for john)
Re-enter password: (Re-enter the password to verify)

If a user ever needs to perform some task as root, they can use su - to temporarily receive root privileges. Another way is to use the sudo package which is, if correctly configured, very secure.

11.b. Optional: Install GRP Packages

Important: This part is for GRP users only. Other users should skip this part and continue with Where to go from here?.

Now that your system is booted, log on as the user you created (for instance, john) and use su - to gain root privileges:

Code Listing 2.1: Gaining root privileges

$ su -
Password: (Enter your root password)

Now we need to change the Portage configuration to look for the prebuilt binaries from the second CD (Gentoo Packages CD). First mount this CD:

Code Listing 2.2: Mount the Packages CD

(Put the Gentoo Packages CD in the CD tray)
# mount /mnt/cdrom

Now configure Portage to use /mnt/cdrom for its prebuilt packages:

Code Listing 2.3: Configuring Portage to use /mnt/cdrom

# ls /mnt/cdrom

(If there is a /mnt/cdrom/packages directory:)
# export PKGDIR="/mnt/cdrom/packages"

# export PKGDIR="/mnt/cdrom"

Now install the packages you want. The Packages CD contains several prebuilt binaries, for instance KDE and GNOME.

Code Listing 2.4: Installing GNOME

# emerge --usepkg gnome

To find out what prebuilt packages are available, do a quick listing of all the files in /mnt/cdrom/All. For instance, to find out if KDE is emergeable:

Code Listing 2.5: Finding out if KDE is installable

# ls /mnt/cdrom/All/kde*

Be sure to install the binaries now. When you do an emerge --sync to update Portage (as you will learn later), the prebuilt binaries might not match against the ebuilds in your updated Portage. You can try to circumvent this by using emerge --usepkgonly instead of emerge --usepkg.

Congratulations, your system is now fully equipped! Continue with Where to go from here? to learn more about Gentoo.

12. Where to go from here?

12.a. Documentation

Congratulations! You now have a working Gentoo system. But where to go from here? What are your options now? What to explore first? Gentoo provides its users with lots of possibilities, and therefore lots of documented (and less documented) features.

You should definitely take a look at the next part of the Gentoo Handbook entitled Working with Gentoo which explains how to keep your software up to date, how to install more software, what USE flags are, how the Gentoo Init system works, etc.

If you are interested in optimizing your system for desktop use, or you want to learn how to configure your system to be a full working desktop system, consult our extensive Gentoo Desktop Documentation Resources. Besides, you might want to use our localization guide to make your system feel more at home.

We also have a Gentoo Security Handbook which is worth reading.

For a full listing of all our available documentation check out our Documentation Resources page.

12.b. Gentoo Online

You are of course always welcome on our Gentoo Forums or on one of our many Gentoo IRC channels.

We also have several mailinglists open to all our users. Information on how to join is contained in that page.

We'll shut up now and let you enjoy your installation :)

12.c. Gentoo Changes since 2008.0


Gentoo is a fast-moving target. The following sections describe important changes that affect a Gentoo installation. We only list those that have anything in common with the installation, not with package changes that did not occur during the installation.

There have been no significant changes since.

B. Working with Gentoo

1. A Portage Introduction

1.a. Welcome to Portage

Portage is probably Gentoo's most notable innovation in software management. With its high flexibility and enormous amount of features it is frequently seen as the best software management tool available for Linux.

Portage is completely written in Python and Bash and therefore fully visible to the users as both are scripting languages.

Most users will work with Portage through the emerge tool. This chapter is not meant to duplicate the information available from the emerge man page. For a complete rundown of emerge's options, please consult the man page:

Code Listing 1.1: Reading the emerge man page

$ man emerge

1.b. The Portage Tree


When we talk about packages, we often mean software titles that are available to the Gentoo users through the Portage tree. The Portage tree is a collection of ebuilds, files that contain all information Portage needs to maintain software (install, search, query, ...). These ebuilds reside in /usr/portage by default.

Whenever you ask Portage to perform some action regarding software titles, it will use the ebuilds on your system as a base. It is therefore important that you regularly update the ebuilds on your system so Portage knows about new software, security updates, etc.

Updating the Portage Tree

The Portage tree is usually updated with rsync, a fast incremental file transfer utility. Updating is fairly simple as the emerge command provides a front-end for rsync:

Code Listing 2.1: Updating the Portage tree

# emerge --sync

If you are unable to rsync due to firewall restrictions you can still update your Portage tree by using our daily generated Portage tree snapshots. The emerge-webrsync tool automatically fetches and installs the latest snapshot on your system:

Code Listing 2.2: Running emerge-webrsync

# emerge-webrsync

An additional advantage of using emerge-webrsync is that it allows the administrator to only pull in portage tree snapshots that are signed by the Gentoo release engineering GPG key. More information on this can be found in the Portage Features section on Fetching Validated Portage Tree Snapshots.

1.c. Maintaining Software

Searching for Software

To search through the Portage tree after software titles, you can use emerge built-in search capabilities. By default, emerge --search returns the names of packages whose title matches (either fully or partially) the given search term.

For instance, to search for all packages who have "pdf" in their name:

Code Listing 3.1: Searching for pdf-named packages

$ emerge --search pdf

If you want to search through the descriptions as well you can use the --searchdesc (or -S) switch:

Code Listing 3.2: Searching for pdf-related packages

$ emerge --searchdesc pdf

When you take a look at the output, you'll notice that it gives you a lot of information. The fields are clearly labelled so we won't go further into their meanings:

Code Listing 3.3: Example 'emerge --search' output

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Installing Software

Once you've found a software title to your liking, you can easily install it with emerge: just add the package name. For instance, to install gnumeric:

Code Listing 3.4: Installing gnumeric

# emerge gnumeric

Since many applications depend on each other, any attempt to install a certain software package might result in the installation of several dependencies as well. Don't worry, Portage handles dependencies well. If you want to find out what Portage would install when you ask it to install a certain package, add the --pretend switch. For instance:

Code Listing 3.5: Pretend to install gnumeric

# emerge --pretend gnumeric

When you ask Portage to install a package, it will download the necessary source code from the internet (if necessary) and store it by default in /usr/portage/distfiles. After this it will unpack, compile and install the package. If you want Portage to only download the sources without installing them, add the --fetchonly option to the emerge command:

Code Listing 3.6: Download the sourcecode for gnumeric

# emerge --fetchonly gnumeric

Finding Installed Package Documentation

Many packages come with their own documentation. Sometimes, the doc USE flag determines whether the package documentation should be installed or not. You can check the existence of a doc USE flag with the emerge -vp <package name> command.

Code Listing 3.7: Checking the existence of a doc USE flag

(alsa-lib is just an example, of course.)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.14_rc1  -debug +doc 698 kB

The best way of enabling the doc USE flag is doing it on a per-package basis via /etc/portage/package.use, so that you get documentation only for packages that you are interested in. Enabling this flag globally is known to cause problems with circular dependencies. For more information, please read the USE Flags chapter.

Once the package installed, its documentation is generally found in a subdirectory named after the package under the /usr/share/doc directory. You can also list all installed files with the equery tool which is part of the app-portage/gentoolkit package.

Code Listing 3.8: Locating package documentation

# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1
total 28
-rw-r--r--  1 root root  669 May 17 21:54 ChangeLog.gz
-rw-r--r--  1 root root 9373 May 17 21:54 COPYING.gz
drwxr-xr-x  2 root root 8560 May 17 21:54 html
-rw-r--r--  1 root root  196 May 17 21:54 TODO.gz

(Alternatively, use equery to locate interesting files:)
# equery files alsa-lib | less
* Contents of media-libs/alsa-lib-1.0.14_rc1:
(Output truncated)

Removing Software

When you want to remove a software package from your system, use emerge --unmerge. This will tell Portage to remove all files installed by that package from your system except the configuration files of that application if you have altered those after the installation. Leaving the configuration files allows you to continue working with the package if you ever decide to install it again.

However, a big warning applies: Portage will not check if the package you want to remove is required by another package. It will however warn you when you want to remove an important package that breaks your system if you unmerge it.

Code Listing 3.9: Removing gnumeric from the system

# emerge --unmerge gnumeric

When you remove a package from your system, the dependencies of that package that were installed automatically when you installed the software are left. To have Portage locate all dependencies that can now be removed, use emerge's --depclean functionality. We will talk about this later on.

Updating your System

To keep your system in perfect shape (and not to mention install the latest security updates) you need to update your system regularly. Since Portage only checks the ebuilds in your Portage tree you first have to update your Portage tree. When your Portage tree is updated, you can update your system with emerge --update @world. In the next example, we'll also use the --ask switch which will tell Portage to display the list of packages it wants to upgrade and ask you if you want to continue:

Code Listing 3.10: Updating your system

# emerge --update --ask @world

Portage will then search for newer version of the applications you have installed. However, it will only verify the versions for the applications you have explicitly installed (the applications listed in /var/lib/portage/world) - it does not thoroughly check their dependencies. If you want to update the dependencies of those packages as well, add the --deep argument:

Code Listing 3.11: Updating your system with dependencies

# emerge --update --deep @world

Still, this doesn't mean all packages: some packages on your system are needed during the compile and build process of packages, but once that package is installed, these dependencies are no longer required. Portage calls those build dependencies. To include those in an update cycle, add --with-bdeps=y:

Code Listing 3.12: Updating your entire system

# emerge --update --deep --with-bdeps=y @world

Since security updates also happen in packages you have not explicitly installed on your system (but that are pulled in as dependencies of other programs), it is recommended to run this command once in a while.

If you have altered any of your USE flags lately you might want to add --newuse as well. Portage will then verify if the change requires the installation of new packages or recompilation of existing ones:

Code Listing 3.13: Performing a full update

# emerge --update --deep --with-bdeps=y --newuse @world


Some packages in the Portage tree don't have any real content but are used to install a collection of packages. For instance, the kde-meta package will install a complete KDE environment on your system by pulling in various KDE-related packages as dependencies.

If you ever want to remove such a package from your system, running emerge --unmerge on the package won't have much effect as the dependencies remain on the system.

Portage has the functionality to remove orphaned dependencies as well, but since the availability of software is dynamically dependent you first need to update your entire system fully, including the new changes you applied when changing USE flags. After this you can run emerge --depclean to remove the orphaned dependencies. When this is done, you need to rebuild the applications that were dynamically linked to the now-removed software titles but don't require them anymore.

All this is handled with the following three commands:

Code Listing 3.14: Removing orphaned dependencies

# emerge --update --deep --newuse @world
# emerge --depclean
# revdep-rebuild

revdep-rebuild is provided by the gentoolkit package; don't forget to emerge it first:

Code Listing 3.15: Installing the gentoolkit package

# emerge gentoolkit

1.d. Licenses

Beginning with Portage version 2.1.7, you can accept or reject software installation based on its license. All packages in the tree contain a LICENSE entry in their ebuilds. Running emerge --search packagename will tell you the package's license.

By default, Portage permits all licenses, except End User License Agreements (EULAs) that require reading and signing an acceptance agreement.

The variable that controls permitted licenses is ACCEPT_LICENSE, which can be set in /etc/portage/make.conf. In the next example, this default value is shown:

Code Listing 4.1: Setting ACCEPT_LICENSE in /etc/portage/make.conf


With this configuration, packages that require interaction during installation to approve their EULA will not be installable. Packages without an EULA will be installable.

You can set ACCEPT_LICENSE globally in /etc/portage/make.conf , or you can specify it on a per-package basis in /etc/portage/package.license.

For example, if you want to allow the truecrypt-2.7 license for app-crypt/truecrypt, add the following to /etc/portage/package.license:

Code Listing 4.2: Specifying a truecrypt license in package.license

app-crypt/truecrypt truecrypt-2.7

This permits installation of truecrypt versions that have the truecrypt-2.7 license, but not versions with the truecrypt-2.8 license.

Important: Licenses are stored in /usr/portage/licenses, and license groups are kept in /usr/portage/profiles/license_groups. The first entry of each line in CAPITAL letters is the name of the license group, and every entry after that is an individual license.

License groups defined in ACCEPT_LICENSE are prefixed with an @ sign. A commonly requested setting is to only allow the installation of free software and documentation. To accomplish this, we can remove all currently accepted licenses (using -*) and then only allow the licenses in the FREE group as follows:

Code Listing 4.3: Only allowing free software and documentation licenses in /etc/portage/make.conf


In this case, "free" is mostly defined by the FSF and OSI. Any package whose license does not meet these requirements will not be installable on your system.

1.e. When Portage is Complaining...

About SLOTs, Virtuals, Branches, Architectures and Profiles

As we stated before, Portage is extremely powerful and supports many features that other software management tools lack. To understand this, we explain a few aspects of Portage without going into too much detail.

With Portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like freetype and freetype2) Portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the freetype package has ebuilds with SLOT="1" and SLOT="2".

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger is listed as an "exclusive" dependency of the logging service in the logger virtual package of the virtual category, so that applications can depend on the virtual/logger package. When installed, the package will pull in the first logging package mentioned in the package, unless a logging package was already installed (in which case the virtual is satisfied).

Software in the Portage tree can reside in different branches. By default your system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although you will see the ebuilds for those software in the Portage tree, Portage will not update them before they are placed in the stable branch.

Some software is only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the Portage tree is unable to verify if the package works on different architectures.

Each Gentoo installation adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

Blocked Packages

Code Listing 5.1: Portage warning about blocked packages (with --pretend)

[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)

Code Listing 5.2: Portage warning about blocked packages (without --pretend)

!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers. 

Ebuilds contain specific fields that inform Portage about its dependencies. There are two possible dependencies: build dependencies, declared in DEPEND and run-time dependencies, declared in RDEPEND. When one of these dependencies explicitly marks a package or virtual as being not compatible, it triggers a blockage.

While recent versions of Portage are smart enough to work around minor blockages without user intervention, occasionally you will need to fix it yourself, as explained below.

To fix a blockage, you can choose to not install the package or unmerge the conflicting package first. In the given example, you can opt not to install postfix or to remove ssmtp first.

You may also see blocking packages with specific atoms, such as <media-video/mplayer-1.0_rc1-r2. In this case, updating to a more recent version of the blocking package would remove the block.

It is also possible that two packages that are yet to be installed are blocking each other. In this rare case, you should find out why you need to install both. In most cases you can do with one of the packages alone. If not, please file a bug on Gentoo's bugtracking system.

Masked Packages

Code Listing 5.3: Portage warning about masked packages

!!! all ebuilds that could satisfy "bootsplash" have been masked. 

Code Listing 5.4: Portage warning about masked packages - reason

!!! possible candidates are:

- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc- (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype- (masked by: skype-eula license(s))

When you want to install a package that isn't available for your system, you will receive this masking error. You should try installing a different application that is available for your system or wait until the package is put available. There is always a reason why a package is masked:

  • ~arch keyword means that the application is not tested sufficiently to be put in the stable branch. Wait a few days or weeks and try again.
  • -arch keyword or -* keyword means that the application does not work on your architecture. If you believe the package does work file a bug at our bugzilla website.
  • missing keyword means that the application has not been tested on your architecture yet. Ask the architecture porting team to test the package or test it for them and report your findings on our bugzilla website.
  • package.mask means that the package has been found corrupt, unstable or worse and has been deliberately marked as do-not-use.
  • profile means that the package has been found not suitable for your profile. The application might break your system if you installed it or is just not compatible with the profile you use.
  • license means that the package's license is not compatible with your ACCEPT_LICENSE setting. You must explicitly permit its license or license group by setting it in /etc/portage/make.conf or in /etc/portage/package.license. Refer to Licenses to learn how licenses work.

Necessary USE Flag Changes

Code Listing 5.5: Portage warning about USE flag change requirement

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

The error message might also be displayed as follows, if --autounmask isn't set:

Code Listing 5.6: Portage error about USE flag change requirement

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Such warning or error occurs when you want to install a package which not only depends on another package, but also requires that that package is built with a particular USE flag (or set of USE flags). In the given example, the package app-text/feelings needs to be built with USE="test", but this USE flag is not set on the system.

To resolve this, either add the requested USE flag to your global USE flags in /etc/portage/make.conf, or set it for the specific package in /etc/portage/package.use.

Missing Dependencies

Code Listing 5.7: Portage warning about missing dependency

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem. 

The application you are trying to install depends on another package that is not available for your system. Please check bugzilla if the issue is known and if not, please report it. Unless you are mixing branches this should not occur and is therefore a bug.

Ambiguous Ebuild Name

Code Listing 5.8: Portage warning about ambiguous ebuild names

[ Results for search key : listen ]
[ Applications found : 2 ]

*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Description:   Raw listen for TinyOS
      License:       BSD

*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Description:   A Music player and management for GNOME
      License:       GPL-2

!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

The application you want to install has a name that corresponds with more than one package. You need to supply the category name as well. Portage will inform you of possible matches to choose from.

Circular Dependencies

Code Listing 5.9: Portage warning about circular dependencies

!!! Error: circular dependencies: 

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 

Two (or more) packages you want to install depend on each other and can therefore not be installed. This is most likely a bug in the Portage tree. Please resync after a while and try again. You can also check bugzilla if the issue is known and if not, report it.

Fetch failed

Code Listing 5.10: Portage warning about fetch failed

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
!!! Some fetch errors were encountered.  Please see above for details.

Portage was unable to download the sources for the given application and will try to continue installing the other applications (if applicable). This failure can be due to a mirror that has not synchronised correctly or because the ebuild points to an incorrect location. The server where the sources reside can also be down for some reason.

Retry after one hour to see if the issue still persists.

System Profile Protection

Code Listing 5.11: Portage warning about profile-protected package

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

You have asked to remove a package that is part of your system's core packages. It is listed in your profile as required and should therefore not be removed from the system.

Digest Verification Failures

Sometimes, when you attempt to emerge a package, it will fail with the message:

Code Listing 5.12: Digest verification failure

>>> checking ebuild checksums
!!! Digest verification failed:

This is a sign that something is wrong with the Portage tree -- often, it is because a developer may have made a mistake when committing a package to the tree.

When the digest verification fails, do not try to re-digest the package yourself. Running ebuild foo manifest will not fix the problem; it will almost certainly make it worse!

Instead, wait an hour or two for the tree to settle down. It's likely that the error was noticed right away, but it can take a little time for the fix to trickle down the Portage tree. While you're waiting, check Bugzilla and see if anyone has reported the problem yet. If not, go ahead and file a bug for the broken package.

Once you see that the bug has been fixed, you may want to re-sync to pick up the fixed digest.

Important: This does not mean that you can re-sync your tree multiple times! As stated in the rsync policy (when you run emerge --sync), users who sync too often will be banned! In fact, it's better to just wait until your next scheduled sync, so that you don't overload the rsync servers.

2. USE flags

2.a. What are USE flags?

The ideas behind USE flags

When you are installing Gentoo (or any other distribution, or even operating system for that matter) you make choices depending on the environment you are working with. A setup for a server differs from a setup for a workstation. A gaming workstation differs from a 3D rendering workstation.

This is not only true for choosing what packages you want to install, but also what features a certain package should support. If you don't need OpenGL, why would you bother installing OpenGL and build OpenGL support in most of your packages? If you don't want to use KDE, why would you bother compiling packages with KDE support if those packages work flawlessly without?

To help users in deciding what to install/activate and what not, we wanted the user to specify his/her environment in an easy way. This forces the user into deciding what they really want and eases the process for Portage, our package management system, to make useful decisions.

Definition of a USE flag

Enter the USE flags. Such a flag is a keyword that embodies support and dependency-information for a certain concept. If you define a certain USE flag, Portage will know that you want support for the chosen keyword. Of course this also alters the dependency information for a package.

Let us take a look at a specific example: the kde keyword. If you do not have this keyword in your USE variable, all packages that have optional KDE support will be compiled without KDE support. All packages that have an optional KDE dependency will be installed without installing the KDE libraries (as dependency). If you have defined the kde keyword, then those packages will be compiled with KDE support, and the KDE libraries will be installed as dependency.

By correctly defining the keywords you will receive a system tailored specifically to your needs.

What USE flags exist?

There are two types of USE flags: global and local USE flags.

  • A global USE flag is used by several packages, system-wide. This is what most people see as USE flags.
  • A local USE flag is used by a single package to make package-specific decisions.

A list of available global USE flags can be found online or locally in /usr/portage/profiles/use.desc.

A list of available local USE flags can be found online or locally in /usr/portage/profiles/use.local.desc.

2.b. Using USE flags

Declare permanent USE flags

In the hope you are convinced of the importance of USE flags we will now inform you how to declare USE flags.

As previously mentioned, all USE flags are declared inside the USE variable. To make it easy for users to search and pick USE flags, we already provide a default USE setting. This setting is a collection of USE flags we think are commonly used by the Gentoo users. This default setting is declared in the make.defaults files part of your profile.

The profile your system listens to is pointed to by the /etc/portage/make.profile symlink. Each profile works on top of another, larger profile, the end result is therefore the sum of all profiles. The top profile is the base profile (/usr/portage/profiles/base).

Let us take a look at this default setting for the 13.0 profile:

Code Listing 2.1: Cumulative make.defaults USE variable for the 13.0 profile

(This example is the sum of the settings in base, default/linux,
 default/linux/x86 and default/linux/x86/13.0/)
USE="a52 aac acpi alsa branding cairo cdr dbus dts dvd dvdr emboss encode exif
fam firefox flac gif gpm gtk hal jpeg lcms ldap libnotify mad mikmod mng mp3
mp4 mpeg ogg opengl pango pdf png ppds qt3support qt4 sdl spell
startup-notification svg tiff truetype vorbis unicode usb X xcb x264 xml xv

As you can see, this variable already contains quite a lot of keywords. Do not alter any make.defaults file to tailor the USE variable to your needs: changes in this file will be undone when you update Portage!

To change this default setting, you need to add or remove keywords to the USE variable. This is done globally by defining the USE variable in /etc/portage/make.conf. In this variable you add the extra USE flags you require, or remove the USE flags you don't want. This latter is done by prefixing the keyword with the minus-sign ("-").

For instance, to remove support for KDE and QT but add support for ldap, the following USE can be defined in /etc/portage/make.conf:

Code Listing 2.2: An example USE setting in /etc/portage/make.conf

USE="-kde -qt4 ldap"

Declaring USE flags for individual packages

Sometimes you want to declare a certain USE flag for one (or a couple) of applications but not system-wide. To accomplish this, you will need to create the /etc/portage directory (if it doesn't exist yet) and edit /etc/portage/package.use. This is usually a single file, but can also be a directory; see man portage for more information. The following examples assume package.use is a single file.

For instance, if you don't want berkdb support globally but you do want it for mysql, you would add:

Code Listing 2.3: /etc/portage/package.use example

dev-db/mysql berkdb

You can of course also explicitly disable USE flags for a certain application. For instance, if you don't want java support in PHP:

Code Listing 2.4: /etc/portage/package.use 2nd example

dev-php/php -java

Declare temporary USE flags

Sometimes you want to set a certain USE setting only once. Instead of editing /etc/portage/make.conf twice (to do and undo the USE changes) you can just declare the USE variable as environment variable. Remember that, when you re-emerge or update this application (either explicitly or as part of a system update) your changes will be lost!

As an example we will temporarily remove java from the USE setting during the installation of seamonkey.

Code Listing 2.5: Using USE as environment variable

# USE="-java" emerge seamonkey


Of course there is a certain precedence on what setting has priority over the USE setting. You don't want to declare USE="-java" only to see that java is still used due to a setting that has a higher priority. The precedence for the USE setting is, ordered by priority (first has lowest priority):

  1. Default USE setting declared in the make.defaults files part of your profile
  2. User-defined USE setting in /etc/portage/make.conf
  3. User-defined USE setting in /etc/portage/package.use
  4. User-defined USE setting as environment variable

To view the final USE setting as seen by Portage, run emerge --info. This will list all relevant variables (including the USE variable) with the content used by Portage.

Code Listing 2.6: Running emerge --info

# emerge --info

Adapting your Entire System to New USE Flags

If you have altered your USE flags and you wish to update your entire system to use the new USE flags, use emerge's --newuse option:

Code Listing 2.7: Rebuilding your entire system

# emerge --update --deep --newuse @world

Next, run Portage's depclean to remove the conditional dependencies that were emerged on your "old" system but that have been obsoleted by the new USE flags.

Warning: Running emerge --depclean is a dangerous operation and should be handled with care. Double-check the provided list of "obsoleted" packages to make sure it doesn't remove packages you need. In the following example we add the -p switch to have depclean only list the packages without removing them.

Code Listing 2.8: Removing obsoleted packages

# emerge -p --depclean

When depclean has finished, run revdep-rebuild to rebuild the applications that are dynamically linked against shared objects provided by possibly removed packages. revdep-rebuild is part of the gentoolkit package; don't forget to emerge it first.

Code Listing 2.9: Running revdep-rebuild

# revdep-rebuild

When all this is accomplished, your system is using the new USE flag settings.

2.c. Package specific USE flags

Viewing available USE flags

Let us take the example of seamonkey: what USE flags does it listen to? To find out, we use emerge with the --pretend and --verbose options:

Code Listing 3.1: Viewing the used USE flags

# emerge --pretend --verbose seamonkey
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] www-client/seamonkey-1.0.7  USE="crypt gnome java -debug -ipv6
-ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznopango
-moznoroaming -postgres -xinerama -xprint" 0 kB

emerge isn't the only tool for this job. In fact, we have a tool dedicated to package information called equery which resides in the gentoolkit package. First, install gentoolkit:

Code Listing 3.2: Installing gentoolkit

# emerge gentoolkit

Now run equery with the uses argument to view the USE flags of a certain package. For instance, for the gnumeric package:

Code Listing 3.3: Using equery to view used USE flags

# equery --nocolor uses =gnumeric-1.6.3 -a
[ Searching for packages matching =gnumeric-1.6.3... ]
[ Colour Code : set unset ]
[ Legend : Left column  (U) - USE flags from make.conf              ]
[        : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for app-office/gnumeric-1.6.3 ]
 U I
 - - debug  : Enable extra debug codepaths, like asserts and extra output.
              If you want to get meaningful backtraces see
 + + gnome  : Adds GNOME support
 + + python : Adds support/bindings for the Python language
 - - static : !!do not set this during bootstrap!! Causes binaries to be
              statically linked instead of dynamically

3. Portage Features

3.a. Portage Features

Portage has several additional features that makes your Gentoo experience even better. Many of these features rely on certain software tools that improve performance, reliability, security, ...

To enable or disable certain Portage features you need to edit /etc/portage/make.conf's FEATURES variable which contains the various feature keywords, separated by white space. In several cases you will also need to install the additional tool on which the feature relies.

Not all features that Portage supports are listed here. For a full overview, please consult the make.conf man page:

Code Listing 1.1: Consulting the make.conf man page

$ man make.conf

To find out what FEATURES are default set, run emerge --info and search for the FEATURES variable or grep it out:

Code Listing 1.2: Finding out the FEATURES that are already set

$ emerge --info | grep ^FEATURES=

3.b. Distributed Compiling

Using distcc

distcc is a program to distribute compilations across several, not necessarily identical, machines on a network. The distcc client sends all necessary information to the available distcc servers (running distccd) so they can compile pieces of source code for the client. The net result is a faster compilation time.

You can find more information about distcc (and how to have it work with Gentoo) in our Gentoo Distcc Documentation.

Installing distcc

Distcc ships with a graphical monitor to monitor tasks that your computer is sending away for compilation. If you use Gnome then put 'gnome' in your USE variable. However, if you don't use Gnome and would still like to have the monitor then you should put 'gtk' in your USE variable.

Code Listing 2.1: Installing distcc

# emerge distcc

Activating Portage Support

Add distcc to the FEATURES variable inside /etc/portage/make.conf. Next, edit the MAKEOPTS variable to your liking. A known guideline is to fill in "-jX" with X the number of CPUs that run distccd (including the current host) plus one, but you might have better results with other numbers.

Now run distcc-config and enter the list of available distcc servers. For a simple example we assume that the available DistCC servers are (the current host), and (two "remote" hosts):

Code Listing 2.2: Configuring distcc to use three available distcc servers

# distcc-config --set-hosts ""

Don't forget to run the distccd daemon as well:

Code Listing 2.3: Starting the distccd daemons

# rc-update add distccd default
# /etc/init.d/distccd start

3.c. Caching Compilation

About ccache

ccache is a fast compiler cache. When you compile a program, it will cache intermediate results so that, whenever you recompile the same program, the compilation time is greatly reduced. The first time you run ccache, it will be much slower than a normal compilation. Subsequent recompiles should be faster. ccache is only helpful if you will be recompiling the same application many times; thus it's mostly only useful for software developers.

If you are interested in the ins and outs of ccache, please visit the ccache homepage.

Warning: ccache is known to cause numerous compilation failures. Sometimes ccache will retain stale code objects or corrupted files, which can lead to packages that cannot be emerged. If this happens (if you receive errors like "File not recognized: File truncated"), try recompiling the application with ccache disabled (FEATURES="-ccache" in /etc/portage/make.conf) before reporting a bug. Unless you are doing development work, do not enable ccache.

Installing ccache

To install ccache, run emerge ccache:

Code Listing 3.1: Installing ccache

# emerge ccache

Activating Portage Support

Open /etc/portage/make.conf and add ccache to the FEATURES variable. Next, add a new variable called CCACHE_SIZE and set it to "2G":

Code Listing 3.2: Editing CCACHE_SIZE in /etc/portage/make.conf


To check if ccache functions, ask ccache to provide you with its statistics. Because Portage uses a different ccache home directory, you need to set the CCACHE_DIR variable as well:

Code Listing 3.3: Viewing ccache statistics

# CCACHE_DIR="/var/tmp/ccache" ccache -s

The /var/tmp/ccache location is Portage' default ccache home directory; if you want to alter this setting you can set the CCACHE_DIR variable in /etc/portage/make.conf.

However, if you would run ccache, it would use the default location of ${HOME}/.ccache, which is why you needed to set the CCACHE_DIR variable when asking for the (Portage) ccache statistics.

Using ccache for non-Portage C Compiling

If you would like to use ccache for non-Portage compilations, add /usr/lib/ccache/bin to the beginning of your PATH variable (before /usr/bin). This can be accomplished by editing .bash_profile in your user's home directory. Using .bash_profile is one way to define PATH variables.

Code Listing 3.4: Editing .bash_profile


3.d. Binary Package Support

Creating Prebuilt Packages

Portage supports the installation of prebuilt packages. Even though Gentoo does not provide prebuilt packages by itself Portage can be made fully aware of prebuilt packages.

To create a prebuilt package you can use quickpkg if the package is already installed on your system, or emerge with the --buildpkg or --buildpkgonly options.

If you want Portage to create prebuilt packages of every single package you install, add buildpkg to the FEATURES variable.

More extended support for creating prebuilt package sets can be obtained with catalyst. For more information on catalyst please read the Catalyst Frequently Asked Questions.

Installing Prebuilt Packages

Although Gentoo doesn't provide one, you can create a central repository where you store prebuilt packages. If you want to use this repository, you need to make Portage aware of it by having the PORTAGE_BINHOST variable point to it. For instance, if the prebuilt packages are on ftp://buildhost/gentoo:

Code Listing 4.1: Setting PORTAGE_BINHOST in /etc/portage/make.conf


When you want to install a prebuilt package, add the --getbinpkg option to the emerge command alongside of the --usepkg option. The former tells emerge to download the prebuilt package from the previously defined server while the latter asks emerge to try to install the prebuilt package first before fetching the sources and compiling it.

For instance, to install gnumeric with prebuilt packages:

Code Listing 4.2: Installing the gnumeric prebuilt package

# emerge --usepkg --getbinpkg gnumeric

More information about emerge's prebuilt package options can be found in the emerge man page:

Code Listing 4.3: Reading the emerge man page

$ man emerge

3.e. Fetching Files

Parallel fetch

When you are emerging a series of packages, Portage can fetch the source files for the next package in the list even while it is compiling another package, thus shortening compile times. To make use of this capability, add "parallel-fetch" to your FEATURES. Note that this is on by default, so you shouldn't need to specifically enable it.


When Portage is run as root, FEATURES="userfetch" will allow Portage to drop root privileges while fetching package sources. This is a small security improvement.

3.f. Pulling Validated Portage Tree Snapshots

As an administrator, you can opt to only update your local Portage tree with a cryptographically validated Portage tree snapshot as released by the Gentoo infrastructure. This ensures that no rogue rsync mirror is adding unwanted code or packages in the tree you are downloading.

To configure Portage, first create a truststore in which you download and accept the keys of the Gentoo Infrastructure responsible for signing the Portage tree snapshots. Of course, if you want to, you can validate this GPG key as per the proper guidelines (like checking the key fingerprint). You can find the list of GPG keys used by the release engineering team on their project page.

Code Listing 6.1: Creating a truststore for Portage

# mkdir -p /etc/portage/gpg
# chmod 0700 /etc/portage/gpg
(... Substitute the keys with those mentioned on the release engineering site ...)
# gpg --homedir /etc/portage/gpg --keyserver --recv-keys 0xDB6B8C1F96D8BF6D
# gpg --homedir /etc/portage/gpg --edit-key 0xDB6B8C1F96D8BF6D trust

Next, edit /etc/portage/make.conf and enable support for validating the signed Portage tree snapshots (using FEATURES="webrsync-gpg") and disabling updating the Portage tree using the regular emerge --sync method.

Code Listing 6.2: Updating make.conf


Code Listing 6.3: Updating repos.conf

# Make sure sync-type and sync-uri are commented out
# sync-type = rsync
# sync-uri = ...

That's it. Next time you run emerge-webrsync, only the snapshots with a valid signature will be expanded on your file system.

4. Initscripts

4.a. Runlevels

Booting your System

When you boot your system, you will notice lots of text floating by. If you pay close attention, you will notice this text is the same every time you reboot your system. The sequence of all these actions is called the boot sequence and is (more or less) statically defined.

First, your boot loader will load the kernel image you have defined in the boot loader configuration into memory after which it tells the CPU to run the kernel. When the kernel is loaded and run, it initializes all kernel-specific structures and tasks and starts the init process.

This process then makes sure that all filesystems (defined in /etc/fstab) are mounted and ready to be used. Then it executes several scripts located in /etc/init.d, which will start the services you need in order to have a successfully booted system.

Finally, when all scripts are executed, init activates the terminals (in most cases just the virtual consoles which are hidden beneath Alt-F1, Alt-F2, etc.) attaching a special process called agetty to it. This process will then make sure you are able to log on through these terminals by running login.

Init Scripts

Now init doesn't just execute the scripts in /etc/init.d randomly. Even more, it doesn't run all scripts in /etc/init.d, only the scripts it is told to execute. It decides which scripts to execute by looking into /etc/runlevels.

First, init runs all scripts from /etc/init.d that have symbolic links inside /etc/runlevels/boot. Usually, it will start the scripts in alphabetical order, but some scripts have dependency information in them, telling the system that another script must be run before they can be started.

When all /etc/runlevels/boot referenced scripts are executed, init continues with running the scripts that have a symbolic link to them in /etc/runlevels/default. Again, it will use the alphabetical order to decide what script to run first, unless a script has dependency information in it, in which case the order is changed to provide a valid start-up sequence.

How Init Works

Of course init doesn't decide all that by itself. It needs a configuration file that specifies what actions need to be taken. This configuration file is /etc/inittab.

If you remember the boot sequence we have just described, you will remember that init's first action is to mount all filesystems. This is defined in the following line from /etc/inittab:

Code Listing 1.1: The system initialisation line in /etc/inittab

si::sysinit:/sbin/rc sysinit

This line tells init that it must run /sbin/rc sysinit to initialize the system. The /sbin/rc script takes care of the initialisation, so you might say that init doesn't do much -- it delegates the task of initialising the system to another process.

Second, init executed all scripts that had symbolic links in /etc/runlevels/boot. This is defined in the following line:

Code Listing 1.2: The system initialisation, continued

rc::bootwait:/sbin/rc boot

Again the rc script performs the necessary tasks. Note that the option given to rc (boot) is the same as the subdirectory of /etc/runlevels that is used.

Now init checks its configuration file to see what runlevel it should run. To decide this, it reads the following line from /etc/inittab:

Code Listing 1.3: The initdefault line


In this case (which the majority of Gentoo users will use), the runlevel id is 3. Using this information, init checks what it must run to start runlevel 3:

Code Listing 1.4: The runlevel definitions

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

The line that defines level 3, again, uses the rc script to start the services (now with argument default). Again note that the argument of rc is the same as the subdirectory from /etc/runlevels.

When rc has finished, init decides what virtual consoles it should activate and what commands need to be run at each console:

Code Listing 1.5: The virtual consoles definition

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

What is a runlevel?

You have seen that init uses a numbering scheme to decide what runlevel it should activate. A runlevel is a state in which your system is running and contains a collection of scripts (runlevel scripts or initscripts) that must be executed when you enter or leave a runlevel.

In Gentoo, there are seven runlevels defined: three internal runlevels, and four user-defined runlevels. The internal runlevels are called sysinit, shutdown and reboot and do exactly what their names imply: initialize the system, powering off the system and rebooting the system.

The user-defined runlevels are those with an accompanying /etc/runlevels subdirectory: boot, default, nonetwork and single. The boot runlevel starts all system-necessary services which all other runlevels use. The remaining three runlevels differ in what services they start: default is used for day-to-day operations, nonetwork is used in case no network connectivity is required, and single is used when you need to fix the system.

Working with the Init Scripts

The scripts that the rc process starts are called init scripts. Each script in /etc/init.d can be executed with the arguments start, stop, restart, zap, status, ineed, iuse, needsme, usesme or broken.

To start, stop or restart a service (and all depending services), start, stop and restart should be used:

Code Listing 1.6: Starting Postfix

# /etc/init.d/postfix start

Note: Only the services that need the given service are stopped or restarted. The other depending services (those that use the service but don't need it) are left untouched.

If you want to stop a service, but not the services that depend on it, you can use the --nodeps argument together with the stop command:

Code Listing 1.7: Stopping Postfix but keep the depending services running

# /etc/init.d/postfix --nodeps stop

If you want to see what status a service has (started, stopped, ...) you can use the status argument:

Code Listing 1.8: Status information for postfix

# /etc/init.d/postfix status

If the status information tells you that the service is running, but you know that it is not, then you can reset the status information to "stopped" with the zap argument:

Code Listing 1.9: Resetting status information for postfix

# /etc/init.d/postfix zap

To also ask what dependencies the service has, you can use iuse or ineed. With ineed you can see the services that are really necessary for the correct functioning of the service. iuse on the other hand shows the services that can be used by the service, but are not necessary for the correct functioning.

Code Listing 1.10: Requesting a list of all necessary services on which Postfix depends

# /etc/init.d/postfix ineed

Similarly, you can ask what services require the service (needsme) or can use it (usesme):

Code Listing 1.11: Requesting a list of all services that require Postfix

# /etc/init.d/postfix needsme

Finally, you can ask what dependencies the service requires that are missing:

Code Listing 1.12: Requesting a list of missing dependencies for Postfix

# /etc/init.d/postfix broken

4.b. Working with rc-update

What is rc-update?

Gentoo's init system uses a dependency-tree to decide what service needs to be started first. As this is a tedious task that we wouldn't want our users to have to do manually, we have created tools that ease the administration of the runlevels and init scripts.

With rc-update you can add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the script to rebuild the dependency tree.

Adding and Removing Services

You have already added init scripts to the "default" runlevel during the installation of Gentoo. At that time you might not have had a clue what the "default" is for, but now you should. The rc-update script requires a second argument that defines the action: add, del or show.

To add or remove an init script, just give rc-update the add or del argument, followed by the init script and the runlevel. For instance:

Code Listing 2.1: Removing Postfix from the default runlevel

# rc-update del postfix default

The rc-update -v show command will show all the available init scripts and list at which runlevels they will execute:

Code Listing 2.2: Receiving init script information

# rc-update -v show

You can also run rc-update show (without -v) to just view enabled init scripts and their runlevels.

4.c. Configuring Services

Why the Need for Extra Configuration?

Init scripts can be quite complex. It is therefore not really desirable to have the users edit the init script directly, as it would make it more error-prone. It is however important to be able to configure such a service. For instance, you might want to give more options to the service itself.

A second reason to have this configuration outside the init script is to be able to update the init scripts without the fear that your configuration changes will be undone.

The /etc/conf.d Directory

Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in /etc/conf.d. For instance, the apache2 initscript (called /etc/init.d/apache2) has a configuration file called /etc/conf.d/apache2, which can contain the options you want to give to the Apache 2 server when it is started:

Code Listing 3.1: Variable defined in /etc/conf.d/apache2


Such a configuration file contains variables and variables alone (just like /etc/portage/make.conf), making it very easy to configure services. It also allows us to provide more information about the variables (as comments).

4.d. Writing Init Scripts

Do I Have To?

No, writing an init script is usually not necessary as Gentoo provides ready-to-use init scripts for all provided services. However, you might have installed a service without using Portage, in which case you will most likely have to create an init script.

Do not use the init script provided by the service if it isn't explicitly written for Gentoo: Gentoo's init scripts are not compatible with the init scripts used by other distributions!


The basic layout of an init script is shown below.

Code Listing 4.1: Basic layout of an init script


depend() {
  (Dependency information)

start() {
  (Commands necessary to start the service)

stop() {
  (Commands necessary to stop the service)

Any init script requires the start() function to be defined. All other sections are optional.


There are two dependency-alike settings you can define that influence the start-up or sequencing of init scripts: use and need. Next to these two, there are also two order-influencing methods called before and after. These last two are no dependencies per se - they do not make the original init script fail if the selected one isn't scheduled to start (or fails to start).

  • The use settings informs the init system that this script uses functionality offered by the selected script, but does not directly depend on it. A good example would be use logger or use dns. If those services are available, they will be put in good use, but if you do not have a logger or DNS server the services will still work. If the services exist, then they are started before the script that use's them.
  • The need setting is a hard dependency. It means that the script that is need'ing another script will not start before the other script is launched successfully. Also, if that other script is restarted, then this one will be restarted as well.
  • When using before, then the given script is launched before the selected one if the selected one is part of the init level. So an init script xdm that defines before alsasound will start before the alsasound script, but only if alsasound is scheduled to start as well in the same init level. If alsasound is not scheduled to start too, then this particular setting has no effect and xdm will be started when the init system deems it most appropriate.
  • Similarly, after informs the init system that the given script should be launched after the selected one if the selected one is part of the init level. If not, then the setting has no effect and the script will be launched by the init system when it deems it most appropriate.

It should be clear from the above that need is the only "true" dependency setting as it affects if the script will be started or not. All the others are merely pointers towards the init system to clarify in which order scripts can be (or should be) launched.

Now, if you look at many of Gentoo's available init scripts, you will notice that some have dependencies on things that are no init scripts. These "things" we call virtuals.

A virtual dependency is a dependency that a service provides, but that is not provided solely by that service. Your init script can depend on a system logger, but there are many system loggers available (metalogd, syslog-ng, sysklogd, ...). As you cannot need every single one of them (no sensible system has all these system loggers installed and running) we made sure that all these services provide a virtual dependency.

Let us take a look at the dependency information for the postfix service.

Code Listing 4.2: Dependency information for Postfix

depend() {
  need net
  use logger dns
  provide mta

As you can see, the postfix service:

  • requires the (virtual) net dependency (which is provided by, for instance, /etc/init.d/net.eth0)
  • uses the (virtual) logger dependency (which is provided by, for instance, /etc/init.d/syslog-ng)
  • uses the (virtual) dns dependency (which is provided by, for instance, /etc/init.d/named)
  • provides the (virtual) mta dependency (which is common for all mail servers)

Controlling the Order

As we described in the previous section, you can tell the init system what order it should use for starting (or stopping) scripts. This ordering is handled both through the dependency settings use and need, but also through the order settings before and after. As we have described these earlier already, let's take a look at the Portmap service as an example of such init script.

Code Listing 4.3: The depend() function in the Portmap service

depend() {
  need net
  before inetd
  before xinetd

You can also use the "*" glob to catch all services in the same runlevel, although this isn't advisable.

Code Listing 4.4: Running an init script as first script in the runlevel

depend() {
  before *

If your service must write to local disks, it should need localmount. If it places anything in /var/run such as a pidfile, then it should start after bootmisc:

Code Listing 4.5: Example depend() function

depend() {
  need localmount
  after bootmisc

Standard Functions

Next to the depend() functionality, you also need to define the start() function. This one contains all the commands necessary to initialize your service. It is advisable to use the ebegin and eend functions to inform the user about what is happening:

Code Listing 4.6: Example start() function

start() {
  if [ "${RC_CMD}" = "restart" ];
    # Do something in case a restart requires more than stop, start

  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?

Both --exec and --pidfile should be used in start and stop functions. If the service does not create a pidfile, then use --make-pidfile if possible, though you should test this to be sure. Otherwise, don't use pidfiles. You can also add --quiet to the start-stop-daemon options, but this is not recommended unless the service is extremely verbose. Using --quiet may hinder debugging if the service fails to start.

Another notable setting used in the above example is to check the contents of the RC_CMD variable. Unlike the previous init script system, the newer openrc system does not support script-specific restart functionality. Instead, the script needs to check the contents of the RC_CMD variable to see if a function (be it start() or stop()) is called as part of a restart or not.

Note: Make sure that --exec actually calls a service and not just a shell script that launches services and exits -- that's what the init script is supposed to do.

If you need more examples of the start() function, please read the source code of the available init scripts in your /etc/init.d directory.

Another function you can define is stop(). You are not obliged to define this function though! Our init system is intelligent enough to fill in this function by itself if you use start-stop-daemon.

Here is an example of a stop() function:

Code Listing 4.7: Example stop() function

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?

If your service runs some other script (for example, bash, python, or perl), and this script later changes names (for example, to foo), then you will need to add --name to start-stop-daemon. You must specify the name that your script will be changed to. In this example, a service starts, which changes names to foo:

Code Listing 4.8: A service that starts the foo script

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?

start-stop-daemon has an excellent man page available if you need more information:

Code Listing 4.9: Getting the man page for start-stop-daemon

$ man start-stop-daemon

Gentoo's init script syntax is based on the POSIX Shell so you are free to use sh-compatible constructs inside your init script. Keep other constructs, like bash-specific ones, out of the init scripts to ensure that the scripts remain functional regardless of the change Gentoo might do on its init system.

Adding Custom Options

If you want your init script to support more options than the ones we have already encountered, you should add the option to the extra_commands variable, and create a function with the same name as the option. For instance, to support an option called restartdelay:

Code Listing 4.10: Supporting the restartdelay option


restartdelay() {
  sleep 3    # Wait 3 seconds before starting again

Important: The function restart() cannot be overridden in openrc!

Service Configuration Variables

You don't have to do anything to support a configuration file in /etc/conf.d: if your init script is executed, the following files are automatically sourced (i.e. the variables are available to use):

  • /etc/conf.d/<your init script>
  • /etc/conf.d/basic
  • /etc/rc.conf

Also, if your init script provides a virtual dependency (such as net), the file associated with that dependency (such as /etc/conf.d/net) will be sourced too.

4.e. Changing the Runlevel Behaviour

Who might benefit from this?

Many laptop users know the situation: at home you need to start net.eth0 while you don't want to start net.eth0 while you're on the road (as there is no network available). With Gentoo you can alter the runlevel behaviour to your own will.

For instance you can create a second "default" runlevel which you can boot that has other init scripts assigned to it. You can then select at boottime what default runlevel you want to use.

Using softlevel

First of all, create the runlevel directory for your second "default" runlevel. As an example we create the offline runlevel:

Code Listing 5.1: Creating a runlevel directory

# mkdir /etc/runlevels/offline

Add the necessary init scripts to the newly created runlevels. For instance, if you want to have an exact copy of your current default runlevel but without net.eth0:

Code Listing 5.2: Adding the necessary init scripts

(Copy all services from default runlevel to offline runlevel)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Remove unwanted service from offline runlevel)
# rc-update del net.eth0 offline
(Display active services for offline runlevel)
# rc-update show offline
(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Even though net.eth0 has been removed from the offline runlevel, udev might want to attempt to start any devices it detects and launch the appropriate services, a functionality that is called hotplugging. By default, Gentoo does not enable hotplugging.

If you do want to enable hotplugging, but only for a selected set of scripts, use the rc_hotplug variable in /etc/rc.conf:

Code Listing 5.3: Disabling device initiated services in /etc/rc.conf

# Allow net.wlan as well as any other service, except those matching net.*
# to be hotplugged
rc_hotplug="net.wlan !net.*"

Note: For more information on device initiated services, please see the comments inside /etc/rc.conf.

Now edit your bootloader configuration and add a new entry for the offline runlevel. For instance, in /boot/grub/grub.conf:

Code Listing 5.4: Adding an entry for the offline runlevel

title Gentoo Linux Offline Usage
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Voilà, you're all set now. If you boot your system and select the newly added entry at boot, the offline runlevel will be used instead of the default one.

Using bootlevel

Using bootlevel is completely analogous to softlevel. The only difference here is that you define a second "boot" runlevel instead of a second "default" runlevel.

5. Environment Variables

5.a. Environment Variables?

What they are

An environment variable is a named object that contains information used by one or more applications. Many users (and especially those new to Linux) find this a bit weird or unmanageable. However, this is a mistake: by using environment variables one can easily change a configuration setting for one or more applications.

Important Examples

The following table lists a number of variables used by a Linux system and describes their use. Example values are presented after the table.

Variable Description
PATH This variable contains a colon-separated list of directories in which your system looks for executable files. If you enter a name of an executable (such as ls, rc-update or emerge) but this executable is not located in a listed directory, your system will not execute it (unless you enter the full path as command, such as /bin/ls).
ROOTPATH This variable has the same function as PATH, but this one only lists the directories that should be checked when the root-user enters a command.
LDPATH This variable contains a colon-separated list of directories in which the dynamical linker searches through to find a library.
MANPATH This variable contains a colon-separated list of directories in which the man command searches for the man pages.
INFODIR This variable contains a colon-separated list of directories in which the info command searches for the info pages.
PAGER This variable contains the path to the program used to list the contents of files through (such as less or more).
EDITOR This variable contains the path to the program used to change the contents of files with (such as nano or vi).
KDEDIRS This variable contains a colon-separated list of directories which contain KDE-specific material.
CONFIG_PROTECT This variable contains a space-delimited list of directories which should be protected by Portage during updates.
CONFIG_PROTECT_MASK This variable contains a space-delimited list of directories which should not be protected by Portage during updates.

Below you will find an example definition of all these variables:

Code Listing 1.1: Example definitions

CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"

5.b. Defining Variables Globally

The /etc/env.d Directory

To centralise the definitions of these variables, Gentoo introduced the /etc/env.d directory. Inside this directory you will find a number of files, such as 00basic, 05gcc, etc. which contain the variables needed by the application mentioned in their name.

For instance, when you installed gcc, a file called 05gcc was created by the ebuild which contains the definitions of the following variables:

Code Listing 2.1: /etc/env.d/05gcc


Other distributions tell you to change or add such environment variable definitions in /etc/profile or other locations. Gentoo on the other hand makes it easy for you (and for Portage) to maintain and manage the environment variables without having to pay attention to the numerous files that can contain environment variables.

For instance, when gcc is updated, the /etc/env.d/05gcc file is updated too without requesting any user-interaction.

This not only benefits Portage, but also you, as user. Occasionally you might be asked to set a certain environment variable system-wide. As an example we take the http_proxy variable. Instead of messing about with /etc/profile, you can now just create a file (/etc/env.d/99local) and enter your definition(s) in it:

Code Listing 2.2: /etc/env.d/99local


By using the same file for all your variables, you have a quick overview on the variables you have defined yourself.

The env-update Script

Several files in /etc/env.d define the PATH variable. This is not a mistake: when you run env-update, it will append the several definitions before it updates the environment variables, thereby making it easy for packages (or users) to add their own environment variable settings without interfering with the already existing values.

The env-update script will append the values in the alphabetical order of the /etc/env.d files. The file names must begin with two decimal digits.

Code Listing 2.3: Update order used by env-update

         00basic        99kde-env       99local

The concatenation of variables does not always happen, only with the following variables: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH and PYTHONPATH. For all other variables the latest defined value (in alphabetical order of the files in /etc/env.d) is used.

You can add more variables into this list of concatenate-variables by adding the variable name to either COLON_SEPARATED or SPACE_SEPARATED variables (also inside an env.d file).

When you run env-update, the script will create all environment variables and place them in /etc/profile.env (which is used by /etc/profile). It will also extract the information from the LDPATH variable and use that to create /etc/ After this, it will run ldconfig to recreate the /etc/ file used by the dynamical linker.

If you want to notice the effect of env-update immediately after you run it, execute the following command to update your environment. Users who have installed Gentoo themselves will probably remember this from the installation instructions:

Code Listing 2.4: Updating the environment

# env-update && source /etc/profile

Note: The above command only updates the variables in your current terminal, new consoles, and their children. Thus, if you are working in X11, you will need to either type source /etc/profile in every new terminal you open or restart X so that all new terminals source the new variables. If you use a login manager, become root and type /etc/init.d/xdm restart. If not, you will need to logout and log back in for X to spawn children with the new variable values.

Important: You cannot use shell variables when defining other variables. This means things like FOO="$BAR" (where $BAR is another variable) are forbidden.

5.c. Defining Variables Locally

User Specific

You do not always want to define an environment variable globally. For instance, you might want to add /home/my_user/bin and the current working directory (the directory you are in) to the PATH variable but don't want all other users on your system to have that in their PATH too. If you want to define an environment variable locally, you should use ~/.bashrc or ~/.bash_profile:

Code Listing 3.1: Extending PATH for local usage in ~/.bashrc

(A colon followed by no directory is treated as the current working directory)

When you relogin, your PATH variable will be updated.

Session Specific

Sometimes even stricter definitions are requested. You might want to be able to use binaries from a temporary directory you created without using the path to the binaries themselves or editing ~/.bashrc for the short time you need it.

In this case, you can just define the PATH variable in your current session by using the export command. As long as you don't log out, the PATH variable will be using the temporary settings.

Code Listing 3.2: Defining a session-specific environment variable

# export PATH="${PATH}:/home/my_user/tmp/usr/bin"

C. Working with Portage

1. Files and Directories

1.a. Portage Files

Configuration Directives

Portage comes with a default configuration stored in /usr/share/portage/config/make.globals. When you take a look at it, you'll notice that all Portage configuration is handled through variables. What variables Portage listens to and what they mean are described later.

Since many configuration directives differ between architectures, Portage also has default configuration files which are part of your profile. Your profile is pointed to by the /etc/portage/make.profile symlink; Portage' configurations are set in the make.defaults files of your profile and all parent profiles. We'll explain more about profiles and the /etc/portage/make.profile directory later on.

If you're planning on changing a configuration variable, don't alter /usr/share/portage/config/make.globals or make.defaults. Instead use /etc/portage/make.conf which has precedence over the previous files. You'll also find a /usr/share/portage/config/make.conf.example. As the name implies, this is merely an example file - Portage does not read in this file.

You can also define a Portage configuration variable as an environment variable, but we don't recommend this.

Profile-Specific Information

We've already encountered the /etc/portage/make.profile directory. Well, this isn't exactly a directory but a symbolic link to a profile, by default one inside /usr/portage/profiles although you can create your own profiles elsewhere and point to them. The profile this symlink points to is the profile to which your system adheres.

A profile contains architecture-specific information for Portage, such as a list of packages that belong to the system corresponding with that profile, a list of packages that don't work (or are masked-out) for that profile, etc.

User-Specific Configuration

When you need to override Portage's behaviour regarding the installation of software, you will end up editing files within /etc/portage. You are highly recommended to use files within /etc/portage and highly discouraged to override the behaviour through environment variables!

Within /etc/portage you can create the following files:

  • package.mask which lists the packages you never want Portage to install
  • package.unmask which lists the packages you want to be able to install even though the Gentoo developers highly discourage you from emerging them
  • package.accept_keywords which lists the packages you want to be able to install even though the package hasn't been found suitable for your system or architecture (yet)
  • package.use which lists the USE flags you want to use for certain packages without having the entire system use those USE flags

These don't have to be files; they can also be directories that contain one file per package. More information about the /etc/portage directory and a full list of possible files you can create can be found in the Portage man page:

Code Listing 1.1: Reading the Portage man page

$ man portage

Changing Portage File & Directory Locations

The previously mentioned configuration files cannot be stored elsewhere - Portage will always look for those configuration files at those exact locations. However, Portage uses many other locations for various purposes: build directory, source code storage, Portage tree location, ...

All these purposes have well-known default locations but can be altered to your own taste through /etc/portage/make.conf. The rest of this chapter explains what special-purpose locations Portage uses and how to alter their placement on your filesystem.

This document isn't meant to be used as a reference though. If you need 100% coverage, please consult the Portage and make.conf man pages:

Code Listing 1.2: Reading the Portage and make.conf man pages

$ man portage
$ man make.conf

1.b. Storing Files

The Portage Tree

The Portage tree default location is /usr/portage. This is defined by the PORTDIR variable. When you store the Portage tree elsewhere (by altering this variable), don't forget to change the /etc/portage/make.profile symbolic link accordingly.

If you alter the PORTDIR variable, you might want to alter the following variables as well since they will not notice the PORTDIR change. This is due to how Portage handles variables: PKGDIR, DISTDIR, RPMDIR.

Prebuilt Binaries

Even though Portage doesn't use prebuilt binaries by default, it has extensive support for them. When you ask Portage to work with prebuilt packages, it will look for them in /usr/portage/packages. This location is defined by the PKGDIR variable.

Source Code

Application source code is stored in /usr/portage/distfiles by default. This location is defined by the DISTDIR variable.

Portage Database

Portage stores the state of your system (what packages are installed, what files belong to which package, ...) in /var/db/pkg. Do not alter these files manually! It might break Portage's knowledge of your system.

Portage Cache

The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: you can clean it if you are not running any portage-related application at that moment.

1.c. Building Software

Temporary Portage Files

Portage's temporary files are stored in /var/tmp by default. This is defined by the PORTAGE_TMPDIR variable.

If you alter the PORTAGE_TMPDIR variable, you might want to alter the following variables as well since they will not notice the PORTAGE_TMPDIR change. This is due to how Portage handles variables: BUILD_PREFIX.

Building Directory

Portage creates specific build directories for each package it emerges inside /var/tmp/portage. This location is defined by the BUILD_PREFIX variable.

Live Filesystem Location

By default Portage installs all files on the current filesystem (/), but you can change this by setting the ROOT environment variable. This is useful when you want to create new build images.

1.d. Logging Features

Ebuild Logging

Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable is set to a location that is writable by Portage (the portage user). By default this variable is unset. If you don't set PORT_LOGDIR, then you won't receive any build logs with the current logging system, though you may receive some logs from the new elog. If you do have PORT_LOGDIR defined and you use elog, you will receive build logs and any logs saved by elog, as explained below.

Portage offers fine-grained control over logging through the use of elog:

  • PORTAGE_ELOG_CLASSES: This is where you set what kinds of messages to be logged. You can use any space-separated combination of info, warn, error, log, and qa.
    • info: Logs "einfo" messages printed by an ebuild
    • warn: Logs "ewarn" messages printed by an ebuild
    • error: Logs "eerror" messages printed by an ebuild
    • log: Logs the "elog" messages found in some ebuilds
    • qa: Logs the "QA Notice" messages printed by an ebuild
  • PORTAGE_ELOG_SYSTEM: This selects the module(s) to process the log messages. If left empty, logging is disabled. You can use any space-separated combination of save, custom, syslog, mail, save_summary, and mail_summary. You must select at least one module in order to use elog.
    • save: This saves one log per package in $PORT_LOGDIR/elog, or /var/log/portage/elog if $PORT_LOGDIR is not defined.
    • custom: Passes all messages to a user-defined command in $PORTAGE_ELOG_COMMAND; this will be discussed later.
    • syslog: Sends all messages to the installed system logger.
    • mail: Passes all messages to a user-defined mailserver in $PORTAGE_ELOG_MAILURI; this will be discussed later. The mail features of elog require >=portage-2.1.1.
    • save_summary: Similar to save, but it merges all messages in $PORT_LOGDIR/elog/summary.log, or /var/log/portage/elog/summary.log if $PORT_LOGDIR is not defined.
    • mail_summary: Similar to mail, but it sends all messages in a single mail when emerge exits.
  • PORTAGE_ELOG_COMMAND: This is only used when the custom module is enabled. Here is where you specify a command to process log messages. Note that you can make use of two variables: ${PACKAGE} is the package name and version, while ${LOGFILE} is the absolute path to the logfile. Here's one possible usage:
    • PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
  • PORTAGE_ELOG_MAILURI: This contains settings for the mail module such as address, user, password, mailserver, and port number. The default setting is "root@localhost localhost".
  • Here's an example for an smtp server that requires username and password-based authentication on a particular port (the default is port 25):
    • PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"
  • PORTAGE_ELOG_MAILFROM: Allows you to set the "from" address of log mails; defaults to "portage" if unset.
  • PORTAGE_ELOG_MAILSUBJECT: Allows you to create a subject line for log mails. Note that you can make use of two variables: ${PACKAGE} will display the package name and version, while ${HOST} is the fully qualified domain name of the host Portage is running on.
  • Here's one possible use:
    • PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"

Important: If you used enotice with Portage-2.0.*, you must completely remove enotice, as it is incompatible with elog.

2. Configuring through Variables

2.a. Portage Configuration

As noted previously, Portage is configurable through many variables which you should define in /etc/portage/make.conf or one of the subdirectories of /etc/portage. Please refer to the make.conf and portage man pages for more and complete information:

Code Listing 1.1: Reading the man pages

$ man make.conf
$ man portage

2.b. Build-specific Options

Configure and Compiler Options

When Portage builds applications, it passes the contents of the following variables to the compiler and configure script:

  • CFLAGS & CXXFLAGS define the desired compiler flags for C and C++ compiling.
  • CHOST defines the build host information for the application's configure script
  • MAKEOPTS is passed to the make command and is usually set to define the amount of parallelism used during the compilation. More information about the make options can be found in the make man page.

The USE variable is also used during configure and compilations but has been explained in great detail in previous chapters.

Merge Options

When Portage has merged a newer version of a certain software title, it will remove the obsoleted files of the older version from your system. Portage gives the user a 5 second delay before unmerging the older version. These 5 seconds are defined by the CLEAN_DELAY variable.

You can tell emerge to use certain options every time it is run by setting EMERGE_DEFAULT_OPTS. Some useful options would be --ask, --verbose, --tree, and so on.

2.c. Configuration File Protection

Portage's Protected Locations

Portage overwrites files provided by newer versions of a software title if the files aren't stored in a protected location. These protected locations are defined by the CONFIG_PROTECT variable and are generally configuration file locations. The directory listing is space-delimited.

A file that would be written in such a protected location is renamed and the user is warned about the presence of a newer version of the (presumable) configuration file.

You can find out about the current CONFIG_PROTECT setting from the emerge --info output:

Code Listing 3.1: Getting the CONFIG_PROTECT setting

$ emerge --info | grep 'CONFIG_PROTECT='

More information about Portage's Configuration File Protection is available in the CONFIGURATION FILES section of the emerge manpage:

Code Listing 3.2: More information about Configuration File Protection

$ man emerge

Excluding Directories

To 'unprotect' certain subdirectories of protected locations you can use the CONFIG_PROTECT_MASK variable.

2.d. Download Options

Server Locations

When the requested information or data is not available on your system, Portage will retrieve it from the Internet. The server locations for the various information and data channels are defined by the following variables:

  • GENTOO_MIRRORS defines a list of server locations which contain source code (distfiles)
  • PORTAGE_BINHOST defines a particular server location containing prebuilt packages for your system

A third setting involves the location of the rsync server which you use when you update your Portage tree. This is defined in the /etc/portage/repos.conf file (or a file inside that directory if it is defined as a directory):

  • sync-type defines the type of server and defaults to "rsync"
  • sync-uri defines a particular server which Portage uses to fetch the Portage tree from

The GENTOO_MIRRORS, sync-type and sync-uri variables can be set automatically through the mirrorselect application. You need to emerge mirrorselect first before you can use it. For more information, see mirrorselect's online help:

Code Listing 4.1: More information about mirrorselect

# mirrorselect --help

If your environment requires you to use a proxy server, you can use the http_proxy, ftp_proxy and RSYNC_PROXY variables to declare a proxy server.

Fetch Commands

When Portage needs to fetch source code, it uses wget by default. You can change this through the FETCHCOMMAND variable.

Portage is able to resume partially downloaded source code. It uses wget by default, but this can be altered through the RESUMECOMMAND variable.

Make sure that your FETCHCOMMAND and RESUMECOMMAND stores the source code in the correct location. Inside the variables you should use \${URI} and \${DISTDIR} to point to the source code location and distfiles location respectively.

You can also define protocol-specific handlers with FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.

Rsync Settings

You cannot alter the rsync command used by Portage to update the Portage tree, but you can set some variables related to the rsync command:

  • PORTAGE_RSYNC_OPTS sets a number of default variables used during sync, each space-separated. These shouldn't be changed unless you know exactly what you're doing. Note that certain absolutely required options will always be used even if PORTAGE_RSYNC_OPTS is empty.
  • PORTAGE_RSYNC_EXTRA_OPTS can be used to set additional options when syncing. Each option should be space separated.
    • --timeout=<number>: This defines the number of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to 180 but dialup users or individuals with slow computers might want to set this to 300 or higher.
    • --exclude-from=/etc/portage/rsync_excludes: This points to a file listing the packages and/or categories rsync should ignore during the update process. In this case, it points to /etc/portage/rsync_excludes. Please read Using a Portage Tree Subset for the syntax of this file.
    • --quiet: Reduces output to the screen
    • --verbose: Prints a complete filelist
    • --progress: Displays a progress meter for each file
  • PORTAGE_RSYNC_RETRIES defines how many times rsync should try connecting to the mirror pointed to by the SYNC variable before bailing out. This variable defaults to 3.

For more information on these options and others, please read man rsync.

2.e. Gentoo Configuration

Branch Selection

You can change your default branch with the ACCEPT_KEYWORDS variable. It defaults to your architecture's stable branch. More information on Gentoo's branches can be found in the next chapter.

Portage Features

You can activate certain Portage features through the FEATURES variable. The Portage Features have been discussed in previous chapters, such as Portage Features.

2.f. Portage Behaviour

Resource Management

With the PORTAGE_NICENESS variable you can augment or reduce the nice value Portage runs with. The PORTAGE_NICENESS value is added to the current nice value.

For more information about nice values, see the nice man page:

Code Listing 6.1: More information about nice

$ man nice

Output Behaviour

The NOCOLOR, which defaults to "false", defines if Portage should disable the use of coloured output.

3. Mixing Software Branches

3.a. Using One Branch

The Stable Branch

The ACCEPT_KEYWORDS variable defines what software branch you use on your system. It defaults to the stable software branch for your architecture, for instance x86.

We recommend that you only use the stable branch. However, if you don't care about stability this much and you want to help out Gentoo by submitting bugreports to, read on.

The Testing Branch

If you want to use more recent software, you can consider using the testing branch instead. To have Portage use the testing branch, add a ~ in front of your architecture.

The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it.

Beware though, you might notice stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. If you do not know how Gentoo works and how to solve problems, we recommend that you stick with the stable and tested branch.

For example, to select the testing branch for the x86 architecture, edit /etc/portage/make.conf and set:

Code Listing 1.1: Setting the ACCEPT_KEYWORDS variable


If you update your system now, you will find out that lots of packages will be updated. Mind you though: when you have updated your system to use the testing branch there is usually no easy way back to the stable, official branch (except for using backups of course).

3.b. Mixing Stable with Testing

The package.accept_keywords location

You can ask Portage to allow the testing branch for particular packages but use the stable branch for the rest of the system. To achieve this, add the package category and name you want to use the testing branch of in /etc/portage/package.accept_keywords. You can also create a directory (with the same name) and list the package in the files under that directory. For instance, to use the testing branch for gnumeric:

Code Listing 2.1: /etc/portage/package.accept_keywords setting for gnumeric


Test Particular Versions

If you want to use a specific software version from the testing branch but you don't want Portage to use the testing branch for subsequent versions, you can add in the version in the package.accept_keywords location. In this case you must use the = operator. You can also enter a version range using the <=, <, > or >= operators.

In any case, if you add version information, you must use an operator. If you leave out version information, you cannot use an operator.

In the following example we ask Portage to accept gnumeric-1.2.13:

Code Listing 2.2: Enabling a particular gnumeric test version


3.c. Using Masked Packages

The package.unmask location

Important: The Gentoo developers do not support the use of this location. Please exercise due caution when doing so. Support requests related to package.unmask and/or package.mask will not be answered. You have been warned.

When a package has been masked by the Gentoo developers and you still want to use it despite the reason mentioned in the package.mask file (situated in /usr/portage/profiles by default), add the desired version (usually this will be the exact same line from profiles) in the /etc/portage/package.unmask file (or in a file in that directory if it is a directory).

For instance, if =net-mail/hotwayd-0.8 is masked, you can unmask it by adding the exact same line in the package.unmask location:

Code Listing 3.1: /etc/portage/package.unmask


Note: If an entry in /usr/portage/profiles/package.mask contains a range of package versions, you will need to unmask only the version(s) you actually want. Please read the previous section to learn how to specify versions in package.unmask.

The package.mask location

When you don't want Portage to take a certain package or a specific version of a package into account you can mask it yourself by adding an appropriate line to the /etc/portage/package.mask location (either in that file or in a file in this directory).

For instance, if you don't want Portage to install newer kernel sources than gentoo-sources-, you add the following line at the package.mask location:

Code Listing 3.2: /etc/portage/package.mask example


4. Additional Portage Tools

4.a. dispatch-conf

dispatch-conf is a tool that aids in merging the ._cfg0000_<name> files. ._cfg0000_<name> files are generated by Portage when it wants to overwrite a file in a directory protected by the CONFIG_PROTECT variable.

With dispatch-conf, you are able to merge updates to your configuration files while keeping track of all changes. dispatch-conf stores the differences between the configuration files as patches or by using the RCS revision system. This means that if you make a mistake when updating a config file, you can revert to the previous version of your config file at any time.

When using dispatch-conf, you can ask to keep the configuration file as-is, use the new configuration file, edit the current one or merge the changes interactively. dispatch-conf also has some nice additional features:

  • Automatically merge configuration file updates that only contain updates to comments
  • Automatically merge configuration files which only differ in the amount of whitespace

Make certain you edit /etc/dispatch-conf.conf first and create the directory referenced by the archive-dir variable.

Code Listing 1.1: Running dispatch-conf

# dispatch-conf

When running dispatch-conf, you'll be taken through each changed config file, one at a time. Press u to update (replace) the current config file with the new one and continue to the next file. Press z to zap (delete) the new config file and continue to the next file. Once all config files have been taken care of, dispatch-conf will exit. You can also press q to exit any time.

For more information, check out the dispatch-conf man page. It tells you how to interactively merge current and new config files, edit new config files, examine differences between files, and more.

Code Listing 1.2: Reading the dispatch-conf man page

$ man dispatch-conf

4.b. etc-update

You can also use etc-update to merge config files. It's not as simple to use as dispatch-conf, nor as featureful, but it does provide an interactive merging setup and can also auto-merge trivial changes.

However, unlike dispatch-conf, etc-update does not preserve the old versions of your config files. Once you update the file, the old version is gone forever! So be very careful, as using etc-update is significantly less safe than using dispatch-conf.

Code Listing 2.1: Running etc-update

# etc-update

After merging the straightforward changes, you will be prompted with a list of protected files that have an update waiting. At the bottom you are greeted by the possible options:

Code Listing 2.2: etc-update options

Please select a file to edit by entering the corresponding number.
              (-1 to exit) (-3 to auto merge all remaining files)
                           (-5 to auto-merge AND not use 'mv -i'):

If you enter -1, etc-update will exit and discontinue any further changes. If you enter -3 or -5, all listed configuration files will be overwritten with the newer versions. It is therefore very important to first select the configuration files that should not be automatically updated. This is simply a matter of entering the number listed to the left of that configuration file.

As an example, we select the configuration file /etc/pear.conf:

Code Listing 2.3: Updating a specific configuration file

Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again

You can now see the differences between the two files. If you believe that the updated configuration file can be used without problems, enter 1. If you believe that the updated configuration file isn't necessary, or doesn't provide any new or useful information, enter 2. If you want to interactively update your current configuration file, enter 3.

There is no point in further elaborating the interactive merging here. For completeness sake, we will list the possible commands you can use while you are interactively merging the two files. You are greeted with two lines (the original one, and the proposed new one) and a prompt at which you can enter one of the following commands:

Code Listing 2.4: Commands available for the interactive merging

ed:     Edit then use both versions, each decorated with a header.
eb:     Edit then use both versions.
el:     Edit then use the left version.
er:     Edit then use the right version.
e:      Edit a new version.
l:      Use the left version.
r:      Use the right version.
s:      Silently include common lines.
v:      Verbosely include common lines.
q:      Quit.

When you have finished updating the important configuration files, you can now automatically update all the other configuration files. etc-update will exit if it doesn't find any more updateable configuration files.

4.c. quickpkg

With quickpkg you can create archives of the packages that are already merged on your system. These archives can be used as prebuilt packages. Running quickpkg is straightforward: just add the names of the packages you want to archive.

For instance, to archive curl, orage, and procps:

Code Listing 3.1: Example quickpkg usage

# quickpkg curl orage procps

The prebuilt packages will be stored in $PKGDIR (/usr/portage/packages/ by default). These packages are placed in $PKGDIR/<category>.

5. Diverting from the Official Tree

5.a. Using a Portage Tree Subset

Excluding Packages/Categories

You can selectively update certain categories/packages and ignore the other categories/packages. We achieve this by having rsync exclude categories/packages during the emerge --sync step.

You need to define the name of the file that contains the exclude patterns in the PORTAGE_RSYNC_EXTRA_OPTS variable in your /etc/portage/make.conf.

Code Listing 1.1: Defining the exclude file in /etc/portage/make.conf


Code Listing 1.2: Excluding all games in /etc/portage/rsync_excludes


Note however that this may lead to dependency issues since new, allowed packages might depend on new but excluded packages.

5.b. Adding Unofficial Ebuilds

Defining a Portage Overlay Directory

You can ask Portage to use ebuilds that are not officially available through the Portage tree. Create a new directory (for instance /usr/local/portage) in which you store the 3rd-party ebuilds. Use the same directory structure as the official Portage tree!

Then define PORTDIR_OVERLAY in /etc/portage/make.conf and have it point to the previously defined directory. When you use Portage now, it will take those ebuilds into account as well without removing/overwriting those ebuilds the next time you run emerge --sync.

Working with Several Overlays

For the powerusers who develop on several overlays, test packages before they hit the Portage tree or just want to use unofficial ebuilds from various sources, the app-portage/layman package brings you layman, a tool to help you keep the overlay repositories up to date.

First install and configure layman as shown in the Overlays Users' Guide, and add your desired repositories with layman -a <overlay-name>.

Suppose you have two repositories called java (for the in-development java ebuilds) and entapps (for the applications developed in-house for your enterprise). You can update those repositories with the following command:

Code Listing 2.1: Using layman to update all repositories

# layman -S

For more information on working with overlays, please read man layman and the layman/overlay users' guide.

5.c. Non-Portage Maintained Software

Using Portage with Self-Maintained Software

In some cases you want to configure, install and maintain software yourself without having Portage automate the process for you, even though Portage can provide the software titles. Known cases are kernel sources and nvidia drivers. You can configure Portage so it knows that a certain package is manually installed on your system. This process is called injecting and supported by Portage through the /etc/portage/profile/package.provided file.

For instance, if you want to inform Portage about gentoo-sources- which you've installed manually, add the following line to /etc/portage/profile/package.provided:

Code Listing 3.1: Example line for package.provided


D. Gentoo Network Configuration

1. Getting Started

1.a. Getting started

Note: This document assumes that you have correctly configured your kernel, its modules for your hardware and you know the interface name of your hardware. We also assume that you are configuring eth0, but it could also be eno0, ens1, wlan0, enp1s0 etc.

To get started configuring your network card, you need to tell the Gentoo RC system about it. This is done by creating a symbolic link from net.lo to net.eth0 (or whatever the network interface name is on your system) in /etc/init.d.

Code Listing 1.1: Symlinking net.eth0 to net.lo

# cd /etc/init.d
# ln -s net.lo net.eth0

Gentoo's RC system now knows about that interface. It also needs to know how to configure the new interface. All the network interfaces are configured in /etc/conf.d/net. Below is a sample configuration for DHCP and static addresses.

Code Listing 1.2: Examples for /etc/conf.d/net

# For DHCP

# For static IP using CIDR notation
routes_eth0="default via"

# For static IP using netmask notation
config_eth0=" netmask"
routes_eth0="default via"

Note: If you do not specify a configuration for your interface then DHCP is assumed.

Note: CIDR stands for Classless InterDomain Routing. Originally, IPv4 addresses were classified as A, B, or C. The early classification system did not envision the massive popularity of the Internet, and is in danger of running out of new unique addresses. CIDR is an addressing scheme that allows one IP address to designate many IP addresses. A CIDR IP address looks like a normal IP address except that it ends with a slash followed by a number; for example, CIDR is described in RFC 1519.

Now that we have configured our interface, we can start and stop it using the following commands:

Code Listing 1.3: Starting and stopping network scripts

# /etc/init.d/net.eth0 start
# /etc/init.d/net.eth0 stop

Important: When troubleshooting networking, take a look at /var/log/rc.log. Unless you have rc_logger="NO" set in /etc/rc.conf, you will find information on the boot activity stored in that log file.

Now that you have successfully started and stopped your network interface, you may wish to get it to start when Gentoo boots. Here's how to do this. The last "rc" command instructs Gentoo to start any scripts in the current runlevel that have not yet been started.

Code Listing 1.4: Configuring a network interface to load at boot time

# rc-update add net.eth0 default
# rc

2. Advanced Configuration

2.a. Advanced Configuration

The config_eth0 variable is the heart of an interface configuration. It's a high level instruction list for configuring the interface (eth0 in this case). Each command in the instruction list is performed sequentially. The interface is deemed OK if at least one command works.

Here's a list of built-in instructions.

Command Description
null Do nothing
noop If the interface is up and there is an address then abort configuration successfully
an IPv4 or IPv6 address Add the address to the interface
dhcp, adsl or apipa (or a custom command from a 3rd party module) Run the module which provides the command. For example dhcp will run a module that provides DHCP which can be one of either dhcpcd, dhclient or pump.

If a command fails, you can specify a fallback command. The fallback has to match the config structure exactly.

You can chain these commands together. Here are some real world examples.

Code Listing 1.1: Configuration examples

# Adding three IPv4 addresses

# Adding an IPv4 address and two IPv6 addresses

# Keep our kernel assigned address, unless the interface goes
# down so assign another via DHCP. If DHCP fails then add a
# static address determined by APIPA

Note: When using the ifconfig module and adding more than one address, interface aliases are created for each extra address. So with the above two examples you will get interfaces eth0, eth0:1 and eth0:2. You cannot do anything special with these interfaces as the kernel and other programs will just treat eth0:1 and eth0:2 as eth0.

Important: The fallback order is important! If we did not specify the null option then the apipa command would only be run if the noop command failed.

Note: APIPA and DHCP are discussed later.

2.b. Network Dependencies

Init scripts in /etc/init.d can depend on a specific network interface or just net. All network interfaces in Gentoo's init system provide what is called net.

If, in /etc/rc.conf, rc_depend_strict="YES" is set, then all network interfaces that provide net must be active before a dependency on "net" is assumed to be met. In other words, if you have a net.eth0 and net.eth1 and an init script depends on "net", then both must be enabled.

On the other hand, if rc_depend_strict="NO" is set, then the "net" dependency is marked as resolved the moment at least one network interface is brought up.

But what about net.br0 depending on net.eth0 and net.eth1? net.eth1 may be a wireless or PPP device that needs configuration before it can be added to the bridge. This cannot be done in /etc/init.d/net.br0 as that's a symbolic link to net.lo.

The answer is defining an rc_need_ setting in /etc/conf.d/net.

Code Listing 2.1: net.br0 dependency in /etc/conf.d/net

rc_need_br0="net.eth0 net.eth1"

That alone, however, is not sufficient. Gentoo's networking init scripts use a virtual dependency called net to inform the system when networking is available. Clearly, in the above case, networking should only be marked as available when net.br0 is up, not when the others are. So we need to tell that in /etc/conf.d/net as well:

Code Listing 2.2: Updating virtual dependencies and provisions for networking


For a more detailed discussion about dependency, consult the section Writing Init Scripts in the Gentoo Handbook. More information about /etc/rc.conf is available as comments within that file.

2.c. Variable names and values

Variable names are dynamic. They normally follow the structure of variable_${interface|mac|essid|apmac}. For example, the variable dhcpcd_eth0 holds the value for dhcpcd options for eth0 and dhcpcd_essid holds the value for dhcpcd options when any interface connects to the ESSID "essid".

However, there is no hard and fast rule that states interface names must be ethx. In fact, many wireless interfaces have names like wlanx, rax as well as ethx. Also, some user defined interfaces such as bridges can be given any name, such as foo. To make life more interesting, wireless Access Points can have names with non alpha-numeric characters in them - this is important because you can configure networking parameters per ESSID.

The downside of all this is that Gentoo uses bash variables for networking - and bash cannot use anything outside of English alpha-numerics. To get around this limitation we change every character that is not an English alpha-numeric into a _ character.

Another downside of bash is the content of variables - some characters need to be escaped. This can be achived by placing the \ character in front of the character that needs to be escaped. The following list of characters needs to be escaped in this way: ", ' and \.

In this example we use wireless ESSID as they can contain the widest scope of characters. We shall use the ESSID My "\ NET:

Code Listing 3.1: variable name example

(This does work, but the domain is invalid)
dns_domain_My____NET="My \"\\ NET"

(The above sets the dns domain to My "\ NET when a wireless card
connects to an AP whose ESSID is My "\ NET)

2.d. Network Interface Naming

How It Works

Network interface names are not chosen arbitrarily: the Linux kernel and the device manager (most systems have udev as their device manager although others are available as well) choose the interface name through a fixed set of rules.

When an interface card is detected on a system, the Linux kernel gathers the necessary data about this card. This includes:

  1. the onboard (on the interface itself) registered name of the network card, which is later seen through the ID_NET_NAME_ONBOARD parameter;
  2. the slot in which the network card is plugged in, which is later seen through the ID_NET_NAME_SLOT parameter;
  3. the path through which the network card device can be accessed, which is later seen through the ID_NET_NAME_PATH parameter;
  4. the (vendor-provided) MAC address of the card, which is later seen through the ID_NET_NAME_MAC parameter;

Based on this information, the device manager decides how to name the interface on the system. By default, it uses the first hit of the first three parameters above (ID_NET_NAME_ONBOARD, _SLOT or _PATH). For instance, if ID_NET_NAME_ONBOARD is found and set to eno1, then the interface will be called eno1.

If you know your interface name, you can see the values of the provided parameters using udevadm:

Code Listing 4.1: Reading the network interface card information

# udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/null
ID_OUI_FROM_DATABASE=Quanta Computer Inc.

As the first (and actually only) hit of the top three parameters is the ID_NET_NAME_PATH one, its value is used as the interface name. If none of the parameters is found, then the system reverts back to the kernel-provided naming (eth0, eth1, etc.)

Using the Old-style Kernel Naming

Before this change, network interface cards were named by the Linux kernel itself, depending on the order that drivers are loaded (amongst other, possibly more obscure reasons). This behavior can still be enabled by setting the net.ifnames=0 boot option in the boot loader.

Using your Own Names

The entire idea behind the change in naming is not to confuse people, but to make changing the names easier. Suppose you have two interfaces that are otherwise called eth0 and eth1. One is meant to access the network through a wire, the other one is for wireless access. With the support for interface naming, you can have these called lan0 (wired) and wifi0 (wireless - it is best to avoid using the previously well-known names like eth* and wlan* as those can still collide with your suggested names).

All you need to do is to find out what the parameters are for the cards and then use this information to set up your own naming rule:

Code Listing 4.2: Setting the lan0 name for the current eth0 interface

# udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
ID_OUI_FROM_DATABASE=Quanta Computer Inc.

# vim /etc/udev/rules.d/76-net-name-use-custom.rules
# First one uses MAC information
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_MAC}=="enxc80aa9429d76", NAME="lan0"
# Second one uses ID_NET_NAME_PATH information
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="wifi0"

Because the rules are triggered before the default one (rules are triggered in alphanumerical order, so 70 comes before 80) the names provided in the rule file will be used instead of the default ones. The number granted to the file should be between 76 and 79 (the environment variables are defined by a rule start starts with 75 and the fallback naming is done in a rule numbered 80).

3. Modular Networking

3.a. Network Modules

We now support modular networking scripts, which means we can easily add support for new interface types and configuration modules while keeping compatibility with existing ones.

Modules load by default if the package they need is installed. If you specify a module here that doesn't have its package installed then you get an error stating which package you need to install. Ideally, you only use the modules setting when you have two or more packages installed that supply the same service and you need to prefer one over the other.

Note: All settings discussed here are stored in /etc/conf.d/net unless otherwise specified.

Code Listing 1.1: Module preference

# Prefer ifconfig over iproute2

# You can also specify other modules for an interface
# In this case we prefer pump over dhcpcd

# You can also specify which modules not to use - for example you may be
# using a supplicant or linux-wlan-ng to control wireless configuration but
# you still want to configure network settings per ESSID associated with.

3.b. Interface Handlers

We provide two interface handlers presently: ifconfig and iproute2. You need one of these to do any kind of network configuration.

ifconfig is installed by default (the net-tools package is part of the system profile). iproute2 is a more powerful and flexible package, but it's not included by default.

Code Listing 2.1: To install iproute2

# emerge sys-apps/iproute2

# To prefer ifconfig over iproute2 if both are installed as openrc prefers
# to use iproute2 then

As both ifconfig and iproute2 do very similar things we allow their basic configuration to work with each other. For example both the below code snippet work regardless of which module you are using.

Code Listing 2.2: ifconfig and iproute2 examples

config_eth0=" netmask"

# We can also specify broadcast
config_eth0=" brd"
config_eth0=" netmask broadcast"

3.c. DHCP

DHCP is a means of obtaining network information (IP address, DNS servers, Gateway, etc) from a DHCP server. This means that if there is a DHCP server running on the network, you just have to tell each client to use DHCP and it sets up the network all by itself. Of course, you will have to configure for other things like wireless, PPP or other things if required before you can use DHCP.

DHCP can be provided by dhclient, dhcpcd, or pump. Each DHCP module has its pros and cons - here's a quick run down.

DHCP Module Package Pros Cons
dhclient net-misc/dhcp Made by ISC, the same people who make the BIND DNS software. Very configurable Configuration is overly complex, software is quite bloated, cannot get NTP servers from DHCP, does not send hostname by default
dhcpcd net-misc/dhcpcd Long time Gentoo default, no reliance on outside tools, actively developed by Gentoo Can be slow at times, does not yet daemonize when lease is infinite
pump net-misc/pump Lightweight, no reliance on outside tools No longer maintained upstream, unreliable, especially over modems, cannot get NIS servers from DHCP

If you have more than one DHCP client installed, you need to specify which one to use - otherwise we default to dhcpcd if available.

To send specific options to the DHCP module, use module_eth0="..." (change module to the DHCP module you're using - i.e. dhcpcd_eth0).

We try and make DHCP relatively agnostic - as such we support the following commands using the dhcp_eth0 variable. The default is not to set any of them:

  • release - releases the IP address for re-use
  • nodns - don't overwrite /etc/resolv.conf
  • nontp - don't overwrite /etc/ntp.conf
  • nonis - don't overwrite /etc/yp.conf

Code Listing 3.1: Sample DHCP configuration in /etc/conf.d/net

# Only needed if you have more than one DHCP module installed

dhcpcd_eth0="-t 10" # Timeout after 10 seconds
dhcp_eth0="release nodns nontp nonis" # Only get an address

Note: dhcpcd and pump send the current hostname to the DHCP server by default so you don't need to specify this anymore.

3.d. ADSL with PPPoE/PPPoA

First we need to install the ADSL software.

Code Listing 4.1: Install the ppp package

# emerge net-dialup/ppp

Second, create the PPP net script and the net script for the ethernet interface to be used by PPP:

Code Listing 4.2: Creating the PPP and ethernet scripts

# ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0
# ln -s /etc/init.d/net.lo /etc/init.d/net.eth0

Be sure to set rc_depend_strict to "YES" in /etc/rc.conf.

Now we need to configure /etc/conf.d/net.

Code Listing 4.3: A basic PPPoE setup

config_eth0=null (Specify your ethernet interface)
link_ppp0="eth0" (Specify your ethernet interface)
holdoff 3
child-timeout 60
lcp-echo-interval 15
lcp-echo-failure 3
noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp"


You can also set your password in /etc/ppp/pap-secrets.

Code Listing 4.4: Sample /etc/ppp/pap-secrets

# The * is important
"username"  *  "password"

If you use PPPoE with a USB modem you'll need to emerge br2684ctl. Please read /usr/portage/net-dialup/speedtouch-usb/files/README for information on how to properly configure it.

Important: Please carefully read the section on ADSL and PPP in /usr/share/doc/netifrc-*/net.example.bz2. It contains many more detailed explanations of all the settings your particular PPP setup will likely need.

3.e. APIPA (Automatic Private IP Addressing)

APIPA tries to find a free address in the range by arping a random address in that range on the interface. If no reply is found then we assign that address to the interface.

This is only useful for LANs where there is no DHCP server and you don't connect directly to the internet and all other computers use APIPA.

For APIPA support, emerge net-misc/iputils or net-analyzer/arping.

Code Listing 5.1: APIPA configuration in /etc/conf.d/net

# Try DHCP first - if that fails then fallback to APIPA

# Just use APIPA

3.f. Bonding

For link bonding/trunking emerge net-misc/ifenslave.

Bonding is used to increase network bandwidth. If you have two network cards going to the same network, you can bond them together so your applications see just one interface but they really use both network cards.

First, clear the configuration of the participating interfaces:

Code Listing 6.1: Clearing interface configuration in /etc/conf.d/net


Next, define the bonding between the interfaces:

Code Listing 6.2: Define the bonding

slaves_bond0="eth0 eth1 eth2"

Remove the net.eth* services from the runlevels, create a net.bond0 one and add that one to the correct runlevel.

3.g. Bridging (802.1d support)

For bridging support emerge net-misc/bridge-utils.

Bridging is used to join networks together. For example, you may have a server that connects to the internet via an ADSL modem and a wireless access card to enable other computers to connect to the internet via the ADSL modem. You could create a bridge to join the two interfaces together.

Code Listing 7.1: Bridge configuration in /etc/conf.d/net

# Configure the bridge - "man brctl" for more details
brctl_br0="setfd 0
sethello 2
stp on"

# To add ports to bridge br0
bridge_br0="eth0 eth1"

# You need to configure the ports to null values so dhcp does not get started

# Finally give the bridge an address - you could use DHCP as well

# Depend on eth0 and eth1 as they may require extra configuration
rc_need_br0="net.eth0 net.eth1"

Important: For using some bridge setups, you may need to consult the variable name documentation.

3.h. MAC Address

If you need to, you can change the MAC address of your interfaces through the network configuration file too.

Code Listing 8.1: MAC Address change example

# To set the MAC address of the interface

# To randomize the last 3 bytes only

# To randomize between the same physical type of connection (e.g. fibre,
# copper, wireless) , all vendors

# To randomize between any physical type of connection (e.g. fibre, copper,
# wireless) , all vendors

# Full randomization - WARNING: some MAC addresses generated by this may
# NOT act as expected

3.i. Tunnelling

You don't need to emerge anything for tunnelling as the interface handler can do it for you.

Code Listing 9.1: Tunnelling configuration in /etc/conf.d/net

# For GRE tunnels
iptunnel_vpn0="mode gre remote key 0xffffffff ttl 255"

# For IPIP tunnels
iptunnel_vpn0="mode ipip remote ttl 255"

# To configure the interface
config_vpn0=" peer"

3.j. VLAN (802.1q support)

For VLAN support, make sure that sys-apps/iproute2 is installed and ensure that iproute2 is used as configuration module rather than ifconfig.

Virtual LAN is a group of network devices that behave as if they were connected to a single network segment - even though they may not be. VLAN members can only see members of the same VLAN even though they may share the same physical network.

To configure VLANs, first specify the VLAN numbers in /etc/conf.d/net like so:

Code Listing 10.1: Specifying VLAN numbers

vlans_eth0="1 2"

Next, configure the interface for each VLAN:

Code Listing 10.2: Interface configuration for each VLAN

config_eth0_1=" netmask"
routes_eth0_1="default via"

config_eth0_2=" netmask"
routes_eth0_2="default via"

VLAN-specific configurations are handled by vconfig like so:

Code Listing 10.3: Configuring the VLANs

vlan1_ingress="2:6 3:5"

Important: For using some VLAN setups, you may need to consult the variable name documentation.

4. Wireless Networking

4.a. Introduction

Wireless networking on Linux is usually pretty straightforward. There are two ways of configuring wifi: graphical clients, or the command line.

The easiest way is to use a graphical client once you've installed a desktop environment. Most graphical clients, such as wicd and NetworkManager, are pretty self-explanatory. They offer a handy point-and-click interface that gets you on a network in just a few seconds.

Note: wicd offers a command line utility in addition to the main graphical interface. You can get it by emerging wicd with the ncurses USE flag set. This wicd-curses utility is particularly useful for folks who don't use a gtk-based desktop environment, but still want an easy command line tool that doesn't require hand-editing configuration files.

However, if you don't want to use a graphical client, then you can configure wifi on the command line by editing a few configuration files. This takes a bit more time to setup, but it also requires the fewest packages to download and install. Since the graphical clients are mostly self-explanatory (with helpful screenshots at their homepages), we'll focus on the command line alternatives.

You can setup wireless networking on the command line by installing wireless-tools or wpa_supplicant. The important thing to remember is that you configure wireless networks on a global basis and not an interface basis.

wpa_supplicant is the best choice. For a list of supported drivers, read the wpa_supplicant site.

wireless-tools supports nearly all cards and drivers, but it cannot connect to WPA-only Access Points. If your networks only offer WEP encryption or are completely open, you may prefer the simplicity of wireless-tools.

Warning: The linux-wlan-ng driver is not supported by baselayout at this time. This is because linux-wlan-ng have its own setup and configuration which is completely different to everyone else's. The linux-wlan-ng developers are rumoured to be changing their setup over to wireless-tools, so when this happens you may use linux-wlan-ng with baselayout.

Some wireless cards are deactivated by default. To activate them, please consult your hardware documentation. Some of these cards can be unblocked using the rfkill application. If that is the case, use "rfkill list" to see the available cards and "rfkill unblock <index>" to activate the wireless functionality. If not, you might need to unblock the wireless card through a button, switch or special key combination on your laptop.

4.b. WPA Supplicant

WPA Supplicant is a package that allows you to connect to WPA enabled access points.

Code Listing 2.1: Install wpa_supplicant

# emerge net-wireless/wpa_supplicant

Important: You have to have CONFIG_PACKET enabled in your kernel for wpa_supplicant to work. Try running grep CONFIG_PACKET /usr/src/linux/.config to see if you have it enabled in your kernel.

Note: Depending on your USE flags, wpa_supplicant can install a graphical interface written in Qt4, which will integrate nicely with KDE. To get it, run echo "net-wireless/wpa_supplicant qt4" >> /etc/portage/package.use as root before emerging wpa_supplicant.

Now we have to configure /etc/conf.d/net to so that we prefer wpa_supplicant over wireless-tools (if both are installed, wireless-tools is the default).

Code Listing 2.2: configure /etc/conf.d/net for wpa_supplicant

# Prefer wpa_supplicant over wireless-tools

# It's important that we tell wpa_supplicant which driver we should
# be using as it's not very good at guessing yet

Note: If you're using the host-ap driver you will need to put the card in Managed mode before it can be used with wpa_supplicant correctly. You can use iwconfig_eth0="mode managed" to achieve this in /etc/conf.d/net.

That was simple, wasn't it? However, we still have to configure wpa_supplicant itself which is a bit more tricky depending on how secure the Access Points are that you are trying to connect to. The below example is taken and simplified from /usr/share/doc/wpa_supplicant-<version>/wpa_supplicant.conf.gz which ships with wpa_supplicant.

Code Listing 2.3: An example /etc/wpa_supplicant/wpa_supplicant.conf

# The below line not be changed otherwise we refuse to work

# Ensure that only root can read the WPA configuration

# Let wpa_supplicant take care of scanning and AP selection

# Simple case: WPA-PSK, PSK as an ASCII passphrase, allow all valid ciphers
  psk="very secret passphrase"
  # The higher the priority the sooner we are matched

# Same as previous, but request SSID-specific scanning (for APs that reject
# broadcast SSID)
  ssid="second ssid"
  psk="very secret passphrase"

# Only WPA-PSK is used. Any valid cipher combination is accepted
  pairwise=CCMP TKIP
  group=CCMP TKIP WEP104 WEP40

# Plaintext connection (no WPA, no IEEE 802.1X)

# Shared WEP key connection (no WPA, no IEEE 802.1X)
  # Keys in quotes are ASCII keys
  # Keys specified without quotes are hex keys

# Shared WEP key connection (no WPA, no IEEE 802.1X) using Shared Key
# IEEE 802.11 authentication

# IBSS/ad-hoc network with WPA-None/TKIP
  ssid="test adhoc"
  psk="secret passphrase"

4.c. Wireless Tools

Initial setup and Managed Mode

Wireless Tools provide a generic way to configure basic wireless interfaces up to the WEP security level. While WEP is a weak security method it's also the most prevalent.

Wireless Tools configuration is controlled by a few main variables. The sample configuration file below should describe all you need. One thing to bear in mind is that no configuration means "connect to the strongest unencrypted Access Point" - we will always try and connect you to something.

Code Listing 3.1: Install wireless-tools

# emerge net-wireless/wireless-tools

Note: Although you can store your wireless settings in /etc/conf.d/wireless this guide recommends you store them in /etc/conf.d/net.

Important: You will need to consult the variable name documentation.

Code Listing 3.2: sample iwconfig setup in /etc/conf.d/net

# Prefer iwconfig over wpa_supplicant

# Configure WEP keys for Access Points called ESSID1 and ESSID2
# You may configure up to 4 WEP keys, but only 1 can be active at
# any time so we supply a default index of [1] to set key [1] and then
# again afterwards to change the active key to [1]
# We do this incase you define other ESSID's to use WEP keys other than 1
# Prefixing the key with s: means it's an ASCII key, otherwise a HEX key
# enc open specified open security (most secure)
# enc restricted specified restricted security (least secure)
key_ESSID1="[1] s:yourkeyhere key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"

# The below only work when we scan for available Access Points

# Sometimes more than one Access Point is visible so we need to
# define a preferred order to connect in
preferred_aps="'ESSID1' 'ESSID2'"

Fine tune Access Point Selection

You can add some extra options to fine-tune your Access Point selection, but these are not normally required.

You can decide whether we only connect to preferred Access Points or not. By default if everything configured has failed and we can connect to an unencrypted Access Point then we will. This can be controlled by the associate_order variable. Here's a table of values and how they control this.

Value Description
any Default behaviour
preferredonly We will only connect to visible APs in the preferred list
forcepreferred We will forceably connect to APs in the preferred order if they are not found in a scan
forcepreferredonly Do not scan for APs - instead just try to connect to each one in order
forceany Same as forcepreferred + connect to any other available AP

Finally we have some blacklist_aps and unique_ap selection. blacklist_aps works in a similar way to preferred_aps. unique_ap is a yes or no value that says if a second wireless interface can connect to the same Access Point as the first interface.

Code Listing 3.3: blacklist_aps and unique_ap example

# Sometimes you never want to connect to certain access points
blacklist_aps="'ESSID3' 'ESSID4'"

# If you have more than one wireless card, you can say if you want
# to allow each card to associate with the same Access Point or not
# Values are "yes" and "no"
# Default is "yes"

Ad-Hoc and Master Modes

If you want to set yourself up as an Ad-Hoc node if you fail to connect to any Access Point in managed mode, you can do that too.

Code Listing 3.4: fallback to ad-hoc mode

adhoc_essid_eth0="This Adhoc Node"

What about connecting to Ad-Hoc networks or running in Master mode to become an Access Point? Here's a configuration just for that! You may need to specify WEP keys as shown above.

Code Listing 3.5: sample ad-hoc/master configuration

# Set the mode - can be managed (default), ad-hoc or master
# Not all drivers support all modes

# Set the ESSID of the interface
# In managed mode, this forces the interface to try and connect to the
# specified ESSID and nothing else
essid_eth0="This Adhoc Node"

# We use channel 3 if you don't specify one

Important: The below is taken verbatim from the BSD wavelan documentation found at the NetBSD documentation. There are 14 channels possible; We are told that channels 1-11 are legal for North America, channels 1-13 for most of Europe, channels 10-13 for France, and only channel 14 for Japan. If in doubt, please refer to the documentation that came with your card or access point. Make sure that the channel you select is the same channel your access point (or the other card in an ad-hoc network) is on. The default for cards sold in North America and most of Europe is 3; the default for cards sold in France is 11, and the default for cards sold in Japan is 14.

Troubleshooting Wireless Tools

There are some more variables you can use to help get your wireless up and running due to driver or environment problems. Here's a table of other things you can try.

Variable Default Value Description
iwconfig_eth0 See the iwconfig man page for details on what to send iwconfig
iwpriv_eth0 See the iwpriv man page for details on what to send iwpriv
sleep_scan_eth0 0 The number of seconds to sleep before attempting to scan. This is needed when the driver/firmware needs more time to active before it can be used.
sleep_associate_eth0 5 The number of seconds to wait for the interface to associate with the Access Point before moving onto the next one
associate_test_eth0 MAC Some drivers do not reset the MAC address associated with an invalid one when they lose or attempt association. Some drivers do not reset the quality level when they lose or attempt association. Valid settings are MAC, quality and all.
scan_mode_eth0 Some drivers have to scan in ad-hoc mode, so if scanning fails try setting ad-hoc here
iwpriv_scan_pre_eth0 Sends some iwpriv commands to the interface before scanning. See the iwpriv man page for more details.
iwpriv_scan_post_eth0 Sends some iwpriv commands to the interface after scanning. See the iwpriv man page for more details.

4.d. Defining network configuration per ESSID

Sometimes, you need a static IP when you connect to ESSID1 and you need DHCP when you connect to ESSID2. In fact, most module variables can be defined per ESSID. Here's how we do this.

Note: These work if you're using WPA Supplicant or Wireless Tools.

Important: You will need to consult the variable name documentation.

Code Listing 4.1: override network settings per ESSID

config_ESSID1=" brd"
routes_ESSID1="default via"

fallback_route_ESSID2="default via"

# We can define nameservers and other things too
# NOTE: DHCP will override these unless it's told not to
dns_search_domains_ESSID1="search.this.domain search.that.domain"

# You override by the MAC address of the Access Point
# This handy if you goto different locations that have the same ESSID
dhcpcd_001122334455="-t 10"

5. Adding Functionality

5.a. Standard function hooks

Four functions can be defined in /etc/conf.d/net which will be called surrounding the start/stop operations. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preup() and predown() functions should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preup() returns a non-zero value, then interface configuration will be aborted. If predown() returns a non-zero value, then the interface will not be allowed to continue deconfiguration.

The return values for the postup() and postdown() functions are ignored since there's nothing to do if they indicate failure.

${IFACE} is set to the interface being brought up/down. ${IFVAR} is ${IFACE} converted to variable name bash allows.

Code Listing 1.1: pre/post up/down function examples in /etc/conf.d/net

preup() {
  # Test for link on the interface prior to bringing it up.  This
  # only works on some network adapters and requires the ethtool
  # package to be installed.
  if ethtool ${IFACE} | grep -q 'Link detected: no'; then
    ewarn "No link on ${IFACE}, aborting configuration"
    return 1

  # Remember to return 0 on success
  return 0

predown() {
  # The default in the script is to test for NFS root and disallow
  # downing interfaces in that case.  Note that if you specify a
  # predown() function you will override that logic.  Here it is, in
  # case you still want it...
  if is_net_fs /; then
    eerror "root filesystem is network mounted -- can't stop ${IFACE}"
    return 1

  # Remember to return 0 on success
  return 0

postup() {
  # This function could be used, for example, to register with a
  # dynamic DNS service.  Another possibility would be to
  # send/receive mail once the interface is brought up.
       return 0

postdown() {
  # This function is mostly here for completeness... I haven't
  # thought of anything nifty to do with it yet ;-)
  return 0

Note: For more information on writing your own functions, please read /usr/share/doc/netifrc-*/net.example.bz2.

5.b. Wireless Tools function hooks

Note: This will not work with WPA Supplicant - but the ${ESSID} and ${ESSIDVAR} variables are available in the postup() function.

Two functions can be defined in /etc/conf.d/net which will be called surrounding the associate function. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preassociate() function should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preassociate() returns a non-zero value, then interface configuration will be aborted.

The return value for the postassociate() function is ignored since there's nothing to do if it indicates failure.

${ESSID} is set to the exact ESSID of the AP you're connecting to. ${ESSIDVAR} is ${ESSID} converted to a variable name bash allows.

Code Listing 2.1: pre/post association functions in /etc/conf.d/net

preassociate() {
  # The below adds two configuration variables leap_user_ESSID
  # and leap_pass_ESSID. When they are both configured for the ESSID
  # being connected to then we run the CISCO LEAP script

  local user pass
  eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
  eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"

  if [[ -n ${user} && -n ${pass} ]]; then
    if [[ ! -x /opt/cisco/bin/leapscript ]]; then
      eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
      return 1
    einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
    if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
      ewarn "Login Failed for ${user}"
      return 1

  return 0

postassociate() {
  # This function is mostly here for completeness... I haven't
  # thought of anything nifty to do with it yet ;-)

  return 0

Note: ${ESSID} and ${ESSIDVAR} are unavailable in predown() and postdown() functions.

Note: For more information on writing your own functions, please read /usr/share/doc/netifrc-*/net.example.bz2.

6. Network Management

6.a. Network Management

If you and your computer are always on the move, you may not always have an ethernet cable or plugged in or an access point available. Also, you may want networking to automatically work when an ethernet cable is plugged in or an access point is found.

Here you can find some tools that help you manage this.

Note: This document only talks about ifplugd, but there are alternatives such as netplug. netplug is a lightweight alternative to ifplugd, but it relies on your kernel network drivers working correctly, and many drivers do not.

6.b. ifplugd

ifplugd is a daemon that starts and stops interfaces when an ethernet cable is inserted or removed. It can also manage detecting association to Access Points or when new ones come in range.

Code Listing 2.1: Installing ifplugd

# emerge sys-apps/ifplugd

Configuration for ifplugd is fairly straightforward too. The configuration file is held in /etc/conf.d/net. Run man ifplugd for details on the available variables. Also, see /usr/share/doc/netifrc-*/net.example.bz2 for more examples.

Code Listing 2.2: Sample ifplug configuration

(Replace eth0 with the interface to be monitored)

(To monitor a wireless interface)

In addition to managing multiple network connections, you may want to add a tool that makes it easy to work with multiple DNS servers and configurations. This is very handy when you receive your IP address via DHCP. Simply emerge openresolv.

Code Listing 2.3: Installing openresolv

# emerge openresolv

See man resolvconf to learn more about its features.


Page updated April 12, 2014

Summary: This is the Gentoo Networkless Handbook, an effort to centralise Gentoo/Linux information. This handbook contains the installation instructions for a networkless installation on PPC systems and parts about working with Gentoo and Portage.

Sven Vermeulen

Grant Goodyear

Roy Marples

Daniel Robbins

Chris Houser

Jerry Alexandratos

Seemant Kulleen
Gentoo x86 Developer

Tavis Ormandy
Gentoo Alpha Developer

Jason Huebel
Gentoo AMD64 Developer

Guy Martin
Gentoo HPPA developer

Pieter Van den Abeele
Gentoo PPC developer

Joe Kallar
Gentoo SPARC developer

John P. Davis

Pierre-Henri Jondot

Eric Stockbridge

Rajiv Manglani

Jungmin Seo

Stoyan Zhekov

Jared Hudson

Colin Morey

Jorge Paulo

Carl Anderson

Jon Portnoy

Zack Gilburd

Jack Morgan

Benny Chuang


Joshua Kinard

Tobias Scherbaum

Lars Weiler

Jochen Maes

Xavier Neys

Joseph Jezak

Joshua Saddler

Gerald J. Normandin Jr.

Donnie Berkholz

Ken Nowack

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.