Handbook:Parts/Installation/System

About fstab
Under Linux, all partitions used by the system must be listed in. 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 file uses a table-like syntax. Every line consists of six fields, separated by whitespace (space(s), tabs, or a mixture of the two). 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 type of filesystem used by the partition.
 * 4) The fourth field shows the mount options used by  when it wants to mount the partition. As every filesystem has its own mount options, so system admins are encouraged to read the mount man page  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   (zero).
 * 6) The sixth field is used by  to determine the order in which filesystems should be checked if the system wasn't shut down properly. The root filesystem should have   while the rest should have   (or   if a filesystem check is not necessary).

In the remainder of the text, the default block device files will be used as partition identifiers.

Filesystem labels and UUIDs
Both MBR (BIOS) and GPT include support for filesystem labels and filesystem UUIDs. These attributes can be defined in as alternatives for the  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 command:

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

Partition labels and UUIDs
Users who have gone the GPT route have a couple more 'robust' options available to define partitions in. 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 command:

While not always true for partition labels, using a UUID to identify a partition in 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 for defining the partitions in  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.

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

When  is used in the third field, it makes the  command guess what the filesystem would be. This is recommended for removable media as they can be created with one of many filesystems. The  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  mount option, which results in a faster system since access times are not registered (those are not needed generally anyway). This is also recommended for systems with solid state drives (SSDs).

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

Networking information
It is important to note the following sections are provided to help the reader quickly setup their system to partake in a local area network.

For systems running OpenRC, a more detailed reference for network setup is available in the advanced network configuration section, which is covered near the end of the handbook. Systems with more specific network needs may need to skip ahead, then return here to continue with the rest of the installation.

For more specific systemd network setup, please review see the networking portion of the systemd article.

Host and domain information
One of the choices the system administrator has to make is name their PC. This seems to be quite easy, but lots of users are having difficulties finding the appropriate name for the hostname. 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.

OpenRC
Second, if a domain name is needed, set it in. 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.

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

systemd
To set the system hostname on systemd on a running system, the utility is used. During the installation process however, firstboot must be used instead (see later on in handbook).

For setting the hostname to "tux", one would run:

View help by running or.

Network
There are many options available for configuring network interfaces. This section covers a only a few methods. Choose the one which seems best suited to the setup needed.

DHCP via dhcpcd (any init system)
Most LAN networks operate a DHCP server. If this is the case, then using the dhcpcd program to obtain an IP address is recommended.

To install:

To enable and then start the service on OpenRC systems:

To enable and start the service on systemd systems:

With these steps completed, next time the system boots, dhcpcd should obtain an IP address from the DHCP server. See the Dhcpcd article for more details.

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

All networking information is gathered in. It uses a straightforward - yet perhaps not intuitive - syntax. Do not fear! Everything is explained below. A fully commented example that covers many different configurations is available in.

First install :

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 :

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

To use DHCP, define config_eth0 :

Please read for a list of additional configuration 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.

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

If, after booting the system, it is discovered the network interface name (which is currently documented as ) was wrong, then execute the following steps to rectify:


 * 1) Update the  file with the correct interface name (like   or , instead of  ).
 * 2) Create new symbolic link (like ).
 * 3) Remove the old symbolic link.
 * 4) Add the new one to the default runlevel.
 * 5) Remove the old one using.

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

Save and exit the editor to continue.

{{#ifeq: {{ROOTPAGENAME}} | X86 |

Optional: Get PCMCIA working
systems needing PCMCIA support should now install the package.


 * }}

Root password
Set the root password using the command.

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.

OpenRC
When using OpenRC with Gentoo, it uses to configure the services, startup, and shutdown of a system. Open up and enjoy all the comments in the file. Review the settings and change where needed.

Next, open to handle keyboard configuration. Edit it to configure and select the right keyboard.

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 to set the clock options. Edit it according to personal preference.

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

systemd
First, it is recommended to run which will prepare various components of the system are set correctly for the first boot into the new systemd environment. The passing the following options will include a prompt for the user to set a locale, timezone, hostname, root password, and root shell values. It will also assign a random machine ID to the installation:

Next users should run to reset all installed unit files to the preset policy values:

It's possible to run the full preset changes but this may reset any services which were already configured during the process:

These two steps will help ensure a smooth transition from the live environment to the installation's first boot.