Seçime bağlı: Yansı seçme
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.
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:
Next, copy the Gentoo repository configuration file provided by Portage to the (newly created) repos.conf directory:
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:
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.
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
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:
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.
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:
Also ensure that mode 1777 is set:
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:
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!
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.
Installing a Gentoo ebuild repository snapshot from the web
Next step is to install a snapshot of the Gentoo 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 (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:
During this operation, emerge-webrsync might complain about a missing /var/db/repos/gentoo/ 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 until 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.
On slow terminals, like some framebuffers or serial consoles, it is recommended to use the
Reading news items
When the Gentoo ebuild repository is synchronized, Portage may output informational messages similar to the following:
News items were created to provide a communication medium to push critical messages to users via the Gentoo ebuild repository. To manage them, use eselect news. The eselect application is a Gentoo-specific utility that allows for a common management interface for system administration. In this case, eselect is asked to use its
More information about the news reader is available through its manual page:
Choosing the right profile
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
Available profile symlink targets:  default/linux/amd64/17.0 *  default/linux/amd64/17.0/desktop  default/linux/amd64/17.0/desktop/gnome  default/linux/amd64/17.0/desktop/kde
The output of the command is just an example and evolves over time.
If you are using Systemd, please make sure the profile name contains systemd. If you are using OpenRC, please make sure the profile name does not contain systemd.
As can be seen, there are also desktop subprofiles available for some architectures.
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. 17.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 amd64 architecture, users can select a different profile for the system:
This is a placeholder for architecture-specific profile information
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:
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:
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,
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:
USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."
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 /var/db/repos/gentoo/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:
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
Although possible, setting
Optional: Configuring the ACCEPT_LICENSE variable
All of the Gentoo packages are tagged with the license(s) the package falls under. This allows users to select software by specific licenses or groups of licenses prior to installing it.
The LICENSE variable in an ebuild is only a guideline for Gentoo developers and users. It is not a legal statement, and there is no guarantee that it will reflect reality. So don't rely on it, but check the package itself in depth, including all files that you use.
Portage uses the ACCEPT_LICENSE variable to determine which packages to allow without prompting the user for the licenses previously accepted. Exceptions can be made per-package in /etc/portage/package.license as well.
The license groups defined in the Gentoo repository, managed by the Gentoo Licenses project, are:
Gentoo comes with a predefined value in the profiles, for example:
This can be customized system wide by changing /etc/portage/make.conf. The default value will only accept licenses that are explicitly approved by the Free Software Foundation, the Open Source Initiative, or that follow the Free Software Definition:
Per package overrides can then be added if necessary and desired, for example:
app-arch/unrar unRAR sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE sys-firmware/intel-microcode intel-ucode
Optional: Using systemd as the init system
The remainder of the Gentoo Handbook focuses on OpenRC (the traditional Gentoo init system) as the default init system. If systemd is desired, please consult the systemd article. It contains instructions equivalent to the instructions in the following sections of this Handbook. Specifically, it will walk the reader through various init system commands (systemctl) and systemd-specific services (such as timedatectl, hostnamectl, etc.) needed to establish a working systemd environment.
Select the timezone for the system. Look for the available timezones in /usr/share/zoneinfo/:
Suppose the timezone of choice is Europe/Brussels.
We write the timezone name into the /etc/timezone file.
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.
We use a slightly different approach here; we generate a symbolic link:
Later, when systemd is running, we can configure the timezone and related settings with the timedatectl command.
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 the rules for sorting strings, displaying dates and times, etc. Locales are case sensitive and must be represented exactly as described. A full listing of available locales can be found in the /usr/share/i18n/SUPPORTED file.
Supported system locales must be defined in the /etc/locale.gen file.
The following locales are an example to get both English (United States) and German (Germany/Deutchland) with the accompanying character formats (like UTF-8).
en_US ISO-8859-1 en_US.UTF-8 UTF-8 de_DE ISO-8859-1 de_DE.UTF-8 UTF-8
We strongly suggest adding at least one UTF-8 locale because many applications may require it to build properly.
The next step is to run the locale-gen command. This command generates all locales specified in the /etc/locale.gen file.
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
With eselect locale list, the available targets are displayed:
Available targets for the LANG variable:  C  C.utf8  en_US  en_US.iso88591  en_US.utf8  de_DE  de_DE.iso88591  de_DE.iso885915  de_DE.utf8  POSIX [ ] (free form)
With eselect locale set <NUMBER> the correct locale can be selected:
Manually, this can still be accomplished through the /etc/env.d/02locale file and for Systemd the /etc/locale.conf file:
Setting the locale will avoid warnings and errors during kernel and software compilations later in the installation.
Now reload the environment:
A full Localization guide to provide additional guidance through the locale selection process. Another interesting article is the UTF-8 guide for very specific information to enable UTF-8 on the system.