text:
Disclaimer :
This handbook has been replaced by a newer version and is not maintained anymore.
1.a. Introduction
First of all, welcome to Gentoo. You are about to enter the world
of customization and performance. When installing Gentoo, this is made clear to
you several times -- you can choose how much you want to compile yourself, how
to install Gentoo, what system logger you want, etc.
Gentoo is a fast, modern meta-distribution with a clean and flexible
design. Gentoo is built around free software and doesn't hide from its
users what is beneath the hood. Portage, the package maintenance system
which Gentoo uses, is written in Python, meaning you can easily view and
modify the source code. Gentoo's packaging system uses source code
(although support for precompiled packages is included too) and
configuring Gentoo happens through regular text files. In other words,
openness everywhere.
It is very important that you understand that empowerment is what makes
Gentoo run. We try not to force anything on our users and try our best to
empower you to make the choices you wish. If you feel a change should be made,
please file a bug report about it.
How do I go about Installing Gentoo?
Gentoo Linux comes with two versions of an easy to use Installer. A GTK+ based
installer (for use with an X based environment) and a Dialog based installer for
use on the console. Chapter 3 of the handbook deals with the GTK+ based
installer while Chapter 4 is for the Dialog based one.
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 Linux Installation CD, a
bootable CD that contains everything you need to get Gentoo Linux up and
running. There are two types of Installation CDs, the InstallCD and the
Installer LiveCD. The InstallCD is a minimal environment which contains only
those packages necessary for installing Gentoo Linux. The LiveCD is a complete
Gentoo Linux environment and can be used for multiple tasks, one of which is
installing Gentoo Linux. The LiveCD is not available on all architectures at
this time. If your architecture does not have a LiveCD, then this document will
refer to the Universal InstallCD for you.
This installation approach however does not immediately use the latest version
of the available packages; if you want this you should check out the
Installation Instructions inside our Gentoo Linux Handbooks.
For help on the other installation approaches,
please read our Alternative Installation
Guide. We also provide a Gentoo Installation Tips &
Tricks document that might be useful to read as well. If you feel that
the current installation instructions are too elaborate, feel free to use our
Quick Installation Guide available from our Documentation Resources if your architecture
has such a document available.
If you find a problem in the installation (or in the installation
documentation), please check the errata from our Gentoo Release Engineering Project,
visit our bug tracking
system and check if the bug is known. If not, please create a bug report
for it so we can take care of it. Do not be afraid of the developers who are
assigned to (your) bugs -- they generally don't eat people.
Note though that, although the document you are now reading is
architecture-specific, it will contain references to other architectures as
well. This is due to the fact that large parts of the Gentoo Handbook use source
code that is common for all architectures (to avoid duplication of efforts and
starvation of development resources). We will try to keep this to a minimum
to avoid confusion.
If you are uncertain if the problem is a user-problem (some error you
made despite having read the documentation carefully) or a
software-problem (some error we made despite having tested the
installation/documentation carefully) you are free to join #gentoo on
irc.freenode.net. Of course, you are welcome otherwise too :)
If you have a question regarding Gentoo, check out our Frequently Asked
Questions, available from the Gentoo Documentation. You can
also view the FAQs on our
forums. If you can't find the answer
there ask on #gentoo, our IRC-channel on irc.freenode.net. Yes, several of
us are freaks who sit on IRC :-)
1.b. Fast Installation using the Gentoo Reference Platform
What is the Gentoo Reference Platform?
The Gentoo Reference Platform, from now on abbreviated to GRP, is a snapshot of
prebuilt packages users (that means you!) can install during the installation
of Gentoo to speed up the installation process. The GRP consists of all
packages required to have a fully functional Gentoo installation. They are not
just the ones you need to have a base installation up to speed in no time, but
all lengthier builds (such as xorg-x11, GNOME, OpenOffice, Mozilla, ...)
are available as GRP packages too.
However, these prebuilt packages aren't maintained during the lifetime of the
Gentoo distribution. They are snapshots released at every Gentoo release and
make it possible to have a functional environment in a short amount of time. You
can then upgrade your system in the background while working in your Gentoo
How Portage Handles GRP Packages
Your Portage tree - the collection of ebuilds (files that contain all
information about a package, such as its description, homepage, sourcecode URLs,
compilation instructions, dependencies, etc.) - must be synchronised with the
GRP set: the versions of the available ebuilds and their accompanying GRP
packages must match.
For this reason you can only benefit from the GRP packages Gentoo provides while
performing the current installation approach. GRP is not available for those
interested in performing an installation using the latest versions of all
available packages.
Is GRP Available?
Not all architectures provide GRP packages. That doesn't mean GRP isn't
supported on the other architectures, but it means that we don't have the
resources to build and test the GRP packages.
At present we provide GRP packages for the following architectures:
If your architecture (or subarchitecture) isn't on this list, you are not
able to opt for a GRP installation.
Now that this introduction is over, let's continue with Booting the Universal InstallCD/Installer
2.a. Hardware Requirements
Before we start, we first list what hardware requirements you need to
successfully install Gentoo on your box using the Installer LiveCD.
Hardware Requirements
2.b. The Gentoo Linux Installer LiveCD
A LiveCD is a bootable medium which contains a self-sustained Gentoo
environment. It allows you to boot Linux from the CD. During the boot process
your hardware is detected and the appropriate drivers are loaded. The Gentoo
Installation CDs are maintained by Gentoo developers.
There currently are two Installation CDs available:
2.c. Download, Burn and Boot the Gentoo Linux Installer LiveCD
Downloading and Burning the Installer LiveCD
You can download the Installer LiveCDs from one of our mirrors. They are located in the
releases/amd64/2007.0/livecd/ directory.
Inside that directory you'll find an ISO-file. That is a full CD image which
you can write on a CD-R.
After downloading the file, you can verify its integrity to see if it is
corrupted or not:
To fetch our public key using the GnuPG application, run the following command:
Code Listing 3.1: Obtaining the public key
$ gpg --keyserver subkeys.pgp.net --recv-keys 17072058
Now verify the signature:
Code Listing 3.2: Verify the cryptographic signature
$ gpg --verify <signature file> <downloaded iso>
To burn the downloaded ISO(s), you have to select raw-burning. How you do this
is highly program-dependent. We will discuss cdrecord and K3B
here; more information can be found in our Gentoo FAQ.
Booting the Installer LiveCD
Read this whole subsection before continuing, as you will probably not have the
opportunity to read it before doing things later.
Once you have burned your LiveCD, it is time to boot it. Remove all CDs from
your CD drives, reboot your system and enter the BIOS. This is usually done by
hitting DEL, F1 or ESC, depending on your BIOS. Inside the BIOS, change the
boot order so that the CD-ROM is tried before the hard disk. This is often
found under "CMOS Setup". If you don't do this, your system will just reboot
from the hard disk, ignoring the CD-ROM.
Now place the LiveCD in the CD-ROM drive and reboot. You should see a boot
prompt. At this screen, you can hit Enter to begin the boot process with the
default boot options, or boot the LiveCD with custom boot options by specifying
a kernel followed by boot options and then hitting Enter.
Specifying a kernel? Yes, we provide a few kernels on our LiveCD. The default
one is gentoo. Other kernels are for specific hardware needs and the
-nofb variants which disable framebuffer.
Below you'll find a short overview on the available kernels:
You can also provide kernel options. They represent optional settings you can
(de)activate at will. The following list is the same as the one you receive
when you press F2 through F7 at the bootscreen.
Code Listing 3.3: Options available to pass to your kernel of choice
Hardware options:
acpi=on This loads support for ACPI and also causes the acpid daemon to
be started by the CD on boot. This is only needed if your
system requires ACPI to function properly. This is not
required for Hyperthreading support.
acpi=off Completely disables ACPI. This is useful on some older
systems, and is also a requirement for using APM. This will
disable any Hyperthreading support of your processor.
console=X This sets up serial console access for the CD. The first
option is the device, usually ttyS0 on x86, followed by any
connection options, which are comma separated. The default
options are 9600,8,n,1.
dmraid=X This allows for passing options to the device-mapper RAID
subsystem. Options should be encapsulated in quotes.
doapm This loads APM driver support. This requires you to also use
doslowusb This adds some extra pauses into the boot process for the slow
USB CDROM of the IBM BladeCenter.
dopcmcia This loads support for PCMCIA and Cardbus hardware and also
causes the pcmcia cardmgr to be started by the CD on boot.
This is only required when booting from a PCMCIA/Cardbus device.
doscsi This loads support for most SCSI controllers. This is also a
requirement for booting most USB devices, as they use the SCSI
subsystem of the kernel.
hda=stroke This allows you to partition the whole hard disk even when your
BIOS is unable to handle large disks. This option is only used
on machines with an older BIOS. Replace hda with the device
that is requiring this option.
ide=nodma This forces the disabling of DMA in the kernel and is required
by some IDE chipsets and also by some CDROM drives. If your
system is having trouble reading from your IDE CDROM, try this
option. This also disables the default hdparm settings from
being executed.
noapic This disables the Advanced Programmable Interrupt Controller
that is present on newer motherboards. It has been known to
cause some problems on older hardware.
nodetect This disables all of the autodetection done by the CD,
including device autodetection and DHCP probing. This is
useful for doing debugging of a failing CD or driver.
nodhcp This disables DHCP probing on detected network cards. This is
useful on networks with only static addresses.
nodmraid Disables support for device-mapper RAID, such as that used for
on-board IDE/SATA RAID controllers.
nofirewire This disables the loading of Firewire modules. This should only
be necessary if your Firewire hardware is causing a problem
with booting the CD.
nogpm This disables gpm console mouse support.
nohotplug This disables the loading of the hotplug and coldplug init
scripts at boot. This is useful for doing debugging of a
failing CD or driver.
nokeymap This disables the keymap selection used to select non-US
keyboard layouts.
nolapic This disables the local APIC on Uniprocessor kernels.
nosata This disables the loading of Serial ATA modules. This is
useful if your system is having problems with the SATA subsystem.
nosmp This disables SMP, or Symmetric Multiprocessing, on SMP-enabled
kernels. This is useful for debugging SMP-related issues with
certain drivers and motherboards.
nosound This disables sound support and volume setting. This is useful
for systems where sound support causes problems.
nousb This disables the autoloading of USB modules. This is useful
for debugging USB issues.
Volume/Device Management:
dodevfs This enables the deprecated device filesystem on 2.6 systems.
You will also need to use noudev for this to take effect.
Since devfs is the only option with a 2.4 kernel, this option
has no effect if booting a 2.4 kernel.
doevms2 This enables support for IBM's pluggable EVMS, or Enterprise
Volume Management System. This is not safe to use with lvm2.
dolvm2 This enables support for Linux's Logical Volume Management.
This is not safe to use with evms2.
noudev This disables udev support on 2.6 kernels. This option
requires that dodevfs is used. Since udev is not an option for
2.4 kernels, this options has no effect if booting a 2.4
unionfs Enables support for Unionfs on supported CD images. This will
create a writable Unionfs overlay in a tmpfs, allowing you to
change any file on the CD.
unionfs=X Enables support for Unionfs on supported CD images. This will
create a writable Unionfs overlay on the device you specify.
The device must be formatted with a filesystem recognized and
writable by the kernel.
Other options:
debug Enables debugging code. This might get messy, as it displays
a lot of data to the screen.
docache This caches the entire runtime portion of the CD into RAM,
which allows you to umount /mnt/cdrom and mount another CDROM.
This option requires that you have at least twice as much
available RAM as the size of the CD.
doload=X This causes the initial ramdisk to load any module listed, as
well as dependencies. Replace X with the module name. Multiple
modules can be specified by a comma-separated list.
noload=X This causes the initial ramdisk to skip the loading of a
specific module that may be causing a problem. Syntax matches
that of doload.
nox This causes an X-enabled LiveCD to not automatically start X,
but rather, to drop to the command line instead.
scandelay This causes the CD to pause for 10 seconds during certain
portions the boot process to allow for devices that are slow to
initialize to be ready for use.
scandelay=X This allows you to specify a given delay, in seconds, to be
added to certain portions of the boot process to allow for
devices that are slow to initialize to be ready for use.
Replace X with the number of seconds to pause.
Now boot your CD, select a kernel (if you are not happy with the default
gentoo kernel) and boot options. As an example, we show you how
to boot the gentoo kernel, with dopcmcia as kernel
Code Listing 3.4: Booting an Installation CD
boot: gentoo dopcmcia
You will then be greeted with a boot screen and progress bar. If you are
installing Gentoo on a system with a non-US keyboard, make sure you
immediately press Alt-F1 to switch to verbose mode and follow the prompt. If no
selection is made in 10 seconds the default (US keyboard) will be accepted and
the boot process will continue. Once the boot process completes, Gnome will
start up and you will be automatically logged in to the "Live" Gentoo Linux
system as "gentoo" in graphical mode. You will be logged in as "root", the
superuser on the other consoles and should have a root ("#") prompt there. You
can switch to those consoles by pressing Alt-F2, Alt-F3, Alt-F4 Alt-F5, Alt-F6.
Get back to the graphical desktop you started on by pressing Alt-F7. To switch
to other consoles from within X, you must prefix the above with Ctrl. You are
able to run commands as root from any terminal within the graphical environment
by using the sudo application. You can even become root within a
terminal to perform multiple tasks.
Code Listing 3.5: Using sudo to run applications
(Example only)
(Editing the group file)
# sudo vi /etc/group
(Becoming root for a session)
# sudo su -
Extra Hardware Configuration
When the LiveCD boots, it tries to detect all your hardware devices and loads
the appropriate kernel modules to support your hardware. In the vast majority
of cases, it does a very good job. However, in some cases, it may not auto-load
the kernel modules you need. If the PCI auto-detection missed some of your
system's hardware, you will have to load the appropriate kernel modules
manually. These tasks require root access.
In the next example we try to load the 8139too module (support for
certain kinds of network interfaces):
Code Listing 3.6: Loading kernel modules
# modprobe 8139too
Optional: Tweaking Hard Disk Performance
If you are an advanced user, you might want to tweak the IDE hard disk
performance using hdparm. You will need root access to use hdparm.
With the -tT options you can test the performance of your disk (execute
it several times to get a more precise impression):
Code Listing 3.7: Testing disk performance
# hdparm -tT /dev/hda
To tweak, you can use any of the following examples (or experiment
yourself) which use /dev/hda as disk (substitute with your
Code Listing 3.8: Tweaking hard disk performance
(Activate DMA:)
# hdparm -d 1 /dev/hda
(Or with Safe Performance Options:)
# hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda
Optional: User Accounts
If you plan on giving other people access to your installation environment or
you want to chat using irssi without root privileges (for security
reasons), you need to create the necessary user accounts and change the root
password. You need root access to change the root password and add new users.
To change the root password, use the passwd utility:
Code Listing 3.9: Changing the root password
$ sudo su -
# passwd
New password: (Enter your new password)
Re-enter password: (Re-enter your password)
To create a user account, we first enter their credentials, followed by its
password. We use useradd and passwd for these tasks. In the next
example, we create a user called "john".
Code Listing 3.10: Creating a user account
# useradd -m -G users john
# passwd john
New password: (Enter john's password)
Re-enter password: (Re-enter john's password)
You can change your user id from root to the newly created user by using
Code Listing 3.11: Changing user id
# su - john
You can also change the password for the "gentoo" user in the graphical
environment. This account is already suitable for use on the Internet.
Code Listing 3.12: Changing the gentoo password
$ passwd
New password: (Enter your new password)
Re-enter password: (Re-enter your password)
Optional: Viewing Documentation while Installing
If you want to view the Gentoo Handbook (either from-CD or online) during the
installation, you can view it with Mozilla Firefox (from the graphical
environment) or with links (from a terminal environment).
Code Listing 3.13: Viewing the on-CD documentation with Firefox
# firefox /mnt/cdrom/docs/handbook/html/index.html
If you would prefer to use links to see a text-only version of the
handbook, make sure you have created a user account (see Optional: User Accounts). Then press Alt-F2
to go to a new terminal and log in.
Code Listing 3.14: Viewing the on-CD documentation with links
# links /mnt/cdrom/docs/handbook/html/index.html
You can go back to your original window by pressing Alt-F7.
However, it is preferred that you use the online Gentoo Handbook as it will be
more recent than the one provided on the CD. You can view it using Firefox or
links as well, but only after having completed the Configuring your
Network chapter (otherwise you won't be able to go on the Internet to view
the document):
Code Listing 3.15: Viewing the online documentation with Firefox
# firefox http://www.gentoo.org/doc/en/handbook/2007.0/handbook-amd64.xml
Code Listing 3.16: Viewing the online documentation with links
# links http://www.gentoo.org/doc/en/handbook/2007.0/handbook-amd64.xml
You can now choose to proceed by using the GTK+
based installer (which needs X) or the Dialog based installer that can be run on a
3.a. Welcome
Before you begin
Once the Gentoo Linux Installer (GLI) has finished loading, you will be greeted
by the welcome screen. It provides a friendly introduction to the process of
installing Gentoo on your computer. Remember to read each option carefully.
There is detailed help available for each step of installation; just look to the
left of each screen. We recommend that you always read the help pages before
making your choices. Note that at any time during the installation process, you
can save your configuration progress in case you need to resume your
installation at a later time.
There are three types of installation modes available. Choose Networkless
to begin installing Gentoo Linux.
Selecting Networkless will make some later configuration options
3.b. Partitioning
Preparing the disks
In order to install Gentoo on your machine, you will need to prepare your
disks. The Partitioning screen will show you a list of detected disks and
allow you to specify the filesystems you would like to have on your
partitions. Clicking Clear partitions will erase all previous partitions on
your disk, so be careful with this option! It is also possible to resize
certain partition types.
If you choose to go with the Recommended layout, the installer will erase
any previous partitions on your disk and create three partitions: 100MB for
/boot, a /swap partition up to 512MB in size, and the
rest of the available space on the disk is used for /, the root
As with any partitioning application, you should backup your system before
making changes to your partition table, as any possible bugs could cause data
loss. Any changes you make to your partition table will be performed by the
installer immediately.
3.c. Network Mounts
Optional: Define network mounts
This screen lets you set up and use any existing network mounts during and after
installation. Click New to begin configuration. At this time, only NFS is
3.d. make.conf
USE flags
Since you are performing a GRP/networkless install, you will not be allowed
to select USE flags before installation. However, you are free to set your own
USE flags in /etc/make.conf after you have rebooted into your
finished system.
You should, however, select your processor type in the CFLAGS section along
with any custom optimizations you may want, such as -O2 and
Any other options you wish to set for future use should be selected now.
Build binary packages creates ready-to-install binary tarballs of all
packages you compile on your system. DistCC allows you to share the
burden of compiling with another computer via your network connection.
You will not be allowed to change your CHOST, as this can seriously damage
your installation. In 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. On a
uniprocessor system, -j2 might be used.
3.e. Timezone
Choose your timezone
Study the map and select the region closest to your actual location. Later,
you will be asked to select if you want your clock to be set to UTC or local
3.f. Kernel Sources
Using the LiveCD kernel
You must use the kernel present on the LiveCD for the GRP/networkless install.
This is merely a gentoo-sources kernel compiled by genkernel,
Gentoo's automated kernel compilation utility and will give you a kernel that
automatically detects and configures your hardware upon boot.
3.g. Networking
Device information
On this screen, you will be able to configure the various network interface
devices on your computer. Read the available options carefully.
On the Hostname/Proxy Information/Other tab, you will need to choose a
hostname for your machine. You may also specify proxy server and DNS settings
if needed.
3.h. Daemons
Cron daemon
Cron daemons are helpful programs that run tasks at scheduled times. While you
do not need to install one, they can be quite useful. Since this is a
Networkless installation, you are limited to vixie-cron or no cron
System logger
A system logger is a necessity for any Linux operating system. Since this is a
Networkless installation, you are limited to syslog-ng or no logger.
3.i. Bootloader
This screen allows to you choose your bootloader and, optionally, specify
additional kernel parameters that will be used at bootup. Since this is a
Networkless installation, you are limited to grub or no bootloader.
You may specify which disk to boot from by choosing the appropriate option
from Boot Drive. In Linux, the first IDE disk in your system is called
hda, the second IDE disk is hdb, and so on. If you have SATA or
SCSI disks, they will be called sda, sdb, etc. Please make the
correct selection for your system.
If you need to pass any additional options to the kernel, such as video and/or
VGA statements, simply add them to the "Extra kernel parameters" section.
If you jumpered your harddrive because the BIOS can't handle large harddrives
you'll need to append hdx=stroke. If you have SCSI devices, you should
add doscsi as a kernel option.
3.j. Users
Adding users and groups
First set the root password for the system administrator (the root
We strongly recommend that you create a regular user for daily work.
Working as root all the time is dangerous and should be avoided! Create
your users, add them to the appropriate groups, and set their passwords. You
can optionally change their home directories, select their login shell, and
set helpful comments.
3.k. Extra Packages
Optional: installing extra packages
The LiveCD contains a number of available pre-built packages. If you wish to
install any of them, check the appropriate box.
3.l. Startup Services
This screen allows you to choose various services to load at system boot.
Study the available options and their descriptions carefully, and then select
your desired services. For example, if you have chosen to install
xorg-x11 and want to boot straight into a graphical desktop, then you
would select "xdm" from the list.
3.m. Other Settings
Miscellaneous options
Now you will be able to change various settings, including keyboard layout,
graphical display manager, the default editor, and whether to set your
hardware clock to UTC or local time.
3.n. Finishing Up
At this point, you're done. You can reboot into your new Gentoo system at any
Congratulations, your system is now fully equipped! Continue with Where to go from here? to learn more about
4.a. Welcome
After you boot the Gentoo Linux Installer LiveCD, it will attempt to load a
graphical desktop. If it is unable to do so, it will instead display a command
line prompt. To launch the installer, simply type:
Code Listing 1.1: Start the installer
# installer-dialog
Once the installer has finished loading, you will be greeted by the welcome
screen. It provides a friendly introduction to the process of installing Gentoo
on your computer. Remember to read each option carefully. There is detailed
help available for each step of installation at the top of the screen. We
recommend that you always read the help provided before making your choices.
Note that at any time during the installation process, you can save your
configuration progress in case you need to resume your installation at a later
time. Use the Tab key (on your keyboard) to move around the menus within
a screen and the Enter key to confirm an action.
There are two types of installation modes available, Standard and
Advanced. The first mode will set a number of options without requiring
your intervention, while the second mode will require you to make several more
choices during installation.
If you choose Standard, skip ahead to Partitioning. Otherwise, continue reading.
4.b. Advanced: Preinstallation Configuration
Manual Network Configuration
Even though you will be installing without a connection to the internet, you
can manually set up connections to your local area network (LAN), in case you
want to install Gentoo from another machine on your LAN.
If you wish to enable SSH access to the machine (for remote installation), you
can start sshd and specify a root password.
Load Additional Kernel Modules
If you need to load more kernel modules to support your hardware, enter their
names, each separated by a space.
4.c. Partitioning
In order to install Gentoo on your machine, you will need to prepare your
disks. The Partitioning screen will show you a list of detected disks and
allow you to specify the filesystems you would like to have on your
partitions. Selecting Clear partitions will erase all previous partitions on
your disk, so be careful with this option!
If you choose to go with the Recommended layout, the installer will
create three partitions: 100MB for /boot, a /swap
partition up to 512MB in size, and the rest of the available space on the disk
is used for /, the root partition.
As with any partitioning application, you should backup your system before
making changes to your partition table, as any possible bugs could cause data
4.d. System Configuration
Installation type
Since you are performing a GRP/networkless install, you must select
Networkless, then continue with the installation.
Study the list and select the region closest to your actual location.
On this screen, you will be able to configure the various network interface
devices detected on your computer. Read the available options carefully.
The next screen gives you a choice between DHCP and manual IP address
configuration. Once your network interface is properly configured, you will
need to create a hostname for your system. Optionally, you may specify a
domainname and any DNS server information needed.
This screen allows to you choose your bootloader (grub, or no
bootloader). Next, select your boot device and (optionally) specify any
additional boot options.
Users and groups
We strongly recommend that you create a regular user for daily work.
Working as root all the time is dangerous and should be avoided! Create
your users, set their passwords, and add them to the appropriate groups. You can
optionally change their home directories and select their login shell.
Extra Packages
Startup Services
This screen allows you to choose various services to load at system boot. Study
the available options and their descriptions carefully, and then select your
desired services. For example, if you have chosen to install xorg-x11
and want to boot straight into a graphical desktop, then you would select
"xdm" from the list.
Other Settings
If you chose to perform an Advanced installation, you now will be able to
change various settings, including keyboard layout, graphical display manager,
the default editor, and whether to set your hardware clock to UTC or local
4.e. Finishing Up
The installer will ask if you want to save your installation profile for
later use. The installer will alert you when it has finished. It will then
return you to the command prompt. All you need to do to reboot is type:
Code Listing 5.1: Rebooting
# shutdown -r now
5.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.
5.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 :)
5.c. Gentoo Changes since 2007.0
Gentoo is a fast-moving target. The following sections describe important
changes that affect a Gentoo installation. We only list those that have anything
in common with the installation, not with package changes that did not occur
during the installation.
There have been no significant changes since.
1.a. Welcome to Portage
Portage is probably Gentoo's most notable innovation in software management.
With its high flexibility and enormous amount of features it is frequently seen
as the best software management tool available for Linux.
Portage is completely written in Python
and Bash and therefore fully
visible to the users as both are scripting languages.
Most users will work with Portage through the emerge tool. This chapter
is not meant to duplicate the information available from the emerge man page.
For a complete rundown of emerge's options, please consult the man page:
Code Listing 1.1: Reading the emerge man page
$ man emerge
1.b. The Portage Tree
When we talk about packages, we often mean software titles that are available to
the Gentoo users through the Portage tree. The Portage tree is a collection of
ebuilds, files that contain all information Portage needs to maintain
software (install, search, query, ...). These ebuilds reside in
/usr/portage by default.
Whenever you ask Portage to perform some action regarding software titles, it
will use the ebuilds on your system as a base. It is therefore important that
you regularly update the ebuilds on your system so Portage knows about new
software, security updates, etc.
Updating the Portage Tree
The Portage tree is usually updated with rsync, a fast incremental file transfer
utility. Updating is fairly simple as the emerge command provides a
front-end for rsync:
Code Listing 2.1: Updating the Portage tree
# emerge --sync
If you are unable to rsync due to firewall restrictions you can still update
your Portage tree by using our daily generated Portage tree snapshots. The
emerge-webrsync tool automatically fetches and installs the latest
snapshot on your system:
Code Listing 2.2: Running emerge-webrsync
# emerge-webrsync
An additional advantage of using emerge-webrsync is that it allows the
administrator to only pull in portage tree snapshots that are signed by the
Gentoo release engineering GPG key. More information on this can be found
in the Portage Features section on
Fetching Validated Portage Tree
1.c. Maintaining Software
Searching for Software
To search through the Portage tree after software titles, you can use
emerge built-in search capabilities. By default, emerge --search
returns the names of packages whose title matches (either fully or partially)
the given search term.
For instance, to search for all packages who have "pdf" in their name:
Code Listing 3.1: Searching for pdf-named packages
$ emerge --search pdf
If you want to search through the descriptions as well you can use the
--searchdesc (or -S) switch:
Code Listing 3.2: Searching for pdf-related packages
$ emerge --searchdesc pdf
When you take a look at the output, you'll notice that it gives you a lot of
information. The fields are clearly labelled so we won't go further into their
Code Listing 3.3: Example 'emerge --search' output
* net-print/cups-pdf
Latest version available: 1.5.2
Latest version installed: [ Not Installed ]
Size of downloaded files: 15 kB
Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
Description: Provides a virtual printer for CUPS to produce PDF files.
License: GPL-2
Installing Software
Once you've found a software title to your liking, you can easily install it
with emerge: just add the package name. For instance, to install
Code Listing 3.4: Installing gnumeric
# emerge gnumeric
Since many applications depend on each other, any attempt to install a certain
software package might result in the installation of several dependencies as
well. Don't worry, Portage handles dependencies well. If you want to find out
what Portage would install when you ask it to install a certain package,
add the --pretend switch. For instance:
Code Listing 3.5: Pretend to install gnumeric
# emerge --pretend gnumeric
When you ask Portage to install a package, it will download the necessary source
code from the internet (if necessary) and store it by default in
/usr/portage/distfiles. After this it will unpack, compile and
install the package. If you want Portage to only download the sources without
installing them, add the --fetchonly option to the emerge command:
Code Listing 3.6: Download the sourcecode for gnumeric
# emerge --fetchonly gnumeric
Finding Installed Package Documentation
Many packages come with their own documentation. Sometimes, the doc USE
flag determines whether the package documentation should be installed or not.
You can check the existence of a doc USE flag with the emerge -vp
<package name> command.
Code Listing 3.7: Checking the existence of a doc USE flag
(alsa-lib is just an example, of course.)
# emerge -vp alsa-lib
[ebuild N ] media-libs/alsa-lib-1.0.14_rc1 -debug +doc 698 kB
The best way of enabling the doc USE flag is doing it on a per-package
basis via /etc/portage/package.use, so that you get documentation
only for packages that you are interested in. Enabling this flag globally is
known to cause problems with circular dependencies. For more information, please
read the USE Flags chapter.
Once the package installed, its documentation is generally found in a
subdirectory named after the package under the /usr/share/doc
directory. You can also list all installed files with the equery tool
which is part of the app-portage/gentoolkit package.
Code Listing 3.8: Locating package documentation
# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1
total 28
-rw-r--r-- 1 root root 669 May 17 21:54 ChangeLog.gz
-rw-r--r-- 1 root root 9373 May 17 21:54 COPYING.gz
drwxr-xr-x 2 root root 8560 May 17 21:54 html
-rw-r--r-- 1 root root 196 May 17 21:54 TODO.gz
(Alternatively, use equery to locate interesting files:)
# equery files alsa-lib | less
* Contents of media-libs/alsa-lib-1.0.14_rc1:
(Output truncated)
Removing Software
When you want to remove a software package from your system, use emerge
--unmerge. This will tell Portage to remove all files installed by that
package from your system except the configuration files of that
application if you have altered those after the installation. Leaving the
configuration files allows you to continue working with the package if you ever
decide to install it again.
However, a big warning applies: Portage will not check if
the package you want to remove is required by another package. It will however
warn you when you want to remove an important package that breaks your system
if you unmerge it.
Code Listing 3.9: Removing gnumeric from the system
# emerge --unmerge gnumeric
When you remove a package from your system, the dependencies of that package
that were installed automatically when you installed the software are left. To
have Portage locate all dependencies that can now be removed, use
emerge's --depclean functionality. We will talk about this later
Updating your System
To keep your system in perfect shape (and not to mention install the latest
security updates) you need to update your system regularly. Since Portage only
checks the ebuilds in your Portage tree you first have to update your Portage
tree. When your Portage tree is updated, you can update your system with
emerge --update @world. In the next example, we'll also use the
--ask switch which will tell Portage to display the list of packages it
wants to upgrade and ask you if you want to continue:
Code Listing 3.10: Updating your system
# emerge --update --ask @world
Portage will then search for newer version of the applications you have
installed. However, it will only verify the versions for the applications you
have explicitly installed (the applications listed in
/var/lib/portage/world) - it does not thoroughly check their
dependencies. If you want to update the dependencies of those packages as well,
add the --deep argument:
Code Listing 3.11: Updating your system with dependencies
# emerge --update --deep @world
Still, this doesn't mean all packages: some packages on your system are
needed during the compile and build process of packages, but once that package
is installed, these dependencies are no longer required. Portage calls those
build dependencies. To include those in an update cycle, add
Code Listing 3.12: Updating your entire system
# emerge --update --deep --with-bdeps=y @world
Since security updates also happen in packages you have not explicitly installed
on your system (but that are pulled in as dependencies of other programs), it
is recommended to run this command once in a while.
If you have altered any of your USE flags
lately you might want to add --newuse as well. Portage will then verify
if the change requires the installation of new packages or recompilation of
existing ones:
Code Listing 3.13: Performing a full update
# emerge --update --deep --with-bdeps=y --newuse @world
Some packages in the Portage tree don't have any real content but are used to
install a collection of packages. For instance, the kde-meta package will
install a complete KDE environment on your system by pulling in various
KDE-related packages as dependencies.
If you ever want to remove such a package from your system, running emerge
--unmerge on the package won't have much effect as the dependencies remain
on the system.
Portage has the functionality to remove orphaned dependencies as well, but since
the availability of software is dynamically dependent you first need to update
your entire system fully, including the new changes you applied when changing
USE flags. After this you can run emerge --depclean to remove the
orphaned dependencies. When this is done, you need to rebuild the applications
that were dynamically linked to the now-removed software titles but don't
require them anymore.
All this is handled with the following three commands:
Code Listing 3.14: Removing orphaned dependencies
# emerge --update --deep --newuse @world
# emerge --depclean
# revdep-rebuild
revdep-rebuild is provided by the gentoolkit package; don't forget
to emerge it first:
Code Listing 3.15: Installing the gentoolkit package
# emerge gentoolkit
1.d. Licenses
Beginning with Portage version 2.1.7, you can accept or reject software
installation based on its license. All packages in the tree contain a
LICENSE entry in their ebuilds. Running emerge --search
packagename will tell you the package's license.
By default, Portage permits all licenses, except End User License Agreements
(EULAs) that require reading and signing an acceptance agreement.
The variable that controls permitted licenses is ACCEPT_LICENSE, which
can be set in /etc/portage/make.conf. In the next example, this
default value is shown:
Code Listing 4.1: Setting ACCEPT_LICENSE in /etc/portage/make.conf
With this configuration, packages that require interaction during installation
to approve their EULA will not be installable. Packages without an EULA
will be installable.
You can set ACCEPT_LICENSE globally in /etc/portage/make.conf
, or you can specify it on a per-package basis in
For example, if you want to allow the truecrypt-2.7 license for
app-crypt/truecrypt, add the following to
Code Listing 4.2: Specifying a truecrypt license in package.license
app-crypt/truecrypt truecrypt-2.7
This permits installation of truecrypt versions that have the
truecrypt-2.7 license, but not versions with the truecrypt-2.8
Licenses are stored in /usr/portage/licenses, and license groups
are kept in /usr/portage/profiles/license_groups. The first entry
of each line in CAPITAL letters is the name of the license group, and every
entry after that is an individual license.
License groups defined in ACCEPT_LICENSE are prefixed with an @
sign. A commonly requested setting is to only allow the installation of free
software and documentation. To accomplish this, we can remove all currently
accepted licenses (using -*) and then only allow the licenses in the
FREE group as follows:
Code Listing 4.3: Only allowing free software and documentation licenses in /etc/portage/make.conf
In this case, "free" is mostly defined by the FSF and OSI. Any package whose license
does not meet these requirements will not be installable on your system.
1.e. When Portage is Complaining...
About SLOTs, Virtuals, Branches, Architectures and Profiles
As we stated before, Portage is extremely powerful and supports many features
that other software management tools lack. To understand this, we explain a few
aspects of Portage without going into too much detail.
With Portage different versions of a single package can coexist on a system.
While other distributions tend to name their package to those versions (like
freetype and freetype2) Portage uses a technology called
SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with
different SLOTs can coexist on the same system. For instance, the
freetype package has ebuilds with SLOT="1" and SLOT="2".
There are also packages that provide the same functionality but are implemented
differently. For instance, metalogd, sysklogd and syslog-ng
are all system loggers. Applications that rely on the availability of "a system
logger" cannot depend on, for instance, metalogd, as the other system
loggers are as good a choice as any. Portage allows for virtuals: each
system logger is listed as an "exclusive" dependency of the logging service in the
logger virtual package of the virtual category, so that
applications can depend on the virtual/logger package. When installed,
the package will pull in the first logging package mentioned in the package,
unless a logging package was already installed (in which case the virtual is
Software in the Portage tree can reside in different branches. By default your
system only accepts packages that Gentoo deems stable. Most new software titles,
when committed, are added to the testing branch, meaning more testing needs to
be done before it is marked as stable. Although you will see the ebuilds for
those software in the Portage tree, Portage will not update them before they are
placed in the stable branch.
Some software is only available for a few architectures. Or the software doesn't
work on the other architectures, or it needs more testing, or the developer that
committed the software to the Portage tree is unable to verify if the package
works on different architectures.
Each Gentoo installation adheres to a certain profile which contains,
amongst other information, the list of packages that are required for a system
to function normally.
Blocked Packages
Code Listing 5.1: Portage warning about blocked packages (with --pretend)
[blocks B ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
Code Listing 5.2: Portage warning about blocked packages (without --pretend)
!!! Error: the mail-mta/postfix package conflicts with another package.
!!! both can't be installed on the same system together.
!!! Please use 'emerge --pretend' to determine blockers.
Ebuilds contain specific fields that inform Portage about its dependencies.
There are two possible dependencies: build dependencies, declared in
DEPEND and run-time dependencies, declared in RDEPEND. When one of
these dependencies explicitly marks a package or virtual as being not
compatible, it triggers a blockage.
While recent versions of Portage are smart enough to work around minor blockages
without user intervention, occasionally you will need to fix it yourself, as
explained below.
To fix a blockage, you can choose to not install the package or unmerge the
conflicting package first. In the given example, you can opt not to install
postfix or to remove ssmtp first.
You may also see blocking packages with specific atoms, such as
<media-video/mplayer-1.0_rc1-r2. In this case, updating to a more
recent version of the blocking package would remove the block.
It is also possible that two packages that are yet to be installed are blocking
each other. In this rare case, you should find out why you need to install both.
In most cases you can do with one of the packages alone. If not, please file a
bug on Gentoo's bugtracking system.
Masked Packages
Code Listing 5.3: Portage warning about masked packages
!!! all ebuilds that could satisfy "bootsplash" have been masked.
Code Listing 5.4: Portage warning about masked packages - reason
!!! possible candidates are:
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-18.104.22.16840808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-188.8.131.52 (masked by: skype-eula license(s))
When you want to install a package that isn't available for your system, you
will receive this masking error. You should try installing a different
application that is available for your system or wait until the package is put
available. There is always a reason why a package is masked:
Necessary USE Flag Changes
Code Listing 5.5: Portage warning about USE flag change requirement
The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test
The error message might also be displayed as follows, if --autounmask
isn't set:
Code Listing 5.6: Portage error about USE flag change requirement
emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])
Such warning or error occurs when you want to install a package which not only
depends on another package, but also requires that that package is built with a
particular USE flag (or set of USE flags). In the given example, the package
app-text/feelings needs to be built with USE="test", but this USE
flag is not set on the system.
To resolve this, either add the requested USE flag to your global USE flags in
/etc/portage/make.conf, or set it for the specific package in
Missing Dependencies
Code Listing 5.7: Portage warning about missing dependency
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.
The application you are trying to install depends on another package that is not
available for your system. Please check bugzilla if the issue is known and if not,
please report it. Unless you are mixing branches this should not occur and is
therefore a bug.
Ambiguous Ebuild Name
Code Listing 5.8: Portage warning about ambiguous ebuild names
[ Results for search key : listen ]
[ Applications found : 2 ]
* dev-tinyos/listen [ Masked ]
Latest version available: 1.1.15
Latest version installed: [ Not Installed ]
Size of files: 10,032 kB
Homepage: http://www.tinyos.net/
Description: Raw listen for TinyOS
License: BSD
* media-sound/listen [ Masked ]
Latest version available: 0.6.3
Latest version installed: [ Not Installed ]
Size of files: 859 kB
Homepage: http://www.listen-project.org
Description: A Music player and management for GNOME
License: GPL-2
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.
The application you want to install has a name that corresponds with more than
one package. You need to supply the category name as well. Portage will inform
you of possible matches to choose from.
Circular Dependencies
Code Listing 5.9: Portage warning about circular dependencies
!!! Error: circular dependencies:
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2
Two (or more) packages you want to install depend on each other and can
therefore not be installed. This is most likely a bug in the Portage tree.
Please resync after a while and try again. You can also check bugzilla if the issue is known and if not,
report it.
Fetch failed
Code Listing 5.10: Portage warning about fetch failed
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
!!! Some fetch errors were encountered. Please see above for details.
Portage was unable to download the sources for the given application and will
try to continue installing the other applications (if applicable). This failure
can be due to a mirror that has not synchronised correctly or because the ebuild
points to an incorrect location. The server where the sources reside can also be
down for some reason.
Retry after one hour to see if the issue still persists.
System Profile Protection
Code Listing 5.11: Portage warning about profile-protected package
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.
You have asked to remove a package that is part of your system's core packages.
It is listed in your profile as required and should therefore not be removed
from the system.
Digest Verification Failures
Sometimes, when you attempt to emerge a package, it will fail with the message:
Code Listing 5.12: Digest verification failure
>>> checking ebuild checksums
!!! Digest verification failed:
This is a sign that something is wrong with the Portage tree -- often, it is
because a developer may have made a mistake when committing a package to the
When the digest verification fails, do not try to re-digest the package
yourself. Running ebuild foo manifest will not fix the problem; it will
almost certainly make it worse!
Instead, wait an hour or two for the tree to settle down. It's likely that the
error was noticed right away, but it can take a little time for the fix to
trickle down the Portage tree. While you're waiting, check Bugzilla and see if anyone has reported
the problem yet. If not, go ahead and file a bug for the broken package.
Once you see that the bug has been fixed, you may want to re-sync to pick up
the fixed digest.
This does not mean that you can re-sync your tree multiple times! As
stated in the rsync policy (when you run emerge --sync), users who sync
too often will be banned! In fact, it's better to just wait until your next
scheduled sync, so that you don't overload the rsync servers.
2.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 list of available global USE flags can be found online or locally in
A list of available local USE flags can be found online or locally in
2.b. Using USE flags
Declare permanent USE flags
In the hope you are convinced of the importance of USE flags we will now inform
you how to declare USE flags.
As previously mentioned, all USE flags are declared inside the USE
variable. To make it easy for users to search and pick USE flags, we already
provide a default USE setting. This setting is a collection of USE flags
we think are commonly used by the Gentoo users. This default setting is declared
in the make.defaults files part of your profile.
The profile your system listens to is pointed to by the
/etc/portage/make.profile symlink. Each profile works on top of
another, larger profile, the end result is therefore the sum of all profiles.
The top profile is the base profile
Let us take a look at this default setting for the 13.0 profile:
Code Listing 2.1: Cumulative make.defaults USE variable for the 13.0 profile
(This example is the sum of the settings in base, default/linux,
default/linux/x86 and default/linux/x86/13.0/)
USE="a52 aac acpi alsa branding cairo cdr dbus dts dvd dvdr emboss encode exif
fam firefox flac gif gpm gtk hal jpeg lcms ldap libnotify mad mikmod mng mp3
mp4 mpeg ogg opengl pango pdf png ppds qt3support qt4 sdl spell
startup-notification svg tiff truetype vorbis unicode usb X xcb x264 xml xv
As you can see, this variable already contains quite a lot of keywords. Do
not alter any make.defaults file to tailor
the USE variable to your needs: changes in this file will be undone when
you update Portage!
To change this default setting, you need to add or remove keywords to the
USE variable. This is done globally by defining the USE variable
in /etc/portage/make.conf. In this variable you add the extra USE
flags you require, or remove the USE flags you don't want. This latter is done
by prefixing the keyword with the minus-sign ("-").
For instance, to remove support for KDE and QT but add support for ldap, the
following USE can be defined in /etc/portage/make.conf:
Code Listing 2.2: An example USE setting in /etc/portage/make.conf
USE="-kde -qt4 ldap"
Declaring USE flags for individual packages
Sometimes you want to declare a certain USE flag for one (or a couple) of
applications but not system-wide. To accomplish this, you will need to create
the /etc/portage directory (if it doesn't exist yet) and edit
/etc/portage/package.use. This is usually a single file, but can
also be a directory; see man portage for more information. The following
examples assume package.use is a single file.
For instance, if you don't want berkdb support globally but you do want
it for mysql, you would add:
Code Listing 2.3: /etc/portage/package.use example
dev-db/mysql berkdb
You can of course also explicitly disable USE flags for a certain
application. For instance, if you don't want java support in PHP:
Code Listing 2.4: /etc/portage/package.use 2nd example
dev-php/php -java
Declare temporary USE flags
Sometimes you want to set a certain USE setting only once. Instead of editing
/etc/portage/make.conf twice (to do and undo the USE changes) you
can just declare the USE variable as environment variable. Remember that, when
you re-emerge or update this application (either explicitly or as part of a
system update) your changes will be lost!
As an example we will temporarily remove java from the USE setting
during the installation of seamonkey.
Code Listing 2.5: Using USE as environment variable
# USE="-java" emerge seamonkey
Of course there is a certain precedence on what setting has priority over the
USE setting. You don't want to declare USE="-java" only to see that
java is still used due to a setting that has a higher priority.
The precedence for the USE setting is, ordered
by priority (first has lowest priority):
To view the final USE setting as seen by Portage, run emerge
--info. This will list all relevant variables (including the USE
variable) with the content used by Portage.
Code Listing 2.6: Running emerge --info
# emerge --info
Adapting your Entire System to New USE Flags
If you have altered your USE flags and you wish to update your entire system to
use the new USE flags, use emerge's --newuse option:
Code Listing 2.7: Rebuilding your entire system
# emerge --update --deep --newuse @world
Next, run Portage's depclean to remove the conditional dependencies that
were emerged on your "old" system but that have been obsoleted by the new USE
Running emerge --depclean is a dangerous operation and should be handled
with care. Double-check the provided list of "obsoleted" packages to make sure
it doesn't remove packages you need. In the following example we add the
-p switch to have depclean only list the packages without removing them.
Code Listing 2.8: Removing obsoleted packages
# emerge -p --depclean
When depclean has finished, run revdep-rebuild to rebuild the
applications that are dynamically linked against shared objects provided by
possibly removed packages. revdep-rebuild is part of the
gentoolkit package; don't forget to emerge it first.
Code Listing 2.9: Running revdep-rebuild
# revdep-rebuild
When all this is accomplished, your system is using the new USE flag settings.
2.c. Package specific USE flags
Viewing available USE flags
Let us take the example of seamonkey: what USE flags does it listen to? To
find out, we use emerge with the --pretend and --verbose
Code Listing 3.1: Viewing the used USE flags
# emerge --pretend --verbose seamonkey
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] www-client/seamonkey-1.0.7 USE="crypt gnome java -debug -ipv6
-ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznopango
-moznoroaming -postgres -xinerama -xprint" 0 kB
emerge isn't the only tool for this job. In fact, we have a tool
dedicated to package information called equery which resides in the
gentoolkit package. First, install gentoolkit:
Code Listing 3.2: Installing gentoolkit
Now run equery with the uses argument to view the USE flags of a
certain package. For instance, for the gnumeric package:
Code Listing 3.3: Using equery to view used USE flags
# equery --nocolor uses =gnumeric-1.6.3 -a
[ Searching for packages matching =gnumeric-1.6.3... ]
[ Colour Code : set unset ]
[ Legend : Left column (U) - USE flags from make.conf ]
[ : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for app-office/gnumeric-1.6.3 ]
- - debug : Enable extra debug codepaths, like asserts and extra output.
If you want to get meaningful backtraces see
http://www.gentoo.org/proj/en/qa/backtraces.xml .
+ + 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.a. Portage Features
Portage has several additional features that makes your Gentoo experience even
better. Many of these features rely on certain software tools that improve
performance, reliability, security, ...
To enable or disable certain Portage features you need to edit
/etc/portage/make.conf's FEATURES variable which contains
the various feature keywords, separated by white space. In several cases you
will also need to install the additional tool on which the feature relies.
Not all features that Portage supports are listed here. For a full overview,
please consult the make.conf man page:
Code Listing 1.1: Consulting the make.conf man page
$ man make.conf
To find out what FEATURES are default set, run emerge --info and search
for the FEATURES variable or grep it out:
Code Listing 1.2: Finding out the FEATURES that are already set
$ emerge --info | grep ^FEATURES=
3.b. Distributed Compiling
Using distcc
distcc is a program to distribute compilations across several, not
necessarily identical, machines on a network. The distcc client sends all
necessary information to the available distcc servers (running distccd)
so they can compile pieces of source code for the client. The net result is a
faster compilation time.
You can find more information about distcc (and how to have it work
with Gentoo) in our Gentoo Distcc
Installing distcc
Distcc ships with a graphical monitor to monitor tasks that your computer is
sending away for compilation. If you use Gnome then put 'gnome' in your USE
variable. However, if you don't use Gnome and would still like to have the
monitor then you should put 'gtk' in your USE variable.
Code Listing 2.1: Installing distcc
# emerge distcc
Activating Portage Support
Add distcc to the FEATURES variable inside /etc/portage/make.conf.
Next, edit the MAKEOPTS variable to your liking. A known guideline is to fill in
"-jX" with X the number of CPUs that run distccd (including the current
host) plus one, but you might have better results with other numbers.
Now run distcc-config and enter the list of available distcc servers. For
a simple example we assume that the available DistCC servers are 192.168.1.102
(the current host), 192.168.1.103 and 192.168.1.104 (two "remote" hosts):
Code Listing 2.2: Configuring distcc to use three available distcc servers
# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"
Don't forget to run the distccd daemon as well:
Code Listing 2.3: Starting the distccd daemons
# rc-update add distccd default
# /etc/init.d/distccd start
3.c. Caching Compilation
About ccache
ccache is a fast compiler cache. When you compile a program, it will
cache intermediate results so that, whenever you recompile the same program, the
compilation time is greatly reduced. The first time you run ccache, it will be
much slower than a normal compilation. Subsequent recompiles should be faster.
ccache is only helpful if you will be recompiling the same application many
times; thus it's mostly only useful for software developers.
If you are interested in the ins and outs of ccache, please visit the
ccache homepage.
ccache is known to cause numerous compilation failures. Sometimes ccache
will retain stale code objects or corrupted files, which can lead to packages
that cannot be emerged. If this happens (if you receive errors like "File not
recognized: File truncated"), try recompiling the application with ccache
disabled (FEATURES="-ccache" in /etc/portage/make.conf)
before reporting a bug. Unless you are doing development work, do not
enable ccache.
Installing ccache
To install ccache, run emerge ccache:
Code Listing 3.1: Installing ccache
# emerge ccache
Open /etc/portage/make.conf and add ccache to the FEATURES
variable. Next, add a new variable called CCACHE_SIZE and set it to "2G":
Code Listing 3.2: Editing CCACHE_SIZE in /etc/portage/make.conf
To check if ccache functions, ask ccache to provide you with its statistics.
Because Portage uses a different ccache home directory, you need to set the
CCACHE_DIR variable as well:
Code Listing 3.3: Viewing ccache statistics
# CCACHE_DIR="/var/tmp/ccache" ccache -s
The /var/tmp/ccache location is Portage' default ccache home
directory; if you want to alter this setting you can set the CCACHE_DIR
variable in /etc/portage/make.conf.
However, if you would run ccache, it would use the default location of
${HOME}/.ccache, which is why you needed to set the
CCACHE_DIR variable when asking for the (Portage) ccache statistics.
Using ccache for non-Portage C Compiling
If you would like to use ccache for non-Portage compilations, add
/usr/lib/ccache/bin to the beginning of your PATH variable (before
/usr/bin). This can be accomplished by editing
.bash_profile in your user's home directory. Using
.bash_profile is one way to define PATH variables.
Code Listing 3.4: Editing .bash_profile
3.d. Binary Package Support
Creating Prebuilt Packages
Portage supports the installation of prebuilt packages. Even though Gentoo does
not provide prebuilt packages by itself Portage
can be made fully aware of prebuilt packages.
To create a prebuilt package you can use quickpkg if the package is
already installed on your system, or emerge with the --buildpkg or
--buildpkgonly options.
If you want Portage to create prebuilt packages of every single package you
install, add buildpkg to the FEATURES variable.
More extended support for creating prebuilt package sets can be obtained with
catalyst. For more information on catalyst please read the Catalyst Frequently Asked
Installing Prebuilt Packages
Although Gentoo doesn't provide one, you can create a central repository where
you store prebuilt packages. If you want to use this repository, you need to
make Portage aware of it by having the PORTAGE_BINHOST variable point to
it. For instance, if the prebuilt packages are on ftp://buildhost/gentoo:
Code Listing 4.1: Setting PORTAGE_BINHOST in /etc/portage/make.conf
When you want to install a prebuilt package, add the --getbinpkg option
to the emerge command alongside of the --usepkg option. The former tells
emerge to download the prebuilt package from the previously defined server
while the latter asks emerge to try to install the prebuilt package first before
fetching the sources and compiling it.
For instance, to install gnumeric with prebuilt packages:
Code Listing 4.2: Installing the gnumeric prebuilt package
# emerge --usepkg --getbinpkg gnumeric
More information about emerge's prebuilt package options can be found in the
emerge man page:
Code Listing 4.3: Reading the emerge man page
3.e. Fetching Files
Parallel fetch
When you are emerging a series of packages, Portage can fetch the source files
for the next package in the list even while it is compiling another package,
thus shortening compile times. To make use of this capability, add
"parallel-fetch" to your FEATURES. Note that this is on by default, so you
shouldn't need to specifically enable it.
When Portage is run as root, FEATURES="userfetch" will allow Portage to drop
root privileges while fetching package sources. This is a small security
3.f. Pulling Validated Portage Tree Snapshots
As an administrator, you can opt to only update your local Portage tree with a
cryptographically validated Portage tree snapshot as released by the Gentoo
infrastructure. This ensures that no rogue rsync mirror is adding unwanted code
or packages in the tree you are downloading.
To configure Portage, first create a truststore in which you download and accept
the keys of the Gentoo Infrastructure responsible for signing the Portage tree
snapshots. Of course, if you want to, you can validate this GPG key as per the
proper guidelines
(like checking the key fingerprint). You can find the list of GPG keys used by
the release engineering team on their project page.
Code Listing 6.1: Creating a truststore for Portage
# mkdir -p /etc/portage/gpg
# chmod 0700 /etc/portage/gpg
(... Substitute the keys with those mentioned on the release engineering site ...)
# gpg --homedir /etc/portage/gpg --keyserver subkeys.pgp.net --recv-keys 0xDB6B8C1F96D8BF6D
# gpg --homedir /etc/portage/gpg --edit-key 0xDB6B8C1F96D8BF6D trust
Next, edit /etc/portage/make.conf and enable support for validating
the signed Portage tree snapshots (using FEATURES="webrsync-gpg") and
disabling updating the Portage tree using the regular emerge --sync
Code Listing 6.2: Updating make.conf
Code Listing 6.3: Updating repos.conf
# Make sure sync-type and sync-uri are commented out
# sync-type = rsync
# sync-uri = ...
That's it. Next time you run emerge-webrsync, only the snapshots with
a valid signature will be expanded on your file system.
4.a. Runlevels
Booting your System
When you boot your system, you will notice lots of text floating by. If you pay
close attention, you will notice this text is the same every time you reboot
your system. The sequence of all these actions is called the boot
sequence and is (more or less) statically defined.
First, your boot loader will load the kernel image you have defined in the
boot loader configuration into memory after which it tells the CPU to run the
kernel. When the kernel is loaded and run, it initializes all kernel-specific
structures and tasks and starts the init process.
This process then makes sure that all filesystems (defined in
/etc/fstab) are mounted and ready to be used. Then it executes
several scripts located in /etc/init.d, which will start the
services you need in order to have a successfully booted system.
Finally, when all scripts are executed, init activates the terminals
(in most cases just the virtual consoles which are hidden beneath Alt-F1,
Alt-F2, etc.) attaching a special process called agetty to it.
This process will then make sure you are able to log on through these terminals
by running login.
Init Scripts
Now init doesn't just execute the scripts in /etc/init.d
randomly. Even more, it doesn't run all scripts in /etc/init.d,
only the scripts it is told to execute. It decides which scripts to execute by
looking into /etc/runlevels.
First, init runs all scripts from /etc/init.d that have
symbolic links inside /etc/runlevels/boot. Usually, it will
start the scripts in alphabetical order, but some scripts have dependency
information in them, telling the system that another script must be run before
they can be started.
When all /etc/runlevels/boot referenced scripts are executed,
init continues with running the scripts that have a symbolic link to them
in /etc/runlevels/default. Again, it will use the alphabetical
order to decide what script to run first, unless a script has dependency
information in it, in which case the order is changed to provide a valid
start-up sequence.
How Init Works
Of course init doesn't decide all that by itself. It needs a
configuration file that specifies what actions need to be taken. This
configuration file is /etc/inittab.
If you remember the boot sequence we have just described, you will remember
that init's first action is to mount all filesystems. This is defined in
the following line from /etc/inittab:
Code Listing 1.1: The system initialisation line in /etc/inittab
si::sysinit:/sbin/rc sysinit
This line tells init that it must run /sbin/rc sysinit to
initialize the system. The /sbin/rc script takes care of the
initialisation, so you might say that init doesn't do much -- it
delegates the task of initialising the system to another process.
Second, init executed all scripts that had symbolic links in
/etc/runlevels/boot. This is defined in the following line:
Code Listing 1.2: The system initialisation, continued
rc::bootwait:/sbin/rc boot
Again the rc script performs the necessary tasks. Note that the option
given to rc (boot) is the same as the subdirectory of
/etc/runlevels that is used.
Now init checks its configuration file to see what runlevel it
should run. To decide this, it reads the following line from
Code Listing 1.3: The initdefault line
In this case (which the majority of Gentoo users will use), the runlevel
id is 3. Using this information, init checks what it must run to start
runlevel 3:
Code Listing 1.4: The runlevel definitions
l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot
The line that defines level 3, again, uses the rc script to start the
services (now with argument default). Again note that the argument of
rc is the same as the subdirectory from /etc/runlevels.
When rc has finished, init decides what virtual consoles it should
activate and what commands need to be run at each console:
Code Listing 1.5: The virtual consoles definition
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
What is a runlevel?
You have seen that init uses a numbering scheme to decide what
runlevel it should activate. A runlevel is a state in which
your system is running and contains a collection of scripts (runlevel scripts or
initscripts) that must be executed when you enter or leave a runlevel.
In Gentoo, there are seven runlevels defined: three internal runlevels, and four
user-defined runlevels. The internal runlevels are called sysinit,
shutdown and reboot and do exactly what their names imply:
initialize the system, powering off the system and rebooting the system.
The user-defined runlevels are those with an accompanying
/etc/runlevels subdirectory: boot,
default, nonetwork and single. The
boot runlevel starts all system-necessary services which all other
runlevels use. The remaining three runlevels differ in what services they start:
default is used for day-to-day operations, nonetwork
is used in case no network connectivity is required, and single is
used when you need to fix the system.
Working with the Init Scripts
The scripts that the rc process starts are called init scripts.
Each script in /etc/init.d can be executed with the arguments
start, stop, restart, zap,
status, ineed, iuse, needsme, usesme or
To start, stop or restart a service (and all depending services), start,
stop and restart should be used:
Code Listing 1.6: Starting Postfix
# /etc/init.d/postfix start
Only the services that need the given service are stopped or restarted.
The other depending services (those that use the service but don't need
it) are left untouched.
If you want to stop a service, but not the services that depend on it, you can
use the --nodeps argument together with the stop command:
Code Listing 1.7: Stopping Postfix but keep the depending services running
# /etc/init.d/postfix --nodeps stop
If you want to see what status a service has (started, stopped, ...) you
can use the status argument:
Code Listing 1.8: Status information for postfix
# /etc/init.d/postfix status
If the status information tells you that the service is running, but you know
that it is not, then you can reset the status information to "stopped" with the
zap argument:
Code Listing 1.9: Resetting status information for postfix
# /etc/init.d/postfix zap
To also ask what dependencies the service has, you can use iuse or
ineed. With ineed you can see the services that are really
necessary for the correct functioning of the service. iuse on the other
hand shows the services that can be used by the service, but are not necessary
for the correct functioning.
Code Listing 1.10: Requesting a list of all necessary services on which Postfix depends
# /etc/init.d/postfix ineed
Similarly, you can ask what services require the service (needsme) or can
use it (usesme):
Code Listing 1.11: Requesting a list of all services that require Postfix
# /etc/init.d/postfix needsme
Finally, you can ask what dependencies the service requires that are missing:
Code Listing 1.12: Requesting a list of missing dependencies for Postfix
# /etc/init.d/postfix broken
4.b. Working with rc-update
What is rc-update?
Gentoo's init system uses a dependency-tree to decide what service needs to be
started first. As this is a tedious task that we wouldn't want our users to
have to do manually, we have created tools that ease the administration of the
runlevels and init scripts.
With rc-update you can add and remove init scripts to a runlevel. The
rc-update tool will then automatically ask the depscan.sh script
to rebuild the dependency tree.
Adding and Removing Services
You have already added init scripts to the "default" runlevel during the
installation of Gentoo. At that time you might not have had a clue what the
"default" is for, but now you should. The rc-update script requires a
second argument that defines the action: add, del or show.
To add or remove an init script, just give rc-update the add or
del argument, followed by the init script and the runlevel. For instance:
Code Listing 2.1: Removing Postfix from the default runlevel
# rc-update del postfix default
The rc-update -v show command will show all the available init scripts and
list at which runlevels they will execute:
Code Listing 2.2: Receiving init script information
# rc-update -v show
You can also run rc-update show (without -v) to just view enabled
init scripts and their runlevels.
4.c. Configuring Services
Why the Need for Extra Configuration?
Init scripts can be quite complex. It is therefore not really desirable to
have the users edit the init script directly, as it would make it more
error-prone. It is however important to be able to configure such a service. For
instance, you might want to give more options to the service itself.
A second reason to have this configuration outside the init script is to be
able to update the init scripts without the fear that your configuration
changes will be undone.
The /etc/conf.d Directory
Gentoo provides an easy way to configure such a service: every init script that
can be configured has a file in /etc/conf.d. For instance, the
apache2 initscript (called /etc/init.d/apache2) has a
configuration file called /etc/conf.d/apache2, which can contain
the options you want to give to the Apache 2 server when it is started:
Code Listing 3.1: Variable defined in /etc/conf.d/apache2
Such a configuration file contains variables and variables alone (just like
/etc/portage/make.conf), making it very easy to configure services.
It also allows us to provide more information about the variables (as comments).
4.d. Writing Init Scripts
Do I Have To?
No, writing an init script is usually not necessary as Gentoo provides
ready-to-use init scripts for all provided services. However, you might have
installed a service without using Portage, in which case you will most likely
have to create an init script.
Do not use the init script provided by the service if it isn't explicitly
written for Gentoo: Gentoo's init scripts are not compatible with the init
scripts used by other distributions!
The basic layout of an init script is shown below.
Code Listing 4.1: Basic layout of an init script
depend() {
(Dependency information)
start() {
(Commands necessary to start the service)
stop() {
(Commands necessary to stop the service)
Any init script requires the start() function to be defined. All
other sections are optional.
There are two dependency-alike settings you can define that influence the
start-up or sequencing of init scripts: use and need. Next to
these two, there are also two order-influencing methods called before and
after. These last two are no dependencies per se - they do not make the
original init script fail if the selected one isn't scheduled to start (or fails
to start).
It should be clear from the above that need is the only "true" dependency
setting as it affects if the script will be started or not. All the others are
merely pointers towards the init system to clarify in which order scripts can be
(or should be) launched.
Now, if you look at many of Gentoo's available init scripts, you will notice
that some have dependencies on things that are no init scripts. These "things"
we call virtuals.
A virtual dependency is a dependency that a service provides, but that is
not provided solely by that service. Your init script can depend on a system
logger, but there are many system loggers available (metalogd, syslog-ng,
sysklogd, ...). As you cannot need every single one of them (no sensible
system has all these system loggers installed and running) we made sure that
all these services provide a virtual dependency.
Let us take a look at the dependency information for the postfix service.
Code Listing 4.2: Dependency information for Postfix
depend() {
need net
use logger dns
provide mta
As you can see, the postfix service:
Controlling the Order
As we described in the previous section, you can tell the init system what order
it should use for starting (or stopping) scripts. This ordering is handled both
through the dependency settings use and need, but also through the
order settings before and after. As we have described these
earlier already, let's take a look at the Portmap service as an example of such
init script.
Code Listing 4.3: The depend() function in the Portmap service
depend() {
need net
before inetd
before xinetd
You can also use the "*" glob to catch all services in the same runlevel,
although this isn't advisable.
Code Listing 4.4: Running an init script as first script in the runlevel
depend() {
before *
If your service must write to local disks, it should need localmount. If
it places anything in /var/run such as a pidfile, then it should
start after bootmisc:
Code Listing 4.5: Example depend() function
depend() {
need localmount
after bootmisc
Standard Functions
Next to the depend() functionality, you also need to define the
start() function. This one contains all the commands necessary to
initialize your service. It is advisable to use the ebegin and
eend functions to inform the user about what is happening:
Code Listing 4.6: Example start() function
start() {
if [ "${RC_CMD}" = "restart" ];
# Do something in case a restart requires more than stop, start
ebegin "Starting my_service"
start-stop-daemon --start --exec /path/to/my_service \
--pidfile /path/to/my_pidfile
eend $?
Both --exec and --pidfile should be used in start and stop
functions. If the service does not create a pidfile, then use
--make-pidfile if possible, though you should test this to be sure.
Otherwise, don't use pidfiles. You can also add --quiet to the
start-stop-daemon options, but this is not recommended unless the
service is extremely verbose. Using --quiet may hinder debugging if the
service fails to start.
Another notable setting used in the above example is to check the contents of
the RC_CMD variable. Unlike the previous init script system, the newer
openrc system does not support script-specific restart functionality.
Instead, the script needs to check the contents of the RC_CMD variable
to see if a function (be it start() or stop()) is called as part
of a restart or not.
Make sure that --exec actually calls a service and not just a shell
script that launches services and exits -- that's what the init script is
supposed to do.
If you need more examples of the start() function, please read the
source code of the available init scripts in your /etc/init.d
Another function you can define is stop(). You are not obliged to define
this function though! Our init system is intelligent enough to fill in this
function by itself if you use start-stop-daemon.
Here is an example of a stop() function:
Code Listing 4.7: Example stop() function
stop() {
ebegin "Stopping my_service"
start-stop-daemon --stop --exec /path/to/my_service \
--pidfile /path/to/my_pidfile
eend $?
If your service runs some other script (for example, bash, python, or perl),
and this script later changes names (for example, 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:
Code Listing 4.8: A service that starts the foo script
start() {
ebegin "Starting my_script"
start-stop-daemon --start --exec /path/to/my_script \
--pidfile /path/to/my_pidfile --name foo
eend $?
start-stop-daemon has an excellent man page available if you need more
Code Listing 4.9: Getting the man page for start-stop-daemon
$ man start-stop-daemon
Gentoo's init script syntax is based on the POSIX Shell so you are
free to use sh-compatible constructs inside your init script. Keep other
constructs, like bash-specific ones, out of the init scripts to ensure that the
scripts remain functional regardless of the change Gentoo might do on its init
Adding Custom Options
If you want your init script to support more options than the ones we have
already encountered, you should add the option to the extra_commands
variable, and create a function with the same name as the option. For instance,
to support an option called restartdelay:
Code Listing 4.10: Supporting the restartdelay option
restartdelay() {
sleep 3 # Wait 3 seconds before starting again
The function restart() cannot be overridden in openrc!
Service Configuration Variables
You don't have to do anything to support a configuration file in
/etc/conf.d: if your init script is executed, the following files
are automatically sourced (i.e. the variables are available to use):
Also, if your init script provides a virtual dependency (such as net),
the file associated with that dependency (such as /etc/conf.d/net)
will be sourced too.
4.e. Changing the Runlevel Behaviour
Who might benefit from this?
Many laptop users know the situation: at home you need to start net.eth0
while you don't want to start net.eth0 while you're on the road (as
there is no network available). With Gentoo you can alter the runlevel behaviour
to your own will.
For instance you can create a second "default" runlevel which you can boot that
has other init scripts assigned to it. You can then select at boottime what
default runlevel you want to use.
Using softlevel
First of all, create the runlevel directory for your second "default" runlevel.
As an example we create the offline runlevel:
Code Listing 5.1: Creating a runlevel directory
# mkdir /etc/runlevels/offline
Add the necessary init scripts to the newly created runlevels. For instance, if
you want to have an exact copy of your current default runlevel but
without net.eth0:
Code Listing 5.2: Adding the necessary init scripts
(Copy all services from default runlevel to offline runlevel)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Remove unwanted service from offline runlevel)
# rc-update del net.eth0 offline
(Display active services for offline runlevel)
# rc-update show offline
(Partial sample Output)
acpid | offline
domainname | offline
local | offline
net.eth0 |
Even though net.eth0 has been removed from the offline runlevel,
udev might want to attempt to start any devices it detects and launch the
appropriate services, a functionality that is called hotplugging. By
default, Gentoo does not enable hotplugging.
If you do want to enable hotplugging, but only for a selected set of scripts,
use the rc_hotplug variable in /etc/rc.conf:
Code Listing 5.3: Disabling device initiated services in /etc/rc.conf
# Allow net.wlan as well as any other service, except those matching net.*
# to be hotplugged
rc_hotplug="net.wlan !net.*"
For more information on device initiated services, please see the comments
inside /etc/rc.conf.
Now edit your bootloader configuration and add a new entry for the
offline runlevel. For instance, in /boot/grub/grub.conf:
Code Listing 5.4: Adding an entry for the offline runlevel
title Gentoo Linux Offline Usage
root (hd0,0)
kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline
Voilà, you're all set now. If you boot your system and select the newly added
entry at boot, the offline runlevel will be used instead of the
default one.
Using bootlevel
Using bootlevel is completely analogous to softlevel. The only
difference here is that you define a second "boot" runlevel instead of a second
"default" runlevel.
5.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
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:
Code Listing 1.1: Example definitions
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
/usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
/usr/share/texmf/tex/platex/config/ /usr/share/config"
5.b. Defining Variables Globally
The /etc/env.d Directory
To centralise the definitions of these variables, Gentoo introduced the
/etc/env.d directory. Inside this directory you will find a number
of files, such as 00basic, 05gcc, etc. which contain
the variables needed by the application mentioned in their name.
For instance, when you installed gcc, a file called 05gcc
was created by the ebuild which contains the definitions of the following
Code Listing 2.1: /etc/env.d/05gcc
Other distributions tell you to change or add such environment variable
definitions in /etc/profile or other locations. Gentoo on the other
hand makes it easy for you (and for Portage) to maintain and manage the
environment variables without having to pay attention to the numerous files that
can contain environment variables.
For instance, when gcc is updated, the /etc/env.d/05gcc file
is updated too without requesting any user-interaction.
This not only benefits Portage, but also you, as user. Occasionally you might
be asked to set a certain environment variable system-wide. As an example we
take the http_proxy variable. Instead of messing about with
/etc/profile, you can now just create a file
(/etc/env.d/99local) and enter your definition(s) in it:
Code Listing 2.2: /etc/env.d/99local
By using the same file for all your variables, you have a quick overview on the
variables you have defined yourself.
The env-update Script
Several files in /etc/env.d define the PATH variable. This
is not a mistake: when you run env-update, it will append the several
definitions before it updates the environment variables, thereby making it easy
for packages (or users) to add their own environment variable settings without
interfering with the already existing values.
The env-update script will append the values in the alphabetical order
of the /etc/env.d files. The file names must begin with two
decimal digits.
Code Listing 2.3: Update order used by env-update
00basic 99kde-env 99local
The concatenation of variables does not always happen, only with the following
variables: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH,
PKG_CONFIG_PATH and PYTHONPATH.
For all other variables the latest defined value (in alphabetical order of the
files in /etc/env.d) is used.
You can add more variables into this list of concatenate-variables by adding the
variable name to either COLON_SEPARATED or SPACE_SEPARATED
variables (also inside an env.d file).
When you run env-update, the script will create all environment variables
and place them in /etc/profile.env (which is used by
/etc/profile). It will also extract the information from the
LDPATH variable and use that to create /etc/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
Code Listing 2.4: Updating the environment
# env-update && source /etc/profile
The above command only updates the variables in your current terminal,
new consoles, and their children. Thus, if you are working in X11, you
will need to either type source /etc/profile in every new terminal you
open or restart X so that all new terminals source the new variables. If you
use a login manager, become root and type /etc/init.d/xdm restart. If
not, you will need to logout and log back in for X to spawn children with the
new variable values.
You cannot use shell variables when defining other variables. This means things
like FOO="$BAR" (where $BAR is another variable) are forbidden.
5.c. Defining Variables Locally
User Specific
You do not always want to define an environment variable globally. For instance,
you might want to add /home/my_user/bin and the current working
directory (the directory you are in) to the PATH variable
but don't want all other users on your system to have that in their PATH
too. If you want to define an environment variable locally, you should use
~/.bashrc or ~/.bash_profile:
Code Listing 3.1: Extending PATH for local usage in ~/.bashrc
(A colon followed by no directory is treated as the current working directory)
When you relogin, your PATH variable will be updated.
Session Specific
Sometimes even stricter definitions are requested. You might want to be able to
use binaries from a temporary directory you created without using the path to
the binaries themselves or editing ~/.bashrc for the short time
you need it.
In this case, you can just define the PATH variable in your current
session by using the export command. As long as you don't log out, the
PATH variable will be using the temporary settings.
Code Listing 3.2: Defining a session-specific environment variable
# export PATH="${PATH}:/home/my_user/tmp/usr/bin"
1.a. Portage Files
Configuration Directives
Portage comes with a default configuration stored in
/usr/share/portage/config/make.globals. When you take a look at it, you'll notice that
all Portage configuration is handled through variables. What variables Portage
listens to and what they mean are described later.
Since many configuration directives differ between architectures, Portage also
has default configuration files which are part of your profile. Your profile is
pointed to by the /etc/portage/make.profile symlink; Portage'
configurations are set in the make.defaults files of your profile
and all parent profiles. We'll explain more about profiles
and the /etc/portage/make.profile directory later on.
If you're planning on changing a configuration variable, don't alter
/usr/share/portage/config/make.globals or make.defaults. Instead use
/etc/portage/make.conf which has precedence over the previous
files. You'll also find a /usr/share/portage/config/make.conf.example.
As the name implies, this is merely an example file - Portage does not read
in this file.
You can also define a Portage configuration variable as an environment variable,
but we don't recommend this.
Profile-Specific Information
We've already encountered the /etc/portage/make.profile directory.
Well, this isn't exactly a directory but a symbolic link to a profile, by
default one inside /usr/portage/profiles although you can create
your own profiles elsewhere and point to them. The profile this symlink points
to is the profile to which your system adheres.
A profile contains architecture-specific information for Portage, such as a
list of packages that belong to the system corresponding with that profile,
a list of packages that don't work (or are masked-out) for that profile, etc.
User-Specific Configuration
When you need to override Portage's behaviour regarding the installation of
software, you will end up editing files within /etc/portage. You
are highly recommended to use files within /etc/portage and
highly discouraged to override the behaviour through environment
Within /etc/portage you can create the following files:
These don't have to be files; they can also be directories that contain one file
per package. More information about the /etc/portage directory and
a full list of possible files you can create can be found in the Portage man
Code Listing 1.1: Reading the Portage man page
$ man portage
Changing Portage File & Directory Locations
The previously mentioned configuration files cannot be stored elsewhere -
Portage will always look for those configuration files at those exact locations.
However, Portage uses many other locations for various purposes: build
directory, source code storage, Portage tree location, ...
All these purposes have well-known default locations but can be altered to your
own taste through /etc/portage/make.conf. The rest of this chapter
explains what special-purpose locations Portage uses and how to alter their
placement on your filesystem.
This document isn't meant to be used as a reference though. If you need 100%
coverage, please consult the Portage and make.conf man pages:
Code Listing 1.2: Reading the Portage and make.conf man pages
$ man portage
$ man make.conf
1.b. Storing Files
The Portage Tree
The Portage tree default location is /usr/portage. This is defined
by the PORTDIR variable. When you store the Portage tree elsewhere (by altering
this variable), don't forget to change the /etc/portage/make.profile
symbolic link accordingly.
If you alter the PORTDIR variable, you might want to alter the following
variables as well since they will not notice the PORTDIR change. This is due to
how Portage handles variables: PKGDIR, DISTDIR, RPMDIR.
Prebuilt Binaries
Even though Portage doesn't use prebuilt binaries by default, it has extensive
support for them. When you ask Portage to work with prebuilt packages, it will
look for them in /usr/portage/packages. This location is defined by
the PKGDIR variable.
Source Code
Application source code is stored in /usr/portage/distfiles by
default. This location is defined by the DISTDIR variable.
Portage Database
Portage stores the state of your system (what packages are installed, what files
belong to which package, ...) in /var/db/pkg. Do not alter
these files manually! It might break Portage's knowledge of your system.
Portage Cache
The Portage cache (with modification times, virtuals, dependency tree
information, ...) is stored in /var/cache/edb. This location really
is a cache: you can clean it if you are not running any portage-related
application at that moment.
1.c. Building Software
Temporary Portage Files
Portage's temporary files are stored in /var/tmp by default. This
is defined by the PORTAGE_TMPDIR variable.
If you alter the PORTAGE_TMPDIR variable, you might want to alter the following
variables as well since they will not notice the PORTAGE_TMPDIR change. This
is due to how Portage handles variables: BUILD_PREFIX.
Building Directory
Portage creates specific build directories for each package it emerges inside
/var/tmp/portage. This location is defined by the BUILD_PREFIX
Live Filesystem Location
By default Portage installs all files on the current filesystem
(/), but you can change this by setting the ROOT environment
variable. This is useful when you want to create new build images.
1.d. Logging Features
Ebuild Logging
Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable
is set to a location that is writable by Portage (the portage user). By default
this variable is unset. If you don't set PORT_LOGDIR, then you won't receive
any build logs with the current logging system, though you may receive some
logs from the new elog. If you do have PORT_LOGDIR defined and you use
elog, you will receive build logs and any logs saved by elog, as explained
Portage offers fine-grained control over logging through the use of
If you used enotice with Portage-2.0.*, you must completely remove
enotice, as it is incompatible with elog.
2.a. Portage Configuration
As noted previously, Portage is configurable through many variables which
you should define in /etc/portage/make.conf or one of the subdirectories
of /etc/portage. Please refer to the make.conf and
portage man pages for more and complete information:
Code Listing 1.1: Reading the man pages
$ man make.conf
$ man portage
2.b. Build-specific Options
Configure and Compiler Options
When Portage builds applications, it passes the contents of the following
variables to the compiler and configure script:
The USE variable is also used during configure and compilations but has been
explained in great detail in previous chapters.
Merge Options
When Portage has merged a newer version of a certain software title, it will
remove the obsoleted files of the older version from your system. Portage gives
the user a 5 second delay before unmerging the older version. These 5 seconds
are defined by the CLEAN_DELAY variable.
You can tell emerge to use certain options every time it is run by
setting EMERGE_DEFAULT_OPTS. Some useful options would be --ask, --verbose,
--tree, and so on.
2.c. Configuration File Protection
Portage's Protected Locations
Portage overwrites files provided by newer versions of a software title if the
files aren't stored in a protected location. These protected locations
are defined by the CONFIG_PROTECT variable and are generally configuration file
locations. The directory listing is space-delimited.
A file that would be written in such a protected location is renamed and the
user is warned about the presence of a newer version of the (presumable)
configuration file.
You can find out about the current CONFIG_PROTECT setting from the emerge
--info output:
Code Listing 3.1: Getting the CONFIG_PROTECT setting
$ emerge --info | grep 'CONFIG_PROTECT='
More information about Portage's Configuration File Protection is available
in the CONFIGURATION FILES section of the emerge manpage:
Code Listing 3.2: More information about Configuration File Protection
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:
A third setting involves the location of the rsync server which you use when you
update your Portage tree. This is defined in the /etc/portage/repos.conf
file (or a file inside that directory if it is defined as a directory):
The GENTOO_MIRRORS, sync-type and sync-uri variables can be set automatically through the
mirrorselect application. You need to emerge mirrorselect first
before you can use it. For more information, see mirrorselect's online
Code Listing 4.1: More information about mirrorselect
# mirrorselect --help
If your environment requires you to use a proxy server, you can use the
http_proxy, ftp_proxy and RSYNC_PROXY variables to declare a proxy server.
Fetch Commands
When Portage needs to fetch source code, it uses wget by default. You
can change this through the FETCHCOMMAND variable.
Portage is able to resume partially downloaded source code. It uses wget
by default, but this can be altered through the RESUMECOMMAND variable.
Make sure that your FETCHCOMMAND and RESUMECOMMAND stores the source code in the
correct location. Inside the variables you should use \${URI} and \${DISTDIR} to
point to the source code location and distfiles location respectively.
You can also define protocol-specific handlers with FETCHCOMMAND_HTTP,
FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.
Rsync Settings
You cannot alter the rsync command used by Portage to update the Portage tree,
but you can set some variables related to the rsync command:
For more information on these options and others, please read man
2.e. Gentoo Configuration
Branch Selection
You can change your default branch with the ACCEPT_KEYWORDS variable. It
defaults to your architecture's stable branch. More information on Gentoo's
branches can be found in the next chapter.
Portage Features
You can activate certain Portage features through the FEATURES variable. The
Portage Features have been discussed in previous chapters, such as Portage Features.
2.f. Portage Behaviour
Resource Management
With the PORTAGE_NICENESS variable you can augment or reduce the nice value
Portage runs with. The PORTAGE_NICENESS value is added to the current
nice value.
For more information about nice values, see the nice man page:
Code Listing 6.1: More information about nice
$ man nice
Output Behaviour
The NOCOLOR, which defaults to "false", defines if Portage should disable the
use of coloured output.
3.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 https://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
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
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
For example, to select the testing branch for the x86 architecture, edit
/etc/portage/make.conf and set:
Code Listing 1.1: Setting the ACCEPT_KEYWORDS variable
If you update your system now, you will find out that lots of packages
will be updated. Mind you though: when you have updated your system to use the
testing branch there is usually no easy way back to the stable, official branch
(except for using backups of course).
3.b. Mixing Stable with Testing
The package.accept_keywords location
You can ask Portage to allow the testing branch for particular packages but use
the stable branch for the rest of the system. To achieve this, add the package
category and name you want to use the testing branch of in
/etc/portage/package.accept_keywords. You can also create a
directory (with the same name) and list the package in the files under that
directory. For instance, to use the testing branch for gnumeric:
Code Listing 2.1: /etc/portage/package.accept_keywords setting for gnumeric
Test Particular Versions
If you want to use a specific software version from the testing branch but you
don't want Portage to use the testing branch for subsequent versions, you can
add in the version in the package.accept_keywords location. In this
case you must use the = operator. You can also enter a version range
using the <=, <, > or >= operators.
In any case, if you add version information, you must use an operator. If
you leave out version information, you cannot use an operator.
In the following example we ask Portage to accept gnumeric-1.2.13:
Code Listing 2.2: Enabling a particular gnumeric test version
3.c. Using Masked Packages
The package.unmask location
The Gentoo developers do not support the use of this location. Please
exercise due caution when doing so. Support requests related to
package.unmask and/or package.mask will not be answered. You have
been warned.
When a package has been masked by the Gentoo developers and you still want to
use it despite the reason mentioned in the package.mask file
(situated in /usr/portage/profiles by default), add the
desired version (usually this will be the exact same line from
profiles) in the /etc/portage/package.unmask file
(or in a file in that directory if it is a directory).
For instance, if =net-mail/hotwayd-0.8 is masked, you can unmask it by
adding the exact same line in the package.unmask location:
Code Listing 3.1: /etc/portage/package.unmask
If an entry in /usr/portage/profiles/package.mask contains a range
of package versions, you will need to unmask only the version(s) you actually
want. Please read the previous section to learn how
to specify versions in package.unmask.
The package.mask location
When you don't want Portage to take a certain package or a specific version of a
package into account you can mask it yourself by adding an appropriate line to
the /etc/portage/package.mask location (either in that file or
in a file in this directory).
For instance, if you don't want Portage to install newer kernel sources than
gentoo-sources-18.104.22.168, you add the following line at the
package.mask location:
Code Listing 3.2: /etc/portage/package.mask example
4.a. dispatch-conf
dispatch-conf is a tool that aids in merging the
._cfg0000_<name> files. ._cfg0000_<name>
files are generated by Portage when it wants to overwrite a file in a directory
protected by the CONFIG_PROTECT variable.
With dispatch-conf, you are able to merge updates to your configuration
files while keeping track of all changes. dispatch-conf stores the
differences between the configuration files as patches or by using the RCS
revision system. This means that if you make a mistake when updating a config
file, you can revert to the previous version of your config file at any time.
When using dispatch-conf, you can ask to keep the configuration file
as-is, use the new configuration file, edit the current one or merge the changes
interactively. dispatch-conf also has some nice additional features:
Make certain you edit /etc/dispatch-conf.conf first and create the
directory referenced by the archive-dir variable.
Code Listing 1.1: Running dispatch-conf
# dispatch-conf
When running dispatch-conf, you'll be taken through each changed config
file, one at a time. Press u to update (replace) the current config file
with the new one and continue to the next file. Press z to zap (delete)
the new config file and continue to the next file. Once all config files have
been taken care of, dispatch-conf will exit. You can also press q
to exit any time.
For more information, check out the dispatch-conf man page. It tells you
how to interactively merge current and new config files, edit new config files,
examine differences between files, and more.
Code Listing 1.2: Reading the dispatch-conf man page
$ man dispatch-conf
4.b. etc-update
You can also use etc-update to merge config files. It's not as simple to
use as dispatch-conf, nor as featureful, but it does provide an
interactive merging setup and can also auto-merge trivial changes.
However, unlike dispatch-conf, etc-update does not preserve
the old versions of your config files. Once you update the file, the old version
is gone forever! So be very careful, as using etc-update is
significantly less safe than using dispatch-conf.
Code Listing 2.1: Running etc-update
# etc-update
After merging the straightforward changes, you will be prompted with a list of
protected files that have an update waiting. At the bottom you are greeted by
the possible options:
Code Listing 2.2: etc-update options
Please select a file to edit by entering the corresponding number.
(-1 to exit) (-3 to auto merge all remaining files)
(-5 to auto-merge AND not use 'mv -i'):
If you enter -1, etc-update will exit and discontinue any further
changes. If you enter -3 or -5, all listed configuration
files will be overwritten with the newer versions. It is therefore very
important to first select the configuration files that should not be
automatically updated. This is simply a matter of entering the number listed to
the left of that configuration file.
As an example, we select the configuration file /etc/pear.conf:
Code Listing 2.3: Updating a specific configuration file
Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again
You can now see the differences between the two files. If you believe that the
updated configuration file can be used without problems, enter 1. If you
believe that the updated configuration file isn't necessary, or doesn't provide
any new or useful information, enter 2. If you want to interactively
update your current configuration file, enter 3.
There is no point in further elaborating the interactive merging here. For
completeness sake, we will list the possible commands you can use while you are
interactively merging the two files. You are greeted with two lines (the
original one, and the proposed new one) and a prompt at which you can enter one
of the following commands:
Code Listing 2.4: Commands available for the interactive merging
ed: Edit then use both versions, each decorated with a header.
eb: Edit then use both versions.
el: Edit then use the left version.
er: Edit then use the right version.
e: Edit a new version.
l: Use the left version.
r: Use the right version.
s: Silently include common lines.
v: Verbosely include common lines.
q: Quit.
When you have finished updating the important configuration files, you can now
automatically update all the other configuration files. etc-update will
exit if it doesn't find any more updateable configuration files.
4.c. quickpkg
With quickpkg you can create archives of the packages that are already
merged on your system. These archives can be used as prebuilt packages. Running
quickpkg is straightforward: just add the names of the packages you want
to archive.
For instance, to archive curl, orage, and procps:
Code Listing 3.1: Example quickpkg usage
# quickpkg curl orage procps
The prebuilt packages will be stored in $PKGDIR
(/usr/portage/packages/ by default). These packages are placed in
5.a. Using a Portage Tree Subset
Excluding Packages/Categories
You can selectively update certain categories/packages and ignore the other
categories/packages. We achieve this by having rsync exclude
categories/packages during the emerge --sync step.
You need to define the name of the file that contains the exclude patterns in
the PORTAGE_RSYNC_EXTRA_OPTS variable in your /etc/portage/make.conf.
Code Listing 1.1: Defining the exclude file in /etc/portage/make.conf
Code Listing 1.2: Excluding all games in /etc/portage/rsync_excludes
Note however that this may lead to dependency issues since new, allowed packages
might depend on new but excluded packages.
5.b. Adding Unofficial Ebuilds
Defining a Portage Overlay Directory
You can ask Portage to use ebuilds that are not officially available through the
Portage tree. Create a new directory (for instance
/usr/local/portage) in which you store the 3rd-party ebuilds. Use
the same directory structure as the official Portage tree!
Then define PORTDIR_OVERLAY in /etc/portage/make.conf and have it
point to the previously defined directory. When you use Portage now, it will
take those ebuilds into account as well without removing/overwriting those
ebuilds the next time you run emerge --sync.
Working with Several Overlays
For the powerusers who develop on several overlays, test packages before they
hit the Portage tree or just want to use unofficial ebuilds from various
sources, the app-portage/layman package brings you
layman, a tool to help you keep the overlay repositories up to date.
First install and configure layman as shown in the Overlays Users' Guide, and add your
desired repositories with layman -a <overlay-name>.
Suppose you have two repositories called java (for the in-development
java ebuilds) and entapps (for the applications developed in-house for
your enterprise). You can update those repositories with the following
Code Listing 2.1: Using layman to update all repositories
# layman -S
For more information on working with overlays, please read man layman and
the layman/overlay users'
5.c. Non-Portage Maintained Software
Using Portage with Self-Maintained Software
In some cases you want to configure, install and maintain software yourself
without having Portage automate the process for you, even though Portage
can provide the software titles. Known cases are kernel sources and nvidia
drivers. You can configure Portage so it knows that a certain package is
manually installed on your system. This process is called injecting and
supported by Portage through the
/etc/portage/profile/package.provided file.
For instance, if you want to inform Portage about
gentoo-sources-184.108.40.206 which you've installed manually, add the
following line to /etc/portage/profile/package.provided:
Code Listing 3.1: Example line for package.provided
1.a. Getting started
This document assumes that you have correctly configured your kernel, its
modules for your hardware and you know the interface name of your hardware.
We also assume that you are configuring eth0, but it could also be
eno0, ens1, wlan0, enp1s0 etc.
To get started configuring your network card, you need to tell the Gentoo RC
system about it. This is done by creating a symbolic link from
net.lo to net.eth0 (or whatever the network interface
name is on your system) in /etc/init.d.
Code Listing 1.1: Symlinking net.eth0 to net.lo
# cd /etc/init.d
# ln -s net.lo net.eth0
Gentoo's RC system now knows about that interface. It also needs to know how
to configure the new interface. All the network interfaces are configured in
/etc/conf.d/net. Below is a sample configuration for DHCP and
static addresses.
Code Listing 1.2: Examples for /etc/conf.d/net
# For DHCP
# For static IP using CIDR notation
routes_eth0="default via 192.168.0.1"
dns_servers_eth0="192.168.0.1 22.214.171.124"
# For static IP using netmask notation
config_eth0="192.168.0.7 netmask 255.255.255.0"
routes_eth0="default via 192.168.0.1"
dns_servers_eth0="192.168.0.1 126.96.36.199"
If you do not specify a configuration for your interface then DHCP is assumed.
CIDR stands for Classless InterDomain Routing. Originally, IPv4 addresses were
classified as A, B, or C. The early classification system did not envision the
massive popularity of the Internet, and is in danger of running out of new
unique addresses. CIDR is an addressing scheme that allows one IP address to
designate many IP addresses. A CIDR IP address looks like a normal IP address
except that it ends with a slash followed by a number; for example,
192.168.0.0/16. CIDR is described in RFC 1519.
Now that we have configured our interface, we can start and stop it using the
following commands:
Code Listing 1.3: Starting and stopping network scripts
# /etc/init.d/net.eth0 start
# /etc/init.d/net.eth0 stop
When troubleshooting networking, take a look at /var/log/rc.log.
Unless you have rc_logger="NO" set in /etc/rc.conf, you
will find information on the boot activity stored in that log file.
Now that you have successfully started and stopped your network interface, you
may wish to get it to start when Gentoo boots. Here's how to do this. The last
"rc" command instructs Gentoo to start any scripts in the current runlevel
that have not yet been started.
Code Listing 1.4: Configuring a network interface to load at boot time
# rc-update add net.eth0 default
# rc
2.a. Advanced Configuration
The config_eth0 variable is the heart of an interface configuration. It's
a high level instruction list for configuring the interface (eth0 in this
case). Each command in the instruction list is performed sequentially. The
interface is deemed OK if at least one command works.
Here's a list of built-in instructions.
If a command fails, you can specify a fallback command. The fallback has to
match the config structure exactly.
You can chain these commands together. Here are some real world examples.
Code Listing 1.1: Configuration examples
# Adding three IPv4 addresses
# Adding an IPv4 address and two IPv6 addresses
# Keep our kernel assigned address, unless the interface goes
# down so assign another via DHCP. If DHCP fails then add a
# static address determined by APIPA
When using the ifconfig module and adding more than one address,
interface aliases are created for each extra address. So with the above two
examples you will get interfaces eth0, eth0:1 and eth0:2.
You cannot do anything special with these interfaces as the kernel and other
programs will just treat eth0:1 and eth0:2 as eth0.
The fallback order is important! If we did not specify the null option
then the apipa command would only be run if the noop command
APIPA and DHCP are discussed later.
2.b. Network Dependencies
Init scripts in /etc/init.d can depend on a specific network
interface or just net. All network interfaces in Gentoo's init system provide
what is called net.
If, in /etc/rc.conf, rc_depend_strict="YES" is set, then all
network interfaces that provide net must be active before a dependency on "net"
is assumed to be met. In other words, if you have a net.eth0 and
net.eth1 and an init script depends on "net", then both must be
On the other hand, if rc_depend_strict="NO" is set, then the "net"
dependency is marked as resolved the moment at least one network interface is
brought up.
But what about net.br0 depending on net.eth0 and
net.eth1? net.eth1 may be a wireless or PPP device
that needs configuration before it can be added to the bridge. This cannot be
done in /etc/init.d/net.br0 as that's a symbolic link to
The answer is defining an rc_need_ setting in
Code Listing 2.1: net.br0 dependency in /etc/conf.d/net
rc_need_br0="net.eth0 net.eth1"
That alone, however, is not sufficient. Gentoo's networking init scripts use a
virtual dependency called net to inform the system when networking is
available. Clearly, in the above case, networking should only be marked as
available when net.br0 is up, not when the others are. So we need
to tell that in /etc/conf.d/net as well:
Code Listing 2.2: Updating virtual dependencies and provisions for networking
For a more detailed discussion about dependency, consult the section Writing Init Scripts in the Gentoo
Handbook. More information about /etc/rc.conf is available as
comments within that file.
2.c. Variable names and values
Variable names are dynamic. They normally follow the structure of
variable_${interface|mac|essid|apmac}. For example, the variable
dhcpcd_eth0 holds the value for dhcpcd options for eth0 and
dhcpcd_essid holds the value for dhcpcd options when any interface
connects to the ESSID "essid".
However, there is no hard and fast rule that states interface names must be
ethx. In fact, many wireless interfaces have names like wlanx, rax as well as
ethx. Also, some user defined interfaces such as bridges can be given any name,
such as foo. To make life more interesting, wireless Access Points can have
names with non alpha-numeric characters in them - this is important because
you can configure networking parameters per ESSID.
The downside of all this is that Gentoo uses bash variables for networking -
and bash cannot use anything outside of English alpha-numerics. To get around
this limitation we change every character that is not an English alpha-numeric
into a _ character.
Another downside of bash is the content of variables - some characters need to
be escaped. This can be achived by placing the \ character in front of
the character that needs to be escaped. The following list of characters needs
to be escaped in this way: ", ' and \.
In this example we use wireless ESSID as they can contain the widest scope
of characters. We shall use the ESSID My "\ NET:
Code Listing 3.1: variable name example
(This does work, but the domain is invalid)
dns_domain_My____NET="My \"\\ NET"
(The above sets the dns domain to My "\ NET when a wireless card
connects to an AP whose ESSID is My "\ NET)
2.d. Network Interface Naming
How It Works
Network interface names are not chosen arbitrarily: the Linux kernel and the
device manager (most systems have udev as their device manager although others
are available as well) choose the interface name through a fixed set of rules.
When an interface card is detected on a system, the Linux kernel gathers the
necessary data about this card. This includes:
Based on this information, the device manager decides how to name the interface
on the system. By default, it uses the first hit of the first three parameters
above (ID_NET_NAME_ONBOARD, _SLOT or _PATH).
For instance, if ID_NET_NAME_ONBOARD is found and set to eno1, then
the interface will be called eno1.
If you know your interface name, you can see the values of the provided
parameters using udevadm:
Code Listing 4.1: Reading the network interface card information
# udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/null
ID_OUI_FROM_DATABASE=Quanta Computer Inc.
As the first (and actually only) hit of the top three parameters is the
ID_NET_NAME_PATH one, its value is used as the interface name. If none of
the parameters is found, then the system reverts back to the kernel-provided
naming (eth0, eth1, etc.)
Using the Old-style Kernel Naming
Before this change, network interface cards were named by the Linux kernel
itself, depending on the order that drivers are loaded (amongst other, possibly
more obscure reasons). This behavior can still be enabled by setting the
net.ifnames=0 boot option in the boot loader.
Using your Own Names
The entire idea behind the change in naming is not to confuse people, but to
make changing the names easier. Suppose you have two interfaces that are
otherwise called eth0 and eth1. One is meant to access the network through a
wire, the other one is for wireless access. With the support for interface
naming, you can have these called lan0 (wired) and wifi0 (wireless - it is best
to avoid using the previously well-known names like eth* and wlan* as those can
still collide with your suggested names).
All you need to do is to find out what the parameters are for the cards and then
use this information to set up your own naming rule:
Code Listing 4.2: Setting the lan0 name for the current eth0 interface
# udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
ID_OUI_FROM_DATABASE=Quanta Computer Inc.
# vim /etc/udev/rules.d/70-net-name-use-custom.rules
# First one uses MAC information, and 70- number to be before other net rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c8:0a:a9:42:9d:76", NAME="lan0"
# vim /etc/udev/rules.d/76-net-name-use-custom.rules
# Second one uses ID_NET_NAME_PATH information, and 76- number to be between
# 75-net-*.rules and 80-net-*.rules
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="wifi0"
Because the rules are triggered before the default one (rules are triggered in
alphanumerical order, so 70 comes before 80) the names provided in the rule file
will be used instead of the default ones. The number granted to the file should
be between 76 and 79 (the environment variables are defined by a rule start
starts with 75 and the fallback naming is done in a rule numbered 80).
3.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.
All settings discussed here are stored in /etc/conf.d/net unless
otherwise specified.
Code Listing 1.1: Module preference
# Prefer ifconfig over iproute2
# You can also specify other modules for an interface
# In this case we prefer pump over dhcpcd
# You can also specify which modules not to use - for example you may be
# using a supplicant or linux-wlan-ng to control wireless configuration but
# you still want to configure network settings per ESSID associated with.
3.b. Interface Handlers
We provide two interface handlers presently: ifconfig and
iproute2. You need one of these to do any kind of network configuration.
ifconfig is installed by default (the net-tools package is part of
the system profile). iproute2 is a more powerful and flexible package,
but it's not included by default.
Code Listing 2.1: To install iproute2
# emerge sys-apps/iproute2
# To prefer ifconfig over iproute2 if both are installed as openrc prefers
# to use iproute2 then
As both ifconfig and iproute2 do very similar things we allow
their basic configuration to work with each other. For example both the below
code snippet work regardless of which module you are using.
Code Listing 2.2: ifconfig and iproute2 examples
config_eth0="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 can be provided by dhclient, dhcpcd, or pump. 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
Code Listing 3.1: Sample DHCP configuration in /etc/conf.d/net
# Only needed if you have more than one DHCP module installed
dhcpcd_eth0="-t 10" # Timeout after 10 seconds
dhcp_eth0="release nodns nontp nonis" # Only get an address
dhcpcd and pump send the current hostname to the
DHCP server by default so you don't need to specify this anymore.
3.d. ADSL with PPPoE/PPPoA
First we need to install the ADSL software.
Code Listing 4.1: Install the ppp package
# emerge net-dialup/ppp
Second, create the PPP net script and the net script for the ethernet interface
to be used by PPP:
Code Listing 4.2: Creating the PPP and ethernet scripts
# ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0
# ln -s /etc/init.d/net.lo /etc/init.d/net.eth0
Be sure to set rc_depend_strict to "YES" in /etc/rc.conf.
Now we need to configure /etc/conf.d/net.
Code Listing 4.3: A basic PPPoE setup
config_eth0=null (Specify your ethernet interface)
link_ppp0="eth0" (Specify your ethernet interface)
holdoff 3
child-timeout 60
lcp-echo-interval 15
lcp-echo-failure 3
noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp"
You can also set your password in /etc/ppp/pap-secrets.
Code Listing 4.4: Sample /etc/ppp/pap-secrets
# The * is important
"username" * "password"
If you use PPPoE with a USB modem you'll need to emerge br2684ctl. Please
read /usr/portage/net-dialup/speedtouch-usb/files/README for
information on how to properly configure it.
Please carefully read the section on ADSL and PPP in
/usr/share/doc/netifrc-*/net.example.bz2. It contains many
more detailed explanations of all the settings your particular PPP setup will
likely need.
3.e. APIPA (Automatic Private IP Addressing)
APIPA tries to find a free address in the range 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.
Code Listing 5.1: APIPA configuration in /etc/conf.d/net
# Try DHCP first - if that fails then fallback to APIPA
# Just use APIPA
3.f. Bonding
For link bonding/trunking emerge net-misc/ifenslave.
Bonding is used to increase network bandwidth or to improve resiliency in face
of hardware failures. 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.
There are many ways to configure bonding. Some of them, such as the 802.3ad LACP
mode, require support and additional configuration of the network switch. For a
reference of the individual options, please refer to your copy of
First, clear the configuration of the participating interfaces:
Code Listing 6.1: Clearing interface configuration in /etc/conf.d/net
Next, define the bonding between the interfaces:
Code Listing 6.2: Define the bonding
slaves_bond0="eth0 eth1 eth2"
# Pick a correct mode and additional configuration options which suit your needs
Remove the net.eth* services from the runlevels, create a
net.bond0 one and add that one to the correct runlevel.
3.g. Bridging (802.1d support)
For bridging support emerge net-misc/bridge-utils.
Bridging is used to join networks together. For example, you may have a server
that connects to the internet via an ADSL modem and a wireless access card to
enable other computers to connect to the internet via the ADSL modem. You could
create a bridge to join the two interfaces together.
Code Listing 7.1: Bridge configuration in /etc/conf.d/net
# Configure the bridge - "man brctl" for more details
brctl_br0="setfd 0
sethello 2
stp on"
# To add ports to bridge br0
bridge_br0="eth0 eth1"
# You need to configure the ports to null values so dhcp does not get started
# Finally give the bridge an address - you could use DHCP as well
# Depend on eth0 and eth1 as they may require extra configuration
rc_need_br0="net.eth0 net.eth1"
For using some bridge setups, you may need to consult the variable name documentation.
3.h. MAC Address
If you need to, you can change the MAC address of your interfaces through
the network configuration file too.
Code Listing 8.1: MAC Address change example
# To set the MAC address of the interface
# To randomize the last 3 bytes only
# To randomize between the same physical type of connection (e.g. fibre,
# copper, wireless) , all vendors
# To randomize between any physical type of connection (e.g. fibre, copper,
# wireless) , all vendors
# Full randomization - WARNING: some MAC addresses generated by this may
# NOT act as expected
3.i. Tunnelling
You don't need to emerge anything for tunnelling as the interface handler can do
it for you.
Code Listing 9.1: Tunnelling configuration in /etc/conf.d/net
# For GRE tunnels
iptunnel_vpn0="mode gre remote 22.214.171.124 key 0xffffffff ttl 255"
# For IPIP tunnels
iptunnel_vpn0="mode ipip remote 184.108.40.206 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, make sure that sys-apps/iproute2 is installed and ensure
that iproute2 is used as configuration module rather than ifconfig.
Virtual LAN is a group of network devices that behave as if they were connected
to a single network segment - even though they may not be. VLAN members can only
see members of the same VLAN even though they may share the same physical
To configure VLANs, first specify the VLAN numbers in
/etc/conf.d/net like so:
Code Listing 10.1: Specifying VLAN numbers
vlans_eth0="1 2"
Next, configure the interface for each VLAN:
Code Listing 10.2: Interface configuration for each VLAN
config_eth0_1="172.16.3.1 netmask 255.255.254.0"
routes_eth0_1="default via 172.16.3.254"
config_eth0_2="172.16.2.1 netmask 255.255.254.0"
routes_eth0_2="default via 172.16.2.254"
VLAN-specific configurations are handled by vconfig like so:
Code Listing 10.3: Configuring the VLANs
vlan1_ingress="2:6 3:5"
For using some VLAN setups, you may need to consult the variable name documentation.
4.a. Introduction
Wireless networking on Linux is usually pretty straightforward. There are two
ways of configuring wifi: graphical clients, or the command line.
The easiest way is to use a graphical client once you've installed a
desktop environment. Most graphical clients,
such as wicd and NetworkManager, are
pretty self-explanatory. They offer a handy point-and-click interface that gets
you on a network in just a few seconds.
wicd offers a command line utility in addition to the main
graphical interface. You can get it by emerging wicd with the
ncurses USE flag set. This wicd-curses utility is particularly
useful for folks who don't use a gtk-based desktop environment, but still want
an easy command line tool that doesn't require hand-editing configuration
However, if you don't want to use a graphical client, then you can configure
wifi on the command line by editing a few configuration files. This takes a bit
more time to setup, but it also requires the fewest packages to download and
install. Since the graphical clients are mostly self-explanatory (with helpful
screenshots at their homepages), we'll focus on the command line alternatives.
You can setup wireless networking on the command line by installing
wireless-tools or wpa_supplicant. The important thing to remember
is that you configure wireless networks on a global basis and not an interface
wpa_supplicant is the best choice. For a list of supported drivers, read the wpa_supplicant
wireless-tools supports nearly all cards and drivers, but it cannot
connect to WPA-only Access Points. If your networks only offer WEP encryption or
are completely open, you may prefer the simplicity of wireless-tools.
The linux-wlan-ng driver is not supported by baselayout at this time.
This is because linux-wlan-ng have its own setup and configuration which
is completely different to everyone else's. The linux-wlan-ng developers
are rumoured to be changing their setup over to wireless-tools, so when
this happens you may use linux-wlan-ng with baselayout.
Some wireless cards are deactivated by default. To activate them, please consult
your hardware documentation. Some of these cards can be unblocked using the
rfkill application. If that is the case, use "rfkill list" to see the available
cards and "rfkill unblock <index>" to activate the wireless functionality.
If not, you might need to unblock the wireless card through a button, switch
or special key combination on your laptop.
4.b. WPA Supplicant
WPA Supplicant is a
package that allows you to connect to WPA enabled access points.
Code Listing 2.1: Install wpa_supplicant
# emerge net-wireless/wpa_supplicant
You have to have CONFIG_PACKET enabled in your kernel for
wpa_supplicant to work. Try running grep CONFIG_PACKET
/usr/src/linux/.config to see if you have it enabled in your kernel.
Depending on your USE flags, wpa_supplicant can install a graphical
interface written in Qt4, which will integrate nicely with KDE. To get it, run
echo "net-wireless/wpa_supplicant qt4" >> /etc/portage/package.use as
root before emerging wpa_supplicant.
Now we have to configure /etc/conf.d/net to so that we prefer
wpa_supplicant over wireless-tools (if both are installed,
wireless-tools is the default).
Code Listing 2.2: configure /etc/conf.d/net for wpa_supplicant
# Prefer wpa_supplicant over wireless-tools
# It's important that we tell wpa_supplicant which driver we should
# be using as it's not very good at guessing yet
If you're using the host-ap driver you will need to put the card in Managed
mode before it can be used with wpa_supplicant correctly. You can use
iwconfig_eth0="mode managed" to achieve this in
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
which ships with wpa_supplicant.
Code Listing 2.3: An example /etc/wpa_supplicant/wpa_supplicant.conf
# The below line not be changed otherwise we refuse to work
# Ensure that only root can read the WPA configuration
# Let wpa_supplicant take care of scanning and AP selection
# Simple case: WPA-PSK, PSK as an ASCII passphrase, allow all valid ciphers
psk="very secret passphrase"
# The higher the priority the sooner we are matched
# Same as previous, but request SSID-specific scanning (for APs that reject
# broadcast SSID)
ssid="second ssid"
psk="very secret passphrase"
# Only WPA-PSK is used. Any valid cipher combination is accepted
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40
# Plaintext connection (no WPA, no IEEE 802.1X)
# Shared WEP key connection (no WPA, no IEEE 802.1X)
# Keys in quotes are ASCII keys
# Keys specified without quotes are hex keys
# Shared WEP key connection (no WPA, no IEEE 802.1X) using Shared Key
# IEEE 802.11 authentication
# IBSS/ad-hoc network with WPA-None/TKIP
ssid="test adhoc"
psk="secret passphrase"
4.c. Wireless Tools
Initial setup and Managed Mode
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
Wireless Tools configuration is controlled by a few main variables. The sample
configuration file below should describe all you need. One thing to bear in mind
is that no configuration means "connect to the strongest unencrypted Access
Point" - we will always try and connect you to something.
Code Listing 3.1: Install wireless-tools
# emerge net-wireless/wireless-tools
Although you can store your wireless settings in
/etc/conf.d/wireless this guide recommends you store them in
You will need to consult the variable name documentation.
Code Listing 3.2: sample iwconfig setup in /etc/conf.d/net
# Prefer iwconfig over wpa_supplicant
# Configure WEP keys for Access Points called ESSID1 and ESSID2
# You may configure up to 4 WEP keys, but only 1 can be active at
# any time so we supply a default index of [1] to set key [1] and then
# again afterwards to change the active key to [1]
# We do this incase you define other ESSID's to use WEP keys other than 1
# Prefixing the key with s: means it's an ASCII key, otherwise a HEX key
# enc open specified open security (most secure)
# enc restricted specified restricted security (least secure)
key_ESSID1="[1] s:yourkeyhere key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"
# The below only work when we scan for available Access Points
# Sometimes more than one Access Point is visible so we need to
# define a preferred order to connect in
preferred_aps="'ESSID1' 'ESSID2'"
Fine tune Access Point Selection
You can add some extra options to fine-tune your Access Point selection, but
these are not normally required.
You can decide whether we only connect to preferred Access Points or not. By
default if everything configured has failed and we can connect to an unencrypted
Access Point then we will. This can be controlled by the associate_order
variable. Here's a table of values and how they control this.
Finally we have some blacklist_aps and unique_ap selection.
blacklist_aps works in a similar way to preferred_aps.
unique_ap is a yes or no value that says if a second
wireless interface can connect to the same Access Point as the first interface.
Code Listing 3.3: blacklist_aps and unique_ap example
# Sometimes you never want to connect to certain access points
blacklist_aps="'ESSID3' 'ESSID4'"
# If you have more than one wireless card, you can say if you want
# to allow each card to associate with the same Access Point or not
# Values are "yes" and "no"
# Default is "yes"
Ad-Hoc and Master Modes
If you want to set yourself up as an Ad-Hoc node if you fail to connect to any
Access Point in managed mode, you can do that too.
Code Listing 3.4: fallback to ad-hoc mode
adhoc_essid_eth0="This Adhoc Node"
What about connecting to Ad-Hoc networks or running in Master mode to become an
Access Point? Here's a configuration just for that! You may need to specify WEP
keys as shown above.
Code Listing 3.5: sample ad-hoc/master configuration
# Set the mode - can be managed (default), ad-hoc or master
# Not all drivers support all modes
# Set the ESSID of the interface
# In managed mode, this forces the interface to try and connect to the
# specified ESSID and nothing else
essid_eth0="This Adhoc Node"
# We use channel 3 if you don't specify one
The below is taken verbatim from the BSD wavelan documentation found at the NetBSD
documentation. There are 14 channels possible; We are told that channels
1-11 are legal for North America, channels 1-13 for most of Europe, channels
10-13 for France, and only channel 14 for Japan. If in doubt, please refer to
the documentation that came with your card or access point. Make sure that the
channel you select is the same channel your access point (or the other card in
an ad-hoc network) is on. The default for cards sold in North America and most
of Europe is 3; the default for cards sold in France is 11, and the default for
cards sold in Japan is 14.
Troubleshooting Wireless Tools
There are some more variables you can use to help get your wireless up and
running due to driver or environment problems. Here's a table of other things
you can try.
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.
These work if you're using WPA Supplicant or Wireless Tools.
Code Listing 4.1: override network settings per ESSID
config_ESSID1="192.168.0.3/24 brd 192.168.0.255"
routes_ESSID1="default via 192.168.0.1"
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 to
dns_servers_ESSID1="192.168.0.1 192.168.0.2"
dns_search_domains_ESSID1="search.this.domain search.that.domain"
# You override by the MAC address of the Access Point
# This handy if you goto different locations that have the same ESSID
dhcpcd_001122334455="-t 10"
dns_servers_001122334455="192.168.0.1 192.168.0.2"
5.a. Standard function hooks
Four functions can be defined in /etc/conf.d/net which will be
called surrounding the start/stop operations. The functions are
called with the interface name first so that one function can control multiple
The return values for the preup() and predown() functions should
be 0 (success) to indicate that configuration or deconfiguration of the
interface can continue. If preup() returns a non-zero value, then
interface configuration will be aborted. If predown() returns a non-zero
value, then the interface will not be allowed to continue deconfiguration.
The return values for the postup() and postdown() functions are
ignored since there's nothing to do if they indicate failure.
${IFACE} is set to the interface being brought up/down. ${IFVAR}
is ${IFACE} converted to variable name bash allows.
Code Listing 1.1: pre/post up/down function examples in /etc/conf.d/net
preup() {
# Test for link on the interface prior to bringing it up. This
# only works on some network adapters and requires the ethtool
# package to be installed.
if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "No link on ${IFACE}, aborting configuration"
return 1
# Remember to return 0 on success
return 0
predown() {
# The default in the script is to test for NFS root and disallow
# downing interfaces in that case. Note that if you specify a
# predown() function you will override that logic. Here it is, in
# case you still want it...
if is_net_fs /; then
eerror "root filesystem is network mounted -- can't stop ${IFACE}"
return 1
# Remember to return 0 on success
return 0
postup() {
# This function could be used, for example, to register with a
# dynamic DNS service. Another possibility would be to
# send/receive mail once the interface is brought up.
return 0
postdown() {
# This function is mostly here for completeness... I haven't
# thought of anything nifty to do with it yet ;-)
return 0
For more information on writing your own functions, please read
5.b. Wireless Tools function hooks
This will not work with WPA Supplicant - but the ${ESSID} and
${ESSIDVAR} variables are available in the postup() function.
Two functions can be defined in /etc/conf.d/net which will be
called surrounding the associate function. The functions are called with the
interface name first so that one function can control multiple adapters.
The return values for the preassociate() function should be 0 (success)
to indicate that configuration or deconfiguration of the interface can continue.
If preassociate() returns a non-zero value, then interface configuration
will be aborted.
The return value for the postassociate() function is ignored since
there's nothing to do if it indicates failure.
${ESSID} is set to the exact ESSID of the AP you're connecting to.
${ESSIDVAR} is ${ESSID} converted to a variable name bash allows.
Code Listing 2.1: pre/post association functions in /etc/conf.d/net
preassociate() {
# The below adds two configuration variables leap_user_ESSID
# and leap_pass_ESSID. When they are both configured for the ESSID
# being connected to then we run the CISCO LEAP script
local user pass
eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"
if [[ -n ${user} && -n ${pass} ]]; then
if [[ ! -x /opt/cisco/bin/leapscript ]]; then
eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
return 1
einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
ewarn "Login Failed for ${user}"
return 1
return 0
postassociate() {
# This function is mostly here for completeness... I haven't
# thought of anything nifty to do with it yet ;-)
return 0
${ESSID} and ${ESSIDVAR} are unavailable in predown() and
postdown() functions.
6.a. Network Management
If you and your computer are always on the move, you may not always have an
ethernet cable or plugged in or an access point available. Also, you may want
networking to automatically work when an ethernet cable is plugged in or an
access point is found.
Here you can find some tools that help you manage this.
This document only talks about ifplugd, but there are alternatives such
as netplug. netplug is a lightweight alternative to
ifplugd, but it relies on your kernel network drivers working correctly,
and many drivers do not.
6.b. ifplugd
ifplugd is a
daemon that starts and stops interfaces when an ethernet cable is inserted or
removed. It can also manage detecting association to Access Points or when new
ones come in range.
Code Listing 2.1: Installing ifplugd
# emerge sys-apps/ifplugd
Configuration for ifplugd is fairly straightforward too. The configuration file
is held in /etc/conf.d/net. Run man ifplugd for details on
the available variables. Also, see
/usr/share/doc/netifrc-*/net.example.bz2 for more examples.
Code Listing 2.2: Sample ifplug configuration
(Replace eth0 with the interface to be monitored)
(To monitor a wireless interface)
In addition to managing multiple network connections, you may want to add a tool
that makes it easy to work with multiple DNS servers and configurations. This is
very handy when you receive your IP address via DHCP. Simply emerge
Code Listing 2.3: Installing openresolv
# emerge openresolv
See man resolvconf to learn more about its features.
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.
Page updated September 25, 2014
This is the Gentoo Networkless Handbook, an effort to centralise Gentoo/Linux
information. This handbook contains the installation instructions for a
networkless installation on AMD64 & EM64T systems and parts about working
with Gentoo and Portage.
Sven Vermeulen
Grant Goodyear
Roy Marples
Daniel Robbins
Chris Houser
Jerry Alexandratos
Joshua Saddler
Seemant Kulleen
Gentoo x86 Developer
Tavis Ormandy
Gentoo Alpha Developer
Jason Huebel
Gentoo AMD64 Developer
Guy Martin
Gentoo HPPA developer
Pieter Van den Abeele
Gentoo PPC developer
Joe Kallar
Gentoo SPARC developer
John P. Davis
EditorPierre-Henri JondotEditor
Eric Stockbridge
Rajiv Manglani
Jungmin Seo
Stoyan Zhekov
Jared Hudson
Colin Morey
Jorge Paulo
Carl Anderson
Jon Portnoy
Zack Gilburd
Jack Morgan
Benny Chuang
Joshua Kinard
Tobias Scherbaum
Xavier Neys
Shyam Mani
Gerald J. Normandin Jr.
Donnie Berkholz
Ken Nowack
Lars Weiler
Donate to support our development efforts.