Gentoo Linux/MIPS Handbook

Content:

• Installing Gentoo
  In this part you learn how to install Gentoo on your system.
  1. About the Gentoo Linux Installation
     This chapter introduces you to the installation approach documented in this part.
  2. Choosing the Right Installation Medium
     You can install Gentoo in many ways. In this chapter we explain how to install Gentoo using the MIPS Netboot images.
  3. Configuring your Network
     To be able to download the latest source code, you will need to setup 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 a stage3 archive. In this chapter we describe how you extract the stage3 archive and configure Portage.
  6. Installing the Gentoo Base System
     After installing and configuring a stage3, 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
      On both Silicon Graphics machines, and on Cobalt servers, both require the use of a bootloader to load the kernel. This section covers setting up arcboot/arcload (for SGI machines) and colo for Cobalt servers.
  11. Finalizing your Gentoo Installation
      You're almost done. We'll just create one (or more) users for your 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.
• Gentoo Network Configuration
  A comprehensive guide to Networking in Gentoo.
  1. Getting Started
     A guide to quickly get your network interface up and running in most common environments.
  2. Advanced Configuration
     Here we learn about how the configuration works - you need to know this before we learn about modular networking.
  3. Modular Networking
     Gentoo provides you flexible networking - here you are told about choosing different DHCP clients, setting up bonding, bridging, VLANs and more.
  4. Wireless Networking
     Wireless isn't straight-forward. Hopefully we'll get you working!
  5. Adding Functionality
     If you're feeling adventurous, you can add your own functions to networking.
  6. Network Management
     For laptop users or people who move their computer around different networks.

A. Installing Gentoo

1. About the Gentoo Linux Installation

1.a. Introduction

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
• After step 3, your hard disks are initialized to house your Gentoo installation
• After step 4, your installation environment is prepared and you are ready to chroot into the new environment
• After step 5, core packages, which are the same on all Gentoo installations, are installed
• After step 6, you have compiled your Linux kernel
• After step 7, you have written most of your Gentoo system configuration files
• After step 8, necessary system tools (which you can choose from a nice list) are installed
• After step 9, your choice of bootloader has been installed and configured and you are logged in into your new Gentoo installation
• After step 10, your Gentoo Linux environment is ready to be explored

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

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

What are my Options?

You can install Gentoo in many different ways. You can download and install from one of our Installation CDs, from 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 a Gentoo Installation CD or, in certain cases, NetBooting. This installation assumes that you want to install the latest available version of each package. If you want to perform a networkless installation, you should read the Gentoo 2006.1 Handbooks which contain the installation instructions for a networkless environment.

Also note that, if you plan on using GRP (the Gentoo Reference Platform, a collection of prebuilt packages meant for immediate use after a Gentoo installation), you must follow the instructions in the Gentoo 2006.1 Handbooks.

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

You also have several possibilities: you can compile your entire system from scratch or use a prebuilt environment 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 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 :-)

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.

Hardware Requirements

You should also check the MIPS Hardware Requirements document available from our website.

2.b. Installation Notes

A note about Processor Architectures

On many architectures, the processor has gone through several generations, each newer generation builds on the foundation of the previous one. MIPS is no exception. There are several generations of CPU covered under the MIPS architecture. In order to choose your netboot image stage tarball and CFLAGS appropriately, you need to be aware of which family your system's CPU belongs in. These families are referred to as the Instruction Set Architecture.

Also, another important concept to grasp is the concept of endianness. Endianness refers to the way that a CPU reads words from main memory. A word can be read as either big endian (most significant byte first), or little endian (least significant byte first). Intel x86 machines are generally Little endian, whilst Apple and Sparc machines are Big Endian. On MIPS, they can be either. To separate them apart, we append el to the architecture name to denote little endian.

For those willing to learn more about ISAs, the following websites may be of assistance.

• Linux/MIPS Website: MIPS ISA
• Linux/MIPS Website: Endianness
• Linux/MIPS Website: Processors
• Wikipedia: Instruction Set

The Stage3 Tarball

A stage3 tarball is an archive containing a minimal Gentoo environment, suitable to continue the Gentoo installation using the instructions in this manual. Previously, the Gentoo Handbook described the installation using one of three stage tarballs. While Gentoo still offers stage1 and stage2 tarballs, the official installation method uses the stage3 tarball. If you are interested in performing a Gentoo installation using a stage1 or stage2 tarball, please read the Gentoo FAQ on How do I Install Gentoo Using a Stage1 or Stage2 Tarball?

2.c. Netbooting Overview

In this section, we'll cover what you need in order to successfully network boot a Silicon Graphics workstation or Cobalt Server appliance. This is just a brief guide, it is not intended to be thorough, for more information, it is recommended that you read the Diskless HOWTO.

What You Need: Depending on the machine, there is a certain amount of hardware that you'll need in order to successfully netboot and install Linux.

• In General:
  • DHCP/BOOTP server (ISC DHCPd recommended)
  • Patience -- and lots of it
• For Silicon Graphics workstations:
  • TFTP server (tftp-hpa recommended)
  • If you want/need to use serial console:
    • MiniDIN8 --> RS-232 serial cable
    • Null-modem cable
    • VT100 or ANSI compatible terminal capable of 9600 baud
• For Cobalt Servers (NOT the original Qube):
  • NFS server
  • Null-modem cable
  • VT100 or ANSI compatible terminal capable of 115200 baud

Setting up TFTP and DHCP -- a brief guide

Okay, so you've got your bits and pieces together, now to set everything up. As mentioned earlier -- this is not a complete guide, this is a bare-bones config that will just get things rolling. You can either use this when starting a setup from scratch, or use the suggestions to amend your existing setup to support netbooting.

It is worth noting that the servers used need not be running Gentoo Linux, you could quite reasonably use FreeBSD or any Unix-like platform. However, this guide will assume you are running Gentoo Linux. You also may run TFTP/NFS on a separate machine to the DHCP server if desired.

First Step -- configuring DHCP. In order for the ISC DHCP daemon to respond to BOOTP requests (as required by the SGI & Cobalt BOOTROM) you need to first enable dynamic BOOTP on the address range in use; then set up an entry for each client with pointers to the boot image.

# emerge dhcp

Once installed you need to create the /etc/dhcp/dhcpd.conf. Here's a bare-bones config to get you started.

# Tell dhcpd to disable dynamic DNS.
# dhcpd will refuse to start without this.
ddns-update-style none;

# Create a subnet:
subnet 192.168.10.0 netmask 255.255.255.0 {
  # Address pool for our booting clients. Don't forget the 'dynamic-bootp' bit!
  pool {
    range dynamic-bootp 192.168.10.1 192.168.10.254;
  }

  # DNS servers and default gateway -- substitute as appropriate
  option domain-name-servers 203.1.72.96, 202.47.56.17;
  option routers 192.168.10.1;

  # Tell the DHCP server it's authoritative for this subnet.
  authoritative;

  # Allow BOOTP to be used on this subnet.
  allow bootp;
}

With that setup, one can then add any number of clients within the subnet clause. We will cover what you need to put in later in this guide.

Next Step -- Setting up TFTP server. It is recommended that you use tftp-hpa as it is the only TFTP daemon known to work correctly. Proceed by installing it as shown below.

# emerge net-ftp/tftp-hpa

This will create /tftproot for you to store the netboot images. You may move this elsewhere if you wish. For the purposes of this guide, it is assumed that you have left it in the default location.

2.d. Netbooting on SGI Workstations

Downloading a Netboot image

Depending on the system you're installing for, there are several possible images available for download. These are all labelled according to the system type and CPU they are compiled for. The machine types are as follows:

Also in the filename, r4k refers to R4000-series processors, r5k for R5000, rm5k for the RM5200 and r10k for R10000. You will find the images available at http://dev.gentoo.org/~kumba/mips/netboot.

DHCP Configuration for an SGI Client

Once you have downloaded the file, place the decompressed image file in your /tftproot directory. (Use bzip2 -d to decompress) Then edit your /etc/dhcp/dhcpd.conf and add the entry for your SGI client.

subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
  # ... usual stuff here ...

  # SGI Workstation... change 'sgi' to your SGI machine's hostname.
  host sgi {
  
    # MAC Address of SGI Machine. Normally this is written on the back
    # or base of the machine.
    hardware ethernet 08:00:69:08:db:77;

    # TFTP Server to download from (by default, same as DHCP server)
    next-server 192.168.10.1;

    # IP address to give to the SGI machine
    fixed-address 192.168.10.3;

    # Filename for the PROM to download and boot
    filename "/gentoo-r4k.img";
  }
}

Kernel Options

We're almost done, but there's a couple of little tweaks still to be done. Pull up a console with root privileges, and enter the following commands.

(Disable "Path Maximum Transfer Unit", otherwise SGI Prom won't find the kernel)
# echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

(Set the port range usable by the SGI PROM)
# echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range

This should be sufficient to allow the Linux server to play nice with SGI's PROM.

Start Your Daemons...

At this point, you should be ready to start the daemons. Enter the following:

# /etc/init.d/dhcp start
# /etc/init.d/in.tftpd start

If nothing went wrong in that last step you should be all set to power on the workstation and proceed with the guide. If the DHCP server isn't firing up for whatever reason, try running 'dhcpd' on the command line and see what it tells you -- if all is well, it should just fork into the background, otherwise you'll see 'exiting.' just below its complaint.

An easy way to verify if the tftp daemon is running is to type the following command -- if you see something like the output mentioned below -- everything is fine.

# netstat -al | grep ^udp
udp        0      0 *:bootpc                *:*
udp        0      0 *:631                   *:*
udp        0      0 *:xdmcp                 *:*
udp        0      0 *:tftp                  *:* <-- (look for this line)

Netbooting the SGI machine

Okay, everything is set, DHCP is running as is TFTP. Now it is time to fire up the SGI machine. Power the unit on -- when you see "Running power-on diagnostics" on the screen, either click "Stop For Maintenance" or press ESCAPE. You'll be presented with a menu like the following. Enter the commands as shown below.

        Running power-on diagnostics

System Maintenance Menu

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor. Type "exit" to return to the menu.
>> bootp(): root=/dev/ram0

From this point, the machine should start downloading the image, then, roughly 20 seconds later, start booting Linux. If all is well, you should be dropped at the Busybox ash shell as shown below, where you can move on to Configuring Your Network.

init started:  BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL

 Gentoo/MIPS Netboot for Silicon Graphics Machines
 Build Date: April 26th, 2004

 * To configure networking, do the following:

 * For Static IP:
 * /bin/net-setup <IP Address> <Gateway Address> [telnet]

 * For Dynamic IP:
 * /bin/net-setup dhcp [telnet]

 * If you would like a telnetd daemon loaded as well, pass "telnet"
 * As the final argument to /bin/net-setup.

Please press Enter to activate this console.

Troubleshooting.

If the machine is being stubborn and refusing to download its image, it can be one of two things, (1) you've made a blunder somewhere, or (2) it needs a little gentle persuasion. (No, put that sledge hammer down!) Here's a list of things you can check:

• dhcpd is giving the SGI Machine an IP Address. You should see some messages about a BOOTP request in the system logs. tcpdump is also useful here.
• Permissions are set properly in your tftp folder (typically /tftproot -- should be world readable)
• Check system logs to see what the tftp server is reporting (errors perhaps)

If you've checked everything on the server, and you're getting timeouts, etc on the SGI machine, try typing this into the console.

>> resetenv
>> unsetenv netaddr
>> unsetenv dlserver
>> init
>> bootp(): root=/dev/ram0

2.e. Alternative Method: Gentoo/MIPS SGI LiveCD

Overview

On Silicon Graphics machines, it is possible to boot from a CD in order to install operating systems. (This is how one installs IRIX for instance) Recently, images for such bootable CDs to install Gentoo have been made possible. These CDs are designed to work in the same way.

At the moment the Gentoo/MIPS Live CD will only work on the SGI Indy, Indigo 2 and O2 workstations equipped with R4000 and R5000-series CPUs, however other platforms may be possible in future.

You can find the Live CD images for download on your favourite Gentoo Mirror under the experimental/mips/livecd directory.

Burning a Live CD

An important thing to note, the SGI PROM does not understand the ISO9660 format, nor does it know anything about the El Torito boot standard. These CD images are constructed as a SGI disklabel with the boot image in the volume header like a hard drive. Therefore, care must be taken when burning the CD image.

Below is an example command that assumes 24x burning speed on an IDE burner. If you have a SCSI burner for instance, you may want to adjust the dev statement as appropriate. Likewise with the speed option - if you strike troubles, you might want to try dropping the speed.

# bzip2 -d mips-livecd-prototype-rc2-20041027.img.bz2
# cdrecord -vv -pad speed=24 dev=ATAPI:0,0,0 -tao mips-livecd-prototype-rc2-20041027.img

2.f. Netbooting on Cobalt Servers

Overview of the netboot procedure

Unlike the SGI machines, Cobalt servers use NFS to transfer their kernel for booting. You boot the machine by holding down the left & right arrow buttons whilst powering the unit on. The machine will then attempt to obtain an IP number via BOOTP, mount the /nfsroot directory from the server via NFS, then try to download and boot the file vmlinux_raq-2800.gz (depending on the model) which it assumes to be a standard ELF binary.

Downloading a Netboot image

Inside http://dev.gentoo.org/~redhatter/mips/cobalt/netboots/ you'll find the necessary boot images for getting a Cobalt up and running. The files you need will have the name nfsroot-KERNEL-COLO-DATE-cobalt.tar -- select the most recent one and unpack it to / as shown below:

# tar -C / -xvf nfsroot-2.6.13.4-1.19-20051122-cobalt.tar

NFS Server configuration

Since this machine uses NFS to download its image, you need to export /nfsroot on your server. If you have not already done so, you'll need to install the net-fs/nfs-utils package.

# emerge net-fs/nfs-utils

Once that is done, place the following in your /etc/exports file. You may set tighter restrictions if you wish.

/nfsroot      *(ro,sync)

Now, once that is done, you may start the NFS server:

# /etc/init.d/nfs start

If the NFS server was already running at the time, you can tell it to take another look at its exports file using exportfs.

# exportfs -av

DHCP Configuration for a Cobalt machine

Now, the DHCP side of things is relatively straightforward. Add the following to your /etc/dhcp/dhcpd.conf file.

subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
  # ... usual stuff here ...

  # Configuration for a Cobalt Server
  # Set the hostname here:
  host qube {
    # Path to the nfsroot directory.
    # This is mainly for when using the TFTP boot option on CoLo
    # You shouldn't need to change this.
    option root-path "/nfsroot";

    # Cobalt server's ethernet MAC address
    hardware ethernet 00:10:e0:00:86:3d;

    # Server to download image from
    next-server 192.168.10.1;

    # IP address of cobalt server
    fixed-address 192.168.10.2;

    # Location of the default.colo file relative to /nfsroot
    # You shouldn't need to change this.
    filename "default.colo";
  }
}

Start Your Daemons...

At this point, you should be ready to start the daemons. Enter the following:

# /etc/init.d/dhcp start
# /etc/init.d/nfs start

If nothing went wrong in that last step you should be all set to power on the workstation and proceed with the guide. If the DHCP server isn't firing up for whatever reason, try running 'dhcpd' on the command line and see what it tells you -- if all is well, it should just fork into the background, otherwise you'll see 'exiting.' just below its complaint.

Netbooting the Cobalt machine

Okay, everything is set, DHCP is running as is NFS. Now it is time to fire up the Cobalt machine. Hook up your null modem cable, and set the serial terminal to use 115200 baud, 8 bits, no parity, 1 stop bit, VT100 emulation. Once that is done, hold down the left & right arrow buttons whilst powering the unit on.

If all is well, the back panel should display "Net Booting", you should see some network activity, closely followed by CoLo kicking in. On the rear panel, scroll down the menu until you see "Network (NFS)" then press ENTER. You should notice the machine starts booting on the serial console.

elf: 80080000 <-- 00001000 6586368t + 192624t
elf: entry 80328040
net: interface down
CPU revision is: 000028a0
FPU revision is: 000028a0
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB 2-way, linesize 32 bytes.
Linux version 2.4.26-mipscvs-20040415 (root@khazad-dum) (gcc version 3.3.3...
Determined physical RAM map:
 memory: 08000000 @ 00000000 (usable)
Initial ramdisk at: 0x80392000 (3366912 bytes)
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,115200 root=/dev/ram0
Calibrating delay loop... 249.85 BogoMIPS
Memory: 122512k/131072k available (2708k kernel code, 8560k reserved, 3424k dat)

If all is well, you should be dropped at the Busybox ash shell as shown below, where you can go onto Configuring Your Network.

VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 280k freed
init started:  BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL

 Gentoo/MIPS Netboot for Cobalt Microserver Machines
 Build Date: April 26th, 2004

 * To configure networking, do the following:

 * For Static IP:
 * /bin/net-setup <IP Address> <Gateway Address> [telnet]

 * For Dynamic IP:
 * /bin/net-setup dhcp [telnet]

 * If you would like a telnetd daemon loaded as well, pass "telnet"
 * As the final argument to /bin/net-setup.

Please press Enter to activate this console.

Troubleshooting.

If the machine is being stubborn and refusing to download its image, it can be one of two things, (1) you've made a blunder somewhere, or (2) it needs a little gentle persuasion. (No, put that sledge hammer down!) Here's a list of things you can check:

• dhcpd is giving the Cobalt Machine an IP Address. You should see some messages about a BOOTP request in the system logs. tcpdump is also useful here.
• Permissions are set properly in your /nfsroot folder. (should be world readable)
• Make sure the NFS server is running and exporting the /nfsroot directory. Check this using exportfs -v on the server.

3. Configuring your Network

3.a. Automatic Network Detection

Maybe it just works?

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

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

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

Optional: Configure any Proxies

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

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

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

http://username:password@proxy.gentoo.org:8080

Testing the Network

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

# ping -c 3 www.yahoo.com

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

3.b. Automatic Network Configuration

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

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

• Regular Ethernet users should continue with Default: Using net-setup
• ADSL users should continue with Alternative: Using RP-PPPoE
• PPTP users should continue with Alternative: Using PPTP

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:

# 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 Installation CD (any version) has made things easy for you by including rp-pppoe. Use the provided pppoe-setup script to configure your connection. You will be prompted for the ethernet device that is connected to your adsl modem, your username and password, the IPs of your DNS servers and if you need a basic firewall or not.

# pppoe-setup
# pppoe-start

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

If everything worked, continue with Preparing the Disks.

Alternative: Using PPTP

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

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

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

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

# pptp <server ip>

Now continue with Preparing the Disks.

3.c. Manual Network Configuration

Loading the Appropriate Network Modules

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

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

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

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

If you find a driver for your network card, use modprobe to load the 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:

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

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

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

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

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

• Using DHCP for automatic IP retrieval
• Preparing for Wireless Access if you have a wireless card
• Understanding Network Terminology explains what you need to know about networking
• Using ifconfig and route explains how to set up your networking manually

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:

# 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

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:

# 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            

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:

(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

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

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

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. every host that you are able to reach must have a unique IP address). In order to distinguish between hosts inside and outside a network, the IP address is divided in two parts: the network part and the host part.

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

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.

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:

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:

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

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

# route add default gw ${GATEWAY}

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

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

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 SCSI HD in a Linux system, namely /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. These are called partitions.

4.b. Designing a Partitioning Scheme

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. You will definitely want to keep /usr big: not only will it contain the majority of applications, the Portage tree alone takes around 500 Mbyte excluding the various sources that are stored in it.

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

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

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

4.c. Using fdisk on MIPS to Partition your Disk

SGI Machines: Creating an SGI Disk Label

All disks in an SGI System require an SGI Disk Label, which serves a similar function as Sun & MS-DOS disklabels -- It stores information about the disk partitions. Creating a new SGI Disk Label will create two special partitions on the disk:

• SGI Volume Header (9th partition): This partition is important. It is where the bootloader will reside, and in some cases, it will also contain the kernel images.
• SGI Volume (11th partition): This partition is similar in purpose to the Sun Disklabel's third partition of "Whole Disk". This partition spans the entire disk, and should be left untouched. It serves no special purpose other than to assist the PROM in some undocumented fashion (or it is used by IRIX in some way).

The following is an example excerpt from an fdisk session. Read and tailor it to your needs...

# fdisk /dev/sda

Command (m for help): x

Expert command (m for help): m
Command action
   b   move beginning of data in a partition
   c   change number of cylinders
   d   print the raw data in the partition table
   e   list extended partitions
   f   fix partition order
   g   create an IRIX (SGI) partition table
   h   change number of heads
   m   print this menu
   p   print the partition table
   q   quit without saving changes
   r   return to main menu
   s   change number of sectors/track
   v   verify the partition table
   w   write table to disk and exit

Expert command (m for help): g
Building a new SGI disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content will be irrecoverably lost.

Expert command (m for help): r

Command (m for help): p

Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 17482 cylinders
Units = cylinders of 2048 * 512 bytes

----- partitions -----
Pt#     Device  Info     Start       End   Sectors  Id  System
 9:  /dev/sda1               0         4     10240   0  SGI volhdr
11:  /dev/sda2               0     17481  35803136   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----

Command (m for help):

Getting the SGI Volume Header to just the right size

Now that an SGI Disklabel is created, partitions may now be defined. In the above example, there are already two partitions defined for you. These are the special partitions mentioned above and should not normally be altered. However, for installing Gentoo, we'll need to load a bootloader, and possibly multiple kernel images (depending on system type) directly into the volume header. The volume header itself can hold up to eight images of any size, with each image allowed eight-character names.

The process of making the volume header larger isn't exactly straight-forward; there's a bit of a trick to it. One cannot simply delete and re-add the volume header due to odd fdisk behavior. In the example provided below, we'll create a 50MB Volume header in conjunction with a 50MB /boot partition. The actual layout of your disk may vary, but this is for illustrative purposes only.

Command (m for help): n
Partition number (1-16): 1
First cylinder (5-8682, default 5): 51
 Last cylinder (51-8682, default 8682): 101

(Notice how fdisk only allows Partition #1 to be re-created starting at a     )
(minimum of cylinder 5?  Had you attempted to delete & re-create the SGI      )
(Volume Header this way, this is the same issue you would have encountered.   )
(In our example, we want /boot to be 50MB, so we start it at cylinder 51 (the )
(Volume Header needs to start at cylinder 0, remember?), and set its ending   )
(cylinder to 101, which will roughly be 50MB (+/- 1-5MB).                     )

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

(Delete Partition #9 (SGI Volume Header))

Command (m for help): n
Partition number (1-16): 9
First cylinder (0-50, default 0): 0
 Last cylinder (0-50, default 50): 50

(Re-Create Partition #9, ending just before Partition #1)

If you're unsure how to use fdisk have a look down further at the instructions for partitioning on Cobalts. The concepts are exactly the same -- just remember to leave the volume header and whole disk partitions alone.

Once this is done, you are safe to create the rest of your partitions as you see fit. After all your partitions are laid out, make sure you set the partition ID of your swap partition to 82, which is Linux Swap. By default, it will be 83, Linux Native.

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

Cobalt Machines: Partitioning your drive

On Cobalt machines, the BOOTROM expects to see a MS-DOS MBR, so partitioning the drive is relatively straightforward -- in fact, it's done the same way as you'd do for an Intel x86 machine. However there are some things you need to bear in mind.

• Cobalt firmware will expect /dev/hda1 to be a Linux partition formatted EXT2 Revision 0. EXT2 Revision 1 partitions will NOT WORK! (The Cobalt BOOTROM only understands EXT2r0)
• The above said partition must contain a gzipped ELF image, vmlinux.gz in the root of that partition, which it loads as the kernel

For that reason, I recommend creating a ~20MB /boot partition formatted EXT2r0 upon which you can install CoLo & your kernels. This allows you to run a modern filesystem (EXT3 or ReiserFS) for your root filesystem.

I will assume you have created /dev/hda1 to mount later as a /boot partition. If you wish to make this /, you'll need to keep the PROM's expectations in mind.

So, continuing on... To create the partitions you type fdisk /dev/hda at the prompt. The main commands you need to know are these:

• o: Wipe out old partition table, starting with an empty MS-DOS partition table
• n: New Partition
• t: Change Partition Type
  • Use type 82 for Linux Swap, 83 for Linux FS
• d: Delete a partition
• p: Display (print) Partition Table
• q: Quit -- leaving old partition table as is.
• w: Quit -- writing partition table in the process.

# fdisk /dev/hda

The number of cylinders for this disk is set to 19870.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

(Start by clearing out any existing partitions)
Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 19870.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

(You can now verify the partition table is empty using the 'p' command)

Command (m for help): p

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System

(Create the /boot partition)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1

(Just press ENTER here to accept the default)

First cylinder (1-19870, default 1):
Last cylinder or +size or +sizeM or +sizeK (1-19870, default 19870): +20M

(and now if we type 'p' again, we should see the new partition)
Command (m for help): p

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          40       20128+  83  Linux

(The rest, I prefer to put in an extended partition, so I'll create that)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
e
Partition number (1-4): 2

(Again, the default is fine, just press ENTER.)

First cylinder (41-19870, default 41):
Using default value 41

(We want to use the whole disk here, so just press ENTER again)
Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870):
Using default value 19870

(Now, the / partition -- I use separate partitions for /usr, /var,
etc... so / can be small. Adjust as per your preference.)

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (41-19870, default 41):<Press ENTER>
Using default value 41
Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870): +500M

(... and similar for any other partitions ...)

(Last but not least, the swap space. I recommend at least 250MB swap,
preferrably 1GB)

Command (m for help): n
Command action
   l   logical (5 or over)
   p   primary partition (1-4)
l
First cylinder (17294-19870, default 17294): <Press ENTER>
Using default value 17294
Last cylinder or +size or +sizeM or +sizeK (1011-19870, default 19870): <Press ENTER>
Using default value 19870

(Now, if we check our partition table, everything should mostly be ship
shape except for one thing...)

Command (m for help): p

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot      Start         End      Blocks      ID  System
/dev/hda1               1          21       10552+  83  Linux
/dev/hda2              22       19870    10003896    5  Extended
/dev/hda5              22        1037      512032+  83  Linux
/dev/hda6            1038        5101     2048224+  83  Linux
/dev/hda7            5102        9165     2048224+  83  Linux
/dev/hda8            9166       13229     2048224+  83  Linux
/dev/hda9           13230       17293     2048224+  83  Linux
/dev/hda10          17294       19870     1298776+  83  Linux

(Notice how #10, our swap partition is still type 83?)

Command (m for help): t
Partition number (1-10): 10
Hex code (type L to list codes): 82
Changed system type of partition 10 to 82 (Linux swap)

(That should fix it... just to verify...)

Command (m for help): p

Disk /dev/hda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot      Start         End      Blocks      ID  System
/dev/hda1               1          21       10552+  83  Linux
/dev/hda2              22       19870    10003896    5  Extended
/dev/hda5              22        1037      512032+  83  Linux
/dev/hda6            1038        5101     2048224+  83  Linux
/dev/hda7            5102        9165     2048224+  83  Linux
/dev/hda8            9166       13229     2048224+  83  Linux
/dev/hda9           13230       17293     2048224+  83  Linux
/dev/hda10          17294       19870     1298776+  82  Linux Swap

(Now, we write out the new partition table.)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

#

And that's all there is to it. You should now be right to proceed onto the next stage: 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?

Several filesystems are available. ReiserFS, EXT2 and EXT3 are found stable on the MIPS architectures, others are experimental.

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.

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:

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

# mke2fs /dev/sda1
# mke2fs -j /dev/sda3

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

Activating the Swap Partition

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

# mkswap /dev/sda2

To activate the swap partition, use swapon:

# swapon /dev/sda2

Create and activate the swap with the commands mentioned above.

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:

# mount /dev/sda3 /mnt/gentoo
# mkdir /mnt/gentoo/boot
# mount /dev/sda1 /mnt/gentoo/boot

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:

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

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 March 29th, 16:21 in the year 2005:

# date 032916212005

Making your Choice

The next step you need to perform is to install the stage tarball of your choice onto your system.

5.b. Downloading the Stage Tarball

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

# cd /gentoo

The table below specifies exactly which stages you need for your system. Stages may be downloaded off the official Gentoo mirrors under the releases/mips/current directory.

If you need to go through a proxy, export the http_proxy and ftp_proxy variables:

# export http_proxy="http://proxy.server.com:port"
# export ftp_proxy="http://proxy.server.com:port"

The Gentoo/MIPS netboot images provide wget as a means of downloading files. Due to space constraints, it is not possible to provide more capable browsers on SGI netboot images. LiveCD users may use elinks.

# wget -c http://distfiles.gentoo.org/releases/mips/mips4/stage3-mips4-2005.1.tar.bz2

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 mips4 stage tarball:

# md5sum -c stage3-mips4-2005.1.tar.bz2.md5
stage3-mips4-2005.1.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:

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

Make sure that you use the same options (-xjpf). The x stands for Extract, 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. Installing Portage

Unpacking a Portage Snapshot

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

Download and Install a Portage Snapshot

Go to the mountpoint where you mounted your filesystem (most likely /gentoo):

# cd /gentoo

Download a portage snapshot from a local mirror. You'll find them in the snapshots/ directory. Transfer it to the target system in the same manner that you did for the stage tarball.

# tar -xjf portage-*.tar.bz2 -C /gentoo/usr

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

Fire up a text editor so we can alter the optimization variables we will discuss hereafter. Two editors are provided, vi (part of Busybox) and nano. We will assume you're using nano.

# nano -w /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.

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). Examples include ISA levels (mips1 ... mips4) and CPU models (r4400, r4600 ... etc). For pure ISA level architectures, one can simply specify -mips3 rather than -march=mips3.

(For an R4600 system...)
-march=r4600

(Any MIPS4-class CPU...)
-march=mips4

(Or just specify the ISA level directly...)
-mips4

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:

-O2

A very important setting in the MIPS world, is the -mabi= flag. MIPS has 3 different ABIs; 32 (pure 32-bit, aka o32), 64 (full 64-bit, aka n64) and n32 (a mix of 32-bit data structures with 64-bit instructions). This flag selects which of these you wish to use. Note you need libraries for the ABI you select. In layman's terms, this means, for example, you can't use -mabi=64 on a 32-bit userland (or even a n32 userland).

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:

CFLAGS="-mabi=32 -mips4 -pipe -O2"
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.

MAKEOPTS="-j2"

Ready, Set, Go!

Update your /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

In order to download source code quickly it is recommended to select a fast mirror. Portage will look in your make.conf file for the GENTOO_MIRRORS variable and use the mirrors listed therein. You can surf to our mirror list and search for a mirror (or mirrors) close to you (as those are most frequently the fastest ones), but we provide a nice tool called mirrorselect which provides you with a nice interface to select the mirrors you want.

# mirrorselect -i -o >> /mnt/gentoo/etc/make.conf

A second important setting is the SYNC setting in make.conf. This variable contains the rsync server you want to use when updating your Portage tree (the collection of ebuilds, scripts containing all the information Portage needs to download and install software). Although you can manually enter a SYNC server for yourself, mirrorselect can ease that operation for you:

# mirrorselect -i -r -o >> /mnt/gentoo/etc/make.conf

After running mirrorselect it is adviseable to double-check the settings in /mnt/gentoo/etc/make.conf !

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.

(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 and /dev Filesystems

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

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

Entering the new Environment

Now that all partitions are initialized and the base environment installed, it is time to enter our new installation environment by chrooting into it. This means that we change from the current installation environment (Installation CD 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.

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

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

6.b. Configuring Portage

Updating the Portage tree

You should now update your Portage tree to the latest version. emerge --sync does this for you.

# emerge --sync
(If you're using a slow terminal like some framebuffers or a serial
console, you can add the --quiet option to speed up this process:)
# emerge --sync --quiet

If you are behind a firewall that blocks rsync traffic, you can use emerge-webrsync which will download and install a portage snapshot for you.

If you are warned that a new Portage version is available and that you should update Portage, you should do it now using emerge portage command.

Choosing the Right Profile

First, a small definition is in place.

A profile is a building block for any Gentoo system. Not only does it specify default values for CHOST, CFLAGS and other important variables, it also locks the system to a certain range of package versions. This is all maintained by the Gentoo developers.

Previously, such a profile was barely touched by the user. However, x86, hppa and alpha users can choose between two profiles, one for a 2.4 kernel and one for a 2.6 kernel. This requirement has been imposed to improve the integration of the 2.6 kernels. The ppc and ppc64 architectures have several profiles available as well. We will talk about those later.

You can see what profile you are currently using with the following command:

# ls -FGg /etc/make.profile
lrwxrwxrwx  1 48 Apr  8 18:51 /etc/make.profile -> ../usr/portage/profiles/default-linux/x86/2006.1/

If you are using one of the aforementioned three architectures, the default profile will provide you with a Linux 2.6-based system. This is the recommended default, but you have the option of choosing another profile too.

There are also desktop and server subprofiles available for some architectures. Look inside the 2006.1/ profile to see if there is one available for your architecture. You may wish to view the desktop profile's make.defaults to determine if it fits your needs.

Some users may wish to install a system based on the older Linux 2.4 profile. If you have good reason to do this, then you should first check that an additional profile exists. On x86, we can do this with the following command:

# ls -d /usr/portage/profiles/default-linux/x86/no-nptl/2.4
/usr/portage/profiles/default-linux/x86/no-nptl/2.4

The above example shows that the additional 2.4 profile exists (i.e. it didn't complain about missing file or directory). It is recommended that you stay with the default, but if you wish to switch, you can do so with as follows:

(Make sure you use the right architecture, the example below is for x86)
# ln -snf /usr/portage/profiles/default-linux/x86/no-nptl/2.4 /etc/make.profile
(List the files in the 2.4 profile)
# ls -FGg /etc/make.profile/
total 12
-rw-r--r--  1 939 Dec 10 14:06 packages
-rw-r--r--  1 347 Dec  3  2004 parent
-rw-r--r--  1 573 Dec  3  2004 virtuals

For ppc, there are a number of new profiles provided with 2006.1:

(Generic PPC profile, for all PPC machines, minimal)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc32/2006.1 /etc/make.profile
(G3 profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc32/2006.1/G3 /etc/make.profile
(G3 Pegasos profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc32/2006.1/G3/Pegasos/ /etc/make.profile
(G4 (Altivec) profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc32/2006.1/G4 /etc/make.profile
(G4 (Altivec) Pegasos profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc32/2006.1/G4/Pegasos/ /etc/make.profile

For ppc64, there are a number of new profiles provided with 2006.1:

(Generic 64bit userland PPC64 profile, for all PPC64 machines)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/64bit-userland /etc/make.profile
(Generic 32bit userland PPC64 profile, for all PPC64 machines)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/32bit-userland /etc/make.profile
(Each type of userland has sub profiles as follows, with (userland) replaced with the chosen userland from above)
(970 profile for JS20)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/(userland)/970 /etc/make.profile
(G5 profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/(userland)/970/pmac /etc/make.profile
(POWER3 profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/(userland)/power3 /etc/make.profile
(POWER4 profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/(userland)/power4 /etc/make.profile
(POWER5 profile)
# ln -snf /usr/portage/profiles/default-linux/ppc/ppc64/2006.1/(userland)/power5 /etc/make.profile
(The multilib profile is not stable as of this release.)

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 the make.defaults files of your profile. You will find make.defaults files in the directory which /etc/make.profile points to and all parent directories as well. The default USE setting is the sum of all USE settings in all make.defaults files. 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.

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

# nano -w /etc/make.conf

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

Optional: GLIBC Locales

You will probably only use one or maybe two locales on your system. You can specify locales you will need in /etc/locale.gen.

# nano -w /etc/locale.gen

The following locales are an example to get both English (United States) and German (Germany) with the accompanying character formats (like UTF-8).

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

The next step is to run locale-gen. It will generate all the locales you have specified in the /etc/locale.gen file.

Now 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 copy it to /etc/localtime. Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8.

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

MIPS-based systems have just the one kernel tree to choose from, mips-sources. This patchset differs from the ones available for other architectures, in that it has lots of patches specific to the MIPS architecture.

(Unpack & install the kernel sources)
# USE="-doc" emerge mips-sources

# emerge kgcc64

When you take a look in /usr/src you should see a symlink called linux pointing to your kernel source. In this case, the installed kernel source points to mips-sources-2.6.13.4. Your version may be different, so keep this in mind.

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

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

# rm /usr/src/linux
# cd /usr/src
# ln -s linux-2.6.13.4 linux

Now it is time to configure and compile your kernel source.

7.c. Kernel Compilation & Installation

Introduction

Previously, we went through the manual configuration of how to set up the kernel sources. This has become impractical with the number of systems we now support. This section details various sources for sample kernel configurations.

Using sample configurations in the kernel source

Many of the systems supported have sample .configs hiding in amongst the kernel source. Not all systems have configs distributed in this way. Those that do, can be configured using the commands mentioned in the table below.

Using the running kernel config from the installation media

All of the Gentoo installation images provide a kernel config option as part of the image itself, accessible as /proc/config.gz. This may be used in many cases. It is best though if your kernel source matches closely, the kernel that is currently running. To extract it, simply run it through zcat as shown below.

# zcat /proc/config.gz > .config

The Hardware Compatability Database

As an aid to users in finding working settings, a hardware compatability database was set up. This database lists the support for various MIPS devices, and allows users to contribute kernel configurations that are known to work. The address for this site is http://stuartl.longlandclan.hopto.org/gentoo/mips.

If you find this service useful, you're welcome to contribute your notes and .config files so that others may benefit from your experience. It should be noted however that there is no guarantee that any of the configuration files downloaded from this site will work.

Customising the configuration for your needs

Once you have found a configuration, download it into your kernel source directory, and rename it to .config. From there, you can run make oldconfig to bring everything up to date, and allow you to customise the configuration before compiling.

# cd /usr/src/linux
# cp /path/to/example-config .config
# make oldconfig
(Just press ENTER at each prompt to accept the defaults... we'll customise later)
# make menuconfig

Compiling and Installing

Now that your kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process:

(For 2.4 kernel only)
# make dep

(2.4 and 2.6 kernels -- compiling natively)
# make vmlinux modules modules_install

(2.4 and 2.6 kernels -- cross-compiling on target machine)
(    Adjust the mips64-unknown-linux-gnu- accordingly    )
# make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu-

(When compiling on another machine, such as an x86 box... use the)
( following commands to compile the kernel & install modules into)
(  a specific directory to be transferred to the target machine. )
# make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu-
# make modules_install INSTALL_MOD_PATH=/somewhere

# make vmlinux.32
(This will create vmlinux.32 -- which is your final kernel)

When the kernel has finished compiling, copy the kernel image to /boot.

# cp vmlinux /boot/kernel-2.6.13.4

(Cobalt Servers -- Compressing the kernel image)
# gzip -9v /boot/kernel-2.6.13.4

7.d. Installing Separate Kernel Modules

Configuring the Modules

You should list the modules you want automatically loaded in one of the relevant files listed below. You can add extra options to the modules too if you want.

• /etc/modules.autoload.d/kernel-2.4 - Kernel 2.4 only
• /etc/modules.autoload.d/kernel-2.6 - Kernel 2.6 only
• /etc/modules.autoload - All Kernels

Therefore, if you have a kernel module that you want to load -- which is common to both 2.4 and 2.6, then place it in /etc/modules.autoload. Otherwise it can be placed in the appropriate file.

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:

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

For instance, to automatically load the 3c59x.o module, edit the appropriate file and enter the module name in it.

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

3c59x

This can be also done in a one-liner:

# echo '3c59x' >> /etc/modules.autoload.d/kernel-2.4
(or kernel-2.6, or /etc/modules.autoload...)

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 mount points 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 mount point at which the partition should be mounted
• The third field shows the filesystem used by the partition
• The fourth field shows the mount options used by mount when it wants to mount the partition. As every filesystem has its own mount options, you are encouraged to read the mount man page (man mount) for a full listing. Multiple mount options 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).

# 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, if you didn't or couldn't create a /boot, don't copy it.

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

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

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

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

/dev/sda1   /boot        ext2    defaults,noatime     1 2
/dev/sda2   none         swap    sw                   0 0
/dev/sda3   /            ext3    noatime              0 1

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

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

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

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

8.b. Networking Information

Host name, 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.

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

(Set the HOSTNAME variable to your host name)
HOSTNAME="tux"

Second we set the domainname in /etc/conf.d/net:

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

(Set the dns_domain variable to your domain name)
dns_domain_lo="homenetwork"

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:

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

(Set the nis_domain variable to your NIS domain name)
nis_domain_lo="my-nisdomain"

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. A fully commented example that covers many different configurations is available in /etc/conf.d/net.example.

DHCP is used by default. For DHCP to work, you will need to install a DHCP client. This is described later in Installing Necessary System Tools. Do not forget to install a DHCP client.

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

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

You will see the following file:

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

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

config_eth0=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" )
routes_eth0=( "default gw 192.168.0.1" )

To use DHCP and add specific DHCP options, define config_eth0 and dhcp_eth0:

config_eth0=( "dhcp" )
dhcp_eth0="nodns nontp nonis"

Please read /etc/conf.d/net.example for a list of all available options.

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

Now save the configuration and exit to continue.

Automatically Start Networking at Boot

To have your network interfaces activated at boot, you need to add them to the default runlevel. If you have PCMCIA interfaces you should skip this action as the PCMCIA interfaces are started by the PCMCIA init script.

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

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

Writing Down Network Information

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

# nano -w /etc/hosts

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

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

Save and exit the editor to continue.

8.c. System Information

Root Password

First we set the root password by typing:

# passwd

If you want root to be able to log on through the serial console, add 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 :)

# nano -w /etc/rc.conf

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

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

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

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

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

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

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

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

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

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

Please continue with Installing Necessary System Tools.

9. Installing Necessary System Tools

9.a. Device Manager

If you are using a 2.4 kernel and are installing Gentoo from stage 3, there are a few things you need to do. Since Gentoo now uses udev by default and udev is not supported by 2.4 kernels, you will have to make use of devfsd and remove udev.

(For those using 2.4.x kernels with a stage 3 install)
# emerge --unmerge udev
# emerge devfsd

9.b. System Logger

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

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

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

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

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

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

9.c. 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.

# emerge vixie-cron
# rc-update add vixie-cron default
(Only if you have chosen dcron or fcron) # crontab /etc/crontab

9.d. 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.

# emerge slocate

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

If you are an EVMS user, you also need to install evms:

# USE="-gtk" emerge evms

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

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

9.f. 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 -- see Modular Networking for a list of available DHCP clients). If you don't do this now, you might not be able to connect to the internet after the installation.

# emerge dhcpcd

Optional: Installing a PPPoE Client

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

# 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).

Optional: RAID utilities for IBM hardware

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

# emerge iprutils

Now continue with Configuring the Bootloader.

10. Configuring the Bootloader

10.a. Silicon Graphics Machines -- Setting Up arcload

Which one?

On SGI machines, we use the arcload boot loader. In previous releases, we also provided arcboot, however it has been officially declared obsolete, in favour of arcload.

Installing arcload

arcload was written for machines that require 64-bit kernels, and therefore can't use arcboot (which can't easily be compiled as a 64-bit binary). It also works around peculiarities that arise when loading kernels directly from the volume header. So, now you know what this is about, we can proceed with the installation:

# emerge arcload dvhtool

Once this has finished, you should find the arcload binary in /usr/lib/arcload. Now, two files exist:

• sashARCS: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S and O2 systems
• sash64: The 64-bit binary for Octane/Octane2, Origin 200/2000 and Indigo2 Impact systems

Use dvhtool to install the appropriate binary for your system into the volume header:

(Indy/Indigo2/Challenge S/O2 users)
# dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS

(Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users)
# dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64

Now just use dvhtool to verify they are in the volume header.

# dvhtool --print-volume-directory
----- directory entries -----
Entry #0, name "sash64", start 4, bytes 55859
#

Now, the arc.cf file has a C-like syntax. For the full detail on how one configures it, see the arcload page on the Linux/MIPS wiki. In short, you define a number of options, which you enable and disable at boot time using the OSLoadFilename variable.

# ARCLoad Configuration

# Some default settings...
append  "root=/dev/sda3";
append  "ro";
append  "console=ttyS0,9600";

# Our main definition. ip28 may be changed if you wish.
ip28 {
        # Definition for a "working" kernel
        # Select this by setting OSLoadFilename="ip28(working)"
        working {
                description     "SGI Indigo2 Impact R10000\n\r";
                image system    "/working";
        }

        # Definition for a "new" kernel
        # Select this by setting OSLoadFilename="ip28(new)"
        new {
                description     "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
                image system    "/new";
        }

        # For debugging a kernel
        # Select this by setting OSLoadFilename="ip28(working,debug)"
        # or OSLoadFilename="ip28(new,debug)"
        debug {
                description     "Debug console";
                append          "init=/bin/bash";
        }
}

This is then placed in the volume header with sash64 (or sashARCS) as shown below. Kernels also get placed in the volume header.

# dvhtool --unix-to-vh arc.cf arc.cf
# dvhtool --unix-to-vh /usr/src/linux/vmlinux new

With this done, now all that's left is to set some options in the PROM. See the section on Rebooting the System.

10.b. Cobalt MicroServers -- Setting Up CoLo

Installing CoLo

On Cobalt servers, these machines have a much less capable firmware installed on chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and has a number of serious limitations.

• There's a 675kB (approximate) limit on kernels. The current size of Linux 2.4 makes it damn near impossible to make a kernel this size. Linux 2.6 is totally out of the question.
• 64-bit kernels are not supported by the stock firmware (although these are highly experimental on Cobalt machines at this time)
• The shell is basic at best

To overcome these limitations, an alternative firmware, called CoLo (Cobalt Loader) was developed. This is a BOOTROM image that can either be flashed into the chip inside the Cobalt server, or loaded from the existing firmware.

Okay, with the warnings over now, we'll get on with installing CoLo. First, start by emerging the package.

# emerge colo

With that installed (I hope you read those messages ;-) you should be able to look inside the /usr/lib/colo directory to find two files, colo-chain.elf: the "kernel" for the stock firmware to load, and colo-rom-image.bin: a ROM image for flashing into the BOOTROM. We start by mounting /boot and dumping a compressed copy of colo-chain.elf in /boot where the system expects it.

# gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz

Configuring CoLo

Now, when the system first boots up, it'll load CoLo which will spit up a menu on the back LCD. The first option (and default that is assumed after roughly 5 seconds) is to boot to the hard disk. The system would then attempt to mount the first Linux partition it finds, and run the script default.colo. The syntax is fully documented in the CoLo documentation (have a peek at /usr/share/doc/colo-X.YY/README.shell.gz -- where X.YY is the version installed), and is very simple.

#:CoLo:#
mount hda1
load /kernel.gz.working
execute root=/dev/hda3 ro console=ttyS0,115200

It is also possible to ask a question, such as which kernel & configuration you'd like to boot, with a default timeout. This configuration does exactly this, asks the user which kernel they wish to use, and executes the chosen image. vmlinux.gz.new and vmlinux.gz.working may be actual kernel images, or just symlinks pointing to the kernel images on that disk. The 50 argument to select specifies that it should proceed with the first option ("Working") after 50/10 seconds.

#:CoLo:#

lcd "Mounting hda1"
mount hda1
select "Which Kernel?" 50 Working New

goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new

@lcd "Loading Linux" {image-name}
load /{image-name}
lcd "Booting..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot

See the documentation in /usr/share/doc/colo-VERSION for more details.

10.c. Setting up for Serial Console

Okay, the Linux installation as it stands now, would boot fine, but assumes you're going to be logged in at a physical terminal. On Cobalt machines, this is particularly bad -- there's no such thing as a physical terminal.

First, pull up an editor and hack away at /etc/inittab. Further down in the file, you'll see something like this:

# SERIAL CONSOLE
#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102

# TERMINALS
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 to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now

First, uncomment the c0 line. By default, it's set to use a terminal baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200 to match the baud rate decided by the BOOT ROM. This is how that section looks on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend commenting out the local terminal lines (c1 through to c6) as these have a habit of misbehaving when they can't open /dev/ttyX.

# SERIAL CONSOLE
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102

# TERMINALS -- These are useless on a headless qube
#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

Now, lastly... we have to tell the system, that the local serial port can be trusted as a secure terminal. The file we need to poke at is /etc/securetty. It contains a list of terminals that the system trusts. We simply stick in two more lines, permitting the serial line to be used for root logins.

(/dev/ttyS0 -- the traditional name for the first serial port)
# echo 'ttyS0' >> /etc/securetty

(Lately, Linux also calls this /dev/tts/0 -- so we add this
too)
# echo 'tts/0' >> /etc/securetty

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.

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

10.e. Tweaking the SGI PROM

Setting generic PROM settings

Now that you've installed the bootloader, you're ready to reboot the machine.

(Exit the chroot environment)
# exit

(Unmount the drives)
# umount /gentoo/boot
# umount /gentoo

(Reboot)
# reboot

When you are rebooted, go to the System Maintenance Menu and select Enter Command Monitor (5) like you did when you netbooted the machine.

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor. Type "exit" to return to the menu.

(Set some options for arcload)

(Provide the location of the Volume Header)
>> setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)

(Automatically boot Gentoo)
>> setenv AutoLoad Yes

(Set the timezone)
>> setenv TimeZone EST5EDT

(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))
>> setenv console d1

(Setting the serial console baud rate. This is optional, 9600 is the          )
(default setting, although one may use rates up to 38400 if that is desired.  )
>> setenv dbaud 9600

Now, the next settings depend on how you are booting the system.

Settings for direct volume-header booting

This is covered here for completeness. It's recommended that users look into installing arcload instead.

(<root device> = Gentoo's root partition, e.g. /dev/sda3)
>> setenv OSLoadPartition <root device>

(To list the available kernels, type "ls")
>> setenv OSLoader <kernel name>
>> setenv OSLoadFilename <kernel name>

(Declare the kernel parameters you want to pass)
>> setenv OSLoadOptions <kernel parameters>

If you wish to try a kernel without messing with kernel parameters, you may do so using the boot -f PROM command:

(Booting a kernel, "new", with additional options)
# boot -f new root=/dev/sda3 ro

Settings for arcload

arcload uses the OSLoadFilename option to specify which options to set from arc.cf. The configuration file is essentially a script, with the top-level blocks defining boot images for different systems, and inside that, optional settings. Thus, setting OSLoadFilename=mysys(serial) pulls in the settings for the mysys block, then sets further options overridden in serial.

In the example file above, we have one system block defined, ip28 with working, new and debug options available. We define our PROM variables as so:

(Select arcload as the bootloader:- sash64 or sashARCS)
>> setenv OSLoader sash64

(Use the "working" kernel image, defined in "ip28" section of arc.cf)
>> setenv OSLoadFilename ip28(working)

All Done

Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and 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:

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:

Login: root
Password: (Your root password)

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

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

12. Where to go from here?

12.a. Documentation

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

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

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

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

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

12.b. Gentoo Online

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

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

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

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:

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

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

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

$ emerge --search pdf

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

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

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

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

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

# emerge --fetchonly gnumeric

Finding Installed Package Documentation

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

(alsa-lib is just an example, of course.)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.9_rc3  +doc -jack 674 kB

You can enable or disable the doc USE flag either globally in the /etc/make.conf file or per package in the /etc/portage/package.use file. You can also create a directory called /etc/portage/package.use and list it in a file inside this directory. The USE Flags chapter covers this aspect in detail.

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

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

(Alternatively, use equery to locate interesting files:)
# equery files alsa-lib | less
media-libs/alsa-lib-1.0.9_rc3
* Contents of media-libs/alsa-lib-1.0.9_rc3:
/usr
/usr/bin
/usr/bin/alsalisp
(Output truncated)

Removing Software

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

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

# emerge --unmerge gnumeric

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

Updating your System

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

# emerge --update --ask world

Portage will then search for newer version of the applications you have installed. However, it will only verify the versions for the applications you have explicitly installed - not the dependencies. If you want to update every single package on your system, add the --deep argument:

# emerge --update --deep world

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

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

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

Metapackages

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:

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

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

# 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 into too much detail.

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

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger 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

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

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

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

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

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

Masked Packages

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

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

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

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

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

Ambiguous Ebuild Name

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

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

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

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

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

Digest Verification Failures

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

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

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

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

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

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

2. USE flags

2.a. What are USE-flags?

The ideas behind USE-flags

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

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

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

Definition of a USE-flag

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

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

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

What USE-flags exist?

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

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

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

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

2.b. Using USE-flags

Declare permanent USE-flags

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

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

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

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

(This example is the sum of the settings in base, default-linux,
 default-linux/x86 and default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
     foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad
     mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt
     quicktime readline sdl 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 any make.defaults file to tailor the USE variable to your needs: changes in this file will be undone when you update Portage!

To change this default setting, you need to add or remove keywords to the USE variable. This is done globally by defining the USE variable in /etc/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:

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:

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:

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.

# USE="-java" emerge mozilla

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 still used due to a setting that has a higher priority. The precedence for the USE setting is, ordered by priority (first has lowest priority):

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

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

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

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

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

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

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

Calculating dependencies ...done!
[ebuild   R   ] www-client/mozilla-1.7.12-r2  USE="crypt gnome java mozsvg ssl
truetype xprint -debug -ipv6 -ldap -mozcalendar -mozdevelop -moznocompose
-moznoirc -moznomail -moznoxft -postgres -xinerama" 0 kB

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

# emerge gentoolkit

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

# equery uses =gnumeric-1.6.3 -a
[ Searching for packages matching =gnumeric-1.6.3... ]
[ Colour Code : set unset ]
[ Legend        : Left column  (U) - USE flags from make.conf  ]
[               : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for app-office/gnumeric-1.6.3 ]
 U I
- - debug   : Tells configure and the makefiles to build for debugging.
                     Effects vary across packages, but generally it will at
                     least add -g to CFLAGS.  Remember to set FEATURES=nostrip too 
- - gnome   : Adds GNOME support
+ + python   : Adds support/bindings for the Python language
- - static   : !!do not set this during bootstrap!! Causes binaries to be
                     statically linked instead of dynamically

3. Portage Features

3.a. Portage Features

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

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

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

$ man make.conf

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

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

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

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

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

# 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":

CCACHE_SIZE="2G"

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

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

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

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

Using ccache for non-Portage C Compiling

If you would like to use ccache for non-Portage compilations, add /usr/lib/ccache/bin to the beginning of your PATH variable (before /usr/bin). This can be accomplished by editing /etc/env.d/00basic, which is the first environment file that defines the PATH variable:

PATH="/usr/lib/ccache/bin:/opt/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 Frequently Asked Questions.

Installing Prebuilt Packages

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

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:

# emerge --usepkg --getbinpkg gnumeric

More information about emerge's prebuilt package options can be found in 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:

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:

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:

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:

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:

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:

# /etc/init.d/postfix start

If you want to stop a service, but not the services that depend on it, you can use the pause argument:

# /etc/init.d/postfix pause

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

# /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:

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

# /etc/init.d/postfix ineed

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

# /etc/init.d/postfix needsme

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

# /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:

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

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

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.

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

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:

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.

depend() {
  before *
}

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

depend() {
  need localmount
  after bootmisc
}

Standard Functions

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

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

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

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.

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.

Although you do not have to create a stop() function, here is an example:

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

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

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

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

$ man start-stop-daemon

Gentoo's init script syntax is based on the Bourne Again Shell (bash) so you are free to use bash-compatible constructs inside your init script.

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:

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:

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

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

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

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

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

Using bootlevel

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

5. Environment Variables

5.a. Environment Variables?

What they are

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

Important Examples

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

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

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:

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:

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. The file names must begin with two decimal digits.

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

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

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:

# 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 and the current working directory (the directory you are in) to the PATH variable but don't want all other users on your system to have that in their PATH too. If you want to define an environment variable locally, you should use ~/.bashrc or ~/.bash_profile:

(A colon followed by no directory is treated as the current working directory)
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.

# 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 default configuration files which are part of your profile. Your profile is pointed to by the /etc/make.profile symlink; Portage' configurations are set in the make.defaults files of your profile and all parent profiles. We'll explain more about profiles and the /etc/make.profile directory later on.

If you're planning on changing a configuration variable, don't alter /etc/make.globals or 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:

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

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

Portage Database

Portage stores the state of your system (what packages are installed, what files belong to which package, ...) in /var/db/pkg. Do not alter these files manually! It might break Portage's knowledge of your system.

Portage Cache

The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: you can clean it if you are not running any portage-related application at that moment.

1.c. Building Software

Temporary Portage Files

Portage's temporary files are stored in /var/tmp by default. This is defined by the PORTAGE_TMPDIR variable.

If you alter the PORTAGE_TMPDIR variable, you might want to alter the following variables as well since they will not notice the PORTAGE_TMPDIR change. This is due to how Portage handles variables: BUILD_PREFIX.

Building Directory

Portage creates specific build directories for each package it emerges inside /var/tmp/portage. This location is defined by the BUILD_PREFIX variable.

Live Filesystem Location

By default Portage installs all files on the current filesystem (/), but you can change this by setting the ROOT environment variable. This is useful when you want to create new build images.

1.d. Logging Features

Ebuild Logging

Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable is set to a location that is writable by Portage (the portage user). By default this variable is unset.

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:

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

$ emerge --info | grep 'CONFIG_PROTECT='

More information about Portage's Configuration File Protection is available through emerge:

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

# 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 number of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to 180 but dialup users or individuals with slow computers might want to set this to 300 or higher.

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:

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

The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it.

Beware though, you might notice stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. If you do not know how Gentoo works and how to solve problems, we recommend that you stick with the stable and tested branch.

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

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 location

You can ask Portage to allow the testing branch for particular packages but use the stable branch for the rest of the system. To achieve this, add the package category and name you want to use the testing branch of in /etc/portage/package.keywords. You can also create a directory (with the same name) and list the package in the files under that directory. For instance, to use the testing branch for gnumeric:

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 location. In this case you must use the = operator. You can also enter a version range using the <=, <, > or >= operators.

In any case, if you add version information, you must use an operator. If you leave out version information, you cannot use an operator.

In the following example we ask Portage to accept gnumeric-1.2.13:

=app-office/gnumeric-1.2.13 ~x86

3.c. Using Masked Packages

The package.unmask location

The Gentoo developers do not support the use of this location. Please exercise due caution when doing so. Support requests related to package.unmask and/or package.mask will not be answered. You have been warned.

When a package has been masked by the Gentoo developers and you still want to use it despite the reason mentioned in the package.mask file (situated in /usr/portage/profiles by default), add the exact same line in the /etc/portage/package.unmask file (or in a file in that directory if it is a directory).

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

=net-mail/hotwayd-0.8

The package.mask location

When you don't want Portage to take a certain package or a specific version of a package into account you can mask it yourself by adding an appropriate line to the /etc/portage/package.mask location (either in that file or in a file in this directory).

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

>sys-kernel/gentoo-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 overwrite a file in a directory protected by the CONFIG_PROTECT variable.

Running etc-update is pretty straight-forward:

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

Please select a file to edit by entering the corresponding number.
              (-1 to exit) (-3 to auto merge all remaining files)
                           (-5 to auto-merge AND not use 'mv -i'):

If you enter -1, etc-update will exit and discontinue any further changes. If you enter -3 or -5, all listed configuration files will be overwritten with the newer versions. It is therefore very important to first select the configuration files that should not be automatically updated. This is simply a matter of entering the number listed to the left of that configuration file.

As an example, we select the configuration file /etc/pear.conf:

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:

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:

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

# quickpkg curl arts procps

The prebuilt packages will be stored in $PKGDIR/All (/usr/portage/packages/All by default). Symbolic links pointing to these packages are placed in $PKGDIR/<category>.

5. Diverting from the Official Tree

5.a. Using a Portage Tree Subset

Excluding Packages/Categories

You can selectively update certain categories/packages and ignore the other categories/packages. We achieve this by having rsync exclude categories/packages during the emerge --sync step.

You need to define the name of the file that contains the exclude patterns in the RSYNC_EXCLUDEFROM variable in your /etc/make.conf.

RSYNC_EXCLUDEFROM=/etc/portage/rsync_excludes

games-*/*

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.

Working with Several Overlays

For the powerusers who develop on several overlays, test packages before they hit the Portage tree or just want to use unofficial ebuilds from various sources, the app-portage/gentoolkit-dev package brings you gensync, a tool to help you keep the overlay repositories up to date.

With gensync you can update all the repositories at once, or select just a few of them. Each repository should have a .syncsource file in the /etc/gensync/ configuration directory which contains the repository location, name, ID, etc.

Suppose you have two additional repositories called java (for the in-development java ebuilds) and entapps (for the applications developed in-house for your enterprise). You can update those repositories with the following command:

# gensync java entapps

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

sys-kernel/vanilla-sources-2.6.11.6

D. Gentoo Network Configuration

1. Getting Started

1.a. Getting started

To get started configuring your network card, you need to tell the Gentoo RC system about it. This is done by creating a symbolic link from net.lo to net.eth0 in /etc/init.d.

# cd /etc/init.d
# ln -s net.lo net.eth0

Gentoo's RC system now knows about that interface. It also needs to know how to configure the new interface. All the network interfaces are configured in /etc/conf.d/net. Below is a sample configuration for DHCP and static addresses.

# For DHCP
config_eth0=( "dhcp" )

# For static IP using CIDR notation
config_eth0=( "192.168.0.7/24" )
routes_eth0=( "default via 192.168.0.1" )

# For static IP using netmask notation
config_eth0=( "192.168.0.7 netmask 255.255.255.0" )
routes_eth0=( "default gw 192.168.0.1" )

Now that we have configured our interface, we can start and stop it using the below commands

# /etc/init.d/net.eth0 start
# /etc/init.d/net.eth0 stop

Now that you have successfully started and stopped your network interface, you may wish to get it to start when Gentoo boots. Here's how to do this. The last "rc" command instructs Gentoo to start any scripts in the current runlevel that have not yet been started.

# rc-update add net.eth0 default
# rc

2. Advanced Configuration

2.a. Advanced Configuration

The config_eth0 variable is the heart of an interface configuration. It's a high level instruction list for configuring the interface (eth0 in this case). Each command in the instruction list is performed sequentially. The interface is deemed OK if at least one command works.

Here's a list of in-built instructions.

If a command fails, you can specify a fallback command. The fallback has to match the config structure exactly.

You can chain these commands together. Here are some real world examples.

# Adding three IPv4 addresses
config_eth0=(
  "192.168.0.2/24"
  "192.168.0.3/24"
  "192.168.0.4/24"
)

# Adding an IPv4 address and two IPv6 addresses
config_eth0=(
  "192.168.0.2/24"
  "4321:0:1:2:3:4:567:89ab"
  "4321:0:1:2:3:4:567:89ac"
)

# Keep our kernel assigned address, unless the interface goes
# down so assign another via DHCP. If DHCP fails then add a
# static address determined by APIPA
config_eth0=(
  "noop"
  "dhcp"
)
fallback_eth0=(
  "null"
  "apipa"
)

2.b. Network Dependencies

Init scripts in /etc/init.d can depend on a specific network interface or just net. net can be defined in /etc/conf.d/rc to mean different things using the RC_NET_STRICT_CHECKING variable.

But what about net.br0 depending on net.eth0 and net.eth1? net.eth1 may be a wireless or PPP device that needs configuration before it can be added to the bridge. This cannot be done in /etc/init.d/net.br0 as that's a symbolic link to net.lo.

The answer is making your own depend() function in /etc/conf.d/net.

# You can use any dependency (use, after, before) as found in current scripts
depend_br0() {
  need net.eth0 net.eth1
}

For a more detailed discussion about dependency, consult the section Writing Init Scripts in the Gentoo Handbook.

2.c. Variable names and values

Variable names are dynamic. They normally follow the structure of variable_${interface|mac|essid|apmac}. For example, the variable dhcpcd_eth0 holds the value for dhcpcd options for eth0 and dhcpcd_essid holds the value for dhcpcd options when any interface connects to the ESSID "essid".

However, there is no hard and fast rule that states interface names must be ethx. In fact, many wireless interfaces have names like wlanx, rax as well as ethx. Also, some user defined interfaces such as bridges can be given any name, such as foo. To make life more interesting, wireless Access Points can have names with non alpha-numeric characters in them - this is important because you can configure networking parameters per ESSID.

The downside of all this is that Gentoo uses bash variables for networking - and bash cannot use anything outside of English alpha-numerics. To get around this limitation we change every character that is not an English alpha-numeric into a _ character.

Another downside of bash is the content of variables - some characters need to be escaped. This can be achived by placing the \ character in front of the character that needs to be escaped. The following list of characters needs to be escaped in this way: ", ' and \.

In this example we use wireless ESSID as they can contain the widest scope of characters. We shall use the ESSID My "\ NET:

# This does work, but the domain is invalid
dns_domain_My____NET="My \"\\ NET"

# The above sets the dns domain to My "\ NET when a wireless card
# connects to an AP whose ESSID is My "\ NET

3. Modular Networking

3.a. Network Modules

We now support modular networking scripts, which means we can easily add support for new interface types and configuration modules while keeping compatibility with existing ones.

Modules load by default if the package they need is installed. If you specify a module here that doesn't have its package installed then you get an error stating which package you need to install. Ideally, you only use the modules setting when you have two or more packages installed that supply the same service and you need to prefer one over the other.

# Prefer iproute2 over ifconfig
modules=( "iproute2" )

# You can also specify other modules for an interface
# In this case we prefer udhcpc over dhcpcd
modules_eth0=( "udhcpc" )

# You can also specify which modules not to use - for example you may be
# using a supplicant or linux-wlan-ng to control wireless configuration but
# you still want to configure network settings per ESSID associated with.
modules=( "!iwconfig" )

3.b. Interface Handlers

We provide two interface handlers presently: ifconfig and iproute2. You need one of these to do any kind of network configuration.

ifconfig is the current Gentoo default and it's included in the system profile. iproute2 is a more powerful and flexible package, but it's not included by default.

# emerge sys-apps/iproute2

# To prefer iproute2 over ifconfig if both are installed
modules=( "iproute2" )

As both ifconfig and iproute2 do very similar things we allow their basic configuration to work with each other. For example both the below code snippet work regardless of which module you are using.

config_eth0=( "192.168.0.2/24" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0" )

# We can also specify broadcast
config_eth0=( "192.168.0.2/24 brd 192.168.0.255" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )

3.c. DHCP

DHCP is a means of obtaining network information (IP address, DNS servers, Gateway, etc) from a DHCP server. This means that if there is a DHCP server running on the network, you just have to tell each client to use DHCP and it sets up the network all by itself. Of course, you will have to configure for other things like wireless, PPP or other things if required before you can use DHCP.

DHCP can be provided by dhclient, dhcpcd, pump or udhcpc. Each DHCP module has its pros and cons - here's a quick run down.

If you have more than one DHCP client installed, you need to specify which one to use - otherwise we default to dhcpcd if available.

To send specific options to the DHCP module, use module_eth0="..." (change module to the DHCP module you're using - i.e. dhcpcd_eth0).

We try and make DHCP relatively agnostic - as such we support the following commands using the dhcp_eth0 variable. The default is not to set any of them:

• release - releases the IP address for re-use
• nodns - don't overwrite /etc/resolv.conf
• nontp - don't overwrite /etc/ntp.conf
• nonis - don't overwrite /etc/yp.conf

# Only needed if you have more than one DHCP module installed
modules=( "dhcpcd" ) 

config_eth0=( "dhcp" )
dhcpcd_eth0="-t 10" # Timeout after 10 seconds
dhcp_eth0="release nodns nontp nonis" # Only get an address

3.d. ADSL Modem

First we need to install the ADSL software.

# emerge net-dialup/rp-pppoe

Now we need to configure eth0 to be an ADSL interface and enter our username by updating /etc/conf.d/net.

config_eth0=( "adsl" )
adsl_user_eth0="username"

Finally you need to define your username and password in /etc/ppp/pap-secrets.

# The * is important
"username"  *  "password"

3.e. APIPA (Automatic Private IP Addressing)

APIPA tries to find a free address in the range 169.254.0.0-169.254.255.255 by arping a random address in that range on the interface. If no reply is found then we assign that address to the interface.

This is only useful for LANs where there is no DHCP server and you don't connect directly to the internet and all other computers use APIPA.

For APIPA support, emerge net-misc/iputils or net-analyzer/arping.

# Try DHCP first - if that fails then fallback to APIPA
config_eth0=( "dhcp" )
fallback_eth0=( "apipa" )

# Just use APIPA
config_eth0=( "apipa" )

3.f. Bonding

For link bonding/trunking emerge net-misc/ifenslave.

Bonding is used to increase network bandwidth. If you have two network cards going to the same network, you can bond them together so your applications see just one interface but they really use both network cards.

# To bond interfaces together
slaves_bond0="eth0 eth1 eth2"

# You may not want to assign an IP to the bonded interface
config_bond0=( "null" )

# Depend on eth0, eth1 and eth2 as they may require extra configuration
depend_bond0() {
  need net.eth0 net.eth1 net.eth2
}

3.g. Bridging (802.1d support)

For bridging support emerge net-misc/bridge-utils.

Bridging is used to join networks together. For example, you may have a server that connects to the internet via an ADSL modem and a wireless access card to enable other computers to connect to the internet via the ADSL modem. You could create a bridge to join the two interfaces together.

# Configure the bridge - "man btctl" for more details
brctl_br0=( "setfd 0" "sethello 0" "stp off" )

# To add ports to bridge br0
bridge_br0="eth0 eth1"

# You need to configure the ports to null values so dhcp does not get started
config_eth0=( "null" )
config_eth1=( "null" )

# Finally give the bridge an address - you could use DHCP as well
config_br0=( "192.168.0.1/24" )

# Depend on eth0 and eth1 as they may require extra configuration
depend_br0() {
  need net.eth0 net.eth1
}

3.h. MAC Address

You don't need to emerge anything for changing the MAC address of your interface if you have sys-apps/baselayout-1.11.14 or newer and want to change to a specific MAC address. However, if you need to change to a random MAC address or have a baselayout older than the version mentioned above, you have to emerge net-analyzer/macchanger to be able to make use of this feature.

# To set the MAC address of the interface
mac_eth0="00:11:22:33:44:55"

# To randomize the last 3 bytes only
mac_eth0="random-ending"

# To randomize between the same physical type of connection (e.g. fibre,
# copper, wireless) , all vendors
mac_eth0="random-samekind"

# To randomize between any physical type of connection (e.g. fibre, copper,
# wireless) , all vendors
mac_eth0="random-anykind"

# Full randomization - WARNING: some MAC addresses generated by this may
# NOT act as expected
mac_eth0="random-full"

3.i. Tunnelling

You don't need to emerge anything for tunnelling as the interface handler can do it for you.

# For GRE tunnels
iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255"

# For IPIP tunnels
iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255"

# To configure the interface
config_vpn0=( "192.168.0.2 peer 192.168.1.1" ) 

3.j. VLAN (802.1q support)

For VLAN support, emerge net-misc/vconfig.

Virtual LAN is a group of network devices that behave as if they were connected to a single network segment - even though they may not be. VLAN members can only see members of the same VLAN even though they may share the same physical network.

# Specify the VLAN numbers for the interface like so
# Please ensure your VLAN IDs are NOT zero-padded
vlans_eth0="1 2"

# You can also configure the VLAN
# see for vconfig man page for more details
vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" )
vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" )

# Configure the interface as usual
config_vlan1=( "172.16.3.1 netmask 255.255.254.0" )
config_vlan2=( "172.16.2.1 netmask 255.255.254.0" )

4. Wireless Networking

4.a. Introduction

Currently we support wireless setup either by wireless-tools or wpa_supplicant. The important thing to remember is that you configure for wireless networks on a global basis and not an interface basis.

wpa_supplicant is the best choice, but it does not support all drivers. For a list of supported drivers, read the wpa_supplicant site. Also, wpa_supplicant can currently only connect to SSID's that you have configured for.

wireless-tools supports nearly all cards and drivers, but it cannot connect to WPA only Access Points.

4.b. WPA Supplicant

WPA Supplicant is a package that allows you to connect to WPA enabled access points. It's setup is fairly fluid as it is still in beta - however it works fine for the most part.

# emerge net-wireless/wpa_supplicant

Now we have to configure /etc/conf.d/net to so that we prefer wpa_supplicant over wireless-tools (if both are installed, wireless-tools is the default).

# Prefer wpa_supplicant over wireless-tools
modules=( "wpa_supplicant" )

# It's important that we tell wpa_supplicant which driver we should
# be using as it's not very good at guessing yet
wpa_supplicant_eth0="-Dmadwifi"

That was simple, wasn't it? However, we still have to configure wpa_supplicant itself which is a bit more tricky depending on how secure the Access Points are that you are trying to connect to. The below example is taken and simplified from /etc/wpa_supplicant.conf.example which ships with wpa_supplicant.

# The below line not be changed otherwise we refuse to work
ctrl_interface=/var/run/wpa_supplicant

# Ensure that only root can read the WPA configuration
ctrl_interface_group=0

# Let wpa_supplicant take care of scanning and AP selection
ap_scan=1

# Simple case: WPA-PSK, PSK as an ASCII passphrase, allow all valid ciphers
network={
  ssid="simple"
  psk="very secret passphrase"
  # The higher the priority the sooner we are matched
  priority=5
}

# Same as previous, but request SSID-specific scanning (for APs that reject
# broadcast SSID)
network={
  ssid="second ssid"
  scan_ssid=1
  psk="very secret passphrase"
  priority=2
}

# Only WPA-PSK is used. Any valid cipher combination is accepted
network={
  ssid="example"
  proto=WPA
  key_mgmt=WPA-PSK
  pairwise=CCMP TKIP
  group=CCMP TKIP WEP104 WEP40
  psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb
  priority=2
}

# Plaintext connection (no WPA, no IEEE 802.1X)
network={
  ssid="plaintext-test"
  key_mgmt=NONE
}

# Shared WEP key connection (no WPA, no IEEE 802.1X)
network={
  ssid="static-wep-test"
  key_mgmt=NONE
  wep_key0="abcde"
  wep_key1=0102030405
  wep_key2="1234567890123"
  wep_tx_keyidx=0
  priority=5
}

# Shared WEP key connection (no WPA, no IEEE 802.1X) using Shared Key
# IEEE 802.11 authentication
network={
  ssid="static-wep-test2"
  key_mgmt=NONE
  wep_key0="abcde"
  wep_key1=0102030405
  wep_key2="1234567890123"
  wep_tx_keyidx=0
  priority=5
  auth_alg=SHARED
}

# IBSS/ad-hoc network with WPA-None/TKIP
network={
  ssid="test adhoc"
  mode=1
  proto=WPA
  key_mgmt=WPA-NONE
  pairwise=NONE
  group=TKIP
  psk="secret passphrase"
}

4.c. Wireless Tools

Initial setup and Managed Mode

Wireless Tools provide a generic way to configure basic wireless interfaces up to the WEP security level. While WEP is a weak security method it's also the most prevalent.

Wireless Tools configuration is controlled by a few main variables. The sample configuration file below should describe all you need. One thing to bear in mind is that no configuration means "connect to the strongest unencrypted Access Point" - we will always try and connect you to something.

# emerge net-wireless/wireless-tools

# Prefer iwconfig over wpa_supplicant
modules=( "iwconfig" )

# Configure WEP keys for Access Points called ESSID1 and ESSID2
# You may configure up to 4 WEP keys, but only 1 can be active at
# any time so we supply a default index of [1] to set key [1] and then
# again afterwards to change the active key to [1]
# We do this incase you define other ESSID's to use WEP keys other than 1
#
# Prefixing the key with s: means it's an ASCII key, otherwise a HEX key
#
# enc open specified open security (most secure)
# enc restricted specified restricted security (least secure)
key_ESSID1="[1] s:yourkeyhere key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"

# The below only work when we scan for available Access Points

# Sometimes more than one Access Point is visible so we need to
# define a preferred order to connect in
preferred_aps=( "ESSID1" "ESSID2" )

Fine tune Access Point Selection

You can add some extra options to fine-tune your Access Point selection, but these are not normally required.

You can decide whether we only connect to preferred Access Points or not. By default if everything configured has failed and we can connect to an unencrypted Access Point then we will. This can be controlled by the associate_order variable. Here's a table of values and how they control this.

Finally we have some blacklist_aps and unique_ap selection. blacklist_aps works in a similar way to preferred_aps. unique_ap is a yes or no value that says if a second wireless interface can connect to the same Access Point as the first interface.

# Sometimes you never want to connect to certain access points
blacklist_aps=( "ESSID3" "ESSID4" )

# If you have more than one wireless card, you can say if you want
# to allow each card to associate with the same Access Point or not
# Values are "yes" and "no"
# Default is "yes"
unique_ap="yes"

Ad-Hoc and Master Modes

If you want to set yourself up as an Ad-Hoc node if you fail to connect to any Access Point in managed mode, you can do that too.

adhoc_essid_eth0="This Adhoc Node"

What about connecting to Ad-Hoc networks or running in Master mode to become an Access Point? Here's a configuration just for that! You may need to specify WEP keys as shown above.

# Set the mode - can be managed (default), ad-hoc or master
# Not all drivers support all modes
mode_eth0="ad-hoc"

# Set the ESSID of the interface
# In managed mode, this forces the interface to try and connect to the
# specified ESSID and nothing else
essid_eth0="This Adhoc Node"

# We use channel 3 if you don't specify one
channel_eth0="9"

Troubleshooting Wireless Tools

There are some more variables you can use to help get your wireless up and running due to driver or environment problems. Here's a table of other things you can try.

4.d. Defining network configuration per ESSID

Sometimes, you need a static IP when you connect to ESSID1 and you need DHCP when you connect to ESSID2. In fact, most module variables can be defined per ESSID. Here's how we do this.

config_ESSID1=( "192.168.0.3/24 brd 192.168.0.255" )
routes_ESSID1=( "default via 192.168.0.1" )

config_ESSID2=( "dhcp" )
fallback_ESSID2=( "192.168.3.4/24" )
fallback_route_ESSID2=( "default via 192.168.3.1" )

# We can define nameservers and other things too
# NOTE: DHCP will override these unless it's told not too
dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" )
dns_domain_ESSID1="some.domain"
dns_search_domains_ESSID1="search.this.domain search.that.domain"

# You override by the MAC address of the Access Point
# This handy if you goto different locations that have the same ESSID
config_001122334455=( "dhcp" )
dhcpcd_001122334455="-t 10"
dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" )

5. Adding Functionality

5.a. Standard function hooks

Four functions can be defined which will be called surrounding the start/stop operations. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preup() and predown() functions should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preup() returns a non-zero value, then interface configuration will be aborted. If predown() returns a non-zero value, then the interface will not be allowed to continue deconfiguration.

The return values for the postup() and postdown() functions are ignored since there's nothing to do if they indicate failure.

${IFACE} is set to the interface being brought up/down. ${IFVAR} is ${IFACE} converted to variable name bash allows.

preup() {
  # Test for link on the interface prior to bringing it up.  This
  # only works on some network adapters and requires the mii-diag
  # package to be installed.
  if mii-tool ${IFACE} 2> /dev/null | grep -q 'no link'; then
    ewarn "No link on ${IFACE}, aborting configuration"
    return 1
  fi

  # Test for link on the interface prior to bringing it up.  This
  # only works on some network adapters and requires the ethtool
  # package to be installed.
  if ethtool ${IFACE} | grep -q 'Link detected: no'; then
    ewarn "No link on ${IFACE}, aborting configuration"
    return 1
  fi

  # Remember to return 0 on success
  return 0
}

predown() {
  # The default in the script is to test for NFS root and disallow
  # downing interfaces in that case.  Note that if you specify a
  # predown() function you will override that logic.  Here it is, in
  # case you still want it...
  if is_net_fs /; then
    eerror "root filesystem is network mounted -- can't stop ${IFACE}"
    return 1
  fi

  # Remember to return 0 on success
  return 0
}

postup() {
  # This function could be used, for example, to register with a
  # dynamic DNS service.  Another possibility would be to
  # send/receive mail once the interface is brought up.
       return 0
}

postdown() {
  # This function is mostly here for completeness... I haven't
  # thought of anything nifty to do with it yet ;-)
  return 0
}

5.b. Wireless Tools function hooks

Two functions can be defined which will be called surrounding the associate function. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preassociate() function should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preassociate() returns a non-zero value, then interface configuration will be aborted.

The return value for the postassociate() function is ignored since there's nothing to do if it indicates failure.

${ESSID} is set to the exact ESSID of the AP you're connecting to. ${ESSIDVAR} is ${ESSID} converted to variable name bash allows.

preassociate() {
  # The below adds two configuration variables leap_user_ESSID
  # and leap_pass_ESSID. When they are both configured for the ESSID
  # being connected to then we run the CISCO LEAP script

  local user pass
  eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
  eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"

  if [[ -n ${user} && -n ${pass} ]]; then
    if [[ ! -x /opt/cisco/bin/leapscript ]]; then
      eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
      return 1
    fi
    einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
    if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
      ewarn "Login Failed for ${user}"
      return 1
    fi
  fi

  return 0
}

postassociate() {
  # This function is mostly here for completeness... I haven't
  # thought of anything nifty to do with it yet ;-)

  return 0
}

6. Network Management

6.a. Network Management

If you and your computer are always on the move, you may not always have an ethernet cable or plugged in or an access point available. Also, we may want networking to automatically work when an ethernet cable is plugged in or an access point is found.

Here you can find some tools that helps you manage this.

6.b. ifplugd

ifplugd is a daemon that starts and stops interfaces when an ethernet cable is inserted or removed. It can also manage detecting association to Access Points or when new ones come in range.

# emerge sys-apps/ifplugd

Configuration for ifplugd is fairly straightforward too. The configuration file is held in /etc/conf.d/ifplugd. Run man ifplugd for details on what the variables do.

# Define which interfaces we monitor
INTERFACES="eth0"

AUTO="no"
BEEP="yes"
IGNORE_FAIL="yes"
IGNORE_FAIL_POSITIVE="no"
IGNORE_RETVAL="yes"
POLL_TIME="1"
DELAY_UP="0"
DELAY_DOWN="0"
API_MODE="auto"
SHUTDOWN="no"
WAIT_ON_FORK="no"
MONITOR="no"
ARGS=""

# Additional parameters for ifplugd for the specified interface. Note that
# the global variable is ignored, when a variable like this is set for an
# interface
MONITOR_wlan0="yes"
DELAY_UP_wlan0="5"
DELAY_DOWN_wlan0="5"

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.