Gentoo Logo

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

Gentoo Linux/x86 Handbook

Content:

  • 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. Choosing the Right Installation Medium
      You can install Gentoo in many ways. This chapter explains how to install Gentoo using one of our LiveCDs.
    3. Configuring your Network
      If you want to install Gentoo using the Internet, you need to set up networking.
    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
      Gentoo installs work through so-called stage-files. In this chapter we describe how you extract a stage-file and configure Portage.
    6. Installing the Gentoo Base System
      Independent of what stage you chose, the eventual result is that you have a Gentoo base system at your disposal. This chapter describes how to progress to that stadium.
    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 choices. In this chapter we help you choose and install some important tools.
    10. Configuring the Bootloader
      Several bootloaders exist for the x86 architecture. Each one of them has its own way of configuration. We 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 leave the installation to reboot into a brand new Gentoo system.
    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.
    6. The Ebuild Application
      In "The Ebuild Application" you are informed about the steps Portage takes while installing software and how you can do this yourself using the ebuild application.

A. Installing Gentoo

1. About the Gentoo Linux Installation

1.a. Introduction

Welcome!

First of all, welcome to Gentoo. You are about to enter the world of choices and performance. Gentoo is all about choices. 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 metadistribution 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 textfiles. In other words, openness everywhere.

It is very important that you understand that choices are what makes Gentoo run. We try not to force you onto anything you don't like. If you feel like we do, please bugreport 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 ready to install Gentoo (this can be optional in certain situations)
  • 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 LiveCDs (installation CDs), from an existing distribution, from a bootable CD (such as Knoppix), from a netbooted environment, from a rescue floppy, etc. This document covers the installation using one of our LiveCDs or, in certain cases, NetBooting. 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.

You also have several possibilities: you can compile your entire system from scratch or install prebuilt packages to have your Gentoo environment up and running in no time. And of course you have intermediate solutions in which you don't compile everything but start from a semi-ready system.

Troubles?

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 bugtracking system and check if the bug is known. If not, please create a bugreport 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 irc.freenode.net. 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 irc.freenode.net. Yes, several of us are freaks who sit on IRC :-)

1.b. Prebuilt or Compile-All?

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 KDE, 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 will have to install a Portage snapshot instead of synchronising Portage with the latest available tree if you want to use the GRP installation method.

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 x86 architecture (x86, i686, pentium3, pentium4, athlon-xp) Note: The x86 and i686 GRP packages (for example packages-x86-2004.2.iso) are available on our mirrors, while pentium3, pentium4, athlon-xp are only available via bittorrent.
  • The amd64 architecture (amd64)
  • The sparc architecture (sparc32, sparc64)
  • The ppc architecture (G3, G4, G5)
  • The alpha architecture (alpha, alphaev5, alphaev56, alphaev6)
  • The mips architecture
  • The hppa architecture

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 Choosing the Right Installation Medium.

2. Choosing the Right Installation Medium

2.a. Hardware Requirements

Introduction

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

The x86 architecture

  • You need at least 1 Gb of free disk space
  • If you do not use prebuilt packages, you need at least 300 Mb of memory (RAM + swap)
  • You need a 486+ processor and at least 64 megabytes of memory

2.b. Make your Choice

Introduction

Still interested in trying out Gentoo? Well, then it is now time to choose the installation medium you want to use. Yes, you have the choice, no, they are not all equal, and yes, the result is always the same: a Gentoo base system.

The installation media we will describe are:

  • Gentoo's Minimal LiveCD
  • Gentoo's Universal LiveCD

Every single media has its advantages and disadvantages. We will list the pros and cons of every medium so you have all the information to make a justified decision. But before we continue, let's explain our three-stage installation.

The Three Stages

Gentoo Linux can be installed using one of three stage tarball files. The one you choose depends on how much of the system you want to compile yourself. The stage1 tarball is used when you want to bootstrap and build the entire system from scratch. The stage2 tarball is used for building the entire system from a bootstrapped "semi-compiled" state. The stage3 tarball already contains a basic Gentoo Linux system that has been built for you. As we will explain later, you can also install Gentoo without compiling anything (except your kernel and some optional packages). If you want this, you have to use a stage3 tarball.

Now what stage do you have to choose?

Starting from a stage1 allows you to have total control over the optimization settings and optional build-time functionality that is initially enabled on your system. This makes stage1 installs good for power users who know what they are doing. It is also a great installation method for those who would like to know more about the inner workings of Gentoo Linux.

A stage1 installation can only be performed when you have a working Internet connection.

Stage1 Pros and Cons
+ Allows you to have total control over the optimization settings and optional build-time functionality that is initially enabled on your system
+ Suitable for powerusers that know what they are doing
+ Allows you to learn more about the inner workings of Gentoo
- Takes a long time to finish the installation
- If you don't intend to tweak the settings, it is probably a waste of time
- Not suitable for networkless installations

Stage2 installs allow you to skip the bootstrap process and doing this is fine if you are happy with the optimization settings that we chose for your particular stage2 tarball.

A stage2 installation can only be performed when you have a working Internet connection.

Stage2 Pros and Cons
+ You don't need to bootstrap
+ Faster than starting with stage1
+ You can still tweak your settings
- You cannot tweak as much as with a stage1
- It's not the fastest way to install Gentoo
- You have to accept the optimizations we chose for the bootstrap
- Not suitable for networkless installations

Choosing to go with a stage3 allows for the fastest install of Gentoo Linux, but also means that your base system will have the optimization settings that we chose for you (which to be honest, are good settings and were carefully chosen to enhance performance while maintaining stability). stage3 is also required if you want to install Gentoo using prebuilt packages or without a network connection.

Stage3 Pros and Cons
+ Fastest way to get a Gentoo base system
+ Suitable for networkless installations
- You cannot tweak the base system - it's built already
- You cannot brag about having used stage1 or stage2

You might be interested to know that, if you decide to use different optimization settings after having installed Gentoo, you will be able to recompile your entire system with the new optimization settings.

Now take a look at the available installation media.

Gentoo LiveCDs

The Gentoo LiveCDs are bootable CDs which contain a self-sustained Gentoo environment. They allow you to boot Linux from the CD. During the boot process your hardware is detected and the appropriate drivers are loaded. They are maintained by Gentoo developers.

All LiveCDs allow you to boot, set up networking, initialize your partitions and start installing Gentoo from the Internet. However, some LiveCDs also contain all necessary source code so you are able to install Gentoo without a working network configuration.

Now what do these LiveCDs contain?

Gentoo's Minimal LiveCD

This is a small, no-nonsense, bootable CD which sole purpose is to boot the system, prepare the networking and continue with the Gentoo installation. It does not contain any stages (or, in some cases, a single stage1 file), source code or precompiled packages. For example the x86 variant of this LiveCD can be found in the universal subdirectory and is called install-x86-minimal-2004.2.iso.

Minimal LiveCD Pros and Cons
+ Smallest download
+ Suitable for a complete architecture
+ You can do a stage1, stage2 or stage3 by getting the stage tarball off the net
- Contains no stages, no Portage snapshot, no GRP packages and therefore not suitable for networkless installation

Gentoo's Universal LiveCD

Gentoo's Universal LiveCD is a bootable CD suitable to install Gentoo without networking. It contains a stage1 and several stage3 tarballs (optimized for the individual subarchitectures). For example the x86 variant of this CD is called install-x86-universal-2004.2.iso and can be found in the universal subdirectory.

If you take a closer look into releases/x86/2004.2 you will see that we also provide Gentoo Package CDs (in the packagecd/) directory. This CD (which isn't bootable) only contains precompiled packages and can be used to install software after a succesfull Gentoo Installation. To install Gentoo, you only need the Universal LiveCD, but if you want OpenOffice.org, Mozilla, KDE, GNOME etc. without having to compile every single one of them, you need the Packages CD too. For example the i686 (a subarchitecture of x86) Packages CD is called packages-i686-2004.2.iso and can be found in the appropriate subdirectory (i686).

You only need the Packages CD if you want to perform a stage3 with GRP installation.

Universal LiveCD with Packages CD Pros and Cons
+ Packages CD is optimized to your subarchitecture
+ Packages CD provides precompiled packages for fast Gentoo installations
+ Contains everything you need. You can even install without a network connection.
- Huge download

2.c. Download, Burn and Boot a Gentoo LiveCD

Downloading and Burning the LiveCDs

You have chosen to use a Gentoo LiveCD. We'll first start by downloading and burning the chosen LiveCD. We previously discussed the several available LiveCDs, but where can you find them?

You can download any of the LiveCDs (and, if you want to, a Packages CD as well) from one of our mirrors. The LiveCDs are located in the releases/x86/2004.2/livecd directory; the Packages CDs are located in the releases/x86/2004.2/packagecd directory.

Inside that directory you'll find so-called ISO-files. Those are full CD images which you can write on a CD-R.

In case you wonder if your downloaded file is corrupted or not, you can check its MD5 checksum and compare it with the MD5 checksum we provide (such as install-x86-minimal-2004.2.iso.md5). You can check the MD5 checksum with the md5sum tool under Linux/Unix or md5sum for Windows.

Another way to check the validity of the downloaded file is to use GnuPG to verify the cryptographic signature that we provide (the file ending with .asc). Download the signature file and obtain the public key:

Code Listing 3.1: Obtaining the public key

$ gpg --keyserver pgp.mit.edu --recv-keys 17072058

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 (replace /dev/hdc with your CD-RW drive's device path) followed by the path to the ISO file :)
  • With K3B, select Tools > CD > Burn Image. Then you can locate your ISO file within the 'Image to Burn' area. Finally click Start.

Booting the LiveCD(s)

Important: Read this whole subsection before continuing, as you will probably not have the opportunity to read it before doing things later.

Once you have burned your installation CDs, it is time to boot them. Remove all CDs from your CD drives, reboot your system and enter the BIOS. This is usually done by hitting DEL, F1 or ESC, depending on your BIOS. Inside the BIOS, change the boot order so that the CD-ROM is tried before the hard disk. This is often found under "CMOS Setup". If you don't do this, your system will just reboot from the hard disk, ignoring the CD-ROM.

Now place the installation CD in the CD-ROM drive (duh) and reboot. You should see a fancy boot screen with the Gentoo Linux logo on it. At this screen, you can hit Enter to begin the boot process with the default boot options, or boot the LiveCD with custom boot options by specifying a kernel followed by boot options and then hitting Enter.

Specifying a kernel? Yes, we provide several kernels on our LiveCDs. The default one is gentoo. Other kernels are smp, which activates support for multi-cpu systems and the -nofb variants which disable framebuffer.

It is recommended that you select the gentoo or gentoo-nofb kernels if you want to install Gentoo Linux with a 2.4 kernel or smp or smp-nofb if you want to install Gentoo Linux with a 2.6 kernel. Otherwise you might run into compatibility issues.

Below you'll find a short overview on the available kernels:

Kernel Description
gentoo Default 2.4 kernel with framebuffer support
smp 2.6 Kernel with support for multiple CPUs
gentoo-nofb Same as gentoo but without framebuffer support
smp-nofb Same as smp but without framebuffer support
memtest86 Test your local RAM for errors

You can also provide kernel options. They represent optional settings you can (de)activate at will. The following list is the same as the one you receive when you press F2 at the bootscreen.

Code Listing 3.3: Options available to pass to your kernel of choice

- agpgart       loads agpgart (use if you have graphic problems,lockups)
- doscsi        scan for scsi devices (breaks some ethernet cards)
- nodetect      causes hwsetup/kudzu and hotplug not to run
- dofirewire    modprobes firewire modules in initrd (for firewire cdroms,etc)
- nousb         disables usb module load from initrd, disables hotplug
- nodhcp        dhcp does not automatically start if nic detected
- doataraid     loads ide raid modules from initrd
- dopcmcia      starts pcmcia service
- noapm         disables apm module load
- noraid        disables loading of evms modules
- nohotplug     disables loading hotplug service
- ide=nodma     Force disabling of dma for malfunctioning ide devices
- docache       Cache the entire runtime portion of cd in ram, allows you
                to umount /mnt/cdrom to mount another cdrom.
- dokeymap      enable keymap selection for non-us keyboard layouts
- noapic        disable apic (try if having hardware problems ,nics,scsi,etc)
- hdx=stroke    (smp/smp-nofb kernel only) Allows you to partition the whole
                harddrive even if your BIOS can't handle large harddrive

Now boot your CD, select a kernel (if you are not happy with the default gentoo kernel) and boot options. As an example, we show you how to boot the gentoo kernel, with dopcmcia as kernel parameters:

Code Listing 3.4: Booting a LiveCD

boot: gentoo dopcmcia

You will then be greeted with another boot screen and progress bar. Once the boot process completes, you will be automatically logged in to the "Live" Gentoo Linux as "root", the super user. You should have a root ("#") prompt on the current console and 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.

If you are installing Gentoo on a system with a non-US keyboard, make sure you boot the LiveCD with the dokeymap boot option.

Now continue with Extra Hardware Configuration.

Extra Hardware Configuration

When the Live 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 (the SPARC LiveCDs don't even do autodetection), 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.5: Loading kernel modules

# modprobe 8139too

Optional: Tweaking Hard Disk Performance

If you are an advanced user, you might want to tweak the IDE hard disk performance using hdparm. With the -tT options you can test the performance of your disk (execute it several times to get a more precise impression):

Code Listing 3.6: Testing disk performance

# hdparm -tT /dev/hda

To tweak, you can use any of the following examples (or experiment yourself) which use /dev/hda as disk (substitute with your disk):

Code Listing 3.7: Tweaking hard disk performance

Activate DMA:                                       # hdparm -d 1 /dev/hda
Activate DMA + Safe Performance-enhancing Options:  # hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda

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 (either from-CD or online) 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 and log in.

If you want to view the documentation on the CD you can immediately run links2 to read it:

Code Listing 3.11: Viewing the on-CD documentation

# links2 /mnt/cdrom/docs/html/index.html

However, it is preferred that you use the online Gentoo Handbook as it will be more recent than the one provided on the CD. You can view it using links2 as well, but only after having completed the Configuring your Network chapter (otherwise you won't be able to go on the Internet to view the document):

Code Listing 3.12: Viewing the Online Documentation

# links2 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml

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.13: Starting the SSH daemon

# /etc/init.d/sshd start

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. You can do without, but...

Who can do without?

Depending on the medium you chose to install Gentoo from, you may or may not continue without networking (and Internet). No, we are not playing with your mind =)

Generally you will need to set up networking (and Internet). However, Gentoo also provides the possibility to install without a network connection. This exception is only possible with the Gentoo Universal LiveCDs.

Why do I need networking?

Installing Gentoo from the Internet results in a fully updated Gentoo Installation. You'll have an installation based on the most recent Portage tree (which is the collection of packages we provide together with the tools to manage your software). This is also the reason why a network-installation is preferred. However, some people cannot or do not want to install Gentoo on a system with a running Internet connection.

If you are in this situation you will need to use a Gentoo Universal LiveCD. This LiveCD includes the source code, a snapshot of the Portage tree and the tools to install a Gentoo base-system and beyond. This method comes at a price: You won't have the very latest software, although differences will be minimal.

If you want to follow this networkless installation you have to use such a Universal LiveCD, skip the rest of this chapter and continue with Preparing the Disks. Otherwise, continue with the networking configuration sections below.

Optional: Configure Proxy

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 proxy.gentoo.org and the port is 8080.

Code Listing 1.1: Defining proxy servers

(If the proxy filters HTTP traffic)
# export http_proxy="http://proxy.gentoo.org:8080"
(If the proxy filters FTP traffic)
# export ftp_proxy="ftp://proxy.gentoo.org:8080"
(If the proxy filters RSYNC traffic)
# export RSYNC_PROXY="proxy.gentoo.org:8080"

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

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

http://username:password@server

For instance, for HTTP proxying with our previous proxy server and a username of "john" with a password of "f00b_r" one would use:

Code Listing 1.3: Authenticated Proxy

# export http_proxy="http://john:f00b_r@proxy.gentoo.org:8080"

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 LiveCD 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:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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 

Testing the Network

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

Code Listing 2.2: Further network testing

# ping -c 3 www.yahoo.com

Are you able to use your network? If so, you can skip the rest of this section and continue with Preparing the Disks. If not, bad luck, you'll have to work on it a bit more.

3.c. Automatic Network Configuration

If the network doesn't work immediately, some installation media allow you to use net-setup (for regular networks) or adsl-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 RP-PPPoE

Assuming you need PPPoE to connect to the internet, the LiveCD (any version) has made things easy for you by including rp-pppoe. Use the provided adsl-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 rp-pppoe

# adsl-setup
# adsl-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

If you need PPTP support, you can use pptpclient which is provided by our LiveCDs. 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 Live 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 adsl-setup failed, then it is possible that your networkcard 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 adsl-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: Not all LiveCDs have the iwconfig command. If yours doesn't, you can still get the extensions working 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 instead of eth0.

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 above fails, you will have to configure your network manually. Have no fear, it is far from difficult. But we are going to explain a certain amount of networking to you as you will need it to be able to configure your network to your satisfaction. When you're done 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):   192.168.0.2
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. all hosts that you are able to reach must have unique IP addresses). To be able to make a distinction between hosts inside a network, and hosts 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, 192.168.0.14 is still part of our example network, but 192.168.1.2 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 192.168.0.1).

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 dev.gentoo.org) to an IP address (such as 64.5.62.82). 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 192.168.0.2
Netmask 255.255.255.0
Broadcast 192.168.0.255
Gateway 192.168.0.1
Nameserver(s) 195.130.130.5, 195.130.130.133

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 IDE drive in a Linux system, namely /dev/hda. If your system uses SCSI or SATA drives, then your first hard drive would be /dev/sda.

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.

Partitions

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 x86 systems, these are called partitions.

Partitions are divided in three types: primary, extended and logical.

A primary partition is a partition which has its information stored in the MBR (master boot record). As an MBR is very small (512 bytes) only four primary partitions can be defined (for instance, /dev/hda1 to /dev/hda4).

An extended partition is a special primary partition (meaning the extended partition must be one of the four possible primary partitions) which contains more partitions. Such a partition didn't exist originally, but as four partitions were too few, it was brought to life to extend the formatting scheme without losing backward compatibility.

A logical partition is a partition inside the extended partition. Their definitions aren't placed inside the MBR, but are declared inside the extended partition.

Advanced Storage

The x86 LiveCDs provide support for EVMS and LVM2. EVMS and LVM2 increase the flexibility offered by your partitioning setup. During the installation instructions, we will focus on "regular" partitions, but it is still good to know EVMS and LVM2 are supported as well.

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:

Partition Filesystem Size Description
/dev/hda1 ext2 32M Boot partition
/dev/hda2 (swap) 512M Swap partition
/dev/hda3 ext3 Rest of the disk Root partition

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 partitioning your disk by reading Using fdisk 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 mails are stored inside /var. A good choice of filesystem will then maximise your performance. Gameservers will have a separate /opt as most gaming servers are installed there. The reason is similar for /home: security and backups.

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.

As an example partitioning, we show you one for a 20Gb disk, used as a demonstration laptop (containing webserver, mailserver, gnome, ...):

Code Listing 2.1: Filesystem usage example

Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/hda5     ext3    509M  132M  351M  28% /
/dev/hda2     ext3    5.0G  3.0G  1.8G  63% /home
/dev/hda7     ext3    7.9G  6.2G  1.3G  83% /usr
/dev/hda8     ext3   1011M  483M  477M  51% /opt
/dev/hda9     ext3    2.0G  607M  1.3G  32% /var
/dev/hda1     ext2     51M   17M   31M  36% /boot
/dev/hda6     swap    516M   12M  504M   2% <not mounted>
(Unpartitioned space for future usage: 2 Gb)

/usr is rather full (83% used) here, but once all software is installed, /usr doesn't tend to grow that much. For /var, people might think the assigned space is too much. However, Gentoo compiles all programs inside /var/tmp/portage, so you should have /var with at least 1G free if you don't want to compile big programs and at least 3G free if compiling KDE or OpenOffice.org is no big deal for you.

4.c. Using fdisk to Partition your Disk

The following parts explain how to create the example partition layout described previously, namely:

Partition Description
/dev/hda1 Boot partition
/dev/hda2 Swap partition
/dev/hda3 Root partition

Change your partition layout according to your own preference.

Viewing the Current Partition Layout

fdisk is a popular and powerful tool to split your disk into partitions. Fire up fdisk on your disk (in our example, we use /dev/hda):

Code Listing 3.1: Starting fdisk

# fdisk /dev/hda

Once in fdisk, you'll be greeted with a prompt that looks like this:

Code Listing 3.2: fdisk prompt

Command (m for help): 

Type p to display your disk's current partition configuration:

Code Listing 3.3: An example partition configuration

Command (m for help): p

Disk /dev/hda: 240 heads, 63 sectors, 2184 cylinders
Units = cylinders of 15120 * 512 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1             1        14    105808+  83  Linux
/dev/hda2            15        49    264600   82  Linux swap
/dev/hda3            50        70    158760   83  Linux
/dev/hda4            71      2184  15981840    5  Extended
/dev/hda5            71       209   1050808+  83  Linux
/dev/hda6           210       348   1050808+  83  Linux
/dev/hda7           349       626   2101648+  83  Linux
/dev/hda8           627       904   2101648+  83  Linux
/dev/hda9           905      2184   9676768+  83  Linux

Command (m for help): 

This particular disk is configured to house seven Linux filesystems (each with a corresponding partition listed as "Linux") as well as a swap partition (listed as "Linux swap").

Removing all Partitions

We will first remove all existing partitions from the disk. Type d to delete a partition. For instance, to delete an existing /dev/hda1:

Code Listing 3.4: Deleting a partition

Command (m for help): d
Partition number (1-4): 1

The partition has been scheduled for deletion. It will no longer show up if you type p, but it will not be erased until your changes have been saved. If you made a mistake and want to abort without saving your changes, type q immediately and hit enter and your partition will not be deleted.

Now, assuming that you do indeed want to wipe out all the partitions on your system, repeatedly type p to print out a partition listing and then type d and the number of the partition to delete it. Eventually, you'll end up with a partition table with nothing in it:

Code Listing 3.5: An empty partition table

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System

Command (m for help):

Now that the in-memory partition table is empty, we're ready to create the partitions. We will use a default partitioning scheme as discussed previously. Of course, don't follow these instructions to the letter if you don't want the same partitioning scheme!

Creating the Boot Partition

We first create a small boot partition. Type n to create a new partition, then p to select a primary partition, followed by 1 to select the first primary partition. When prompted for the first cylinder, hit enter. When prompted for the last cylinder, type +32M to create a partition 32 Mbyte in size:

Code Listing 3.6: Creating the boot partition

Command (m for help): n
Command action
  e   extended
  p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-3876, default 1): (Hit Enter)
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-3876, default 3876): +32M

Now, when you type p, you should see the following partition printout:

Code Listing 3.7: Created boot partition

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1          1        14    105808+  83  Linux

We need to make this partition bootable. Type a to toggle the bootable flag on a partition and select 1. If you press p again, you will notice that an * is placed in the "Boot" column.

Creating the Swap Partition

Let's now create the swap partition. To do this, type n to create a new partition, then p to tell fdisk that you want a primary partition. Then type 2 to create the second primary partition, /dev/hda2 in our case. When prompted for the first cylinder, hit enter. When prompted for the last cylinder, type +512M to create a partition 512MB in size. After you've done this, type t to set the partition type, 2 to select the partition you just created and then type in 82 to set the partition type to "Linux Swap". After completing these steps, typing p should display a partition table that looks similar to this:

Code Listing 3.8: Partition listing after creating a swap partition

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1 *        1        14    105808+  83  Linux
/dev/hda2         15        81    506520   82  Linux swap

Creating the Root Partition

Finally, let's create the root partition. To do this, type n to create a new partition, then p to tell fdisk that you want a primary partition. Then type 3 to create the third primary partition, /dev/hda3 in our case. When prompted for the first cylinder, hit enter. When prompted for the last cylinder, hit enter to create a partition that takes up the rest of the remaining space on your disk. After completing these steps, typing p should display a partition table that looks similar to this:

Code Listing 3.9: Partition listing after creating the root partition

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1 *        1        14    105808+  83  Linux
/dev/hda2         15        81    506520   82  Linux swap
/dev/hda3         82      3876  28690200   83  Linux

Saving the Partition Layout

To save the partition layout and exit fdisk, type w.

Code Listing 3.10: Save and exit fdisk

Command (m for help): w

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

4.d. Creating Filesystems

Introduction

Now that your partitions are created, it is time to place a filesystem on them. If you don't care about what filesystem to choose and are happy with what we use as default in this handbook, continue with Applying a Filesystem to a Partition. Otherwise read on to learn about the available filesystems...

Filesystems?

The Linux kernel supports various filesystems. We'll explain ext2, ext3, ReiserFS, XFS and JFS as these are the most commonly used filesystems on Linux systems.

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. ext3 is a very good and reliable filesystem. It has an additional hashed b-tree indexing option that enables high performance in almost all situations. In short, ext3 is an excellent filesystem.

ReiserFS is a B*-tree based filesystem that has very good overall performance and greatly outperforms both ext2 and ext3 when dealing with small files (files less than 4k), often by a factor of 10x-15x. ReiserFS also scales extremely well and has metadata journaling. As of kernel 2.4.18+, ReiserFS is solid and usable as both general-purpose filesystem and for extreme cases such as the creation of large filesystems, the use of many small files, very large files and directories containing tens of thousands of files.

XFS is a filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. We only recommend using this filesystem on Linux systems with high-end SCSI and/or fibre channel storage and an uninterruptible power supply. Because XFS aggressively caches in-transit data in RAM, improperly designed programs (those that don't take proper precautions when writing files to disk and there are quite a few of them) can lose a good deal of data if the system goes down unexpectedly.

JFS is IBM's high-performance journaling filesystem. It has recently become production-ready and there hasn't been a sufficient track record to comment positively nor negatively on its general stability at this point.

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
jfs mkfs.jfs

For instance, to have the boot partition (/dev/hda1 in our example) in ext2 and the root partition (/dev/hda3 in our example) in ext3 (as in our example), you would use:

Code Listing 4.1: Applying a filesystem on a partition

# mke2fs /dev/hda1
# mke2fs -j /dev/hda3

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

Activating the Swap Partition

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

Code Listing 4.2: Creating a Swap signature

# mkswap /dev/hda2

To activate the swap partition, use swapon:

Code Listing 4.3: Activating the swap partition

# swapon /dev/hda2

Create and activate the swap now.

4.e. Mounting

Now that your partitions are initialized and are housing a filesystem, it is time to mount those partitions. Use the mount command. Don't forget to create the necessary mount directories for every partition you created. As an example we mount the root and boot partition:

Code Listing 5.1: Mounting partitions

# mount /dev/hda3 /mnt/gentoo
# mkdir /mnt/gentoo/boot
# mount /dev/hda1 /mnt/gentoo/boot

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

We will also have to mount the proc filesystem (a virtual interface with the kernel) on /proc. But first we will need to place our files on the partitions.

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
Sun Apr 25 16:21:18 CEST 2004

If the date/time displayed is wrong, update it using the date MMDDhhmmYYYY syntax (Month, Day, hour, minute and Year). For instance, to set the date to April 25th, 16:21 in the year 2004:

Code Listing 1.2: Setting the date/time

# date 042516212004

Making your Choice

The next step you need to perform is to install the stage tarball of your choice onto your system. You have the option of downloading the required tarball from the Internet or, if you are booted from one of the Gentoo Universal LiveCDs, copy it over from the CD itself. If you have a Universal CD and the stage you want to use is on the CD, downloading it from the Internet is just a waste of bandwidth as the stage files are the same.

5.b. Default: Using a Stage from the Internet

Downloading the Stage Tarball

Go to the Gentoo mountpoint at which you mounted your filesystems (most likely /mnt/gentoo):

Code Listing 2.1: Going to the Gentoo mountpoint

# cd /mnt/gentoo

Depending on your installation medium, you have a couple of tools available to download a stage. If you have links2 available, then you can immediately surf to the Gentoo mirrorlist and choose a mirror close to you. If you don't have links2 available you should have lynx at your disposal. In this case, substitute all occurrences of links2 in the rest of the instructions with lynx.

Pick the releases/ directory, followed by your architecture (for instance x86/) and the Gentoo version (2004.2/) to finish up with the stages/ directory. There you should see all available stage files for your architecture (they might be stored within subdirectories named to the individual sub architectures). Select one and press D to download. When you're finished, press Q to quit the browser.

Code Listing 2.2: Surfing to the mirror listing with links2

(Without proxy)   # links2 http://www.gentoo.org/main/en/mirrors.xml
(With proxy)      # links2 -http-proxy proxy.server.com:8080 http://www.gentoo.org/main/en/mirrors.xml

If you want to check the integrity of the downloaded stage tarball, use md5sum and compare the output with the MD5 checksum provided on the mirror. For instance, to check the validity of the x86 stage tarball:

Code Listing 2.3: Example checking integrity of a stage tarball

# md5sum -c stage1-x86-2004.2.tar.bz2.md5
stage1-x86-2004.2.tar.bz2: OK

Unpacking the Stage Tarball

Now unpack your downloaded stage onto your system. We use GNU's tar to proceed as it is the easiest method:

Code Listing 2.4: Unpacking the stage

# tar -xvjpf stage?-*.tar.bz2

Make sure that you use the same options (-xvjpf). The x stands for Extract, the v for Verbose (okay, yes, this 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.

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

5.c. Alternative: Using a Stage from the LiveCD

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 3.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 3.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 3.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 GNU tar tool. Make sure you use the same options (-xvjpf)! In the next example, we extract the stage tarball stage3-<subarch>-2004.2.tar.bz2. Be sure to substitute the tarball filename with your stage.

Code Listing 3.4: Extracting the stage tarball

# tar -xvjpf /mnt/cdrom/stages/stage3-<subarch>-2004.2.tar.bz2

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

5.d. Installing Portage

Network or No Network?

If you don't have a working network connection, you have to install a Portage snapshot provided by one of our LiveCDs. This automatically assumes that you are installing from a stage3 tarball (as it is the only tarball supported for networkless installations). If you want to use prebuilt packages later on to speed up the installation, you must use a Portage snapshot from the LiveCD. Other users will download a fully updated Portage tree using emerge in the next chapter.

Continue with the appropriate part:

Installing a Portage Snapshot and Source Code from LiveCD

There is a Portage snapshot available on the Universal LiveCDs. Since you are reading this, we can safely assume you are using such a LiveCD. To install this snapshot, take a look inside /mnt/cdrom/snapshots/ to see what snapshot we have available:

Code Listing 4.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 to tar. Also, the -C is with a capital C, not c. In the next example we use portage-20040710.tar.bz2 as the snapshot filename. Be sure to substitute with your snapshot.

Code Listing 4.2: Extracting a Portage snapshot

# tar -xvjf /mnt/cdrom/snapshots/portage-20040710.tar.bz2 -C /mnt/gentoo/usr

You also need to copy over all source code from the CD:

Code Listing 4.3: Copy over source code

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

Now that your Portage snapshot is installed, continue with Configuring the Compile Options.

5.e. Configuring the Compile Options

Introduction

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 5.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.

CHOST

Warning: Although it might be tempting for non-stage1 users, they should not change the CHOST setting in make.conf. Doing so might render their system unusable. Again: only change this variable if you use a stage1 installation.

The CHOST variable defines what architecture gcc has to compile programs for. The possibilities are:

Architecture Subarchitecture CHOST Setting
x86 i386 i386-pc-linux-gnu
x86 i486 i486-pc-linux-gnu
x86 i586 i586-pc-linux-gnu
x86 i686 and above (incl. athlon) i686-pc-linux-gnu
alpha alpha-unknown-linux-gnu
ppc powerpc-unknown-linux-gnu
ppc64 powerpc64-unknown-linux-gnu
sparc sparc-unknown-linux-gnu
hppa (generic) hppa-unknown-linux-gnu
hppa pa7000 hppa1.1-unknown-linux-gnu
hppa pa8000 and above hppa2.0-unknown-linux-gnu
mips mips-unknown-linux-gnu
amd64 x86_64-pc-linux-gnu

CFLAGS and CXXFLAGS

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 will not explain all possible optimization options. If you want to know them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.

A first setting is the -march= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments). For instance, for the x86 Athlon XP architecture:

Code Listing 5.2: The GCC march setting

# AMD64 users who want to use a native 64 bit system should not use athlon-xp
-march=athlon-xp

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 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). For instance, for a class-2 optimization:

Code Listing 5.3: The GCC O setting

-O2

Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation).

Mind you that 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, like in the following example:

Code Listing 5.4: Defining the CFLAGS and CXXFLAGS variable

CFLAGS="-march=athlon-xp -pipe -O2"   # AMD64 users should not use athlon-xp
CXXFLAGS="${CFLAGS}"                  # Use the same settings for both variables

MAKEOPTS

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 5.5: MAKEOPTS for a regular, 1-CPU system

MAKEOPTS="-j2"

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 Installing the Gentoo Base System.

6. Installing the Gentoo Base System

6.a. Chrooting

Optional: Selecting Mirrors

If you have booted from a Gentoo LiveCD, you are able to use mirrorselect to update /etc/make.conf so fast mirrors are used for both Portage and source code (of course in case you have a working network connection):

Warning: An error within mirrorselect might make it output garbage after the GENTOO_MIRRORS statement. Please open /mnt/gentoo/etc/make.conf and remove the garbage at the end of the GENTOO_MIRRORS statement if applicable.

Code Listing 1.1: Selecting fast mirrors

# mirrorselect -a -s4 -o | grep 'GENTOO_MIRRORS=' >> /mnt/gentoo/etc/make.conf

If for some reason mirrorselect fails, don't panic. This step is completely optional, the default values suffice.

Copy DNS Info

One thing still remains to be done before we enter the new environment and that is copying over the DNS information in /etc/resolv.conf. You need to do this to ensure that networking still works even after entering the new environment. /etc/resolv.conf contains the nameservers for your network.

Code Listing 1.2: Copy over DNS information

(The "-L" option is needed to make sure we don't copy a symbolic link)
# cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf

Mounting the proc Filesystem

Mount the /proc filesystem on /mnt/gentoo/proc to allow the installation to use the kernel-provided information even within the chrooted environment.

Code Listing 1.3: Mounting /proc

# mount -t proc none /mnt/gentoo/proc

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 (LiveCD or other installation medium) 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.4: Chrooting into the new environment

# chroot /mnt/gentoo /bin/bash
# env-update
 * Caching service dependencies...
# source /etc/profile

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 :-)

Optional: Updating the Portage tree

If you haven't installed a Portage snapshot in the previous chapter, you must download a recent Portage tree from the Internet. emerge --sync does this for you. Other users should skip this and continue with Configuring the USE variable.

Code Listing 1.5: Updating the Portage tree

# emerge --sync

Portage uses the RSYNC protocol for updating the Portage tree. If the above command fails due to your firewall, use emerge-webrsync which downloads and installs a Portage snapshot for you using the regular HTTP protocol.

Code Listing 1.6: Updating the Portage tree with emerge-webrsync

# emerge-webrsync

If you are warned that a new Portage version is available and that you should update Portage, you should ignore it. Portage will be updated for you later on during the installation.

Configuring 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 -qt will compile your programs with gnome (and gtk) support, and not with kde (and qt) support, making your system fully tweaked for GNOME.

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 1.7: 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 1.8: Opening /etc/make.conf

# nano -w /etc/make.conf

Code Listing 1.9: USE setting

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

You will probably only use one or maybe two locales on your system. Up until now after compiling glibc a full set of all available locales will be created. As of now you can activate the userlocales USE flag and specify only the locales you will need in /etc/locales.build.

Code Listing 1.10: Activate the userlocales USE flag especially for glibc

# mkdir /etc/portage
# echo "sys-libs/glibc userlocales" >> /etc/portage/package.use

Now specify the locales you want to be able to use:

Code Listing 1.11: nano -w /etc/locales.build

en_US/ISO-8859-1
en_US.UTF-8/UTF-8
de_DE/ISO-8859-1
de_DE@euro/ISO-8859-15

Optional: Using Distributed Compiling

If you are interested in using a collection of systems to help in compiling your system you might want to take a look at our DistCC Guide. By using distcc you can use the processing power of several systems to aid you with the installation.

6.b. Differences between Stage1, Stage2 and Stage3

Now take a seat and think of your previous steps. We asked you to select a stage1, stage2 or stage3 and warned you that your choice is important for further installation steps. Well, this is the first place where your choice defines the subsequent steps.

6.c. Progressing from Stage1 to Stage2

Introduction to Bootstrapping

So, you want to compile everything from scratch? Okay then :-)

In this step, we will bootstrap your Gentoo system. This takes a long time, but the result is a system that has been optimized from the ground up for your specific machine and needs.

Bootstrapping means building the GNU C Library, GNU Compiler Collection and several other key system programs.

Before starting the bootstrap, we list a couple of options you might or might not want. If you do not want to read those, continue with Bootstrapping the System.

Optional: Downloading the Sources First

If you haven't copied over all source code before, then the bootstrap script will download all necessary files. It goes without saying that this only works if you have a working network connnection :-) If you want to download the source code first and later bootstrap the system (for instance because you don't want to have your internet connection open during the compilation) use the -f option of the bootstrap script, which will fetch (hence the letter f) all source code for you.

Code Listing 3.1: Downloading the necessary sources

# cd /usr/portage
# scripts/bootstrap.sh -f

Bootstrapping the System

Okay then, take your keyboard and punch in the next commands to start the bootstrap. Then go amuse yourself with something else because this step takes quite some time to finish.

Code Listing 3.2: Bootstrapping the system

# cd /usr/portage
# scripts/bootstrap.sh

Now continue with the next step, Progressing from Stage2 to Stage3.

6.d. Progressing from Stage2 to Stage3

Introduction

If you are reading this section, then you have a bootstrapped system (either because you bootstrapped it previously, or you are using a stage2). Then it is now time to build all system packages.

All system packages? No, not really. In this step, you will build the system packages of which there are no alternatives to use. Some system packages have several alternatives (such as system loggers) and as Gentoo is all about choices, we don't want to force one upon you.

Optional: Viewing what will be done

If you want to know what packages will be installed, execute emerge --pretend system. This will list all packages that will be built. As this list is pretty big, you should also use a pager like less or more to go up and down the list.

Code Listing 4.1: View what 'emerge system' will do

# emerge --pretend system | less

Optional: Downloading the Sources

If you want emerge to download the sources before you continue (for instance because you don't want the internet connection to be left open while you are building all packages) you can use the --fetchonly option of emerge which will fetch all sources for you.

Code Listing 4.2: Fetching the sources

# emerge --fetchonly system

Building the System

To start building the system, execute emerge system. Then go do something to keep your mind busy, because this step takes a long time to complete.

Code Listing 4.3: Building the System

# emerge system

You can for now safely ignore any warnings about updated configuration files (and running etc-update). When your Gentoo system is fully installed and booted, do read our documentation on Configuration File Protection.

When the build process has completed, continue with Configuring the Kernel.

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 make a symlink to /etc/localtime using ln:

Code Listing 1.1: Setting the timezone information

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

7.b. Installing the 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 kernel sources. A full listing with description is available at the Gentoo Kernel Guide.

For x86-based systems we have, amongst other kernels, vanilla-sources (the default 2.4 kernel source as developed by the linux-kernel developers), gentoo-sources (2.4 kernel source patched with performance-enhancing features), gentoo-dev-sources (kernel v2.6 source patched with performance-enhancing features), development-sources (vanilla 2.6 kernel source), ...

If you are performing a network-less install your kernel choices will be limited to those provided on the CD. For the 2004.2 release those are:

  • gentoo-sources
  • vanilla-sources
  • gentoo-dev-sources
  • development-sources

Choose your kernel source and install it using emerge.

Code Listing 2.1: Installing a kernel source

# emerge gentoo-sources

When you take a look in /usr/src you should see a symlink called linux pointing to your kernel source. We will assume the kernel source installed is gentoo-sources-2.4.26-r6:

Code Listing 2.2: Viewing the kernel source symlink

# ls -l /usr/src/linux
lrwxrwxrwx    1 root     root           12 Oct 13 11:04 /usr/src/linux -> linux-2.4.26-gentoo-r6

If this isn't the case (i.e. the symlink points to a different kernel source) change the symlink before you continue:

Code Listing 2.3: Changing the kernel source symlink

# rm /usr/src/linux
# cd /usr/src
# ln -s linux-2.4.26-gentoo-r6 linux

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 LiveCD. We explain the "manual" configuration first though, as it is the best way to optimize your environment.

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

Introduction

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 couple of kernels you don'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 viewing the contents of /proc/pci (or by using lspci if available). You can also run lsmod to see what kernel modules the LiveCD uses (it might provide you with a nice hint on what to enable).

Now go to your kernel source directory and execute make menuconfig. This will fire up an ncurses-based configuration menu.

Code Listing 3.1: Invoking menuconfig

# cd /usr/src/linux
# 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 of all, activate the use of development and experimental code/drivers. You need this, otherwise some very important code/drivers won't show up:

Code Listing 3.2: Selecting experimental code/drivers

Code maturity level options --->
  [*] Prompt for development and/or incomplete code/drivers

Make sure that you compile your kernel with the correct processor family:

Code Listing 3.3: Selecting correct processor family

Processor type and features --->
  (Change according to your system)
  (Athlon/Duron/K7) Processor family

Now 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 Virtual memory, /proc file system, /dev file system + Automatically mount at boot:

Code Listing 3.4: Selecting necessary file systems

(With a 2.4.x kernel)
File systems --->
  [*] Virtual memory file system support (former shm fs)
  [*] /proc file system support
  [*] /dev file system support (EXPERIMENTAL)
  [*]   Automatically mount at boot
  [ ] /dev/pts file system for Unix98 PTYs

(With a 2.6.x kernel)
File systems --->
  Pseudo Filesystems --->
    [*] /proc file system support
    [*] /dev file system support (OBSOLETE)
    [*]   Automatically mount at boot
    [*] Virtual memory file system support (former shm fs)

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

If your BIOS can't handle large harddrives and you jumpered the harddrive to report a limited size you have to enable the following option to gain access to your whole harddrive:

Code Listing 3.5: Selecting autogeometry resizing support

(2.4.x kernel only)
ATA/IDE/MFM/RLL support --->
  IDE, ATA and ATAPI Block devices --->
    <*>   Include IDE/ATA-2 DISK support
    [ ]     Use multi-mode by default
    [*]     Auto-Geometry Resizing 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.6: Selecting PPPoE necessary drivers

(With a 2.4.x kernel)
Network device support --->
  <*> PPP (point-to-point protocol) support
  <*>   PPP support for async serial ports
  <*>   PPP support for sync tty ports

(With a 2.6.x kernel)
Device Drivers --->
  Networking 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 definitely needed, neither does the PPP over Ethernet option, that might only be used by rp-pppoe when configured to do kernel mode PPPoE.

If you require it, don't forget to include support in the kernel for your ethernet card.

If you have an Intel CPU that supports HyperThreading (tm), or you have a multi-CPU system, you should activate "Symmetric multi-processing support":

Code Listing 3.7: Activating SMP support

Processor type and features  --->
  [*] Symmetric multi-processing support

If you use USB Input Devices (like Keyboard our Mouse) don't forget to enable those as well:

Code Listing 3.8: Activating USB Support for Input Devices

USB Support --->
  <*>   USB Human Interface Device (full HID) support

Laptop-users who want PCMCIA support should not use the PCMCIA drivers if they choose to use a 2.4 kernel. More recent drivers are available through the pcmcia-cs package which will be installed later on. 2.6-kernel users however should use the PCMCIA drivers from the kernel.

When you've finished configuring the 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 and run make dep && make bzImage modules modules_install:

Code Listing 3.9: Compiling the kernel

(For 2.4 kernel)
# make dep && make bzImage modules modules_install

(For 2.6 kernel)
# make && make modules_install

When the kernel has finished compiling, copy the kernel image to /boot. From here onwards we assume that the kernel you are installing is the 2.4.26 version of the gentoo-sources. Use whatever name you feel is appropriate for your choice and remember it as you will need it later on when you configure your bootloader.

Code Listing 3.10: Installing the kernel

# cp arch/i386/boot/bzImage /boot/kernel-2.4.26-gentoo-r6
# cp System.map /boot/System.map-2.4.26-gentoo-r6

It is also wise to copy over your kernel configuration file to /boot, just in case :)

Code Listing 3.11: Backing up your kernel configuration

# cp .config /boot/config-2.4.26-gentoo-r6

Now continue with Installing Separate Kernel Modules.

7.d. Alternative: Using genkernel

If you are reading this section, you have chosen to use our genkernel script to configure your kernel for you.

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 LiveCD 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 Live 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 4.1: Emerging genkernel

# emerge genkernel

Now, compile your kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports almost all hardware, this compilation will take quite a while to finish!

Note that, if your boot partition 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).

Code Listing 4.2: Running genkernel

# genkernel 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 it when writing the bootloader configuration file. The initrd will be started immediately after booting to perform hardware autodetection (just like on the Live CD) before your "real" system starts up.

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

# ls /boot/kernel* /boot/initrd*

Now, let's perform one more step to get our system to be more like the Live CD -- let's emerge hotplug. While the initrd autodetects hardware that is needed to boot your system, hotplug autodetects everything else. To emerge and enable hotplug, type the following:

Code Listing 4.4: Emerging and enabling hotplug

# emerge hotplug
# rc-update add hotplug default

7.e. Installing Separate Kernel Modules

Installing Extra Modules

If appropriate, you should emerge ebuilds for any additional hardware that is on your system. Here is a list of kernel-related ebuilds that you could emerge:

Ebuild Purpose Command
nvidia-kernel Accelerated NVIDIA graphics for xorg-x11 emerge nvidia-kernel
nforce-audio On-board audio on NVIDIA NForce(2) motherboards emerge nforce-audio
e100 Intel e100 Fast Ethernet Adapters emerge e100
e1000 Intel e1000 Gigabit Ethernet Adapters emerge e1000
emu10k1 Creative Sound Blaster Live!/Audigy support (for 2.4 kernels only) emerge emu10k1
ati-drivers Accelerated ATI Radeon 8500+/FireGL graphics for xorg-x11 emerge ati-drivers
ati-drivers-extra Graphical ATI tools emerge ati-drivers-extra

Beware though, some of these ebuilds might deal with big dependencies. To verify what packages will be installed by emerging an ebuild, use emerge --pretend. For instance, for the emu10k1 package:

Code Listing 5.1: View full installation package listing

# emerge --pretend emu10k1

If you don't like the packages it wants to install, use emerge --pretend --verbose to see what USE-flags are checked when deciding the dependencies:

Code Listing 5.2: View USE-flag usage

# emerge --pretend --verbose emu10k1
...
[ebuild  N    ] media-sound/aumix-2.8  +gpm +nls +gtk +gnome +alsa -gtk2

In the previous example you can see that one of emu10k1's dependencies (aumix) uses the gtk and gnome USE-flags, making gtk (which depends on xorg-x11) be compiled with it.

If you don't want all this to be compiled, deselect all USE-flags, for instance:

Code Listing 5.3: Emerging emu10k1 with all USE-flags deselected

# USE="-gpm -nls -gtk -gnome -alsa" emerge --pretend emu10k1

When you're happy with the results, remove the --pretend to start installing emu10k1.

Configuring the Modules

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

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 5.4: Viewing all available modules

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

For instance, to automatically load the 3c59x.o module, edit the kernel-2.4 or kernel-2.6 file and enter the module name in it.

Code Listing 5.5: Editing /etc/modules.autoload.d/kernel-2.4

(Example for 2.4 kernels)
# nano -w /etc/modules.autoload.d/kernel-2.4

Code Listing 5.6: /etc/modules.autoload.d/kernel-2.4 or kernel-2.6

3c59x

Now run modules-update to commit your changes to the /etc/modules.conf file:

Code Listing 5.7: Running modules-update

# modules-update

Continue the installation 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).

The default /etc/fstab file provided by Gentoo is no valid fstab file, so start nano (or your favorite editor) to create your /etc/fstab:

Code Listing 1.1: Opening /etc/fstab

# nano -w /etc/fstab

Let us take a look at how we write down the options for the /boot partition. This is just an example, so if your architecture doesn't require a /boot partition (such as PPC), don't copy it verbatim.

In our default x86 partitioning example /boot is the /dev/hda1 partition, with ext2 as filesystem. It needs to be checked during boot, so we would write down:

Code Listing 1.2: An example /boot line for /etc/fstab

/dev/hda1   /boot     ext2    defaults        1 2

Some users don't want their /boot partition to be mounted automatically to improve their system's security. Those people should substitute defaults with noauto. This does mean that you need to manually mount this partition every time you want to use it.

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

Code Listing 1.3: An improved /boot line for /etc/fstab

/dev/hda1   /boot     ext2    defaults,noatime    1 2

If we continue with this, we would end up with the following three lines (for /boot, / and the swap partition):

Code Listing 1.4: Three /etc/fstab lines

/dev/hda1   /boot     ext2    defaults,noatime  1 2
/dev/hda2   none      swap    sw                0 0
/dev/hda3   /         ext3    noatime           0 1

To finish up, you should add a rule for /proc, tmpfs (required) and for your CD-ROM drive (and of course, if you have other partitions or drives, for those too):

Code Listing 1.5: A full /etc/fstab example

/dev/hda1   /boot     ext2    noauto,noatime       1 2
/dev/hda2   none      swap    sw                   0 0
/dev/hda3   /         ext3    noatime              0 1

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

/dev/cdroms/cdrom0    /mnt/cdrom    auto      noauto,user    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.

Now use the above example to create your /etc/fstab. If you are a SPARC-user, you should add the following line to your /etc/fstab too:

Code Listing 1.6: Adding openprom filesystem to /etc/fstab

none        /proc/openprom  openpromfs    defaults      0 0

If you need usbfs, add the following line to /etc/fstab:

Code Listing 1.7: Adding usbfs filesystem to /etc/fstab

none        /proc/bus/usb   usbfs         defaults      0 0

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

# echo tux > /etc/hostname

Second we set the domainname:

Code Listing 2.2: Setting the domainname

# echo homenetwork > /etc/dnsdomainname

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

# echo nis.homenetwork > /etc/nisdomainname

Now add the domainname script to the default runlevel:

Code Listing 2.4: Adding domainname to the default runlevel

# rc-update add domainname default

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.

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 :)

First open /etc/conf.d/net with your favorite editor (nano is used in this example):

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

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

The first variable you'll find is iface_eth0. It uses the following syntax:

Code Listing 2.6: iface_eth0 syntaxis

iface_eth0="<your ip address> broadcast <your broadcast address> netmask <your netmask>"

If you use DHCP (automatic IP retrieval), you should just set iface_eth0 to dhcp. If you use rp-pppoe (e.g. for ADSL), set it to up. If you need to set up your network manually and you're not familiar with all the above terms, please read the section on Understanding Network Terminology if you haven't done so already.

So let us give three examples; the first one uses DHCP, the second one a static IP (192.168.0.2) with netmask 255.255.255.0, broadcast 192.168.0.255 and gateway 192.168.0.1 while the third one just activates the interface for rp-pppoe usage:

Code Listing 2.7: Examples for /etc/conf.d/net

(For DHCP)
iface_eth0="dhcp"
# Some network admins require that you use the
# hostname and domainname provided by the DHCP server.
# In that case, add the following to let dhcpcd use them.
# That will override your own hostname and domainname definitions.
dhcpcd_eth0="-HD"
# If you intend on using NTP to keep your machine clock synchronized, use
# the -N option to prevent dhcpcd from overwriting your /etc/ntp.conf file
dhcpcd_eth0="-N"

(For static IP)
iface_eth0="192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0"
gateway="eth0/192.168.0.1"

(For rp-pppoe)
iface_eth0="up"

If you have several network interfaces, create extra iface_eth variables, like iface_eth1, iface_eth2 etc. The gateway variable shouldn't be reproduced as you can only set one gateway per computer.

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. If you have PCMCIA interfaces you should skip this action as the PCMCIA interfaces are started by the PCMCIA init script.

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.eth0 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. For instance, if your internal network consists of three PCs called jenny (192.168.0.5), benny (192.168.0.6) and tux (192.168.0.7 - this system) you would open /etc/hosts and fill in the values:

Code Listing 2.10: Opening /etc/hosts

# nano -w /etc/hosts

Code Listing 2.11: Filling in the networking information

127.0.0.1     localhost
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny
192.168.0.7   tux.homenetwork tux

If your system is the only system (or the nameservers handle all name resolution) a single line is sufficient. For instance, if you want to call your system tux.homenetwork:

Code Listing 2.12: /etc/hosts for lonely or fully integrated PCs

127.0.0.1     tux.homenetwork tux localhost

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

Note: pcmcia-cs is only available for x86, amd64 and ppc platforms.

PCMCIA-users should first install the pcmcia-cs package. This also includes users who will be working with a 2.6 kernel (even though they won't be using the PCMCIA drivers from this package). The USE="-X" is necessary to avoid installing xorg-x11 at this moment:

Code Listing 2.13: Installing pcmcia-cs

# USE="-X" emerge pcmcia-cs

When pcmcia-cs is installed, add pcmcia to the default runlevel:

Code Listing 2.14: Adding pcmcia to the default runlevel

# rc-update add pcmcia default

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

As you can see, this file is well commented to help you set up the necessary configuration variables. Take special care with the KEYMAP setting: if you select the wrong KEYMAP you will get weird results when typing on your keyboard.

Note: Users of USB-based SPARC systems and SPARC clones might need to select an i386 keymap (such as "us") instead of "sunkeymap".

PPC uses x86 keymaps on most systems. Users who want to be able to use ADB keymaps on boot have to enable ADB keycode sendings in their kernel and have to set a mac/ppc keymap in rc.conf.

When you're finished configuring /etc/rc.conf, save and exit, then continue with Installing Necessary System Tools.

9. Installing Necessary System Tools

9.a. System Logger

When we mentioned what stage3 was, we said that it contained all necessary system tools for which we cannot provide a choice to our users. We also said that we would install the other tools later on. Well, here we are :)

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 can't choose one, use metalog as it is very powerful yet comes with a great default configuration.

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 metalog. Of course substitute with your system logger:

Warning: The stage3 tarballs of the 2004.2 release erroneously contain the sysklogd logger. You will need to unmerge this logger before emerging a new one.

Code Listing 1.1: Installing a system logger

(First unmerge the sysklogd logger if you use a stage3 tarball)
# emerge unmerge sysklogd
(You will also need to remove the sysklogd init script)
# rm /etc/init.d/sysklogd

(Now install the system logger of your choice)
# emerge metalog
# rc-update add metalog 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).

Gentoo offers three possible cron daemons: dcron, fcron and vixie-cron. Installing one of them is similar to installing a system logger. However, dcron and fcron require an extra configuration command, namely crontab /etc/crontab. If you don't know what to choose, use vixie-cron.

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
(Only if you have chosen dcron or fcron) # crontab /etc/crontab

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.

Note: If you are not installing Gentoo using cascading profiles slocate will already be part of your system. Cascading profiles are not used by default yet so if you don't understand it you can assume that you're not using cascading profiles.

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:

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

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

9.e. Networking Tools

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!

Note: If you are not installing Gentoo using cascading profiles dhcpcd will already be part of your system. Cascading profiles are not used by default yet so if you don't understand it you can assume that you're not using cascading profiles.

Code Listing 5.1: Installing dhcpcd

# emerge dhcpcd

Optional: Installing a PPPoE Client

If you need rp-pppoe to connect to the net, you need to install it.

Code Listing 5.2: Installing rp-pppoe

# USE="-X" emerge rp-pppoe

The USE="-X" will prohibit xorg-x11 to be installed as a dependency (rp-pppoe has graphical tools; if you want those enabled, you can recompile rp-pppoe later on or have xorg-x11 installed now -- which takes a long time to compile).

Now continue with Configuring the Bootloader.

10. Configuring the Bootloader

10.a. Making your Choice

Introduction

Now that your kernel is configured and compiled and the necessary system configuration files are filled in correctly, it is time to install a program that will fire up your kernel when you start the system. Such a program is called a bootloader. For x86, Gentoo Linux provides GRUB and LILO. But before we install one of these two bootloaders, we inform you how to configure framebuffer (assuming you want it of course). With framebuffer you can run the Linux command line with (limited) graphical features (such as using the nice bootsplash image Gentoo provides).

Optional: Framebuffer

If you have configured your kernel with framebuffer support (or you used genkernel's default kernel configuration), you have to add a vga- or video-statement to your bootloader configuration file if you require framebuffer. The former is for 2.4 kernels while you should use the latter for 2.6 kernels. The next table lists the available vga-values you can use. In the example configuration files we use 800x600 @ 16bpp for 2.4 kernels, thus 788.

For the vga-statement:

640x480 800x600 1024x768 1280x1024
8 bpp 769 771 773 775
16 bpp 785 788 791 794
32 bpp 786 789 792 795

For the video-statement, a simplified syntax is used. Most of the time it's sufficient to use video=vesafb.

More information can be found in /usr/src/linux/Documentation/fb/vesafb.txt.

Remember (or write down) your value; you will need it shortly.

Now continue by installing GRUB or LILO.

10.b. Default: Using GRUB

Understanding GRUB's terminology

The most critical part of understanding GRUB is getting comfortable with how GRUB refers to hard drives and partitions. Your Linux partition /dev/hda1 is called (hd0,0) under GRUB. Notice the parenthesis around the hd0,0 - they are required.

Hard drives count from zero rather than "a" and partitions start at zero rather than one. Be aware too that with the hd devices, only hard drives are counted, not atapi-ide devices such as cdrom players and burners. Also, the same construct is used with scsi drives. (Normally they get higher numbers than ide drives except when the bios is configured to boot from scsi devices.)

Assuming you have a hard drive on /dev/hda, a cdrom player on /dev/hdb, a burner on /dev/hdc, a second hard drive on /dev/hdd and no SCSI hard drive, /dev/hdd7 gets translated to (hd1,6). It might sound tricky and tricky it is indeed, but as we will see, GRUB offers a tab completion mechanism that comes handy for those of you having a lot of hard drives and partitions and who are a little lost in the GRUB numbering scheme.

Having gotten the feel for that, it is time to install GRUB.

Installing GRUB

To install GRUB, let's first emerge it:

Code Listing 2.1: Installing GRUB

# emerge grub

Although GRUB is now installed, we still need to write up a configuration file for it and place GRUB in our MBR so that GRUB automatically boots your newly created kernel. Create /boot/grub/grub.conf with nano (or, if applicable, another editor):

Code Listing 2.2: Creating /boot/grub/grub.conf

# nano -w /boot/grub/grub.conf

Now we are going to write up a grub.conf. Below you'll find two possible grub.conf for the partitioning example we use in this guide, with kernel image kernel-2.4.26-gentoo-r6. We've only extensively commented the first grub.conf. Make sure you use your kernel image filename and, if appropriate, your initrd image filename.

  • The first grub.conf is for people who have not used genkernel to build their kernel
  • The second grub.conf is for people who have used genkernel to build their kernel

Code Listing 2.3: grub.conf for non-genkernel users

# Which listing to boot as default. 0 is the first, 1 the second etc.
default 0
# How many seconds to wait before the default listing is booted.
timeout 30
# Nice, fat splash-image to spice things up :)
# Comment out if you don't have a graphics card installed
splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo Linux 2.4.26-r6
# Partition where the kernel image (or operating system) is located
root (hd0,0)
kernel /kernel-2.4.26-gentoo-r6 root=/dev/hda3

# The next four lines are only if you dualboot with a Windows system.
# In this case, Windows is hosted on /dev/hda6.
title=Windows XP
rootnoverify (hd0,5)
makeactive
chainloader +1

Code Listing 2.4: grub.conf for genkernel users

default 0
timeout 30
splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo Linux 2.4.26-r6
root (hd0,0)
kernel /kernel-2.4.26-gentoo-r6 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3
initrd /initrd-2.4.26-gentoo-r6

# Only in case you want to dual-boot
title=Windows XP
root (hd0,5)
makeactive
chainloader +1

Note: If you use a different partitioning scheme and/or kernel image, adjust accordingly. However, make sure that anything that follows a GRUB-device (such as (hd0,0)) is relative to the mountpoint, not the root. In other words, (hd0,0)/grub/splash.xpm.gz is in reality /boot/grub/splash.xpm.gz since (hd0,0) is /boot.

If you need to pass any additional options to the kernel, simply add them to the end of the kernel command. We're already passing one option (root=/dev/hda3 or real_root=/dev/hda3), but you can pass others as well. As an example we use the vga statement for framebuffer we discussed previously:

Code Listing 2.5: Adding the vga-statement as a kernel option

title=Gentoo Linux 2.4.26-r6
  root (hd0,0)
  kernel /kernel-2.4.26-gentoo-r6 root=/dev/hda3 vga=788

If you're using a 2.6.7 or higher kernel and you jumpered your harddrive because the BIOS can't handle large harddrives you'll need to append hdx=stroke.

genkernel users should know that their kernels use the same boot options as is used for the LiveCD. For instance, if you have SCSI devices, you should add doscsi as kernel option.

Now save the grub.conf file and exit. You still need to install GRUB in the MBR (Master Boot Record) so that GRUB is automatically executed when you boot your system.

The GRUB developers recommend the use of grub-install. However, if for some reason grub-install fails to work correctly you still have the option to manually install GRUB.

Continue with Default: Setting up GRUB using grub-install or Alternative: Setting up GRUB using manual instructions.

Default: Setting up GRUB using grub-install

To install GRUB you will need to issue the grub-install command. However, grub-install won't work off-the-shelf since we are inside a chrooted environment. We need to update /etc/mtab (the file with information about all mounted filesystems) first: luckily there is an easy way to accomplish this - just copy over /proc/mounts to /etc/mtab:

Code Listing 2.6: Updating /etc/mtab

# cp /proc/mounts /etc/mtab

Now we can install GRUB using grub-install:

Code Listing 2.7: Running grub-install

# grub-install --root-directory=/boot /dev/hda

If you have more questions regarding GRUB, please consult the GRUB FAQ or the GRUB Manual.

Continue with Rebooting the System.

Alternative: Setting up GRUB using manual instructions

To start configuring GRUB, you type in grub. You'll be presented with the grub> grub command-line prompt. Now, you need to type in the right commands to install the GRUB boot record onto your hard drive.

Code Listing 2.8: Starting the GRUB shell

# grub

Note: If your system does not have any floppy drives, add the --no-floppy option to the above command to prevent grub from probing the (non-existing) floppy drives.

In the example configuration we want to install GRUB so that it reads its information from the boot-partition /dev/hda1, and installs the GRUB boot record on the hard drive's MBR (master boot record) so that the first thing we see when we turn on the computer is the GRUB prompt. Of course, if you haven't followed the example configuration during the installation, change the commands accordingly.

The tab completion mechanism of GRUB can be used from within GRUB. For instance, if you type in "root (" followed by a TAB, you will be presented with a list of devices (such as hd0). If you type in "root (hd0," followed by a TAB, you will receive a list of available partitions to choose from (such as hd0,0).

By using the tab completion, setting up GRUB should be not that hard. Now go on, configure GRUB, shall we? :-)

Code Listing 2.9: Installing GRUB in the MBR

grub> root (hd0,0)          (Specify where your /boot partition resides)
grub> setup (hd0)           (Install GRUB in the MBR)
grub> quit                  (Exit the GRUB shell)

Note: If you want to install GRUB in a certain partition instead of the MBR, you have to alter the setup command so it points to the right partition. For instance, if you want GRUB installed in /dev/hda3, then the command becomes setup (hd0,2). Few users however want to do this.

If you have more questions regarding GRUB, please consult the GRUB FAQ or the GRUB Manual.

Continue with Rebooting the System.

10.c. Alternative: Using LILO

Installing LILO

LILO, the LInuxLOader, is the tried and true workhorse of Linux bootloaders. However, it lacks some features that GRUB has (which is also the reason why GRUB is currently gaining popularity). The reason why LILO is still used is that, on some systems, GRUB doesn't work and LILO does. Of course, it is also used because some people know LILO and want to stick with it. Either way, Gentoo supports both, and apparently you have chosen to use LILO.

Installing LILO is a breeze; just use emerge.

Code Listing 3.1: Installing LILO

# emerge --usepkg lilo

Configuring LILO

To configure LILO, you must create /etc/lilo.conf. Fire up your favorite editor (in this handbook we use nano for consistency) and create the file.

Code Listing 3.2: Creating /etc/lilo.conf

# nano -w /etc/lilo.conf

Some sections ago we have asked you to remember the kernel-image name you have created. In the next example lilo.conf we assume the imagename is kernel-2.4.26-gentoo-r6. We also use the example partitioning scheme in this example. There are two separate parts:

  • One for those who have not used genkernel to build their kernel
  • One for those who have used genkernel to build their kernel

Make sure you use your kernel image filename and, if appropriate, your initrd image filename.

Code Listing 3.3: Example /etc/lilo.conf

boot=/dev/hda             # Install LILO in the MBR
prompt                    # Give the user the chance to select another section
timeout=50                # Wait 5 (five) seconds before booting the default section
default=gentoo            # When the timeout has passed, boot the "gentoo" section
# Only if you use framebuffer. Otherwise remove the following line:
vga=788                   # Framebuffer setting. Adjust to your own will

# For non-genkernel users
image=/boot/kernel-2.4.26-gentoo-r6
  label=gentoo            # Name we give to this section
  read-only               # Start with a read-only root. Do not alter!
  root=/dev/hda3          # Location of the root filesystem

# For genkernel users
image=/boot/kernel-2.4.26-gentoo-r6
  label=gentoo
  read-only
  root=/dev/ram0
  append="init=/linuxrc ramdisk=8192 real_root=/dev/hda3"
  initrd=/boot/initrd-2.4.26-gentoo-r6

# The next two lines are only if you dualboot with a Windows system.
# In this case, Windows is hosted on /dev/hda6.
other=/dev/hda6
  label=windows

Note: If you use a different partitioning scheme and/or kernel image, adjust accordingly.

If you need to pass any additional options to the kernel, add an append statement to the section. As an example, we add the vga=788 statement to enable framebuffer:

Code Listing 3.4: Using append to add kernel options

image=/boot/kernel-2.4.26-gentoo-r6
  label=gentoo
  read-only
  root=/dev/hda3
  append="vga=788"

If you're using a 2.6.7 or higher kernel and you jumpered your harddrive because the BIOS can't handle large harddrives you'll need to append hdx=stroke.

genkernel users should know that their kernels use the same boot options as is used for the LiveCD. For instance, if you have SCSI devices, you should add doscsi as kernel option.

Now save the file and exit. To finish up, you have to run /sbin/lilo so LILO can apply the /etc/lilo.conf to your system (i.e. install itself on the disk). Keep in mind that you'll also have to rerun /sbin/lilo every time you install a new kernel or make any changes to the menu.

Code Listing 3.5: Finishing the LILO installation

# /sbin/lilo

You can now continue with Rebooting the System.

10.d. 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 4.1: Unmounting all partitions and rebooting

# exit
cdimage ~# cd
cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo
cdimage ~# reboot

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

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 access cdrom devices
floppy be able to access floppy devices
games be able to play games
usb be able to access USB devices
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,tty -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"

(Otherwise:)
# export PKGDIR="/mnt/cdrom"

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

Code Listing 2.4: Installing KDE

# emerge --usepkg 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 equiped! 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.

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 :)

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

Ebuilds

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

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
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      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

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.7: 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:

Code Listing 3.8: Updating your system

# emerge --update 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 - not the dependencies. If you want to update every single package on your system, add the --deep argument:

Code Listing 3.9: Updating your entire system

# emerge --update --deep world

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.10: Performing a full update

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

Stub Packages

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 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.11: 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.12: Installing the gentoolkit package

# emerge gentoolkit

1.d. 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 in 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 provides virtual/syslog so that applications can depend on virtual/syslog.

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 4.1: Portage warning about blocked packages (with --pretend)

[blocks B     ] gnome-base/bonobo-activation (from pkg gnome-base/libbonobo-2.4.0)

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

!!! Error: the gnome-base/bonobo-activation 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.

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 libbonobo or to remove bonobo-activation first.

Masked Packages

Code Listing 4.3: Portage warning about masked packages

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

Code Listing 4.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-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- media-video/ati-gatos-4.3.0 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)

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.

Missing Dependencies

Code Listing 4.5: Portage warning about missing dependency

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-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 4.6: Portage warning about ambiguous ebuild names

!!! The short ebuild name "aterm" is ambiguous.  Please specify
!!! one of the following fully-qualified ebuild names instead:

    dev-libs/aterm
    x11-terms/aterm

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 4.7: 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 4.8: 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 4.9: 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.

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 managment 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 short (very incomplete) snippet:

Code Listing 1.1: A short snippet of available USE-flags

gtk     - Adds support for x11-libs/gtk+ (The GIMP Toolkit)
gtk2    - Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both.
gtkhtml - Adds support for gnome-extra/gtkhtml
guile   - Adds support for dev-util/guile (interpreter for Scheme)
icc     - Use the Intel C++ Compiler if the package supports it
icc-pgo - Enable PGO data generation or use when use icc.
imap    - Adds support for IMAP

A list of available local USE-flags can be found 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 /etc/make.profile/make.defaults file. Let us take a look at this default setting:

Code Listing 2.1: /etc/make.profile/make.defaults USE variable on an x86 system

USE="x86 oss apm arts avi berkdb crypt cups encode foomaticdb gdbm gif gpm
     gtk gtk2 imlib jpeg kde gnome libg++ libwww mad mikmod motif mpeg ncurses
     nls oggvorbis opengl pam pdflib png python qt quicktime readline sdl
     slang spell ssl svga tcpd truetype X xml2 xmms xv zlib"

As you can see, this variable already contains quite a lot of keywords. Do not alter the /etc/make.profile/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/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/make.conf:

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

USE="-kde -qt 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.

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/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 mozilla.

Code Listing 2.5: Using USE as environment variable

# USE="-java" emerge mozilla

Inheriting USE-flags

Some packages don't only listen to USE-flags, but also provide USE-flags. When you install such a package, the USE-flag they provide is added to your USE setting. To view the list of packages that provide a USE-flag, check /etc/make.profile/use.defaults:

Code Listing 2.6: A snippet from /etc/make.profile/use.defaults

gnome           gnome-base/gnome
gtk             x11-libs/gtk+
qt              x11-libs/qt
kde             kde-base/kdebase
motif           x11-libs/openmotif

Precedence

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 declared anyway. The precedence for the USE setting is, ordered by priority (first has lowest priority):

  1. Default USE setting declared in /etc/make.profile/make.defaults
  2. Inherited USE setting if a package from /etc/make.profile/use.defaults is installed
  3. User-defined USE setting in /etc/make.conf
  4. User-defined USE setting in /etc/portage/package.use
  5. 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.7: 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.8: 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.9: 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.10: 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 mozilla: 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 mozilla
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] net-www/mozilla-1.5-r1 +java +crypt -ipv6 -gtk2 +ssl +ldap 
+gnome -debug +mozcalendar -mozaccess -mozxmlterm -moznoirc -moznomail
-moznocompose -moznoxft 

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

Code Listing 3.2: Installing gentoolkit

# emerge gentoolkit

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

Code Listing 3.3: Using etcat to view used USE-flags

# etcat uses gnumeric
[ Colour Code : set unset ]
[ Legend      : (U) Col 1 - Current USE flags        ]
[             : (I) Col 2 - Installed With USE flags ]

 U I [ Found these USE variables in : app-office/gnumeric-1.2.0 ]
 - - libgda  : Adds GNU Data Access (CORBA wrapper) support for gnumeric
 - - gnomedb : unknown
 + + python  : Adds support/bindings for the Python language
 + + bonobo  : Adds support for gnome-base/bonobo (Gnome CORBA interfaces)

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/make.conf's FEATURES variable. 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/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 192.168.1.102 (the current host), 192.168.1.103 and 192.168.1.104 (two "remote" hosts):

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

# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

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. In common compilations this can result in 5 to 10 times faster compilation times.

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

Installing ccache

To install ccache, run emerge ccache:

Code Listing 3.1: Installing ccache

# emerge ccache

Activating Portage Support

Open /etc/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/make.conf

CCACHE_SIZE="2G"

To check if ccache functions, ask ccache to provide you with its statistics:

Code Listing 3.3: Viewing ccache statistics

# ccache -s

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 /etc/env.d/00basic:

Code Listing 3.4: Editing /etc/env.d/00basic

PATH="/usr/local/bin:/opt/bin:/usr/lib/ccache/bin"

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 (except for the GRP snapshots) 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 Reference Manual and Catalyst Howto.

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/make.conf

PORTAGE_BINHOST="ftp://buildhost/gentoo"

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

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

id:3:initdefault:

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, pause, 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 pause argument:

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

# /etc/init.d/postfix pause

If you want to see what status a service has (started, stopped, paused, ...) 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 depscan.sh 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 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 show

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

APACHE2_OPTS="-D PHP4"

Such a configuration file contains variables and variables alone (just like /etc/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!

Layout

The basic layout of an init script is shown below.

Code Listing 4.1: Basic layout of an init script

#!/sbin/runscript

depend() {
  (Dependency information)
}

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

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

restart() {
  (Commands necessary to restart the service)
}

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

Dependencies

There are two dependencies you can define: use and need. As we have mentioned before, the need dependency is more strict than the use dependency. Following this dependency type you enter the service you depend on, or the virtual dependency.

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

In some cases you might not require a service, but want your service to be started before (or after) another service if it is available on the system (note the conditional - this is no dependency anymore) and run in the same runlevel (note the conditional - only services in the same runlevel are involved). You can provide this information using the before or after settings.

As an example we view the settings of the Portmap service:

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 *
}

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.5: Example start() function

start() {
  ebegin "Starting my_service"
  start-stop-daemon --start --quiet --exec /path/to/my_service
  eend $?
}

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. As for start-stop-daemon, there is an excellent man page available if you need more information:

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

# man start-stop-daemon

Other functions you can define are: stop() and restart(). You are not obliged to define these functions! Our init system is intelligent enough to fill these functions by itself if you use start-stop-daemon.

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 opts variable, and create a function with the same name as the option. For instance, to support an option called restartdelay:

Code Listing 4.7: Supporting the restartdelay option

opts="${opts} restartdelay"

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

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

# ls /etc/runlevels/default
acpid  domainname  local  net.eth0  netmount  postfix  syslog-ng  vixie-cron
# rc-update add acpid offline
# rc-update add domainname offline
# rc-update add local offline
# rc-update add syslog-ng offline
# rc-update add vixie-cron offline

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

Code Listing 5.3: 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

Voila, 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.
CLASSPATH This variable contains a colon-separated list of directories which contain Java classes.
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

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CLASSPATH="/opt/blackdown-jre-1.4.1/lib/rt.jar:."
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"
CONFIG_PROTECT_MASK="/etc/gconf

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

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

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

http_proxy="proxy.server.com:8080"

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. This is why many of the files in /etc/env.d begin with a number.

Code Listing 2.3: Update order used by env-update

         00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

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/ld.so.conf. After this, it will run ldconfig to recreate the /etc/ld.so.cache 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

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 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

PATH="${PATH}:/home/my_user/bin"

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 /etc/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 a default configuration file inside your profile: /etc/make.profile/make.defaults. We'll explain more about profiles and the /etc/make.profile directory later on.

If you're planning on changing a configuration variable, don't alter /etc/make.globals or /etc/make.profile/make.defaults. Instead use /etc/make.conf which has precedence over the previous files. You'll also find a /etc/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/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.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

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/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/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.

RPM Files

Even though Portage cannot use RPM files, it is able to generate them using the ebuild command (see The Ebuild Application). The default location where Portage stores RPM files is /usr/portage/rpm and is defined by the RPMDIR variable.

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.

2. Configuring through Variables

2.a. Portage Configuration

As noted previously, Portage is configurable through many variables which you should define in /etc/make.conf. Please refer to the make.conf man page for more and complete information:

Code Listing 1.1: Reading the make.conf man page

$ man make.conf

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.

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 through emerge:

Code Listing 3.2: More information about Configuration File Protection

$ emerge --help config

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:

  • SYNC defines a particular server which Portage uses to fetch the Portage tree from

The GENTOO_MIRRORS and SYNC 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:

  • RSYNC_EXCLUDEFROM points to a file listing the packages and/or categories rsync should ignore during the update process
  • 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.
  • RSYNC_TIMEOUT defines the amount of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to 180 but dialup users probably want to set this to 300 or higher.

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 http://bugs.gentoo.org, 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.

For instance, to select the testing branch for the x86 architecture, edit /etc/make.conf and set:

Code Listing 1.1: Setting the ACCEPT_KEYWORDS variable

ACCEPT_KEYWORDS="~x86"

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.keywords file

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.keywords. For instance, to use the testing branch for gnumeric:

Code Listing 2.1: /etc/portage/package.keywords setting for gnumeric

app-office/gnumeric

The same can be achieved when you add the correct keyword at the end of the line, for instance for the x86 architecture:

Code Listing 2.2: /etc/portage/package.keywords setting for gnumeric, full line

app-office/gnumeric ~x86

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.keywords file. 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.3: Using a particular gnumeric version

=app-office/gnumeric-1.2.13 

3.c. Using Masked Packages

The package.unmask file

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 exact same line in /etc/portage/package.unmask.

For instance, if =net-mail/hotwayd-0.8 is masked, you can unmask it by adding the exact same line in the package.unmask file:

Code Listing 3.1: /etc/portage/package.unmask

=net-mail/hotwayd-0.8

The package.mask file

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 /etc/portage/package.mask.

For instance, if you don't want Portage to install newer kernel sources than development-sources-2.6.8.1, you add the following line to package.mask:

Code Listing 3.2: /etc/portage/package.mask example

>sys-kernel/development-sources-2.6.8.1

4. Additional Portage Tools

4.a. etc-update

etc-update is a tool that aids in merging the ._cfg0000_<name> files. It provides an interactive merging setup and can also auto-merge trivial changes. ._cfg0000_<name> files are generated by Portage when it wants to store a file in a directory protected by the CONFIG_PROTECT variable.

Running etc-update is pretty straight-forward:

Code Listing 1.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 1.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 without performing any 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 1.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 1.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.b. dispatch-conf

Using 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.

Like etc-update, you can ask to keep the configuration file as-is, use the new configuration file, edit the current one or merge the changes interactively. However, 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.

For more information, check out the dispatch-conf man page:

Code Listing 2.1: Reading the dispatch-conf man page

$ man dispatch-conf

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, arts and procps:

Code Listing 3.1: Example quickpkg usage

# quickpkg curl arts procps

The prebuilt packages will be stored in /usr/portage/packages/All. Symbolic links pointing to these packages are placed in /usr/portage/packages/<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.

By default, rsync will check the contents of /etc/portage/rsync_excludes (if it exists) which contains the categories or packages that you don't want rsync to update.

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/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.

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 development-sources-2.6.8.1 which you've installed manually, add the following line to /etc/portage/profile/package.provided:

Code Listing 3.1: Example line for package.provided

sys-kernel/development-sources-2.6.8.1

6. The Ebuild Application

6.a. Emerge and Ebuild

The ebuild application is a lower level interface to the Portage system. Using this application you can execute specific actions against a given ebuild. For instance, you can perform the individual merging steps by yourself.

Using ebuild is more for development purposes; more information about ebuild can therefore be found in the Developers Handbook. However, we will explain what ebuild instances are invoked by Portage during the merge process of a certain software title, and how to invoke the post-configuration steps some ebuilds allow you to perform.

6.b. Manually Installing Software

Fetching the Sources & Checksumming

Whenever you invoke ebuild against a given ebuild file, it will verify if the checksums of all involved files are equal to those given in the accompanying Manifest or files/digest-<name>-<version> file. This happens after the sources have been fetched.

To fetch the sources using ebuild, run:

Code Listing 2.1: Fetching the sources

# ebuild path/to/ebuild fetch

If the ebuild's md5sum does not match the one listed in the Manifest file, or one of the downloaded sources don't match those listed in the files/digest-<package> file, you will receive an error similar to this:

Code Listing 2.2: Ebuild checksum failure

!!! File is corrupt or incomplete. (Digests do not match)
>>> our recorded digest: db20421ce35e8e54346e3ef19e60e4ee
>>>  your file's digest: f10392b7c0b2bbc463ad09642606a7d6

The subsequent line will mention the erroneous file.

If you are certain that the sources you've fetched and the ebuild itself are valid, you can regenerate the Manifest and digest-<package> file using ebuild's digest functionality:

Code Listing 2.3: Regenerate Manifest and digest

# ebuild path/to/ebuild digest

Unpacking the Sources

To unpack the sources in /var/tmp/portage (or any other directory location you have specified in /etc/make.conf), run ebuild's unpack functionality:

Code Listing 2.4: Unpacking the sources

# ebuild path/to/ebuild unpack

This will execute the ebuild's src_unpack() function (which defaults to plain extraction if no src_unpack() function is defined). It is also in this step that all necessary patches are applied.

Compiling the Sources

The next step in the merge process is to compile the sources. The ebuild's compile functionality takes care of this step by executing the src_compile() function in the ebuild. This also includes the configure steps if appropriate.

Code Listing 2.5: Compiling the sources

# ebuild path/to/ebuild compile

You are advised to edit the ebuild's src_compile() function if you want to change the compilation instructions. However, you can also trick Portage into believing that the ebuild application has finished the compile steps. Run all necessary commands yourself and create an empty file called .compiled in the working directory:

Code Listing 2.6: Informing Portage about the finished compilation jobs

# touch .compiled

Installing the Files in a Temporary Location

In the next step Portage will install all necessary files in a temporary location. This directory will then contain all files that are to be merged on the live filesystem. You can accomplish this by running ebuild's install functionality, which executes the ebuild's src_install() function:

Code Listing 2.7: Installing the files

# ebuild path/to/ebuild install

Merging the Files onto the Live Filesystem

The final step is to merge all files onto the live filesystem and register those in the Portage backend. ebuild calls this step "qmerge" and involves the following steps:

  • Execute the pkg_preinst() function if specified
  • Copy over all files to the live filesystem
  • Register the files in the Portage backend
  • Execute the pkg_postinst() function if specified

Run ebuild's qmerge functionality to accomplish these steps:

Code Listing 2.8: Merging the files on the live filesystem

# ebuild path/to/ebuild qmerge

Cleaning the Temporary Directory

Finally you can clean the temporary directory using ebuild's clean functionality:

Code Listing 2.9: Cleaning the temporary directory

# ebuild path/to/ebuild clean

6.c. Additional Ebuild Features

Running all Merge-related Commands

Using ebuild's merge functionality you can run the fetch, unpack, compile, install and qmerge commands in one go:

Code Listing 3.1: Installing software

# ebuild path/to/ebuild merge

Performing Configuration Actions

Some applications include instructions that configure the package further on your system. These instructions can be interactive and are therefore not automatically executed. To run these configuration steps, which are enlisted in the ebuild's (optional) config() function, use ebuild's config functionality:

Code Listing 3.2: Configuring a package

# ebuild path/to/ebuild config

Building an (RPM) Package

You can instruct Portage to create a binary package of an ebuild or even an RPM file. Use ebuild's package or rpm functionality to create these archives. There are a few differences between those functionalities though:

  • The package functionality is a lot like the merge functionality, executing all necessary steps (fetch, unpack, compile, install) before creating the package
  • The rpm functionality builds an RPM package from the files created after having run ebuild's install functionality

Code Listing 3.3: Creating packages

(For a Portage-compatible binary package)
# ebuild path/to/ebuild package

(For an RPM package)
# ebuild path/to/ebuild rpm

The created RPM file however does not contain the ebuild's dependency information.

6.d. More Information

Please consult the following man pages for more information about Portage, the ebuild application and the ebuild files:

Code Listing 4.1: Man pages

$ man portage    (Portage itself)
$ man emerge     (The emerge command)
$ man ebuild     (The ebuild command)
$ man 5 ebuild   (The ebuild file syntax)

You will also find more development-related information in the Developers Handbook.

Print

Page updated September 25, 2004

Summary: This is the Gentoo Handbook, an effort to centralise Gentoo/Linux information.

Sven Vermeulen
Author

Daniel Robbins
Author

Chris Houser
Author

Jerry Alexandratos
Author

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
Editor

Pierre-Henri Jondot
Editor

Eric Stockbridge
Editor

Rajiv Manglani
Editor

Jungmin Seo
Editor

Stoyan Zhekov
Editor

Jared Hudson
Editor

Colin Morey
Editor

Jorge Paulo
Editor

Carl Anderson
Editor

Jon Portnoy
Editor

Zack Gilburd
Editor

Jack Morgan
Editor

Benny Chuang
Editor

Erwin
Editor

Joshua Kinard
Editor

Tobias Scherbaum
Editor

Grant Goodyear
Reviewer

Gerald J. Normandin Jr.
Reviewer

Donnie Berkholz
Reviewer

Ken Nowack
Reviewer

Lars Weiler
Contributor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.