Gentoo Linux mips Handbook: Installing Gentoo

Introduction

Welcome

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

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

It is very important that everyone understands that choices are what makes Gentoo run. We try not to force users into anything they do not like. If anyone believes otherwise, please bug report it.

How the installation is structured

The Gentoo Installation can be seen as a 10-step procedure, corresponding to the next set of chapters. Each step results in a certain state:

Step	Result
1	The user is in a working environment ready to install Gentoo.
2	The Internet connection is ready to install Gentoo.
3	The hard disks are initialized to host the Gentoo installation.
4	The installation environment is prepared and the user is ready to chroot into the new environment.
5	Core packages, which are the same on all Gentoo installations, are installed.
6	The Linux kernel is installed.
7	The user will have configured most of the Gentoo system configuration files.
8	The necessary system tools are installed.
9	The proper boot loader has been installed and configured.
10	The freshly installed Gentoo Linux environment is ready to be explored.

Whenever a certain choice is presented the handbook will try to explain the pros and cons of each choice. Although the text then continues with a default choice (identified by "Default: " in the title), the other possibilities will be documented as well (marked by "Alternative: " in the title). Do not think that the default is what Gentoo recommends. It is however what Gentoo believes most users will use.

Sometimes an optional step can be followed. Such steps are marked as "Optional: " and are therefore not needed to install Gentoo. However, some optional steps are dependent on a previously made decision. The instructions will inform the reader when this happens, both when the decision is made, and right before the optional step is described.

Installation options for Gentoo

Gentoo can be installed in many different ways. It can be downloaded and installed from official Gentoo installation media such as our CDs and DVDs. The installation media can be installed on a USB stick or accessed via a netbooted environment. Alternatively, Gentoo can be installed from non-official media such as an already installed distribution or a non-Gentoo bootable disk (such as Knoppix).

This document covers the installation using official Gentoo Installation media or, in certain cases, netbooting.

Note
For help on the other installation approaches, including using non-Gentoo CDs, please read our Alternative installation guide.

We also provide a Gentoo installation tips and tricks document that might be useful to read as well.

Troubles

If a problem is found in the installation (or in the installation documentation), please 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 the bugs - they (generally) don't eat people.

Note though that, although this document is architecture-specific, it might contain references to other architectures as well. This is due to the fact that large parts of the Gentoo Handbook use installation source text that is shared 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 there is some uncertainty whether or not the problem is a user-problem (some error made despite having read the documentation carefully) or a software-problem (some error we made despite having tested the installation/documentation carefully) everybody is welcome to join the #gentoo channel on irc.freenode.net. Of course, everyone is welcome otherwise too as our chat channel covers the broad Gentoo spectrum.

Speaking of which, if there are any additional questions regarding Gentoo, check out the Frequently Asked Questions article. There are also FAQs on the Gentoo Forums.

Hardware requirements

CPU (Big Endian port)	MIPS3, MIPS4, MIPS5 or MIPS64-class CPU
CPU (Little Endian port)	MIPS4, MIPS5 or MIPS64-class CPU
Memory	128 MB
Disk space	3.0 GB (excluding swap space)
Swap space	At least 256 MB

For more information, read MIPS Hardware Requirements.

Installation notes

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

MIPS ISA	32/64-bit	CPUs Covered
MIPS 1	32-bit	R2000, R3000
MIPS 2	32-bit	R6000
MIPS 3	64-bit	R4000, R4400, R4600, R4700
MIPS 4	64-bit	R5000, RM5000, RM7000 R8000, R9000, R10000, R12000, R14000, R16000
MIPS 5	4-bit	None As Yet
MIPS32	32-bit	AMD Alchemy series, 4kc, 4km, many others... There are a few revisions in the MIPS32 ISA.
MIPS64	64-bit	Broadcom SiByte SB1, 5kc ... etc... There are a few revisions in the MIPS64 ISA.

Note
The MIPS5 ISA level was designed by Silicon Graphics back in 1994, but never actually got used in a real life CPU. It lives on as part of the MIPS64 ISA.

Note
The MIPS32 and MIPS64 ISAs are a common source of confusion. The MIPS64 ISA level is actually a superset of the MIPS5 ISA, so it includes all instructions from MIPS5 and earlier ISAs. MIPS32 is the 32-bit subset of MIPS64, it exists because most applications only require 32-bit processing.

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

Architecture	32/64-bit	Endianness	Machines covered
mips	32-bit	Big Endian	Silicon Graphics
mipsel	32-bit	Little Endian	Cobalt Servers
mips64	64-bit	Big Endian	Silicon Graphics
mips64el	64-bit	Little Endian	Cobalt Servers

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

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

Netbooting overview

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

Depending on the machine, there is a certain amount of hardware that is needed in order to successfully netboot and install Linux.

• In General:
  • DHCP/BOAMD Alchemy series, 4kc, 4km, many others... There are a few revisions in the MIPS32 ISA.OTP server (ISC DHCPd recommended)
  • Patience -- and lots of it
• For Silicon Graphics workstations:
  • TFTP server (tftp-hpa recommended)
  • When the serial console needs to be used:
    • MiniDIN8 --> RS-232 serial cable (only needed for IP22 and IP28 systems)
    • Null-modem cable
    • VT100 or ANSI compatible terminal capable of 9600 baud
• For Cobalt Servers (NOT the original Qube):
  • NFS server
  • Null-modem cable
  • VT100 or ANSI compatible terminal capable of 115200 baud

Note
SGI machines use a MiniDIN 8 connector for the serial ports. Apparently Apple modem cables work just fine as serial cables, but with Apple machines being equipped with USB & internal modems, these are getting harder to find. One wiring diagram is available from the Linux/MIPS Wiki, and most electronics stores should stock the plugs required.

Note
For the terminal, this could be a real VT100/ANSI terminal, or it could be a PC running terminal emulation software (such as HyperTerminal, Minicom, seyon, Telex, xc, screen - whatever your preference). It doesn't matter what platform this machine runs - just so long as it has one RS-232 serial port available, and appropriate software.

Note
This guide does NOT cover the original Qube. The original Qube server appliance lacks a serial port in its default configuration, and therefore it is not possible to install Gentoo onto it without the aid of a screwdriver and a surrogate machine to do the installation.

Setting up TFTP and DHCP

As mentioned earlier -- this is not a complete guide, this is a bare-bones config that will just get things rolling. Either use this when starting a setup from scratch, or use the suggestions to amend an existing setup to support netbooting.

It is worth noting that the servers used need not be running Gentoo Linux, they could very well be using FreeBSD or any Unix-like platform. However, this guide will assume to be using Gentoo Linux. If desired, it is also possible to run TFTP/NFS on a separate machine to the DHCP server.

Warning
The Gentoo/MIPS Team cannot help with setting up other operating systems as netboot servers.

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

root #emerge --ask net-misc/dhcp

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

FILE /etc/dhcp/dhcpd.confBare Bones dhcpd.conf

# Tell dhcpd to disable dynamic DNS.
# dhcpd will refuse to start without this.
ddns-update-style none;
  
# Create a subnet:
subnet 192.168.10.0 netmask 255.255.255.0 {
  # Address pool for our booting clients. Don't forget the 'dynamic-bootp' bit!
  pool {
    range dynamic-bootp 192.168.10.1 192.168.10.254;
  }
  
  # DNS servers and default gateway -- substitute as appropriate
  option domain-name-servers 203.1.72.96, 202.47.56.17;
  option routers 192.168.10.1;
  
  # Tell the DHCP server it's authoritative for this subnet.
  authoritative;
  
  # Allow BOOTP to be used on this subnet.
  allow bootp;
}

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

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

root #emerge --ask net-ftp/tftp-hpa

This will create /tftproot to store the netboot images. Move this elsewhere if necessary. For the purposes of this guide, it is assumed that it is kept in the default location.

Netbooting on SGI stations

Downloading a netboot image

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

Codename	Machines
IP22	Indy, *Indigo 2, Challenge S
IP26	*Indigo 2 Power
IP27	Origin 200, Origin 2000
IP28	*Indigo 2 Impact
IP30	Octane
IP32	O2

Note
Indigo 2 - It is a common mistake to mix up the IRIS Indigo (IP12 w/ R3000 CPU or IP20 with a R4000 CPU, neither of which run Linux), the Indigo 2 (IP22, which runs Linux fine), the R8000-based Indigo 2 Power (which doesn't run Linux at all) and the R10000-based Indigo 2 Impact (IP28, which is highly experimental). Please bear in mind that these are different machines.

Also in the filename, r4k refers to R4000-series processors, r5k for R5000, rm5k for the RM5200 and r10k for R10000. The images are available on the Gentoo mirrors.

DHCP configuration for an SGI client

After downloading the file, place the decompressed image file in the /tftproot/ directory. (Use bzip2 -d to decompress). Then edit the /etc/dhcp/dhcpd.conf file and add the appropriate entry for the SGI client.

FILE /etc/dhcp/dhcpd.confsnippet for SGI Workstation

subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
  # ... usual stuff here ...
  
  # SGI Workstation... change 'sgi' to your SGI machine's hostname.
  host sgi {
  
    # MAC Address of SGI Machine. Normally this is written on the back
    # or base of the machine.
    hardware ethernet 08:00:69:08:db:77;
  
    # TFTP Server to download from (by default, same as DHCP server)
    next-server 192.168.10.1;
  
    # IP address to give to the SGI machine
    fixed-address 192.168.10.3;
  
    # Filename for the PROM to download and boot
    filename "/gentoo-r4k.img";
  }
}

Kernel options

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

Disable "Path Maximum Transfer Unit", otherwise SGI PROM won't find the kernel:

root #echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

Set the port range usable by the SGI PROM:

root #echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range

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

Starting the daemons

At this point, start the daemons.

root #/etc/init.d/dhcp start

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

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

An easy way to verify if the tftp daemon is running is to type the following command and confirm the output:

root #netstat -al | grep ^udp

udp        0      0 *:bootpc                *:*
udp        0      0 *:631                   *:*
udp        0      0 *:xdmcp                 *:*
udp        0      0 *:tftp                  *:* <-- (look for this line)

Netbooting the SGI station

Okay, everything is set, DHCP is running as is TFTP. Now it is time to fire up the SGI machine. Power the unit on - when "Running power-on diagnostics" comes on the screen, either click "Stop For Maintenance" or press Escape. A menu similar to the following will show up.

Running power-on diagnostics

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

Type in 5 to enter the command monitor. On the monitor, start the BootP process:

>>bootp(): root=/dev/ram0

From this point, the machine should start downloading the image, then, roughly 20 seconds later, start booting Linux. If all is well, a busybox ash shell will be started as shown below and the installation of Gentoo Linux can continue.

CODE When things are going right...

init started:  BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary
  
Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL
  
 Gentoo/MIPS Netboot for Silicon Graphics Machines
 Build Date: April 26th, 2004
  
 * To configure networking, do the following:
  
 * For Static IP:
 * /bin/net-setup <IP Address> <Gateway Address> [telnet]
  
 * For Dynamic IP:
 * /bin/net-setup dhcp [telnet]
  
 * If you would like a telnetd daemon loaded as well, pass "telnet"
 * As the final argument to /bin/net-setup.
  
Please press Enter to activate this console.

Troubleshooting

If the machine is being stubborn and refusing to download its image, it can be one of two things:

1. The instructions were not followed correctly, or
2. It needs a little gentle persuasion (No, put that sledge hammer down!)

Here's a list of things to check:

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

If everything on the server is checked, and timeouts or other errors occur on the SGI machine, try typing this into the console.

>>resetenv

>>unsetenv netaddr

>>unsetenv dlserver

>>init

>>bootp(): root=/dev/ram0

Netbooting on Cobalt stations

Overview of the netboot procedure

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

Downloading a Cobalt netboot image

Inside http://distfiles.gentoo.org/experimental/mips/historical/netboot/cobalt/ the necessary boot images for getting a Cobalt up and running are made available. The files will have the name nfsroot-KERNEL-COLO-DATE-cobalt.tar - select the most recent one and unpack it to / as shown below:

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

NFS server configuration

Since this machine uses NFS to download its image, it is necessary to export /nfsroot/ on the server. Install the net-fs/nfs-utils package:

root #emerge --ask net-fs/nfs-utils

Once that is done, place the following in the /etc/exports file.

FILE /etc/exportsExporting the /nfsroot directory

/nfsroot      *(ro,sync)

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

root #/etc/init.d/nfs start

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

root #exportfs -av

DHCP configuration for a Cobalt machine

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

FILE /etc/dhcp/dhcpd.confSnippet for Cobalt server

subnet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx {
  # ... usual stuff here ...
  
  # Configuration for a Cobalt Server
  # Set the hostname here:
  host qube {
    # Path to the nfsroot directory.
    # This is mainly for when using the TFTP boot option on CoLo
    # You shouldn't need to change this.
    option root-path "/nfsroot";
  
    # Cobalt server's ethernet MAC address
    hardware ethernet 00:10:e0:00:86:3d;
  
    # Server to download image from
    next-server 192.168.10.1;
  
    # IP address of Cobalt server
    fixed-address 192.168.10.2;
  
    # Location of the default.colo file relative to /nfsroot
    # You shouldn't need to change this.
    filename "default.colo";
  }
}

Starting daemons

Now start the daemons. Enter the following:

root #/etc/init.d/dhcp start

root #/etc/init.d/nfs start

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

Netbooting the Cobalt machine

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

The back panel should display "Net Booting", and some network activity should be visible, closely followed by CoLo kicking in. On the rear panel, scroll down the menu until the "Network (NFS)" option then press Enter. Notice that the machine starts booting on the serial console.

...

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

A busybox ash shell will pop up as shown below, from which the Gentoo Linux installation can continue.

CODE When things are going right...

VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 280k freed
init started:  BusyBox v1.00-pre10 (2004.04.27-02:55+0000) multi-call binary
  
Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL
  
 Gentoo/MIPS Netboot for Cobalt Microserver Machines
 Build Date: April 26th, 2004
  
 * To configure networking, do the following:
  
 * For Static IP:
 * /bin/net-setup <IP Address> <Gateway Address> [telnet]
  
 * For Dynamic IP:
 * /bin/net-setup dhcp [telnet]
  
 * If you would like a telnetd daemon loaded as well, pass "telnet"
 * As the final argument to /bin/net-setup.
  
Please press Enter to activate this console.

Troubleshooting

If the machine is being stubborn and refusing to download its image, it can be one of two things:

1. the instructions have not been followed correctly, or
2. it needs a little gentle persuasion. (No, put that sledge hammer down!)

Here's a list of things to check:

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

Using an installation CD

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

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

The Live CD images can be found under the experimental/mips/livecd/ directory on a Gentoo mirror.

Warning
These CDs are highly experimental at this time. They may or may not work at this time. Please report success or failures either on Bugzilla, this forum thread or in the #gentoo-mips IRC channel.

Automatic network detection

Maybe it just works?

If the system is plugged into an Ethernet network with a DHCP server, it is very likely that the networking configuration has already been set up automatically. If so, then the many included network-aware commands on the installation CD such as ssh, scp, ping, irssi, wget, and links, among others, will work immediately.

Determine interface names

ifconfig command

If networking has been configured, the ifconfig command should list one or more network interfaces (besides lo). In the example below eth0 shows up:

root #ifconfig

eth0      Link encap:Ethernet  HWaddr 00:50:BA:8F:61:7A
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1984 txqueuelen:100
          RX bytes:485691215 (463.1 Mb)  TX bytes:123951388 (118.2 Mb)
          Interrupt:11 Base address:0xe800 

As a result of the shift towards predictable network interface names, the interface name on the system can be quite different from the old eth0 naming convention. Recent installation media might show regular network interfaces names like eno0, ens1, or enp5s0. Look for the interface in the ifconfig output that has an IP address related to the local network.

Tip
If no interfaces are displayed when the standard ifconfig command is used, try using the same command with the -a option. This option forces the utility to show all network interfaces detected by the system whether they be in an up or down state. If ifconfig -a produces no results then the hardware is faulty or the driver for the interface has not been loaded into the kernel. Both situations reach beyond the scope of this Handbook. Contact #gentoo for support.

ip command

As an alternative to ifconfig, the ip command can be used to determine interface names. The following example shows the output of ip addr (of another system so the information shown is different from the previous example):

root #ip addr

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
    inet 10.0.20.77/22 brd 10.0.23.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::ea40:f2ff:feac:257a/64 scope link 
       valid_lft forever preferred_lft forever

The output above may be a bit more complicated to read than alternative. The interface name in the above example directly follows the number; it is eno1.

In the remainder of this document, the handbook will assume that the operating network interface is called eth0.

Optional: Configure any proxies

If the Internet is accessed through a proxy, then it is necessary to set up proxy information during the installation. It is very easy to define a proxy: just define a variable which contains the proxy server information.

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

To set up an HTTP proxy (for HTTP and HTTPS traffic):

root #export http_proxy="http://proxy.gentoo.org:8080"

To set up an FTP proxy:

root #export ftp_proxy="ftp://proxy.gentoo.org:8080"

To set up an RSYNC proxy:

root #export RSYNC_PROXY="proxy.gentoo.org:8080"

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

CODE Adding username/password to the proxy variable

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

Testing the network

Try pinging your ISP's DNS server (found in /etc/resolv.conf) and a web site of choice. This ensures that the network is functioning properly and that the network packets are reaching the net, DNS name resolution is working correctly, etc.

root #ping -c 3 www.gentoo.org

If this all works, then the remainder of this chapter can be skipped to jump right to the next step of the installation instructions (Preparing the disks).

Automatic network configuration

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

If the installation medium does not contain any of these tools, continue with the Manual network configuration.

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

Default: Using net-setup

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

root #net-setup eth0

net-setup will ask some questions about the network environment. When all is done, the network connection should work. Test the network connection as stated before. If the tests are positive, congratulations! Skip the rest of this section and continue with Preparing the disks.

If the network still doesn't work, continue with Manual network configuration.

Alternative: Using PPP

Assuming PPPoE is needed to connect to the Internet, the installation CD (any version) has made things easier by including ppp. Use the provided pppoe-setup script to configure the connection. During the setup the Ethernet device that is connected to your ADSL modem, the username and password, the IPs of the DNS servers and if a basic firewall is needed or not will be asked.

root #pppoe-setup

root #pppoe-start

If something goes wrong, double-check that the username and password are correct by looking at etc/ppp/pap-secrets or /etc/ppp/chap-secrets and make sure to use the right Ethernet device. If the Ethernet device does not exist, the appropriate network modules need to be loaded. In that case continue with Manual network configuration as it will explain how to load the appropriate network modules there.

If everything worked, continue with Preparing the disks.

Alternative: Using PPTP

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

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

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

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

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

root #pptp <server ip>

Now continue with Preparing the disks.

Manual network configuration

Loading the appropriate network modules

When the Installation CD boots, it tries to detect all the hardware devices and loads the appropriate kernel modules (drivers) to support the 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 needed.

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

To find out what kernel modules are provided for networking, use the ls command:

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

If a driver is found for the network device, use modprobe to load the kernel module. For instance, to load the pcnet32 module:

root #modprobe pcnet32

To check if the network card is now detected, use ifconfig. A detected network card would result in something like this (again, eth0 here is just an example):

root #ifconfig eth0

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

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

root #ifconfig eth0

eth0: error fetching interface information: Device not found

The available network interface names on the system can be listed through the /sys file system:

root #ls /sys/class/net

dummy0  eth0  lo  sit0  tap0  wlan0

In the above example, 6 interfaces are found. The eth0 one is most likely the (wired) Ethernet adapter whereas wlan0 is the wireless one.

Assuming that the network card is now detected, retry net-setup or pppoe-setup again (which should work now), but for the hardcore people we explain how to configure the network manually as well.

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

• Using DHCP for automatic IP retrieval
• Preparing for wireless access if a wireless network is used
• Understanding network terminology explains the basics about networking
• Using ifconfig and route explains how to set up networking manually

Using DHCP

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

root #dhcpcd eth0

Some network administrators require that the hostname and domainname provided by the DHCP server is used by the system. In that case, use:

root #dhcpcd -HD eth0

If this works (try pinging some Internet server, like Google's 8.8.8.8 or Cloudflare's 1.1.1.1), then everything is set and ready to continue. Skip the rest of this section and continue with Preparing the disks.

Preparing for wireless access

Note
Support for the iw command might be architecture-specific. If the command is not available see if the net-wireless/iw package is available for the current architecture. The iw command will be unavailable unless the net-wireless/iw package has been installed.

When using a wireless (802.11) card, the wireless settings need to be configured before going any further. To see the current wireless settings on the card, one can use iw. Running iw might show something like:

root #iw dev wlp9s0 info

Interface wlp9s0
	ifindex 3
	wdev 0x1
	addr 00:00:00:00:00:00
	type managed
	wiphy 0
	channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
	txpower 30.00 dBm

To check for a current connection:

root #iw dev wlp9s0 link

Not connected.

or

root #iw dev wlp9s0 link

Connected to 00:00:00:00:00:00 (on wlp9s0)
	SSID: GentooNode
	freq: 2462
	RX: 3279 bytes (25 packets)
	TX: 1049 bytes (7 packets)
	signal: -23 dBm
	tx bitrate: 1.0 MBit/s

Note
Some wireless cards may have a device name of wlan0 or ra0 instead of wlp9s0. Run ip link to determine the correct device name.

For most users, there are only two settings needed to connect, the ESSID (aka wireless network name) and, optionally, the WEP key.

• First, ensure the interface is active:

root #ip link set dev wlp9s0 up

• To connect to an open network with the name GentooNode:

root #iw dev wlp9s0 connect -w GentooNode

• To connect with a hex WEP key, prefix the key with d::

root #iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd

• To connect with an ASCII WEP key:

root #iw dev wlp9s0 connect -w GentooNode key 0:some-password

Note
If the wireless network is set up with WPA or WPA2, then wpa_supplicant needs to be used. For more information on configuring wireless networking in Gentoo Linux, please read the Wireless networking chapter in the Gentoo Handbook.

Confirm the wireless settings by using iw dev wlp9s0 link. Once wireless is working, continue configuring the IP level networking options as described in the next section (Understanding network terminology) or use the net-setup tool as described previously.

Understanding network terminology

Note
If the IP address, broadcast address, netmask and nameservers are known, then skip this subsection and continue with Using ifconfig and route.

If all of the above fails, the network will need to be configured manually. This is not difficult at all. However, some knowledge of network terminology and basic concepts might be necessary. After reading this section, users will know what a gateway is, what a netmask serves for, how a broadcast address is formed and why systems need nameservers.

In a network, hosts are identified by their IP address (Internet Protocol address). Such an address is perceived as a combination of four numbers between 0 and 255. Well, at least when using IPv4 (IP version 4). In reality, such an IPv4 address consists of 32 bits (ones and zeros). Let's view an example:

CODE Example of an IPv4 address

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

Note
The successor of IPv4, IPv6, uses 128 bits (ones and zeros). In this section, the focus is on IPv4 addresses.

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

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

CODE Example of network/host separation

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

In other words, 192.168.0.14 is part of the example network, but 192.168.1.2 is not.

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

CODE Broadcast address

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

To be able to surf on the Internet, each computer in the network must know which host shares the Internet connection. This host is called the gateway. Since it is a regular host, it has a regular IP address (for instance 192.168.0.1).

Previously we stated that every host has its own IP address. To be able to reach this host by a name (instead of an IP address) we need a service that translates a name (such as dev.gentoo.org) to an IP address (such as 64.5.62.82). Such a service is called a name service. To use such a service, the necessary name servers need to be defined in /etc/resolv.conf.

In some cases, the gateway also serves as a nameserver. Otherwise the nameservers provided by the ISP need to be entered in this file.

To summarize, the following information is needed before continuing:

Network item	Example
The system IP address	192.168.0.2
Netmask	255.255.255.0
Broadcast	192.168.0.255
Gateway	192.168.0.1
Nameserver(s)	195.130.130.5, 195.130.130.133

Using ifconfig and route

Setting up the network consists of three steps:

1. Assign an IP address using ifconfig
2. Set up routing to the gateway using route
3. Finish up by placing the nameserver IPs in /etc/resolv.conf

To assign an IP address, the IP address, broadcast address and netmask are needed. Then execute the following command, substituting ${IP_ADDR} with the right IP address, ${BROADCAST} with the right broadcast address and ${NETMASK} with the right netmask:

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

Set up routing using route. Substitute ${GATEWAY} with the right gateway IP address:

root #route add default gw ${GATEWAY}

Now open /etc/resolv.conf:

root #nano -w /etc/resolv.conf

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

FILE /etc/resolv.confDefault resolv.conf template

nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}

That's it. Now test the network by pinging some Internet server (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1). If this works, congratulations then. Continue with Preparing the disks.

Introduction to block devices

Block devices

Let's take a good look at disk-oriented aspects of Gentoo Linux and Linux in general, including Linux filesystems, partitions, and block devices. Once the ins and outs of disks and filesystems are understood, partitions and filesystems can be established for the Gentoo Linux installation.

To begin, let's look at block devices. The most famous block device is probably the one that represents the first drive in a Linux system, namely /dev/sda. SCSI and Serial ATA drives are both labeled /dev/sd*; even IDE drives are labeled /dev/sd* with the libata framework in the kernel. When using the old device framework, then the first IDE drive is /dev/hda.

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

Partitions

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

Designing a partition scheme

How many partitions and how big?

The number of partitions is highly dependent on the environment. For instance, if there are lots of users, then it is advised to have /home/ separate as it increases security and makes backups easier. If Gentoo is being installed to perform as a mail server, then /var/ should be separate as all mails are stored inside /var/. A good choice of filesystem will then maximize the performance. Game servers will have a separate /opt/ as most gaming servers are installed there. The reason is similar for the /home/ directory: security and backups. In most situations, /usr/ is to be kept big: not only will it contain the majority of applications, it typically also hosts the Gentoo ebuild repository (by default located at /usr/portage) which already takes around 650 MiB. This disk space estimate excludes the packages/ and distfiles/ directories that are generally stored within this ebuild repository.

It very much depends on what the administrator wants to achieve. Separate partitions or volumes have the following advantages:

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

However, multiple partitions have disadvantages as well. If not configured properly, the system might have lots of free space on one partition and none on another. Another nuisance is that separate partitions - especially for important mount points like /usr/ or /var/ - often require the administrator to boot with an initramfs to mount the partition before other boot scripts start. This isn't always the case though, so results may vary.

There is also a 15-partition limit for SCSI and SATA unless the disk uses GPT labels.

What about swap space?

There is no perfect value for the swap partition. The purpose of swap space is to provide disk storage to the kernel when internal memory (RAM) is under pressure. A swap space allows for the kernel to move memory pages that are not likely to be accessed soon to disk (swap or page-out), freeing memory. Of course, if that memory is suddenly needed, these pages need to be put back in memory (page-in) which will take a while (as disks are very slow compared to internal memory).

When the system is not going to run memory intensive applications or the system has lots of memory available, then it probably does not need much swap space. However, swap space is also used to store the entire memory in case of hibernation. If the system is going to need hibernation, then a bigger swap space is necessary, often at least the amount of memory installed in the system.

Using fdisk

SGI machines: Creating an SGI disk label

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

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

Warning
The SGI Volume Header must begin at cylinder 0. Failure to do so means a failure to boot from the disk.

The following is an example excerpt from an fdisk session. Read and tailor it to personal preference...

root #fdisk /dev/sda

Switch to expert mode:

Command (m for help):x

With m the full menu of options is displayed:

Expert command (m for help):m

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

Build an SGI disk label:

Expert command (m for help):g

Building a new SGI disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content will be irrecoverably lost.

Return to the main menu:

Expert command (m for help):r

Take a look at the current partition layout:

Command (m for help):p

Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 17482 cylinders
Units = cylinders of 2048 * 512 bytes
  
----- partitions -----
Pt#     Device  Info     Start       End   Sectors  Id  System
 9:  /dev/sda1               0         4     10240   0  SGI volhdr
11:  /dev/sda2               0     17481  35803136   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----

Note
If the disk already has an existing SGI Disklabel, then fdisk will not allow the creation of a new label. There are two ways around this. One is to create a Sun or MS-DOS disklabel, write the changes to disk, and restart fdisk. The second is to overwrite the partition table with null data via the following command: dd if=/dev/zero of=/dev/sda bs=512 count=1

Resizing the SGI volume header

Important
This step is often needed, due to a bug in fdisk. For some reason, the volume header isn't created correctly, the end result being it starts and ends on cylinder 0. This prevents multiple partitions from being created. To get around this issue... read on.

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

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

Create a new partition:

Command (m for help):n

Partition number (1-16): 1
First cylinder (5-8682, default 5): 51
 Last cylinder (51-8682, default 8682): 101

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

Delete the partition:

Command (m for help):d

Partition number (1-16): 9

Now recreate it:

Command (m for help):n

Partition number (1-16): 9
First cylinder (0-50, default 0): 0
 Last cylinder (0-50, default 50): 50

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

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

Partitioning Cobalt drives

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

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

For that reason, it is recommended to create a ~20MB /boot/ partition formatted EXT2r0 upon which to install CoLo & kernels. This allows the user to run a modern filesystem (EXT3 or ReiserFS) for the root filesystem.

In the example, it is assumed that /dev/sda1 is created to mount later as a /boot/ partition. To make this /, keep the PROM's expectations in mind.

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

CODE List of important fdisk commands

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

root #fdisk /dev/sda

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

Start by clearing out any existing partitions:

Command (m for help):o

Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
  
  
The number of cylinders for this disk is set to 19870.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Now verify the partition table is empty using the p command:

Command (m for help):p

Disk /dev/sda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
  
   Device Boot      Start         End      Blocks   Id  System

Create the /boot partition:

Command (m for help):n

Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-19870, default 1):
Last cylinder or +size or +sizeM or +sizeK (1-19870, default 19870): +20M

When printing the partitions, notice the newly created one:

Command (m for help):p

Disk /dev/sda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          40       20128+  83  Linux

Let's now create an extended partition that covers the remainder of the disk. In that extended partition, we'll create the rest (logical partitions):

Command (m for help):n

Command action
   e   extended
   p   primary partition (1-4)
e
Partition number (1-4): 2
First cylinder (41-19870, default 41):
Using default value 41
Last cylinder or +size or +sizeM or +sizeK (41-19870, default 19870):
Using default value 19870

Now we create the / partition, /usr, /var, et.

Command (m for help):n

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

Repeat this as needed.

Last but not least, the swap space. It is recommended to have at least 250MB swap, preferrably 1GB:

Command (m for help):n

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

When checking the partition table, everything should be ready - one thing notwithstanding.

Command (m for help):p

Disk /dev/sda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
  
Device Boot      Start         End      Blocks      ID  System
/dev/sda1               1          21       10552+  83  Linux
/dev/sda2              22       19870    10003896    5  Extended
/dev/sda5              22        1037      512032+  83  Linux
/dev/sda6            1038        5101     2048224+  83  Linux
/dev/sda7            5102        9165     2048224+  83  Linux
/dev/sda8            9166       13229     2048224+  83  Linux
/dev/sda9           13230       17293     2048224+  83  Linux
/dev/sda10          17294       19870     1298776+  83  Linux

Notice how #10, the swap partition is still type 83? Let's change that to the proper type:

Command (m for help):t

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

Now verify:

Command (m for help):p

Disk /dev/sda: 10.2 GB, 10254827520 bytes
16 heads, 63 sectors/track, 19870 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
  
Device Boot      Start         End      Blocks      ID  System
/dev/sda1               1          21       10552+  83  Linux
/dev/sda2              22       19870    10003896    5  Extended
/dev/sda5              22        1037      512032+  83  Linux
/dev/sda6            1038        5101     2048224+  83  Linux
/dev/sda7            5102        9165     2048224+  83  Linux
/dev/sda8            9166       13229     2048224+  83  Linux
/dev/sda9           13230       17293     2048224+  83  Linux
/dev/sda10          17294       19870     1298776+  82  Linux Swap

We write out the new partition table:

Command (m for help):w

The partition table has been altered!
  
Calling ioctl() to re-read partition table.
Syncing disks.

Creating file systems

Introduction

Now that the partitions are created, it is time to place a filesystem on them. In the next section the various file systems that Linux supports are described. Readers that already know which filesystem to use can continue with Applying a filesystem to a partition. The others should read on to learn about the available filesystems...

Filesystems

Several filesystems are available. Some of them are found stable on the mips architecture - it is advised to read up on the filesystems and their support state before selecting a more experimental one for important partitions.

btrfs

A next generation filesystem that provides many advanced features such as snapshotting, self-healing through checksums, transparent compression, subvolumes and integrated RAID. A few distributions have begun to ship it as an out-of-the-box option, but it is not production ready. Reports of filesystem corruption are common. Its developers urge people to run the latest kernel version for safety because the older ones have known problems. This has been the case for years and it is too early to tell if things have changed. Fixes for corruption issues are rarely backported to older kernels. Proceed with caution when using this filesystem!

ext2

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

ext3

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

ext4

Initially created as a fork of ext3, ext4 brings new features, performance improvements, and removal of size limits with moderate changes to the on-disk format. It can span volumes up to 1 EB and with maximum file size of 16TB. Instead of the classic ext2/3 bitmap block allocation ext4 uses extents, which improve large file performance and reduce fragmentation. Ext4 also provides more sophisticated block allocation algorithms (delayed allocation and multiblock allocation) giving the filesystem driver more ways to optimize the layout of data on the disk. Ext4 is the recommended all-purpose all-platform filesystem.

f2fs

The Flash-Friendly File System was originally created by Samsung for the use with NAND flash memory. As of Q2, 2016, this filesystem is still considered immature, but it is a decent choice when installing Gentoo to microSD cards, USB drives, or other flash-based storage devices.

JFS

IBM's high-performance journaling filesystem. JFS is a light, fast and reliable B+tree-based filesystem with good performance in various conditions.

ReiserFS

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

XFS

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

vfat

Also known as FAT32, is supported by Linux but does not support any permission settings. It is mostly used for interoperability with other operating systems (mainly Microsoft Windows) but is also a necessity for some system firmware (like UEFI).

NTFS

This "New Technology" filesystem is the flagship filesystem of Microsoft Windows. Similar to vfat above it does not store permission settings or extended attributes necessary for BSD or Linux to function properly, therefore it cannot be used as a root filesystem. It should only be used for interoperability with Microsoft Windows systems (note the emphasis on only).

When using ext2, ext3, or ext4 on a small partition (less than 8GB), then the file system must be created with the proper options to reserve enough inodes. The mke2fs (mkfs.ext2) application uses the "bytes-per-inode" setting to calculate how many inodes a file system should have. On smaller partitions, it is advised to increase the calculated number of inodes.

On ext2, ext3 and ext4, this can be done using one of the following commands, respectively:

root #mkfs.ext2 -T small /dev/<device>

root #mkfs.ext3 -T small /dev/<device>

root #mkfs.ext4 -T small /dev/<device>

This will generally quadruple the number of inodes for a given file system as its "bytes-per-inode" reduces from one every 16kB to one every 4kB. This can be tuned even further by providing the ratio:

root #mkfs.ext2 -i <ratio> /dev/<device>

Applying a filesystem to a partition

To create a filesystem on a partition or volume, there are user space utilities available for each possible filesystem. Click the filesystem's name in the table below for additional information on each filesystem:

Filesystem	Creation command	On minimal CD?	Package
btrfs	mkfs.btrfs	Yes	sys-fs/btrfs-progs
ext2	mkfs.ext2	Yes	sys-fs/e2fsprogs
ext3	mkfs.ext3	Yes	sys-fs/e2fsprogs
ext4	mkfs.ext4	Yes	sys-fs/e2fsprogs
f2fs	mkfs.f2fs	Yes	sys-fs/f2fs-tools
jfs	mkfs.jfs	Yes	sys-fs/jfsutils
reiserfs	mkfs.reiserfs	Yes	sys-fs/reiserfsprogs
xfs	mkfs.xfs	Yes	sys-fs/xfsprogs
vfat	mkfs.vfat	Yes	sys-fs/dosfstools
NTFS	mkfs.ntfs	Yes	sys-fs/ntfs3g

For instance, to have the boot partition (/dev/sda1) in ext2 and the root partition (/dev/sda5) in ext4 as used in the example partition structure, the following commands would be used:

root #mkfs.ext2 /dev/sda1

root #mkfs.ext4 /dev/sda5

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

Activating the swap partition

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

root #mkswap /dev/sda10

To activate the swap partition, use swapon:

root #swapon /dev/sda10

Create and activate the swap with the commands mentioned above.

Mounting the root partition

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

root #mount /dev/sda5 /mnt/gentoo

Note
If /tmp/ needs to reside on a separate partition, be sure to change its permissions after mounting:

root #chmod 1777 /mnt/gentoo/tmp

This also holds for /var/tmp.

Later in the instructions the proc filesystem (a virtual interface with the kernel) as well as other kernel pseudo-filesystems will be mounted. But first we install the Gentoo installation files.

Installing a stage tarball

Setting the date and time

Before installing Gentoo, it is a good idea to be sure the date and time are set correctly. A mis-configured clock may lead to strange results: base system files should be extracted with accurate time stamps. In fact, due to several websites and services using encrypted communications (SSL/TLS), it might not be possible to download the installation files at all if the system clock is too far skewed!

Verify the current date and time by running the date command:

root #date

Mon Oct  3 13:16:22 PDT 2016

If the date/time displayed is wrong, update it using one of the methods below.

Note
Motherboards that do not include a Real-Time Clock (RTC) should be configured to automatically sync the system clock with a time server. This is also true for systems that do include a RTC, but have a failed battery.

Automatic

Official Gentoo installation media includes the ntpd command (available through the net-misc/ntp package). Official media includes a configuration file pointing to ntp.org time servers. It can be used to automatically sync the system clock to UTC time using a time server. Using this method requires a working network configuration and may not be available on all architectures.

Warning
Automatic time sync comes at a price. It will reveal the system's IP address and related network information to a time server (in the case of the example below ntp.org). Users with privacy concerns should be aware of this before setting the system clock using the below method.

root #ntpd -q -g

Manual

The date command can also be used to perform a manual set on the system clock. Use the MMDDhhmmYYYY syntax (Month, Day, hour, minute and Year).

UTC time is recommended for all Linux systems. Later on during the installation a timezone will be defined. This will modify the display of the clock to local time.

For instance, to set the date to October 3rd, 13:16 in the year 2016:

root #date 100313162016

Choosing a stage tarball

Multilib (32 and 64-bit)

Choosing a base tarball for the system can save a considerable amount of time later on in the installation process, specifically when it is time to choose a system profile. The selection of a stage tarball will directly impact future system configuration and can save a headache or two later on down the line. The multilib tarball uses 64-bit libraries when possible, and only falls back to the 32-bit versions when necessary for compatibility. This is an excellent option for the majority of installations because it provides a great amount of flexibility for customization in the future. Those who desire their systems to be capable of easily switching profiles should download the multilib tarball option for their respective processor architecture.

Most users should not use the 'advanced' tarballs options; they are for specific software or hardware configurations.

No-multilib (pure 64-bit)

Selecting a no-multilib tarball to be the base of the system provides a complete 64-bit operating system environment. This effectively renders the ability to switch to multilib profiles improbable, but possible. Those who are just starting out with Gentoo should not choose a no-multilib tarball unless it is absolutely necessary.

Warning
Be aware, migrating from a no-multilib to a multilib system requires an extremely well-working knowledge of Gentoo and the lower-level toolchain (it may even cause our Toolchain developers to shudder a little). It is not for the faint of heart and is beyond the scope of this guide.

Downloading the stage tarball

Go to the Gentoo mount point where the root file system is mounted (most likely /mnt/gentoo):

root #cd /mnt/gentoo

Depending on the installation medium, the only tool necessary to download a stage tarball is a web browser.

Graphical browsers

Those using environments with fully graphical web browsers will have no problem copying a stage file URL from the main website's download section. Simply select the appropriate tab, right click the link to the stage file, then Copy link address (Firefox) or Copy link location (Chromium) to copy the link to the clipboard, then paste the link to the wget utility on the command-line to download the stage tarball:

root #wget <PASTED_STAGE_URL>

Command-line browsers

More traditional readers or 'old timer' Gentoo users, working exclusively from command-line may prefer using links, a non-graphical, menu-driven browser. To download a stage, surf to the Gentoo mirror list like so:

root #links https://www.gentoo.org/downloads/mirrors/

To use an HTTP proxy with links, pass on the URL with the -http-proxy option:

root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/

Next to links there is also the lynx browser. Like links it is a non-graphical browser but it is not menu-driven.

root #lynx https://www.gentoo.org/downloads/mirrors/

If a proxy needs to be defined, export the http_proxy and/or ftp_proxy variables:

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

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

On the mirror list, select a mirror close by. Usually HTTP mirrors suffice, but other protocols are available as well. Move to the releases/mips/autobuilds/ directory. There all available stage files are displayed (they might be stored within subdirectories named after the individual sub-architectures). Select one and press d to download.

After the stage file download completes, it is possible to verify the integrity and validate the contents of the stage tarball. Those interested should proceed to the next section.

Those not interested in verifying and validating the stage file can close the command-line browser by pressing q and can move directly to the Unpacking the stage tarball section.

Verifying and validating

Note
Some tarballs are being delivered via xz compression. When downloading a tarball ending in .tar.xz, be sure to adjust the tarball filename from .tar.bz2 in the following commands.

Like with the minimal installation CDs, additional downloads to verify and validate the stage file are available. Although these steps may be skipped, these files are provided for users who care about the legitimacy of the file(s) they just downloaded.

• A .CONTENTS file that contains a list of all files inside the stage tarball.
• A .DIGESTS file that contains checksums of the stage file in different algorithms.
• A .DIGESTS.asc file that, like the .DIGESTS file, contains checksums of the stage file in different algorithms, but is also cryptographically signed to ensure it is provided by the Gentoo project.

Use openssl and compare the output with the checksums provided by the .DIGESTS or .DIGESTS.asc files.

For instance, to validate the SHA512 checksum:

root #openssl dgst -r -sha512 stage3-mips-<release>.tar.?(bz2|xz)

Another way is to use the sha512sum command:

root #sha512sum stage3-mips-<release>.tar.?(bz2|xz)

To validate the Whirlpool checksum:

root #openssl dgst -r -whirlpool stage3-mips-<release>.tar.?(bz2|xz)

Compare the output of these commands with the value registered in the .DIGESTS(.asc) files. The values need to match, otherwise the downloaded file might be corrupt (or the digests file is).

Just like with the ISO file, it is also possible to verify the cryptographic signature of the .DIGESTS.asc file using gpg to make sure the checksums have not been tampered with:

root #gpg --verify stage3-mips-<release>.tar.?(bz2|xz){.DIGESTS.asc,}

Unpacking the stage tarball

Now unpack the downloaded stage onto the system. We use tar to proceed:

root #tar xpvf stage3-*.tar.bz2 --xattrs-include='*.*' --numeric-owner

Make sure that the same options (xpf and --xattrs-include='*.*') are used. The x stands for extract, the p for preserve permissions and the f to denote that we want to extract a file (not standard input). --xattrs-include='*.*' is to include preservation of the the extended attributes in all namespaces stored in the archive. Finally, --numeric-owner is used to ensure that the user and group IDs of the files being extracted from the tarball will remain the same as Gentoo's release engineering team intended (even if adventurous users are not using official Gentoo installation media).

Now that the stage file is unpacked, proceed with Configuring the compile options.

Configuring compile options

Introduction

To optimize Gentoo, it is possible to set a couple of variables which impacts the behavior of Portage, Gentoo's officially supported package manager. All those variables can be set as environment variables (using export) but that isn't permanent. To keep the settings, Portage reads in the /etc/portage/make.conf file, a configuration file for Portage.

Note
A commented listing of all possible variables can be found in /mnt/gentoo/usr/share/portage/config/make.conf.example. For a successful Gentoo installation only the variables that are mentioned below need to be set.

Fire up an editor (in this guide we use nano) to alter the optimization variables we will discuss hereafter.

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

From the make.conf.example file it is obvious how the file should be structured: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. Several of those variables are discussed next.

CFLAGS and CXXFLAGS

The CFLAGS and CXXFLAGS variables define the optimization flags for GCC C and C++ compilers respectively. Although those are defined generally here, for maximum performance one would need to optimize these flags for each program separately. The reason for this is because every program is different. However, this is not manageable, hence the definition of these flags in the make.conf file.

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

We will not explain all possible optimization options. To understand them all, read the GNU Online Manual(s) or the gcc info page (info gcc - only works on a working Linux system). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.

A first setting is the -march= or -mtune= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments). A commonly used value is native as that tells the compiler to select the target architecture of the current system (the one users are installing Gentoo on).

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

Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation). It has no impact on the generated code, but uses more memory. On systems with low memory, gcc might get killed. In that case, do not use this flag.

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

When the CFLAGS and CXXFLAGS variables are defined, combine the several optimization flags in one string. The default values contained in the stage3 archive that is unpacked should be good enough. The following one is just an example:

CODE Example CFLAGS and CXXFLAGS variables

# Compiler flags to set for all languages
COMMON_FLAGS="-mabi=32 -mips4 -pipe -O2"
# Use the same settings for both variables
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"

Tip
Although the GCC optimization article has more information on how the various compilation options can affect a system, the Safe CFLAGS article may be a more practical place for beginners to start optimizing their systems.

MAKEOPTS

The MAKEOPTS variable defines how many parallel compilations should occur when installing a package. A good choice is the number of CPUs (or CPU cores) in the system plus one, but this guideline isn't always perfect.

CODE Example MAKEOPTS declaration in make.conf

MAKEOPTS="-j2"

Ready, set, go!

Update the /mnt/gentoo/etc/portage/make.conf file to match personal preference and save (nano users would hit Ctrl+X).

Then continue with Installing the Gentoo base system.

Chrooting

Optional: Selecting mirrors

Distribution files

In order to download source code quickly it is recommended to select a fast mirror. Portage will look in the make.conf file for the GENTOO_MIRRORS variable and use the mirrors listed therein. It is possible to surf to the Gentoo mirror list and search for a mirror (or mirrors) that is close to the system's physical location (as those are most frequently the fastest ones). However, we provide a nice tool called mirrorselect which provides users with a nice interface to select the mirrors needed. Just navigate to the mirrors of choice and press Spacebar to select one or more mirrors.

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

Gentoo ebuild repository

A second important step in selecting mirrors is to configure the Gentoo ebuild repository via the /etc/portage/repos.conf/gentoo.conf file. This file contains the sync information needed to update the package repository (the collection of ebuilds and related files containing all the information Portage needs to download and install software packages).

Configuring the repository can be done in a few simple steps. First, if it does not exist, create the repos.conf directory:

root #mkdir --parents /mnt/gentoo/etc/portage/repos.conf

Next, copy the Gentoo repository configuration file provided by Portage to the (newly created) repos.conf directory:

root #cp /mnt/gentoo/usr/share/portage/config/repos.conf /mnt/gentoo/etc/portage/repos.conf/gentoo.conf

Take a peek with a text editor or by using the cat command. The inside of the file should be in .ini format and look like this:

FILE /mnt/gentoo/etc/portage/repos.conf/gentoo.conf

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
auto-sync = yes
sync-rsync-verify-jobs = 1
sync-rsync-verify-metamanifest = yes
sync-rsync-verify-max-age = 24
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4

# for daily squashfs snapshots
#sync-type = squashdelta
#sync-uri = mirror://gentoo/../snapshots/squashfs

The default sync-uri variable value listed above will determine a mirror location based on a rotation. This will aid in easing bandwidth stress on Gentoo's infrastructure and will provide a fail-safe in case a specific mirror is offline. It is recommended the default URI is retained unless a local, private Portage mirror will be used.

Tip
For those interested, the official specification for Portage's plug-in sync API can be found in the Portage project's Sync article.

Copy DNS info

One thing still remains to be done before entering the new environment and that is copying over the DNS information in /etc/resolv.conf. This needs to be done to ensure that networking still works even after entering the new environment. /etc/resolv.conf contains the name servers for the network.

To copy this information, it is recommended to pass the --dereference option to the cp command. This ensures that, if /etc/resolv.conf is a symbolic link, that the link's target file is copied instead of the symbolic link itself. Otherwise in the new environment the symbolic link would point to a non-existing file (as the link's target is most likely not available inside the new environment).

root #cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

Mounting the necessary filesystems

In a few moments, the Linux root will be changed towards the new location. To make sure that the new environment works properly, certain filesystems need to be made available there as well.

The filesystems that need to be made available are:

• /proc/ which is a pseudo-filesystem (it looks like regular files, but is actually generated on-the-fly) from which the Linux kernel exposes information to the environment
• /sys/ which is a pseudo-filesystem, like /proc/ which it was once meant to replace, and is more structured than /proc/
• /dev/ is a regular file system, partially managed by the Linux device manager (usually udev), which contains all device files

The /proc/ location will be mounted on /mnt/gentoo/proc/ whereas the other two are bind-mounted. The latter means that, for instance, /mnt/gentoo/sys/ will actually be /sys/ (it is just a second entry point to the same filesystem) whereas /mnt/gentoo/proc/ is a new mount (instance so to speak) of the filesystem.

root #mount --types proc /proc /mnt/gentoo/proc

root #mount --rbind /sys /mnt/gentoo/sys

root #mount --make-rslave /mnt/gentoo/sys

root #mount --rbind /dev /mnt/gentoo/dev

root #mount --make-rslave /mnt/gentoo/dev

Note
The --make-rslave operations are needed for systemd support later in the installation.

Warning
When using non-Gentoo installation media, this might not be sufficient. Some distributions make /dev/shm a symbolic link to /run/shm/ which, after the chroot, becomes invalid. Making /dev/shm/ a proper tmpfs mount up front can fix this:

root #test -L /dev/shm && rm /dev/shm && mkdir /dev/shm

root #mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm

Also ensure that mode 1777 is set:

root # chmod 1777 /dev/shm

Entering the new environment

Now that all partitions are initialized and the base environment installed, it is time to enter the new installation environment by chrooting into it. This means that the session will change its root (most top-level location that can be accessed) from the current installation environment (installation CD or other installation medium) to the installation system (namely the initialized partitions). Hence the name, change root or chroot.

This chrooting is done in three steps:

1. The root location is changed from / (on the installation medium) to /mnt/gentoo/ (on the partitions) using chroot
2. Some settings (those in /etc/profile) are reloaded in memory using the source command
3. The primary prompt is changed to help us remember that this session is inside a chroot environment.

root #chroot /mnt/gentoo /bin/bash

root #source /etc/profile

root #export PS1="(chroot) ${PS1}"

From this point, all actions performed are immediately on the new Gentoo Linux environment. Of course it is far from finished, which is why the installation still has some sections left!

Tip
If the Gentoo installation is interrupted anywhere after this point, it should be possible to 'resume' the installation at this step. There is no need to repartition the disks again! Simply mount the root partition and run the steps above starting with copying the DNS info to re-enter the working environment. This is also useful for fixing bootloader issues. More information can be found in the chroot article.

Mounting the boot partition

Now that the new environment has been entered, it is necessary to create and mount the /boot partition. This will be important when it is time to compile the kernel and install the bootloader:

root #mkdir /boot

root #mount /dev/sda1 /boot

Configuring Portage

Installing an ebuild repository snapshot from the web

Next step is to install a snapshot of the main ebuild repository. This snapshot contains a collection of files that informs Portage about available software titles (for installation), which profiles the system administrator can select, package or profile specific news items, etc.

The use of emerge-webrsync is recommended for those who are behind restrictive firewalls (because it uses HTTP/FTP protocols for downloading the snapshot) and saves network bandwidth. Readers who have no network or bandwidth restrictions can happily skip down to the next section.

This will fetch the latest snapshot (which is released on a daily basis) from one of Gentoo's mirrors and install it onto the system:

root #emerge-webrsync

Note
During this operation, emerge-webrsync might complain about a missing /usr/portage/ location. This is to be expected and nothing to worry about - the tool will create the location.

From this point onward, Portage might mention that certain updates are recommended to be executed. This is because system packages installed through the stage file might have newer versions available; Portage is now aware of new packages because of the repository snapshot. Package updates can be safely ignored for now; updates can be delayed after the Gentoo installation has finished.

Optional: Updating the Gentoo ebuild repository

It is possible to update the Gentoo ebuild repository to the latest version. The previous emerge-webrsync command will have installed a very recent snapshot (usually recent up to 24h) so this step is definitely optional.

Suppose there is a need for the last package updates (up to 1 hour), then use emerge --sync. This command will use the rsync protocol to update the Gentoo ebuild repository (which was fetched earlier on through emerge-webrsync) to the latest state.

root #emerge --sync

On slow terminals, like some framebuffers or serial consoles, it is recommended to use the --quiet option to speed up the process:

root #emerge --sync --quiet

Reading news items

When the Gentoo ebuild repository is synchronized to the system, Portage may warn the user with messages similar to the following:

* IMPORTANT: 2 news items need reading for repository 'gentoo'.

* Use eselect news to read news items.

News items were created to provide a communication medium to push critical messages to users via the rsync tree. To manage them, use eselect news. The eselect application is a Gentoo application that allows for a common management interface towards system changes and operations. In this case, eselect is asked to use its news module.

For the news module, three operations are most used:

• With list an overview of the available news items is displayed.
• With read the news items can be read.
• With purge news items can be removed once they have been read and will not be reread anymore.

root #eselect news list

root #eselect news read

More information about the newsreader is available through its manual page:

root #man news.eselect

Choosing the right profile

Warning
Do not select any of the the 17.1 profiles until reading the corresponding 17.1 news item. This profile is experimental and requires special migration instructions.

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

You can see what profile the system is currently using with eselect, now using the profile module:

root #eselect profile list

Available profile symlink targets:
  [1]   default/linux/mips/13.0 *
  [2]   default/linux/mips/13.0/desktop
  [3]   default/linux/mips/13.0/desktop/gnome
  [4]   default/linux/mips/13.0/desktop/kde

Note
The output of the command is just an example and evolves over time.

As can be seen, there are also desktop subprofiles available for some architectures.

Warning
Profile upgrades are not to be taken lightly. When selecting the initial profile, make sure to use profile corresponding to the same version as the one initially used by stage3 (e.g. 13.0). Each new profile version is announced through a news item containing migration instructions. Make sure to read it and follow them before switching to a newer profile.

After viewing the available profiles for the mips architecture, users can select a different profile for the system:

root #eselect profile set 2

Note
The developer subprofile is specifically for Gentoo Linux development and is not meant to be used by casual users.

Updating the @world set

At this point, it is wise to update the system's @world set so that a base can be established.

This following step is necessary so the system can apply any updates or USE flag changes which have appeared since the stage3 was built and from any profile selection:

root #emerge --ask --verbose --update --deep --newuse @world

Tip
If a full scale desktop environment profile has been selected this process could greatly extend the amount of time necessary for the install process. Those in a time crunch can work by this 'rule of thumb': the shorter the profile name, the less specific the system's @world set; the less specific the @world set, the fewer packages the system will require. In other words:

• selecting default/linux/amd64/13.0 will require very few packages to be updated, whereas
• selecting default/linux/amd64/13.0/desktop/gnome/systemd will require many packages to be installed since the init system is changing from OpenRC to systemd, and the GNOME desktop environment framework will be installed.

Configuring the USE variable

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

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

In the USE variable users define keywords which are mapped onto compile-options. For instance, ssl will compile SSL support in the programs that support it. -X will remove X-server support (note the minus sign in front). gnome gtk -kde -qt4 -qt5 will compile programs with GNOME (and GTK+) support, and not with KDE (and Qt) support, making the system fully tweaked for GNOME (if the architecture supports it).

The default USE settings are placed in the make.defaults files of the Gentoo profile used by the system. Gentoo uses a (complex) inheritance system for its profiles, which we will not dive into at this stage. The easiest way to check the currently active USE settings is to run emerge --info and select the line that starts with USE:

root #emerge --info | grep ^USE

USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."

Note
The above example is truncated, the actual list of USE values is much, much larger.

A full description on the available USE flags can be found on the system in /usr/portage/profiles/use.desc.

root #less /usr/portage/profiles/use.desc

Inside the less command, scrolling can be done using the ↑ and ↓ keys, and exited by pressing q.

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

root #nano -w /etc/portage/make.conf

FILE /etc/portage/make.confEnabling USE for a KDE-based system with DVD, ALSA and CD recording support

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

When USE is defined in /etc/portage/make.conf it is added (or removed if the USE flag starts with the - sign) from that default list. Users who want to ignore any default USE settings and manage it completely themselves should start the USE definition in make.conf with -*:

FILE /etc/portage/make.confIgnoring default USE flags

USE="-* X acl alsa"

Warning
Although possible, setting -* (as seen in the example above) is discouraged as carefully chosen USE flag defaults may be configured in some ebuilds to prevent conflicts and other errors.

Timezone

Select the timezone for the system. Look for the available timezones in /usr/share/zoneinfo/, then write it in the /etc/timezone file.

root #ls /usr/share/zoneinfo

Suppose the timezone of choice is Europe/Brussels:

root #echo "Europe/Brussels" > /etc/timezone

Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8.

Next, reconfigure the sys-libs/timezone-data package, which will update the /etc/localtime file for us, based on the /etc/timezone entry. The /etc/localtime file is used by the system C library to know the timezone the system is in.

root #emerge --config sys-libs/timezone-data

Configure locales

Most users will want to use only one or two locales on their system.

Locales specify not only the language that the user should use to interact with the system, but also what the rules are for sorting strings, displaying dates and times, etc.

The locales that a system should support should be mentioned in /etc/locale.gen.

root #nano -w /etc/locale.gen

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

FILE /etc/locale.genEnabling US and DE locales with the appropriate character formats

en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8

Warning
We strongly suggest to use at least one UTF-8 locale because some applications may require it.

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

root #locale-gen

To verify that the selected locales are now available, run locale -a.

Once done, it is now time to set the system-wide locale settings. Again we use eselect for this, now with the locale module.

With eselect locale list, the available targets are displayed:

root #eselect locale list

Available targets for the LANG variable:
  [1] C
  [2] POSIX
  [3] en_US
  [4] en_US.iso88591
  [5] en_US.utf8
  [6] de_DE
  [7] de_DE.iso88591
  [8] de_DE.iso885915
  [9] de_DE.utf8
  [ ] (free form)

With eselect locale set VALUE the correct locale can be set:

root #eselect locale set 9

Manually, this can still be accomplished through the /etc/env.d/02locale file:

FILE /etc/env.d/02localeManually setting system locale definitions

LANG="de_DE.UTF-8"
LC_COLLATE="C"

Make sure a locale is set, as the system would otherwise display warnings and errors during kernel builds and other software deployments later in the installation.

Now reload the environment:

root #env-update && source /etc/profile && export PS1="(chroot) $PS1"

We made a full Localization guide to help the user guide through this process. Another interesting article is the UTF-8 guide for very specific information to enable UTF-8 on the system.

Installing the sources

The core around which all distributions are built is the Linux kernel. It is the layer between the user programs and the system hardware. Gentoo provides its users several possible kernel sources. A full listing with description is available at the Kernel overview page.

For mips-based systems Gentoo recommends the sys-kernel/mips-sources package.

Choose an appropriate kernel source and install it using emerge:

root #emerge --ask sys-kernel/mips-sources

This will install the Linux kernel sources in /usr/src/ in which a symbolic link called linux will be pointing to the installed kernel source:

root #ls -l /usr/src/linux

lrwxrwxrwx    1 root   root    12 Oct 13 11:04 /usr/src/linux -> linux-3.16.5-gentoo

Now it is time to configure and compile the kernel sources. There are two approaches for this:

1. The kernel is manually configured and built.
2. A tool called genkernel is used to automatically build and install the Linux kernel.

We explain the manual configuration as the default choice here as it is the best way to optimize an environment.

Default: Manual configuration

Introduction

Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true - after configuring a couple of kernels no-one even remembers that it was difficult ;)

However, one thing is true: it is vital to know the system when a kernel is configured manually. Most information can be gathered by emerging sys-apps/pciutils which contains the lspci command:

root #emerge --ask sys-apps/pciutils

Note
Inside the chroot, it is safe to ignore any pcilib warnings (like pcilib: cannot open /sys/bus/pci/devices) that lspci might throw out.

Another source of system information is to run lsmod to see what kernel modules the installation CD uses as it might provide a nice hint on what to enable.

Now go to the kernel source directory and execute make menuconfig. This will fire up menu-driven configuration screen.

root #cd /usr/src/linux

root #make menuconfig

The Linux kernel configuration has many, many sections. Let's first list some options that must be activated (otherwise Gentoo will not function, or not function properly without additional tweaks). We also have a Gentoo kernel configuration guide on the Gentoo wiki that might help out further.

Activating required options

Make sure that every driver that is vital to the booting of the system (such as SCSI controller, etc.) is compiled in the kernel and not as a module, otherwise the system will not be able to boot completely.

Next select the exact processor type. It is also recommended to enable MCE features (if available) so that users are able to be notified of any hardware problems. On some architectures (such as x86_64), these errors are not printed to dmesg, but to /dev/mcelog. This requires the app-admin/mcelog package.

Also select Maintain a devtmpfs file system to mount at /dev so that critical device files are already available early in the boot process (CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT):

KERNEL Enabling devtmpfs support

Device Drivers --->
  Generic Driver Options --->
    [*] Maintain a devtmpfs filesystem to mount at /dev
    [ ]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

Verify SCSI disk support has been activated (CONFIG_BLK_DEV_SD):

KERNEL Enabling SCSI disk support

Device Drivers --->
   SCSI device support  --->
      <*> SCSI disk support

Now go to File Systems and select support for the filesystems you use. Don't compile the file system that is used for the root filesystem as module, otherwise the Gentoo system will not be able to mount the partition. Also select Virtual memory and /proc file system. Select one or more of the following options as needed by the system (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS):

KERNEL Selecting necessary file systems

File systems --->
  <*> Second extended fs support
  <*> The Extended 3 (ext3) filesystem
  <*> The Extended 4 (ext4) filesystem
  <*> Reiserfs support
  <*> JFS filesystem support
  <*> XFS filesystem support
  <*> Btrfs filesystem support
  DOS/FAT/NT Filesystems  --->
    <*> MSDOS fs support
    <*> VFAT (Windows-95) fs support
 
Pseudo Filesystems --->
    [*] /proc file system support
    [*] Tmpfs virtual memory file system support (former shm fs)

If PPPoE is used to connect to the Internet, or a dial-up modem, then enable the following options (CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY):

KERNEL Selecting PPPoE necessary drivers

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

The two compression options won't harm but are not definitely needed, neither does the PPP over Ethernet option, that might only be used by ppp when configured to do kernel mode PPPoE.

Don't forget to include support in the kernel for the network (Ethernet or wireless) cards.

Most systems also have multiple cores at their disposal, so it is important to activate Symmetric multi-processing support (CONFIG_SMP):

KERNEL Activating SMP support

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

Note
In multi-core systems, each core counts as one processor.

If USB input devices (like keyboard or mouse) or other USB devices will be used, do not forget to enable those as well (CONFIG_HID_GENERIC and CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD):

KERNEL Activating USB support for input devices

Device Drivers --->
  HID support  --->
    -*- HID bus support
    <*>   Generic HID driver
    [*]   Battery level reporting for HID devices
      USB HID support  --->
        <*> USB HID transport layer
  [*] USB support  --->
    <*>     xHCI HCD (USB 3.0) support
    <*>     EHCI HCD (USB 2.0) support
    <*>     OHCI HCD (USB 1.1) support

Preparing the configuration

Important
On the Origin 200/2000, Indigo2 Impact (R10000), Octane/Octane2 and O2, a 64-bit kernel is required to boot these systems. For these machines, emerge sys-devel/kgcc64 to create a cross-compiler for building 64-bit kernels.

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

System	Configure command
Cobalt Servers	make cobalt_defconfig
Indy, Indigo2 (R4k), Challenge S	make ip22_defconfig
Origin 200/2000	make ip27_defconfig
Indigo2 Impact (R10k)	make ip28_defconfig
O2	make ip32_defconfig

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

root #zcat /proc/config.gz > .config

Important
This kernel config is set up for a netboot image. That is, it will expect to find a root filesystem image somewhere nearby, either as a directory for initramfs, or a loopback device for initrd. When executing make menuconfig, don't forget to go into General Setup and disable the options for initramfs.

Customizing the configuration

Once a configuration is found, download it into the kernel source directory, and rename it to .config. From there, run make oldconfig to bring everything up to date according to the instructions above, and customize the configuration before compiling.

root #cd /usr/src/linux

root #cp /path/to/example-config .config

root #make oldconfig

Just press the ENTER (or Return) key at each prompt to accept the defaults for now ...

root #make menuconfig

Important
In the Kernel Hacking section, there is an option named "Are You Using A Cross Compiler?". This tells the kernel Makefiles to prepend "mips-linux-" (or mipsel-linux ... etc) to gcc and as commands when compiling the kernel. This should be turned off, even if cross-compiling. Instead, if a cross-compiler needs to be called, specify the prefix using the CROSS_COMPILE variable as shown in the next section.

Important
There is a known issue with JFS and ALSA on Octane systems where the ALSA fails to work. Given the experimental nature of JFS on MIPS, it is recommended that people avoid using JFS for the time being.

Compiling and installing

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

Note
On 64-bit machines, specify CROSS_COMPILE=mips64-unknown-linux-gnu- (or mips64el-... if on a little-endian system) to use the 64-bit compiler.

To compile natively:

root #make vmlinux modules modules_install

Cross-compiling on target machine, adjust the mips64-unknown-linux-gnu- accordingly:

root #make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu-

When compiling on another machine, such as an x86 box, use the following commands to compile the kernel & install modules into a specific directory to be transferred to the target machine.

root #make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu-

root #make modules_install INSTALL_MOD_PATH=/somewhere

Important
When compiling a 64-bit kernel for the Indy, Indigo2 (R4k), Challenge S and O2, use the vmlinux.32 target instead of vmlinux. Otherwise, the machine will not be able to boot. This is to work around the PROM not understanding the ELF64 format.

root #make vmlinux.32

Note
It is possible to enable parallel builds using make -jX with X being the number of parallel tasks that the build process is allowed to launch. This is similar to the instructions about /etc/portage/make.conf earlier, with the MAKEOPTS variable.

The above will create vmlinux.32, which is the final kernel.

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

Note
On Cobalt servers, the bootloader will expect to see a compressed kernel image. Remember to gzip -9 the file once it is in /boot/.

root #cp vmlinux /boot/kernel-3.16.5-gentoo

For Cobalt servers, compress the kernel image:

root #gzip -9v /boot/kernel-3.16.5-gentoo

Optional: Building an initramfs

In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs.

Without an initramfs, there is a huge risk that the system will not boot up properly as the tools that are responsible for mounting the file systems need information that resides on those file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.

To install an initramfs, install sys-kernel/genkernel first, then have it generate an initramfs:

root #emerge --ask sys-kernel/genkernel

root #genkernel --install initramfs

In order to enable specific support in the initramfs, such as LVM or RAID, add in the appropriate options to genkernel. See genkernel --help for more information. In the next example support is enabled for LVM and software RAID (mdadm):

root #genkernel --lvm --mdadm --install initramfs

The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:

root #ls /boot/initramfs*

Now continue with Kernel modules.

Alternative: Using genkernel

If a manual configuration looks too daunting, then using genkernel is recommended. It will configure and build the kernel automatically.

genkernel works by configuring a kernel nearly identically to the way the installation CD kernel is configured. This means that when genkernel is used to build the kernel, the system will generally detect all hardware at boot-time, just like the installation CD does. Because genkernel doesn't require any manual kernel configuration, it is an ideal solution for those users who may not be comfortable compiling their own kernels.

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

root #emerge --ask sys-kernel/genkernel

Next, edit the /etc/fstab file so that the line containing /boot/ as second field has the first field pointing to the right device. If the partitioning example from the handbook is followed, then this device is most likely /dev/sda1 with the ext2 file system. This would make the entry in the file look like so:

root #nano -w /etc/fstab

FILE /etc/fstabConfiguring the /boot mountpoint

/dev/sda1	/boot	ext2	defaults	0 2

Note
Further in the Gentoo installation, /etc/fstab will be configured again. The /boot setting is needed right now as the genkernel application reads in this configuration.

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

Note
If the boot partition doesn't use ext2 or ext3 as filesystem it might be necessary to manually configure the kernel using genkernel --menuconfig all and add support for this particular filesystem in the kernel (i.e. not as a module). Users of LVM2 will probably want to add --lvm as an argument as well.

root #genkernel all

Once genkernel completes, a kernel, full set of modules and initial ram disk (initramfs) will be created. We will use the kernel and initrd when configuring a boot loader later in this document. Write down the names of the kernel and initrd as this information is used when the boot loader configuration file is edited. The initrd will be started immediately after booting to perform hardware autodetection (just like on the installation CD) before the "real" system starts up.

root #ls /boot/kernel* /boot/initramfs*

Kernel modules

Configuring the modules

Note
Hardware modules are optional to be listed manually. udev will normally load all hardware modules that are detected to be connected in most cases. However, it is not harmful for automatically detected modules to be listed. Sometimes exotic hardware requires help to load their drivers.

List the modules that need to be loaded automatically in /etc/modules-load.d/*.conf files one module per line. Extra options for the modules, if necessary, should be set in /etc/modprobe.d/*.conf files.

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

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

For instance, to automatically load the 3c59x.ko module (which is the driver for a specific 3Com network card family), edit the /etc/modules-load.d/network.conf file and enter the module name in it. The actual file name is insignificant to the loader.

root #mkdir -p /etc/modules-load.d

root #nano -w /etc/modules-load.d/network.conf

FILE /etc/modules-load.d/network.confForce loading 3c59x module

3c59x

Continue the installation with Configuring the system.

Optional: Installing firmware

Some drivers require additional firmware to be installed on the system before they work. This is often the case for network interfaces, especially wireless network interfaces. Also, modern video chips, from vendors like AMD, NVidia, and Intel when using open source drivers, often need external firmware files. Most of the firmware is packaged in sys-kernel/linux-firmware:

root #emerge --ask sys-kernel/linux-firmware

Filesystem information

About fstab

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

Creating the fstab file

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

1. The first field shows the block special device or remote filesystem to be mounted. Several kinds of device identifiers are available for block special device nodes, including paths to device files, filesystem labels and UUIDs, and partition labels and UUIDs.
2. The second field shows the mount point at which the partition should be mounted.
3. The third field shows the filesystem used by the partition.
4. The fourth field shows the mount options used by mount when it wants to mount the partition. As every filesystem has its own mount options, users are encouraged to read the mount man page (man mount) for a full listing. Multiple mount options are comma-separated.
5. The fifth field is used by dump to determine if the partition needs to be dumped or not. This can generally be left as 0 (zero).
6. The sixth field is used by fsck to determine the order in which filesystems should be checked if the system wasn't shut down properly. The root filesystem should have 1 while the rest should have 2 (or 0 if a filesystem check isn't necessary).

Important
The default /etc/fstab file provided by Gentoo is not a valid fstab file but instead more of a template.

root #nano -w /etc/fstab

In the remainder of the text, we use the default /dev/sd* block device files as partition.

Filesystem labels and UUIDs

Both MBR (BIOS) and GPT include support for filesystem labels and filesystem UUIDs. These attributes can be defined in /etc/fstab as alternatives for the mount command to use when attempting to find and mount block devices. Filesystem labels and UUIDs are identified by the LABEL and UUID prefix and can be viewed with the blkid command:

root #blkid

Warning
If the filesystem inside a partition is wiped, then the filesystem label and the UUID values will be subsequently altered or removed.

Because of uniqueness, readers that are using an MBR-style partition table are recommended to use UUIDs over labels to define mountable volumes in /etc/fstab.

Partition labels and UUIDs

Users who have gone the GPT route have a couple more 'robust' options available to define partitions in /etc/fstab. Partition labels and partition UUIDs can be used to identify the block device's individual partition(s), regardless of what filesystem has been chosen for the partition itself. Partition labels and UUIDs are identified by the PARTLABEL and PARTUUID prefixes respectively and can be viewed nicely in the terminal by running the blkid command:

root #blkid

While not always true for partition labels, using a UUID to identify a partition in fstab provides a guarantee that the bootloader will not be confused when looking for a certain volume, even if the filesystem would be changed in the future. Using the older default block device files (/dev/sd*N) for defining the partitions in fstab is risky for systems that are restarted often and have SATA block devices added and removed regularly.

The naming for block device files depends on a number of factors, including how and in what order the disks are attached to the system. They also could show up in a different order depending on which of the devices are detected by the kernel first during the early boot process. With this being stated, unless one intends to constantly fiddle with the disk ordering, using default block device files is a simple and straightforward approach.

Let us take a look at how to write down the options for the /boot/ partition. This is just an example, and should be modified according to the partitioning decisions made earlier in the installation. In our mips partitioning example, /boot/ is usually the /dev/sda1 partition, with ext2 as filesystem. It needs to be checked during boot, so we would write down:

FILE /etc/fstabAn example /boot line for /etc/fstab

/dev/sda1   /boot     ext2    defaults        0 2

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

Add the rules that match the previously decided partitioning scheme and append rules for devices such as CD-ROM drive(s), and of course, if other partitions or drives are used, for those too.

Below is a more elaborate example of an /etc/fstab file:

FILE /etc/fstabA full /etc/fstab example

/dev/sda1   /boot        ext2    defaults,noatime     0 2
/dev/sda10   none         swap    sw                   0 0
/dev/sda5   /            ext4    noatime              0 1
  
/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

When auto is used in the third field, it makes the mount command guess what the filesystem would be. This is recommended for removable media as they can be created with one of many filesystems. The user option in the fourth field makes it possible for non-root users to mount the CD.

To improve performance, most users would want to add the noatime mount option, which results in a faster system since access times aren't registered (those are not needed generally anyway). This is also recommended for solid state drive (SSD) users, who should also enable the discard mount option (ext4 and btrfs only for now) which makes the TRIM command work.

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

Networking information

Host and domain information

One of the choices the user has to make is name his/her PC. This seems to be quite easy, but lots of users are having difficulties finding the appropriate name for their Linux PC. To speed things up, know that the decision is not final - it can be changed afterwards. In the examples below, the hostname tux is used within the domain homenetwork.

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

# Set the hostname variable to the selected host name
hostname="tux"

Second, if a domain name is needed, set it in /etc/conf.d/net. This is only necessary if the ISP or network administrator says so, or if the network has a DNS server but not a DHCP server. Don't worry about DNS or domain names if the system uses DHCP for dynamic IP address allocation and network configuration.

Note
The /etc/conf.d/net file does not exist by default, so needs to be created.

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

# Set the dns_domain_lo variable to the selected domain name
dns_domain_lo="homenetwork"

Note
If no domain name is configured, then users will notice they get "This is hostname.(none)" messages at their login screen. This should then be fixed by editing /etc/issue and deleting the string .\O from that file.

If a NIS domain is needed (users that do not know this will not need one), define that one too:

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

# Set the nis_domain_lo variable to the selected NIS domain name
nis_domain_lo="my-nisdomain"

Note
For more information on configuring DNS and NIS, please read the examples provided in /usr/share/doc/netifrc-*/net.example.bz2 which can be read using bzless. Also, it might be interesting to install net-dns/openresolv to help manage the DNS/NIS setup.

Configuring the network

During the Gentoo Linux installation, networking was already configured. However, that was for the installation CD itself and not for the installed environment. Right now, the network configuration is made for the installed Gentoo Linux system.

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

All networking information is gathered in /etc/conf.d/net. It uses a straightforward yet perhaps not intuitive syntax. But don't fear, everything is explained below. A fully commented example that covers many different configurations is available in /usr/share/doc/netifrc-*/net.example.bz2.

First install net-misc/netifrc:

root #emerge --ask --noreplace net-misc/netifrc

DHCP is used by default. For DHCP to work, a DHCP client needs to be installed. This is described later in Installing Necessary System Tools.

If the network connection needs to be configured because of specific DHCP options or because DHCP is not used at all, then open /etc/conf.d/net:

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

Set both config_eth0 and routes_eth0 to enter IP address information and routing information:

Note
This assumes that the network interface will be called eth0. This is, however, very system dependent. It is recommended to assume that the interface is named the same as the interface name when booted from the installation media if the installation media is sufficiently recent. More information can be found in Network Interface Naming.

FILE /etc/conf.d/netStatic IP definition

config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"

To use DHCP, define config_eth0:

FILE /etc/conf.d/netDHCP definition

config_eth0="dhcp"

Please read /usr/share/doc/netifrc-*/net.example.bz2 for a list of all available options. Be sure to also read up on the DHCP client man page if specific DHCP options need to be set.

If the system has several network interfaces, then repeat the above steps for config_eth1, config_eth2, etc.

Now save the configuration and exit to continue.

Automatically start networking at boot

To have the network interfaces activated at boot, they need to be added to the default runlevel.

root #cd /etc/init.d

root #ln -s net.lo net.eth0

root #rc-update add net.eth0 default

If the system has several network interfaces, then the appropriate net.* files need to be created just like we did with net.eth0.

If after booting the system we find out that the assumption about the network interface name (which is currently documented as eth0) was wrong, then execute the following steps to rectify this:

1. Update the /etc/conf.d/net file with the correct interface name (like enp3s0 instead of eth0).
2. Create new symbolic link (like /etc/init.d/net.enp3s0).
3. Remove the old symbolic link (rm /etc/init.d/net.eth0).
4. Add the new one to the default runlevel.
5. Remove the old one using rc-update del net.eth0 default.

The hosts file

Next inform Linux about the network environment. This is defined in /etc/hosts and helps in resolving host names to IP addresses for hosts that aren't resolved by the nameserver.

root #nano -w /etc/hosts

FILE /etc/hostsFilling in the networking information

# This defines the current system and must be set
127.0.0.1     tux.homenetwork tux localhost
  
# Optional definition of extra systems on the network
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny

Save and exit the editor to continue.

Optional: Get PCMCIA working

PCMCIA users should now install the sys-apps/pcmciautils package.

root #emerge --ask sys-apps/pcmciautils

System information

Root password

Set the root password using the passwd command.

root #passwd

The root Linux account is an all-powerful account, so pick a strong password. Later an additional regular user account will be created for daily operations.

Init and boot configuration

Gentoo (at least when using OpenRC) uses /etc/rc.conf to configure the services, startup, and shutdown of a system. Open up /etc/rc.conf and enjoy all the comments in the file. Review the settings and change where needed.

root #nano -w /etc/rc.conf

Next, open /etc/conf.d/keymaps to handle keyboard configuration. Edit it to configure and select the right keyboard.

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

Take special care with the keymap variable. If the wrong keymap is selected, then weird results will come up when typing on the keyboard.

Finally, edit /etc/conf.d/hwclock to set the clock options. Edit it according to personal preference.

root #nano -w /etc/conf.d/hwclock

If the hardware clock is not using UTC, then it is necessary to set clock="local" in the file. Otherwise the system might show clock skew behavior.

System logger

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

The first tool to decide on has to provide logging facilities for the system. Unix and Linux have an excellent history of logging capabilities - if needed, everything that happens on the system can be logged in log files. This happens through the system logger.

Gentoo offers several system logger utilities. A few of these include:

• app-admin/sysklogd - Offers the traditional set of system logging daemons. The default logging configuration works well out of the box which makes this package a good option for beginners.
• app-admin/syslog-ng - An advanced system logger. Requires additional configuration for anything beyond logging to one big file. More advanced users may choose this package based on it's logging potential; be aware additional configuration is a necessity for any kind of smart logging.
• app-admin/metalog - A highly-configurable system logger.

Others are available through Portage as well - the number of available packages increases on a daily basis.

Tip
If sysklogd or syslog-ng are going to be used, it is recommended to install and configure logrotate afterwards as those system loggers don't provide any rotation mechanism for the log files.

Tip
systemd provides its own logging facility called the "journal". Installing a separate syslog provider is optional on systems running systemd, and may require additional configuration to have the syslog daemon read messages from the journal.

To install the system logger of choice, emerge it and have it added to the default runlevel using rc-update. The following example installs app-admin/sysklogd:

root #emerge --ask app-admin/sysklogd

root #rc-update add sysklogd default

Optional: Cron daemon

Next is the cron daemon. Although it is optional and not required for every system, it is wise to install one.

A cron daemon executes scheduled commands. It is very handy if some command needs to be executed regularly (for instance daily, weekly or monthly).

Gentoo offers several possible cron daemons, including sys-process/bcron, sys-process/dcron, sys-process/fcron, and sys-process/cronie. Installing one of them is similar to installing a system logger. The following example uses sys-process/cronie:

root #emerge --ask sys-process/cronie

root #rc-update add cronie default

If dcron or fcron are used, an additional initialization command needs to be executed:

root #crontab /etc/crontab

Optional: File indexing

In order to index the file system to provide faster file location capabilities, install sys-apps/mlocate.

root #emerge --ask sys-apps/mlocate

Optional: Remote access

To be able to access the system remotely after installation, add the sshd init script to the default runlevel:

root #rc-update add sshd default

If serial console access is needed (which is possible in case of remote servers), uncomment the serial console section in /etc/inittab:

root #nano -w /etc/inittab

# SERIAL CONSOLES
s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100

Filesystem tools

Depending on the filesystems used, it is necessary to install the required file system utilities (for checking the filesystem integrity, creating additional file systems etc.). Note that tools for managing ext2, ext3, or ext4 filesystems (sys-fs/e2fsprogs) are already installed as a part of the @system set.

The following table lists the tools to install if a certain filesystem is used:

Filesystem	Package
Ext2, 3, and 4	sys-fs/e2fsprogs
XFS	sys-fs/xfsprogs
ReiserFS	sys-fs/reiserfsprogs
JFS	sys-fs/jfsutils
VFAT (FAT32, ...)	sys-fs/dosfstools
Btrfs	sys-fs/btrfs-progs

Tip
For more information on filesystems in Gentoo see the filesystem article.

Networking tools

If there is no need for any additional networking tools, continue immediately with the section on Configuring a bootloader.

Installing a DHCP client

Important
Although optional, the majority of users will find that they need a DHCP client to connect to the DHCP server on their network. Please take this opportunity to install a DHCP client. If this step is forgotten, then the system might not be able to get on the network thus making it impossible to download a DHCP client afterward.

In order for the system to automatically obtain an IP address for one or more network interface(s) using netifrc scripts, it is necessary to install a DHCP client. We recommend the use of net-misc/dhcpcd although many other DHCP clients are available through the Gentoo repository:

root #emerge --ask net-misc/dhcpcd

More information on dhcpcd can be found in the dhcpcd article.

Optional: Installing a PPPoE client

If PPP is used to connect to the internet, install the net-dialup/ppp package:

root #emerge --ask net-dialup/ppp

Optional: Install wireless networking tools

If the system will be connecting to wireless networks, install the net-wireless/iw package for Open or WEP networks and/or the net-wireless/wpa_supplicant package for WPA or WPA2 networks. iw is also a useful basic diagnostic tool for scanning wireless networks.

root #emerge --ask net-wireless/iw net-wireless/wpa_supplicant

Now continue with Configuring the bootloader.

arcload for Silicon Graphics machines

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

root #emerge arcload dvhtool

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

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

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

For Indy/Indigo2/Challenge S/O2 users:

root #dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS

For Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users:

root #dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64

Note
The name sashARCS or sash64 does not have to be used, unless the operation is installing to the volume header of a bootable CD. For normal boot from hard-disk, it can be named whatever the user wants.

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

root #dvhtool --print-volume-directory

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

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

Filearc.cfAn example arc.cf

'"`UNIQ--pre-00000057-QINU`"'

This is a deprecated template. Help us update this template!

Starting with arcload-0.5, arc.cf and kernels may reside either in the volume header, or on a partition. To utilize this newer feature, place the files in the /boot/ partition (or / if the boot partition is not separate). arcload uses the filesystem driver code from the popular grub bootloader, and thus supports the same range of filesystems.

root #dvhtool --unix-to-vh arc.cf arc.cf

root #dvhtool --unix-to-vh /usr/src/linux/vmlinux new

CoLo for Cobalt MicroServers

Installing CoLo

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

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

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

Note
This guide will go through setting up CoLo so that it is loaded by the stock firmware. This is the only truly safe, and recommended way to set up CoLo.

Warning
If wanted, these can be flashed into the server to totally replace the original firmware -- however, you are entirely on your own in that endeavour. Should anything go wrong, physically remove the BOOTROM and reprogram it with the stock firmware. If this sounds scary -- then DO NOT flash the machine. We take no responsibility for whatever happens if you ignore this advice.

Let's get on with installing CoLo. First, start by emerging the package.

root #emerge --ask sys-boot/colo

With that installed, take a look inside the /usr/lib/colo/ directory to find two files:

• colo-chain.elf (the "kernel" for the stock firmware to load), and
• colo-rom-image.bin (a ROM image for flashing into the BOOTROM)

We start by mounting /boot/ and dumping a compressed copy of colo-chain.elf in /boot/ where the system expects it.

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

Configuring CoLo

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

Note
Just a tip: when installing kernels, it is recommended to create two kernel images, kernel.gz.working -- a known working kernel, and kernel.gz.new -- a kernel that's just been compiled. It is possible to use symlinks to point to the curent "new" and "working" kernels, or just rename the kernel images.

Filedefault.coloAn example CoLo configuration

'"`UNIQ--pre-0000005A-QINU`"'

This is a deprecated template. Help us update this template!

Note
CoLo will refuse to load a script that does not begin with the #:CoLo:# line. Think of it as the equivalent of saying #!/bin/sh in shell scripts.

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

Filedefault.coloMenu-based configuration

'"`UNIQ--pre-0000005D-QINU`"'

This is a deprecated template. Help us update this template!

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

Setting up for serial console

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

Note
Those who do have the luxury of a supported video chipset may skip this section if they wish.

First, pull up an editor and hack away at /etc/inittab. Further down in the file, notice the following:

File/etc/inittabSnippet from inittab

'"`UNIQ--pre-00000060-QINU`"'

This is a deprecated template. Help us update this template!

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

File/etc/inittabExample snippet from inittab

'"`UNIQ--pre-00000063-QINU`"'

This is a deprecated template. Help us update this template!

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

root #echo 'ttyS0' >> /etc/securetty

Lately, Linux also calls this /dev/tts/0 -- so we add this too:

root #echo 'tts/0' >> /etc/securetty

Tweaking the SGI PROM

Setting generic PROM settings

With the bootloader installed, after rebooting (which we will come to in a second), go to the System Maintenance Menu and select Enter Command Monitor (5) like did initially when netbooting the system.

CodeMenu after boot

'"`UNIQ--pre-00000066-QINU`"'

This is a deprecated template. Help us update this template!

Provide the location of the Volume Header:

>>setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)

Automatically boot Gentoo:

>>setenv AutoLoad Yes

Set the timezone:

>>setenv TimeZone EST5EDT

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

>>setenv console d1

Set the serial console baud rate. This is optional, 9600 is the default setting, although one may use rates up to 38400 if that is desired:

>>setenv dbaud 9600

Now, the next settings depend on how the system is booted.

Settings for direct volume-header booting

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

Note
This only works on the Indy, Indigo2 (R4k) and Challenge S.

Set the root device to Gentoo's root partition, such as /dev/sda3:

>>setenv OSLoadPartition <root device>

To list the available kernels, type "ls".

>>setenv OSLoader <kernel name>

>>setenv OSLoadFilename <kernel name>

Declare the kernel parameters to pass:

>>setenv OSLoadOptions <kernel parameters>

To try a kernel without messing with kernel parameters, use the boot -f PROM command:

root #boot -f new root=/dev/sda5 ro

Settings for arcload

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

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

Select arcload as the bootloader:- sash64 or sashARCS:

>>setenv OSLoader sash64

Use the "working" kernel image, defined in "ip28" section of arc.cf:

>>setenv OSLoadFilename ip28(working)

Starting with arcload-0.5, files no longer need to be placed in the volume header -- they may be placed in a partition instead. To tell arcload where to look for its configuration file and kernels, one must set the OSLoadPartition PROM variable. The exact value here will depend on where the disk resides on the SCSI bus. Use the SystemPartition PROM variable as a guide -- only the partition number should need to change.

Note
Partitions are numbered starting at 0, not 1 as is the case in Linux.

To load from the volume header -- use partition 8:

>>setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)

Otherwise, specify the partition and filesystem type:

>>setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]

Rebooting the system

Exit the chrooted environment and unmount all mounted partitions. Then type in that one magical command that initiates the final, true test: reboot.

root #exit

cdimage ~#cd

cdimage ~#umount -l /mnt/gentoo/dev{/shm,/pts,}

cdimage ~#umount -R /mnt/gentoo

cdimage ~#reboot

Do not forget to remove the bootable CD, otherwise the CD might be booted again instead of the new Gentoo system.

Once rebooted in the freshly installed Gentoo environment, finish up with Finalizing the Gentoo installation.

User administration

Adding a user for daily use

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

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

Group	Description
audio	Be able to access the audio devices.
cdrom	Be able to directly access optical devices.
floppy	Be able to directly access floppy devices.
games	Be able to play games.
portage	Be able to access portage restricted resources.
usb	Be able to access USB devices.
video	Be able to access video capturing hardware and doing hardware acceleration.
wheel	Be able to use su.

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

Login:root

Password: (Enter the root password)

root #useradd -m -G users,wheel,audio -s /bin/bash larry

root #passwd larry

Password: (Enter the password for larry)
Re-enter password: (Re-enter the password to verify)

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

Disk cleanup

Removing tarballs

With the Gentoo installation finished and the system rebooted, if everything has gone well, we can now remove the downloaded stage3 tarball from the hard disk. Remember that they were downloaded to the / directory.

root #rm /stage3-*.tar.bz2*

Where to go from here

Documentation

Not sure where to go from here? There are many paths to explore... Gentoo provides its users with lots of possibilities, and therefore lots of documented (and less documented) features.

Definitely take a look at the next part of the Gentoo Handbook entitled Working with Gentoo which explains how to keep the software up to date, install additional software packages, details on USE flags, the OpenRC init system, etc.

Apart from the handbook, readers should also feel encouraged to explore other corners of the Gentoo wiki to find additional, community-provided documentation. The Gentoo wiki team also offers a Documentation topic overview which lists a selection of wiki articles by category. For instance, it refers to the localization guide to make a system feel more at home (particularly useful for users who speak English as a second language).

Gentoo online

Everyone is of course always welcome on our Gentoo forums or on one of our Gentoo IRC channels.

We also have several mailing lists open to our users.

Enjoy Gentoo!