Gentoo Linux hppa Handbook: Installing Gentoo
Introduction
Welcome
Welcome to Gentoo! Gentoo is a free operating system based on Linux that can be automatically optimized and customized for just about any application or need. It is built on an ecosystem of free software and does not hide what is running beneath the hood from its users.
Openness
Gentoo's premier tools are built from simple programming languages. Portage, Gentoo's package maintenance system, is written in Python. Ebuilds, which provide package definitions for Portage are written in bash. Our users are encouraged to review, modify, and enhance the source code for all parts of Gentoo.
By default, packages are only patched when necessary to fix bugs or provide interoperability within Gentoo. They are installed to the system by compiling source code provided by upstream projects into binary format (although support for precompiled binary packages is included too). Configuring Gentoo happens through text files.
For the above reasons and others: openness is built-in as a design principle.
Choice
Choice is another Gentoo design principle.
When installing Gentoo, choice is made clear throughout the Handbook. System administrators can choose two fully supported init systems (Gentoo's own OpenRC and Freedesktop.org's systemd), partition structure for storage disk(s), what file systems to use on the disk(s), a target system profile, remove or add features on a global (system-wide) or package specific level via USE flags, bootloader, network management utility, and much, much more.
As a development philosophy, Gentoo's authors try to avoid forcing users onto a specific system profile or desktop environment. If something is offered in the GNU/Linux ecosystem, it's likely available in Gentoo. If not, then we'd love to see it so. For new packages, it is recommended to first submit a package to GURU. Once it has matured and a Gentoo developer has volunteered to sponsor the new package, it can then be added to the official Gentoo package repository.
Power
Being a source-based operating system allows Gentoo to be ported onto new computer instruction set architectures and also allows all installed packages to be tuned. This strength surfaces another Gentoo design principle: power.
A system administrator who has successfully installed and customized Gentoo has compiled a tailored operating system from source code. The entire operating system can be tuned at a binary level via the mechanisms included in Portage's make.conf file. If so desired, adjustments can be made on a per-package basis, or a package group basis. In fact, entire sets of functionality can be added or removed using USE flags.
It is very important that the Handbook reader understands that these design principles are what makes Gentoo unique. With the principles of great power, many choices, and extreme openness highlighted, diligence, thought, and intentionality should be employed while using Gentoo.
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 | Most of the Gentoo system configuration files are created. |
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. |
Deciding which steps to take
The handbook presents an overwhelming amount of options, especially for someone who has never installed Linux without an installer.
It's important to realize that the handbook is designed to describe the steps required to install on a very wide variety of hardware, with different install needs. Because of this, many options presented in the handbook are unnecessary for a particular install and can be skipped.
Suggested steps
Prefixed with "Suggested:", some steps are not strictly required, but help in most cases, such as installing sys-kernel/linux-firmware.
Optional steps
Prefixed with "Optional:", many sections in the handbook are purely optional, and can be skipped if the user is looking for a simple, mostly vanilla install.
Examples of this include compiler flag customization, using a totally custom kernel, and disabling root login.
When following optional steps, it's important to be careful that all prerequisites were satisfied. Some optional steps depend on other optional steps.
Deprecated steps
Gentoo has existed for a long time. Some install processes are described in the handbook because they used to be more relevant, but are now largely deprecated. Instead of immediately removing this information, as it may still be helpful for some users, it may be designated as Deprecated: before removal. Once removed, the history must be used to view this content.
Defaults and alternatives
Whenever choices are presented, the handbook will try to explain the pros and cons of each choice.
If potential choices are mutually exclusive, "Default:" is used to designate the most supported or commonly chosen option, while alternatives are listed with "Alternative".
Alternative options are not inferior to Defaults, but Default options are typically more widely used and may have better support.
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 bootable ISO images. 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 Linux Mint).
This document covers the installation using official Gentoo Installation media or, in certain cases, netbooting.
For help on the other installation approaches, including using non-Gentoo bootable media, please read our Alternative installation guide.
We also provide a Gentoo installation tips and tricks document that might be useful.
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.
Although this document is architecture-specific, it may contain references to other architectures as well, because large parts of the Gentoo Handbook use text that is identical for all architectures (to avoid duplication of effort). Such references have been kept to a minimum, to avoid confusion.
If there is some uncertainty about 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 (webchat) channel on irc.libera.chat. 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
Before proceeding with the installation process, minimum hardware requirements should be met in order to successfully install Gentoo for the hppa system architecture.
A list of supported hardware can be found on the PA Team website. Additional information about a system can be looked up in the Parisc-Linux Hardware Database and the processor list on www.openpa.net.
It is important to know if the current system is using PA-RISC 1.1 or 2.0. Check the links above if this is unclear.
Memory | 64 MB |
---|---|
Disk space | 1.5 GB (excluding swap space) |
Swap space | At least 256 MB |
Gentoo Linux installation media
While it's recommended to use the official Gentoo boot media when installing, it's possible to use other installation environments. However, there is no guarantee they will contain required components. If an alternate install environment is used, skip to Preparing the disks.
Minimal installation CD
The Gentoo minimal installation CD, also known as the installcd, is a small, bootable image: a self-contained Gentoo environment. This image is maintained by Gentoo developers and designed to allow any user with an Internet connection to install Gentoo. During the boot process, the hardware is detected, and appropriate drivers are automatically loaded.
Minimal Installation CD releases are named using the format: install-<arch>-minimal-<release timestamp>.iso.
The Gentoo LiveGUI
Some users may find it easier to install Gentoo using the LiveGUI, which provides a KDE desktop environment. In addition to providing a useful graphical environment, the LiveGUI also allows for easier WiFi setup with help of the NetworkManager Applet.
The Gentoo LiveGUI USB image is built for the amd64 architecture weekly.
What are stage files?
A stage file is an archive which serves as the seed for a Gentoo environment.
Stage 3 files can be downloaded from releases/hppa/autobuilds/ on any of the official Gentoo mirrors. Stages are updated frequently and are therefore not included within official live images.
For now, stage files can be ignored. They will be described in greater detail later when they are needed
Historically, the handbook described installation steps for stage files with versions lower than 3. These stages contained environments unsuitable for typical installations, and are no longer covered in the handbook.
Downloading
Obtain the media
The default installation media used by Gentoo Linux are the minimal installation CDs, which provide a very small, bootable, Gentoo Linux environment. This environment contains the necessary tools to install Gentoo. The images themselves can be downloaded from the downloads page (recommended) or by manually browsing to the ISO location on one of the many available mirrors.
If downloading from a mirror, the minimal installation CDs can be found by:
- Connect to the mirror, typically using a local one found at Gentoo source mirrors.
- Navigate to the releases/ directory.
- Select the directory for the relevant target architecture (such as hppa/).
- Select the autobuilds/ directory.
- For amd64 and x86 architectures select either the current-install-amd64-minimal/ or current-install-x86-minimal/ directory (respectively). For all other architectures navigate to the current-iso/ directory.
Some target architectures such as arm, mips, and s390 will not have minimal install CDs. At this time the Gentoo Release Engineering project does not support building .iso files for these targets.
Inside this location, the installation media file is the file with the .iso suffix. For instance, take a look at the following listing:
[TXT] install-amd64-minimal-20231112T170154Z.iso.asc 2023-11-12 20:41 488
[TXT] install-amd64-minimal-20231119T164701Z.iso.asc 2023-11-19 18:41 488
[TXT] install-amd64-minimal-20231126T163200Z.iso.asc 2023-11-26 18:41 488
[TXT] install-amd64-minimal-20231203T170204Z.iso.asc 2023-12-03 18:41 488
[TXT] install-amd64-minimal-20231210T170356Z.iso.asc 2023-12-10 19:01 488
[TXT] install-amd64-minimal-20231217T170203Z.iso.asc 2023-12-17 20:01 488
[TXT] install-amd64-minimal-20231224T164659Z.iso.asc 2023-12-24 20:41 488
[TXT] install-amd64-minimal-20231231T163203Z.iso.asc 2023-12-31 19:01 488
[ ] install-amd64-minimal-20240107T170309Z.iso 2024-01-07 20:42 466M
[ ] install-amd64-minimal-20240107T170309Z.iso.CONTENTS.gz 2024-01-07 20:42 9.8K
[ ] install-amd64-minimal-20240107T170309Z.iso.DIGESTS 2024-01-07 21:01 1.3K
[TXT] install-amd64-minimal-20240107T170309Z.iso.asc 2024-01-07 21:01 488
[ ] install-amd64-minimal-20240107T170309Z.iso.sha256 2024-01-07 21:01 660
[TXT] latest-install-amd64-minimal.txt 2024-01-08 02:01 653
In the above example, the install-amd64-minimal-20240107T170309Z.iso file is the minimal installation CD itself. But as can be seen, other related files exist as well:
- A .CONTENTS.gz file which is a gz-compressed text file listing all files available on the installation media. This file can be useful to verify if particular firmware or drivers are available on the installation media before downloading it.
- A .DIGESTS file which contains the hash of the ISO file itself, in various hashing formats/algorithms. This file can be used to verify ISO file integrity.
- A .asc file which is a cryptographic signature of the ISO file. This can be used to verify image integrity and authenticity - that the download is indeed provided by the Gentoo Release Engineering team, free from tampering.
Ignore the other files available at this location for now - those will come back when the installation has proceeded further. Download the .iso file and, if verification of the download is wanted, download the .iso.asc file for the .iso file as well.
The .DIGESTS file is only needed if the signature in the .iso.asc file is not verified.
Verifying the downloaded files
This is an optional step and not necessary to install Gentoo Linux. However, it is recommended as it ensures that the downloaded file is not corrupt and has indeed been provided by the Gentoo Infrastructure team.
The .asc file provides a cryptographic signature of the ISO. By validating it, one can make sure that the installation file is provided by the Gentoo Release Engineering team and is intact and unmodified.
Microsoft Windows-based verification
To first verify the cryptographic signature, tools such as GPG4Win can be used. After installation, the public keys of the Gentoo Release Engineering team need to be imported. The list of keys is available on the signatures page. Once imported, the user can then verify the signature in the .asc file.
Linux based verification
On a Linux system, the most common method for verifying the cryptographic signature is to use the app-crypt/gnupg software. With this package installed, the following command can be used to verify the cryptographic signature in the .asc file.
When importing Gentoo keys, verify that the 16-character key ID (
BB572E0E2D182910
) matches.Gentoo keys can be downloaded from hkps://keys.gentoo.org using fingerprints available on the signatures page:
user $
gpg --keyserver hkps://keys.gentoo.org --recv-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910
gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported gpg: Total number processed: 1 gpg: imported: 1
Alternatively you can use instead the WKD to download the key:
user $
gpg --auto-key-locate=clear,nodefault,wkd --locate-key releng@gentoo.org
gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported gpg: Total number processed: 2 gpg: imported: 2 gpg: no ultimately trusted keys found pub dsa1024 2004-07-20 [SC] [expires: 2025-07-01] D99EAC7379A850BCE47DA5F29E6438C817072058 uid [ unknown] Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org> sub elg2048 2004-07-20 [E] [expires: 2025-07-01]
Or if using official Gentoo release media, import the key from /usr/share/openpgp-keys/gentoo-release.asc (provided by sec-keys/openpgp-keys-gentoo-release):
user $
gpg --import /usr/share/openpgp-keys/gentoo-release.asc
gpg: directory '/home/larry/.gnupg' created gpg: keybox '/home/larry/.gnupg/pubring.kbx' created gpg: key DB6B8C1F96D8BF6D: 2 signatures not checked due to missing keys gpg: /home/larry/.gnupg/trustdb.gpg: trustdb created gpg: key DB6B8C1F96D8BF6D: public key "Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>" imported gpg: key 9E6438C817072058: 3 signatures not checked due to missing keys gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported gpg: key BB572E0E2D182910: 1 signature not checked due to a missing key gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported gpg: key A13D0EF1914E7A72: 1 signature not checked due to a missing key gpg: key A13D0EF1914E7A72: public key "Gentoo repository mirrors (automated git signing key) <repomirrorci@gentoo.org>" imported gpg: Total number processed: 4 gpg: imported: 4 gpg: no ultimately trusted keys found
Next verify the cryptographic signature:
user $
gpg --verify install-hppa-minimal-20240107T170309Z.iso.asc
gpg: assuming signed data in 'install-hppa-minimal-20240107T170309Z.iso' gpg: Signature made Sun 07 Jan 2024 03:01:10 PM CST gpg: using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910 Subkey fingerprint: 534E 4209 AB49 EEE1 C19D 9616 2C44 695D B9F6 043D
To be absolutely certain that everything is valid, verify the fingerprint shown with the fingerprint on the Gentoo signatures page.
It's generally good practice to mark an imported key as trusted, once it's certain the key is trustworthy. When trusted keys are verified, gpg will not say unknown and warn about the signature being untrusted.
Writing the boot media
Of course, with just an ISO file downloaded, the Gentoo Linux installation cannot be started. The ISO file must be written to bootable media. This generally requires that the image is extracted to a filesystem, or written directly to a device.
Writing a bootable USB
Most modern systems support booting from a USB device.
Writing with Linux
dd is typically available on most Linux distros, and can be used to write the Gentoo boot media to a USB drive.
Determining the USB device path
Before writing, the path to the desired storage device must be determined.
dmesg will display detailed information describing the storage device as it is added to the system:
root #
dmesg
[268385.319745] sd 19:0:0:0: [sdd] 60628992 512-byte logical blocks: (31.0 GB/28.9 GiB)
Alternatively, lsblk can be used to display available storage devices:
root #
lsblk
sdd 8:48 1 28.9G 0 disk ├─sdd1 8:49 1 246K 0 part ├─sdd2 8:50 1 2.8M 0 part ├─sdd3 8:51 1 463.5M 0 part └─sdd4 8:52 1 300K 0 part
Once the device name has been determined, this can be added to the path prefix /dev/ to get the device path /dev/sdd.
Using the base device path, ie. sdd opposed to sdd1, is recommend as the Gentoo boot media contains a full GPT partition scheme.
Writing with dd
Be sure to check the target (of=target) path before executing dd, as it will be overwritten.
With the device path (/dev/sdd) and boot media install-amd64-minimal-<release timestamp>.iso ready:
root #
dd if=install-amd64-minimal-<release timestamp>.iso of=/dev/sdd bs=4096 status=progress && sync
if= specifies the input file, of= specifies the output file, which in this case, is a device.
bs=4096 is used as it speeds up transfers in most cases, status=progress displays transfers stats.
Burning a disk
A more elaborate set of instructions can be found in CD/DVD/BD_writing#Image_writing.
Burning with Microsoft Windows 7 and above
Versions of Microsoft Windows 7 and above can both mount and burn ISO images to optical media without the requirement for third-party software. Simply insert a burnable disk, browse to the downloaded ISO files, right click the file in Windows Explorer, and select "Burn disk image".
Burning with Linux
The cdrecord utility from the package app-cdr/cdrtools can burn ISO images on Linux.
To burn the ISO file on the CD in the /dev/sr0 device (this is the first CD device on the system - substitute with the right device file if necessary):
user $
cdrecord dev=/dev/sr0 install-hppa-minimal-20141204.iso
Users that prefer a graphical user interface can use K3B, part of the kde-apps/k3b package. In K3B, go to Tools and use Burn CD Image.
Booting
Booting the installation CD
When experiencing problems when booting the Installation CD or any other media, please read the PA-RISC Linux Boot HOWTO.
Boot the HPPA system. During the boot process, a message similar to the following will show up:
Searching for Potential Boot Devices.
To terminate search, press and hold the ESCAPE key.
When this message appears, press and hold the Esc key until an option menu appears. This can take a while, be patient. By default, this should enter the BOOT_ADMIN console. If an option menu is displayed, choose Enter Boot Administration mode to enter the BOOT_ADMIN console. This should result in an '>' prompt.
Put the Gentoo installation CD in the CD-ROM. If the SCSI ID of the CD-ROM drive is unknown, then the PA-RISC station will search for it if the search
command is invoked.
>
search
The PA-RISC station will now display all the available boot media. This is an example result of this command:
Device Selection Device Path Device Type and Utilities
---------------------------------------------------------------------------
P0 scsi.5.0 TOSHIBA CD-ROM XM-3301TA
IPL
P1 scsi.2.0 COMPAQ ST32550N
IPL
P2 lan.0010a7-06d1b6.3.6 server
IPL
To boot from a CD-ROM the accompanying Device Path is needed. For instance, to boot from the TOSHIBA CD-ROM in the above example, type the following command:
>
boot scsi.5.0 ipl
Trying scsi.5.0
The ipl keyword (Initial Program Loader) tells palo (the PA-RISC boot LOader) to enter interactive mode. This will allow to change, for example, the kernel boot parameters.
When the boot is successful, palo will start in interactive mode:
Boot path initialized.
Attempting to load IPL.
HARD Booted.
palo ipl 1.5 root@hope Sat Apr 23 18:06:47 CEST 2005
Boot image contains:
0/vmlinux32 6241293 bytes @ 0x3904000
0/vmlinux64 8352719 bytes @ 0x3ef8000
0/ramdisk 1007589 bytes @ 0x105800
Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial). Current command line:
0/vmlinux initrd=initrd TERM=linux root=/dev/ram0 init=/linuxrc cdroot looptype=squashfs loop=/livecd.squashfs hda=scsi console=ttyS0
0: 0/vmlinux
1: initrd=initrd
2: TERM=linux
3: root=/dev/ram0
4: init=/linuxrc
5: cdroot
6: looptype=squashfs
7: loop=/livecd.squashfs
8: hda=scsi
9: console=ttyS0
<#> edit the numbered field
'b' boot with this command line
'r' restore command line
'l' list dir
These parameters are suitable for most situations.
If extra features are needed, add the appropriate keyword(s) to the end of the command line. To add a keyword, edit the last field, add a space and type your keyword. The only implemented keywords as of now are cdcache which tells the installation CD to load itself into RAM, allowing to unmount the CD, and noload=module1[,module2[,...]] which allows to explicitly disable loading of particular modules.
(or 'b' to boot with this command line)?
9
console=ttyS0 hdb=scsi
Now that the kernel boot parameters are set, boot it!
(or 'b' to boot with this command line)?
b
This should result in a root ("#") prompt on the current console. It is possible to switch to other consoles by pressing Alt+F2, Alt+F3, and Alt+F4. Get back to the first one, press Alt+F1.
Extra hardware configuration
When the Installation medium boots, it tries to detect all the hardware devices and loads the appropriate kernel modules 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 by the system. If the PCI auto-detection missed some of the system's hardware, the appropriate kernel modules have to be loaded manually.
In the next example the 8139too module (which supports certain kinds of network interfaces) is loaded:
root #
modprobe 8139too
Optional: User accounts
If other people need access to the installation environment, or there is need to run commands as a non-root user on the installation medium (such as to chat using irssi without root privileges for security reasons), then an additional user account needs to be created and the root password set to a strong password.
To change the root password, use the passwd utility:
root #
passwd
New password: (Enter the new password) Re-enter password: (Re-enter the password)
To create a user account, first enter their credentials, followed by the account's password. The useradd and passwd commands are used for these tasks.
In the next example, a user called john is created:
root #
useradd -m -G users john
root #
passwd john
New password: (Enter john's password) Re-enter password: (Re-enter john's password)
To switch from the (current) root user to the newly created user account, use the su command:
root #
su - john
Optional: Viewing documentation while installing
TTYs
To view the Gentoo handbook from a TTY during the installation, first create a user account as described above, then press Alt+F2 to go to a new terminal (TTY) and login as the newly created user. Following the principle of least privilege, it is best practice to avoid browsing the web or generally performing any task with higher privileges than necessary. The root account has full control of the system and therefore must be used sparingly.
During the installation, the links web browser can be used to browse the Gentoo handbook - of course only from the moment that the Internet connection is working.
user $
links https://wiki.gentoo.org/wiki/Handbook:HPPA
To go back to the original terminal, press Alt+F1.
When booted to the Gentoo minimal or Gentoo admin environments, seven TTYs will be available. They can be switched by pressing Alt then a function key between F1-F7. It can be useful to switch to a new terminal when waiting for job to complete, to open documentation, etc.
GNU Screen
The Screen utility is installed by default on official Gentoo installation media. It may be more efficient for the seasoned Linux enthusiast to use screen to view installation instructions via split panes rather than the multiple TTY method mentioned above.
Optional: Starting the SSH daemon
To allow other users to access the system during the installation (perhaps to provide/receive support during an installation, or even do it remotely), a user account needs to be created (as was documented earlier on) and the SSH daemon needs to be started.
To fire up the SSH daemon on an OpenRC init, execute the following command:
root #
rc-service sshd start
If users log on to the system, they will see a message that the host key for this system needs to be confirmed (through what is called a fingerprint). This behavior is typical and can be expected for initial connections to an SSH server. However, later when the system is set up and someone logs on to the newly created system, the SSH client will warn that the host key has been changed. This is because the user now logs on to - for SSH - a different server (namely the freshly installed Gentoo system rather than the live environment that the installation is currently using). Follow the instructions given on the screen then to replace the host key on the client system.
To be able to use sshd, the network needs to function properly. Continue with the chapter on Configuring the network.
Automatic network configuration
Maybe it just works?
If the system is connected to an Ethernet network with an IPv6 router or DHCP server, it's very likely that the system's network was configured automatically. If additional, advanced configuration is not required, Internet connectivity can be tested.
Using DHCP
DHCP (Dynamic Host Configuration Protocol) assists in network configuration, and can automatically provide configuration for a variety of parameters including: IP address, network mask, routes, DNS servers, NTP servers, etc.
DHCP requires that a server be running on the same Layer 2 (Ethernet) segment as the client requesting a lease. DHCP is often used on RFC1918 (private) networks, but is also used to acquire public IP information from ISPs.
Official Gentoo boot media runs dhcpcd automatically at startup. This behavior can be disabled by adding the
nodhcp
argument to the boot media kernel commandline.If it is not already running, dhcpcd can be started on enp1s0 with:
root #
dhcpcd enp1s0
Some network administrators require that the hostname and domain name provided by the DHCP server is used by the system. In that case, use:
root #
dhcpcd -HD enp1s0
To stop dhcpcd, -x can be used:
root #
dhcpcd -x
sending signal Term to pid 10831 waiting for pid 10831 to exit
Dhcpcd usage
Testing the network
A properly configured default route is a critical component of Internet connectivity, route configuration can be checked with:
root #
ip route
default via 192.168.0.1 dev enp1s0
If no default route is defined, Internet connectivity is unavailable, and additional configuration is required.
Basic internet connectivity can be confirmed with a ping:
root #
ping -c 3 1.1.1.1
It's helpful to start by pinging a known IP address instead of a hostname. This can isolate DNS issues from basic Internet connectivity issues.
Outbound HTTPS access and DNS resolution can be confirmed with:
root #
curl --location gentoo.org --output /dev/null
Unless curl reports an error, or other tests fail, the installation process can be continued with disk preparation.
If curl reports an error, but Internet-bound pings work, DNS may need configuration.
If Internet connectivity has not been established, first interface information should be verified, then:
- net-setup can be used to assist in network configuration.
- Application specific configuration may be required.
- Manual network configuration can be attempted.
Obtaining interface info
If networking doesn't work out of the box, additional steps must be taken to enable Internet connectivity. Generally, the first step is to enumerate host network interfaces.
The ip command, part of the sys-apps/iproute2 package, can be used to query and configure system networking.
The link argument can be used to display network interface links:
root #
ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 4: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
The address argument can be used to query device address information:
root #
ip address
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<pre> 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 enp1s0 valid_lft forever preferred_lft forever inet6 fe80::ea40:f2ff:feac:257a/64 scope link valid_lft forever preferred_lft forever
The output of this command contains information for each network interface on the system. Entries begin with the device index, followed by the device name: enp1s0.
If no interfaces other than the lo (loopack) are displayed, then the networking 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. Please ask for support in contact #gentoo (webchat).
For consistency, the handbook will assume that the primary network interface is called enp1s0.
As a result of the shift toward predictable network interface names, the interface name on the system can be quite different than the old eth0 naming convention. Modern Gentoo boot media uses interface names with prefixes such as eno0, ens1, or enp5s0.
Optional: Application specific configuration
The following methods are not generally required, but may be helpful in situations where additional configuration is required for Internet connectivity.
Configure web proxies
If the internet is accessed through a web proxy, then it will be necessary to define proxy information to for Portage to properly access the proxy for each supported protocol. Portage observes the http_proxy, ftp_proxy, and RSYNC_PROXY environment variables in order to download packages via its wget and rsync retrieval mechanisms.
Certain text-mode web browsers such as links can also make use of environment variables that define web proxy settings; in particular for the HTTPS access it also will require the https_proxy environment variable to be defined. While Portage will be influenced without passing extra run time parameters during invocation, links will require proxy settings to be set.
In most cases, it is sufficient to define environment variables using the server hostname. In the following example, it is assumed the proxy server host is called proxy.gentoo.org and the port is 8080.
The
#
symbol in the following commands is a comment. It has been added for clarity only and does not need to be typed when entering the commands.To define an HTTP proxy (for HTTP and HTTPS traffic):
root #
export http_proxy="http://proxy.gentoo.org:8080" # Applies to Portage and Links
root #
export https_proxy="http://proxy.gentoo.org:8080" # Only applies for Links
If the HTTP proxy requires authentication, set a username and password with the following syntax:
root #
export http_proxy="http://username:password@proxy.gentoo.org:8080" # Applies to Portage and Links
root #
export https_proxy="http://username:password@proxy.gentoo.org:8080" # Only applies for Links
Start links using the following parameters for proxy support:
user $
links -http-proxy ${http_proxy} -https-proxy ${https_proxy}
To define an FTP proxy for Portage and/or links:
root #
export ftp_proxy="ftp://proxy.gentoo.org:8080" # Applies to Portage and Links
Start links using the following parameter for a FTP proxy:
user $
links -ftp-proxy ${ftp_proxy}
To define an RSYNC proxy for Portage:
root #
export RSYNC_PROXY="proxy.gentoo.org:8080" # Applies to Portage; Links does not support a rsync proxy
Using pppoe-setup for ADSL
If PPPoE is required for Internet access, the Gentoo boot media includes the pppoe-setup script to simplify ppp configuration.
During setup, pppoe-setup will ask for:
- The name of the Ethernet interface connected to the ADSL modem.
- The PPPoE username and password.
- DNS server IPs.
- Whether or not a firewall is needed.
root #
pppoe-setup
root #
pppoe-start
In the event of failure, credentials in /etc/ppp/pap-secrets or /etc/ppp/chap-secrets should be verified. If credentials are correct, PPPoE Ethernet interface selection should be checked.
Using PPTP
If PPTP support is needed, pptpclient can be used, but requires configuration prior to usage.
Edit /etc/ppp/pap-secrets or /etc/ppp/chap-secrets so it contains the correct username/password combination:
root #
nano /etc/ppp/chap-secrets
Then adjust /etc/ppp/options.pptp if necessary:
root #
nano /etc/ppp/options.pptp
Once configuration is complete, run pptp (along with the options that couldn't be set in options.pptp) to connect the server:
root #
pptp <server ipv4 address>
Configuring WEP
Do not use WEP unless it is the only option. WEP provides essentially no security over an open network.
The iw command is only available on the following architectures: amd64, x86, arm, arm64, ppc, ppc64, and riscv.
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
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
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.
Using net-setup
In cases where automatic network configuration is unsuccessful, the Gentoo boot media provides scripts to aid in network configuration. net-setup can be used to configure wireless network information and static IPs.
root #
net-setup enp1s0
net-setup will ask some questions about the network environment and will use that information to configure wpa_supplicant or static addressing.
Network status should be tested after any configuration steps are taken. In the event that configuration scripts do not work, manual network configuration is required.
Internet and IP basics
If all of the above fails, the network must be configured manually. This is not particularly difficult, but should be done with consideration. This section serves to clarify terminology and introduce users to basic networking concepts pertaining to manually configuring an Internet connection.
Some CPE (Carrier Provided Equipment) combines the functions of a router, access point, modem, DHCP server, and DNS server into one unit. It's important to differentiate the functions of a device from the physical appliance.
Interfaces and addresses
Network interfaces are logical representations of network devices. An interface needs an address to communicate with other devices on the network. While only a single address is required, multiple addresses can be assigned to a single interface. This is especially useful for dual stack (IPv4 + IPv6) configurations.
For consistency, this primer will assume the interface enp1s0 will be using the address 192.168.0.2.
IP addresses can be set arbitrarily. As a result, it's possible for multiple devices to use the same IP address, resulting in an address conflict. Address conflicts should be avoided by using DHCP or SLAAC.
IPv6 typically uses StateLess Address AutoConfiguration (SLAAC) for address configuration. In most cases, manually setting IPv6 addresses is a bad practice. If a specific address suffix is preferred, interface identification tokens can be used.
Networks and CIDR
Once an address is chosen, how does a device know how to talk to other devices?
IP addresses are associated with networks. IP networks are contiguous logical ranges of addresses.
Classless Inter-Domain Routing or CIDR notation is used to distinguish network sizes.
- The CIDR value, often notated starting with a /, represents the size of the network.
- The formula 2 ^ (32 - CIDR) can be used to calculate network size.
- Once network size is calculated, usable node count must be reduced by 2.
- The first IP in a network is the Network address, and the last is typically the Broadcast address. These addresses are special and cannot be used by normal hosts.
The most common CIDR values are /24, and /32, representing 254 nodes and a single node respectively.
A CIDR of /24 is the de-facto default network size. This corresponds to a subnet mask of 255.255.255.0, where the last 8 bits are reserved for IP addresses for nodes on a network.
The notation: 192.168.0.2/24 can be interpreted as:
- The address 192.168.0.2
- On the network 192.168.0.0
- With a size of 254 (2 ^ (32 - 24) - 2)
- Usable IPs are in the range 192.168.0.1 - 192.168.0.254
- With a broadcast address of 192.168.0.255
- In most cases, the last address on a network is used as the broadcast address, but this can be changed.
Using this configuration, a device should be able to communicate with any host on the same network (192.168.0.0).
The Internet
Once a device is on a network, how does it know how to talk to devices on the Internet?
To communicate with devices outside of local networks, routing must be used. A router is simply a network device that forwards traffic for other devices. The term default route or gateway typically refers to whatever device on the current network is used for external network access.
It's a standard practice to make the gateway the first or last IP on a network.
If an Internet-connected router is available at 192.168.0.1, it can be used as the default route, granting Internet access.
To summarize:
- Interfaces must be configured with an address and network information, such as the CIDR value.
- Local network access is used to access a router on the same network.
- The default route is configured, so traffic destined for external networks is forwarded to the gateway, providing Internet access.
The Domain Name System
Remembering IPs is hard. The Domain Name System was created to allow mapping between Domain Names and IP addresses.
Linux systems use /etc/resolv.conf to define nameservers to be used for DNS resolution.
Many routers can also function as a DNS server, and using a local DNS server can augment privacy and speed up queries through caching.
Many ISPs run a DNS server that is generally advertised to the gateway over DHCP. Using a local DNS server tends to improve query latency, but most public DNS servers will return the same results, so server usage is largely based on preference.
Manual network configuration
Interface address configuration
When manually configuring IP addresses, the local network topology must be considered. IP addresses can be set arbitrarily; conflicts may cause network disruption.
To configure enp1s0 with the address 192.168.0.2 and CIDR /24:
root #
ip address add 192.168.0.2/24 dev enp1s0
The start of this command can be shortened to ip a.
Default route configuration
Configuring address and network information for an interface will configure link routes, allowing communication with that network segment:
root #
ip route
192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2
This command can be shortened to ip r.
The default route can be set to 192.168.0.1 with:
root #
ip route add default via 192.168.0.1
DNS configuration
Nameserver info is typically acquired using DHCP, but can be set manually by adding nameserver
entries to /etc/resolv.conf.
If dhcpcd is running, changes to /etc/resolv.conf will not persist. Status can be checked with
ps x | grep dhcpcd
.nano is included in Gentoo boot media and can be used to edit /etc/resolv.conf with:
root #
nano /etc/resolv.conf
Lines containing the keyword nameserver
followed by a DNS server IP address are queried in order of definition:
nameserver 9.9.9.9
nameserver 149.112.112.112
nameserver 1.1.1.1
nameserver 1.0.0.1
DNS status can be checked by pinging a domain name:
root #
ping -c 3 gentoo.org
Once connectivity has been verified, 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 block devices, partitions, and Linux filesystems. Once the ins and outs of disks are understood, partitions and filesystems can be established for installation.
To begin, let's look at block devices. SCSI and Serial ATA drives are both labeled under device handles such as: /dev/sda, /dev/sdb, /dev/sdc, etc. On more modern machines, PCI Express based NVMe solid state disks have device handles such as /dev/nvme0n1, /dev/nvme0n2, etc.
The following table will help readers determine where to find a certain type of block device on the system:
Type of device | Default device handle | Editorial notes and considerations |
---|---|---|
IDE, SATA, SAS, SCSI, or USB flash | /dev/sda | Found on hardware from roughly 2007 until the present, this device handle is perhaps the most commonly used in Linux. These types of devices can be connected via the SATA bus, SCSI, USB bus as block storage. As example, the first partition on the first SATA device is called /dev/sda1. |
NVM Express (NVMe) | /dev/nvme0n1 | The latest in solid state technology, NVMe drives are connected to the PCI Express bus and have the fastest transfer block speeds on the market. Systems from around 2014 and newer may have support for NVMe hardware. The first partition on the first NVMe device is called /dev/nvme0n1p1. |
MMC, eMMC, and SD | /dev/mmcblk0 | embedded MMC devices, SD cards, and other types of memory cards can be useful for data storage. That said, many systems may not permit booting from these types of devices. It is suggested to not use these devices for active Linux installations; rather consider using them to transfer files, which is their typical design intention. Alternatively this storage type could be useful for short-term file backups or snapshots. |
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 SATA, SCSI, or something else. The program can simply address the storage on the disk as a bunch of contiguous, randomly-accessible 4096-byte (4K) blocks.
Partitions and slices
Although it is theoretically possible to use a full disk to house the Linux system, this is almost never done in practice. Instead, full disk block devices are split up in smaller, more manageable block devices. On most systems, these are called partitions. Other architectures use a similar technique, called slices.
Designing a partition scheme
How many partitions and how big?
The design of disk partition layout is highly dependent on the demands of the system and the file system(s) applied to the device. If there are lots of users, then it is advised to have /home on a separate partition which will increase security and make backups and other types of maintenance easier. If Gentoo is being installed to perform as a mail server, then /var should be a separate partition as all mails are stored inside the /var directory. Game servers may have a separate /opt partition since most gaming server software is installed therein. The reason for these recommendations is similar to the /home directory: security, backups, and maintenance.
In most situations on Gentoo, /usr and /var should be kept relatively large in size. /usr hosts the majority of applications available on the system and the Linux kernel sources (under /usr/src). By default, /var hosts the Gentoo ebuild repository (located at /var/db/repos/gentoo) which, depending on the file system, generally consumes around 650 MiB of disk space. This space estimate excludes the /var/cache/distfiles and /var/cache/binpkgs directories, which will gradually fill with source files and (optionally) binary packages respectively as they are added to the system.
How many partitions and how big very much depends on considering the trade-offs and choosing the best option for the circumstance. 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 realized 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 certain disadvantages as well:
- If not configured properly, the system might have lots of free space on one partition and little free space on another.
- A separate partition for /usr/ may require the administrator to boot with an initramfs to mount the partition before other boot scripts start. Since the generation and maintenance of an initramfs is beyond the scope of this handbook, we recommend that newcomers do not use a separate partition for /usr/.
- There is also a 15-partition limit for SCSI and SATA unless the disk uses GPT labels.
Installations that intend to use systemd as the service and init system must have the /usr directory available at boot, either as part of the root filesystem or mounted via an initramfs.
What about swap space?
RAM size | Suspend support? | Hibernation support? |
---|---|---|
2 GB or less | 2 * RAM | 3 * RAM |
2 to 8 GB | RAM amount | 2 * RAM |
8 to 64 GB | 8 GB minimum, 16 maximum | 1.5 * RAM |
64 GB or greater | 8 GB minimum | Hibernation not recommended! Hibernation is not recommended for systems with very large amounts of memory. While possible, the entire contents of memory must be written to disk in order to successfully hibernate. Writing tens of gigabytes (or worse!) out to disk can can take a considerable amount of time, especially when rotational disks are used. It is best to suspend in this scenario. |
There is no perfect value for swap space size. The purpose of the space is to provide disk storage to the kernel when internal dynamic 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), which will free memory in RAM for the current task. Of course, if the pages swapped to disk are suddenly needed, they will need to be put back in memory (page-in) which will take considerably longer than reading from RAM (as disks are very slow compared to internal memory).
When a system is not going to run memory intensive applications or has lots of RAM available, then it probably does not need much swap space. However do note in case of hibernation that swap space is used to store the entire contents of memory (likely on desktop and laptop systems rather than on server systems). If the system requires support for hibernation, then swap space larger than or equal to the amount of memory is necessary.
As a general rule for RAM amounts less than 4 GB, the swap space size is recommended to be twice the internal memory (RAM). For systems with multiple hard disks, it is wise to create one swap partition on each disk so that they can be utilized for parallel read/write operations. The faster a disk can swap, the faster the system will run when data in swap space must be accessed. When choosing between rotational and solid state disks, it is better for performance to put swap on the solid state hardware.
It is worth noting that swap files can be used as an alternative to swap partitions; this is mostly helpful for systems with very limited disk space.
Using fdisk on HPPA
Use fdisk to create the partitions needed:
root #
fdisk /dev/sda
HPPA machines use the PC standard DOS partition tables. To create a new DOS partition table press the o key.
Command (m for help):
o
Building a new DOS disklabel.
PALO (the HPPA bootloader) needs a special partition to work. A partition of at least 16 MB at the beginning of the disk needs to be created for it. The partition type must be of type f0 (Linux/PA-RISC boot). It is also possible to use the PALO partition as /boot.
If this is forgotten and the installation continues without a special PALO partition, then eventually the system will fail to restart. Also, if the disk is larger than 2 GB, make sure that the boot partition is in the first 2 GB of the disk. PALO is unable to read a kernel after the 2 GB limit.
/dev/sda2 /boot ext2 noauto,noatime 1 1
/dev/sda3 none swap sw 0 0
/dev/sda4 / ext4 noatime 0 0
In fdisk, such a partition layout looks like so:
Command (m for help):
p
Disk /dev/sda: 4294 MB, 4294816768 bytes 133 heads, 62 sectors/track, 1017 cylinders Units = cylinders of 8246 * 512 = 4221952 bytes Device Boot Start End Blocks Id System /dev/sda1 1 8 32953 f0 Linux/PA-RISC boot /dev/sda2 9 20 49476 83 Linux /dev/sda3 21 70 206150 82 Linux swap /dev/sda4 71 1017 3904481 83 Linux
Creating file systems
When using SSD or NVMe drive, it is wise to check for firmware upgrades. Some Intel SSDs in particular (600p and 6000p) require a firmware upgrade for possible data corruption induced by XFS I/O usage patterns. The problem is at the firmware level and not any fault of the XFS filesystem. The smartctl utility can help check the device model and firmware version.
Introduction
Now that the partitions have been 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
Linux supports several dozen filesystems, although many of them are only wise to deploy for specific purposes. Only certain filesystems may be found stable on the hppa architecture - it is advised to read up on the filesystems and their support state before selecting a more experimental one for important partitions. XFS is the recommended all-purpose, all-platform filesystem. The below is a non-exhaustive list:
- XFS
- Filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. It has been continuously upgraded to include modern features. The only downside is that XFS partitions cannot yet be shrunk, although this is being worked on. XFS notably supports reflinks and Copy on Write (CoW) which is particularly helpful on Gentoo systems because of the amount of compiles users complete. XFS is the recommended modern all-purpose all-platform filesystem. Requires a partition to be at least 300MB.
- ext4
- Ext4 is a reliable, all-purpose all-platform filesystem, although it lacks modern features like reflinks.
- VFAT
- Also known as FAT32, is supported by Linux but does not support standard UNIX permission settings. It is mostly used for interoperability/interchange with other operating systems (Microsoft Windows or Apple's macOS) but is also a necessity for some system bootloader firmware (like UEFI). Users of UEFI systems will need an EFI System Partition formatted with VFAT in order to boot.
- btrfs
- Newer generation filesystem. Provides advanced features like snapshotting, self-healing through checksums, transparent compression, subvolumes, and integrated RAID. Kernels prior to 5.4.y are not guaranteed to be safe to use with btrfs in production because fixes for serious issues are only present in the more recent releases of the LTS kernel branches. RAID 5/6 and quota groups unsafe on all versions of btrfs.
- F2FS
- The Flash-Friendly File System was originally created by Samsung for the use with NAND flash memory. It is a decent choice when installing Gentoo to microSD cards, USB drives, or other flash-based storage devices.
- NTFS
- This "New Technology" filesystem is the flagship filesystem of Microsoft Windows since Windows NT 3.1. Similarly to VFAT, it does not store UNIX permission settings or extended attributes necessary for BSD or Linux to function properly, therefore it should not be used as a root filesystem for most cases. It should only be used for interoperability or data interchange with Microsoft Windows systems (note the emphasis on only).
- ZFS Importante: ZFS pools can only be created on the admincd and LiveGUI ISOs, for further information, refer to ZFS/rootfs
- Next generation file system created by Matthew Ahrens and Jeff Bonwick. It was designed around a few key ideas: Administration of storage should be simple, redundancy should be handled by the filesystem, file systems should never be taken offline for repair, automated simulations of worst case scenarios before shipping code is important, and data integrity is paramount.
More extensive information on filesystems can be found in the community maintained Filesystem article.
Applying a filesystem to a partition
Please make sure to emerge the relevant user space utilities package for the chosen filesystem before rebooting. There will be a reminder to do so near the end of the installation process.
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 | Within the live environment? | Package |
---|---|---|---|
XFS | mkfs.xfs | Yes | sys-fs/xfsprogs |
ext4 | mkfs.ext4 | Yes | sys-fs/e2fsprogs |
VFAT (FAT32, ...) | mkfs.vfat | Yes | sys-fs/dosfstools |
btrfs | mkfs.btrfs | Yes | sys-fs/btrfs-progs |
F2FS | mkfs.f2fs | Yes | sys-fs/f2fs-tools |
NTFS | mkfs.ntfs | Yes | sys-fs/ntfs3g |
ZFS | zpool create ... | No | sys-fs/zfs |
The handbook recommends new partitions as part of the installation process, but it is important to note running any mkfs command will erase any data contained within the partition. When necessary, ensure any data that exists within is appropriately backed up before creating a new filesystem.
For instance, to have the root partition (/dev/sda4) as xfs as used in the example partition structure, the following commands would be used:
root #
mkfs.xfs /dev/sda4
Legacy BIOS boot partition filesystem
Systems booting via legacy BIOS with a MBR/DOS disklabel can use any filesystem format supported by the bootloader.
For example, to format with XFS:
root #
mkfs.xfs /dev/sda2
Small ext4 partitions
When using the ext4 filesystem on a small partition (less than 8 GiB), the filesystem should be created with the proper options to reserve enough inodes. This can specified using the -T small
option:
root #
mkfs.ext4 -T small /dev/<device>
Doing so will quadruple the number of inodes for a given filesystem, since its "bytes-per-inode" reduces from one every 16kB to one every 4kB.
Activating the swap partition
mkswap is the command that is used to initialize swap partitions:
root #
mkswap /dev/sda3
To activate the swap partition, use swapon:
root #
swapon /dev/sda3
This 'activation' step is only necessary because the swap partition is newly created within the live environment. Once the system has been rebooted, as long as the swap partition is properly defined within fstab or other mount mechanism, swap space will activate automatically.
Mounting the root partition
Installations which were previously started, but did not finish the installation process can resume the installation from this point in the handbook. Use this link as the permalink: Resumed installations start here.
Certain live environments may be missing the suggested mount point for Gentoo's root partition (/mnt/gentoo), or mount points for additional partitions created in the partitioning section:
root #
mkdir --parents /mnt/gentoo
Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command.
With mount points created, it is time to make the partitions accessible via mount command.
Mount the root partition:
root #
mount /dev/sda4 /mnt/gentoo
Continue mounting additional (custom) partitions as necessary using the mount command.
If /tmp/ needs to reside on a separate partition, be sure to change its permissions after mounting:
root #
chmod 1777 /mnt/gentoo/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 the Gentoo stage file must be extracted.
Choosing a stage file
On supported architectures, it is recommended for users targeting a desktop (graphical) operating system environment to use a stage file with the term
desktop
within the name. These files include packages such as sys-devel/llvm and dev-lang/rust-bin and USE flag tuning which will greatly improve install time.The stage file acts as the seed of a Gentoo install. Stage files are generated with Catalyst by the Release Engineering Team. Stage files are based on specific profiles, and contain an almost-complete system.
When choosing a stage file, it's important to pick one with profile targets corresponding to the desired system type.
While it's possible to make major profile changes after an installation has been established, switching requires substantial effort and consideration, and is outside the scope of this installation manual. Switching init systems is difficult, but switching from
no-multilib
to multilib
requires extensive Gentoo and low-level toolchain knowledge.Most users should not need to use the 'advanced' tarballs options; they are for atypical or advanced software or hardware configurations.
OpenRC
OpenRC is a dependency-based init system (responsible for starting up system services once the kernel has booted) that maintains compatibility with the system provided init program, normally located in /sbin/init. It is Gentoo's native and original init system, but is also deployed by a few other Linux distributions and BSD systems.
OpenRC does not function as a replacement for the /sbin/init file by default and is 100% compatible with Gentoo init scripts. This means a solution can be found to run the dozens of daemons in the Gentoo ebuild repository.
systemd
systemd is a modern SysV-style init and rc replacement for Linux systems. It is used as the primary init system by a majority of Linux distributions. systemd is fully supported in Gentoo and works for its intended purpose. If something seems lacking in the Handbook for a systemd install path, review the systemd article before asking for support.
Multilib (32 and 64-bit)
Not every architecture has a multilib option. Many only run with native code. Multilib is most commonly applied to amd64.
The multilib profile uses 64-bit libraries when possible, and only falls back to the 32-bit versions when strictly 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.
Using
multilib
targets makes it easier to switch profiles later, compared to no-multilib
No-multilib (pure 64-bit)
Readers who are just starting out with Gentoo should not choose a no-multilib tarball unless it is absolutely necessary. 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.Selecting a no-multilib tarball to be the base of the system provides a complete 64-bit operating system environment - free of 32-bit software. This effectively renders the ability to switch to multilib
profiles burdensome, although still technically possible.
Downloading the stage file
Before downloading the stage file, the current directory should be set to the location of the mount used for the install:
root #
cd /mnt/gentoo
Setting the date and time
Stage archives are generally obtained using HTTPS which requires relatively accurate system time. Clock skew can prevent downloads from working, and can cause unpredictable errors if the system time is adjusted by any considerable amount after installation.
The current date and time can be verified with date:
root #
date
Mon Oct 3 13:16:22 PDT 2021
If the displayed date/time is more than few minutes off, it should be updated using one of the following methods.
Automatic
Using NTP to correct clock skew is typically easier and more reliable than manually setting the system clock.
chronyd, part of net-misc/chrony can be used to update the system clock to UTC with:
root #
chronyd -q
Systems without a functioning Real-Time Clock (RTC) must sync the system clock at every system start, and on regular intervals thereafter. This is also beneficial for systems with a RTC, as the battery could fail, and clock skew can accumulate.
Standard NTP traffic not authenticated, it is important to verify time data obtained from the network.
Manual
When NTP access is unavailable, date can be used to manually set the system clock.
UTC time is recommended for all Linux systems. Later, a system timezone is defined, which changes the offset when the date is displayed.
The following argument format is used to set the time: MMDDhhmmYYYY
syntax (Month, Day, hour, minute and Year).
For instance, to set the date to October 3rd, 13:16 in the year 2021, issue:
root #
date 100313162021
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 to copy the link to the clipboard, then paste the link to the wget utility on the command-line to download the stage file:
root #
wget <PASTED_STAGE_FILE_URL>
Command-line browsers
More traditional readers or 'old timer' Gentoo users, working exclusively from command-line may prefer using links (www-client/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 (www-client/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/hppa/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 file. 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 file section.
Verifying and validating
Most stages are now explicitly suffixed with the init system type (openrc or systemd), although some architectures may still be missing these for now.
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 integrity of the file(s) they just downloaded. The extra files are available under the root of the mirrors directory. Browse to the appropriate location for the hardware architecture and the system profile and download the associated .CONTENTS.gz, .DIGESTS, and .sha256 files.
root #
wget https://distfiles.gentoo.org/releases/
- .CONTENTS.gz - A compressed file that contains a list of all files inside the stage file.
- .DIGESTS - Contains checksums of the stage file in using several cryptographic hash algorithms.
- .sha256 - Contains a PGP signed SHA256 checksum of the stage file. This file may not be available for download for all stage files.
Cryptographic tools and utilities such as openssl, sha256sum, or sha512sum can be used to compare the output with the checksums provided by the .DIGESTS file.
To verify the SHA512 checksum with openssl:
root #
openssl dgst -r -sha512 stage3-hppa-<release>-<init>.tar.xz
dgst
instructs the openssl command to use the Message Digest sub-command, -r
prints the digest output in coreutils format, and -sha512
selects the SHA512 digest.
To verify the BLAKE2B512 checksum with openssl:
root #
openssl dgst -r -blake2b512 stage3-hppa-<release>-<init>.tar.xz
Compare the output(s) of the checksum commands with the hash and filename paired values contained within the .DIGESTS file. The paired values need to match the output of the checksum commands, otherwise the downloaded file is corrupt, and should be discarded and re-downloaded.
To verify the SHA256 hash from an associated .sha256 file using the sha256sum utility:
root #
sha256sum --check stage3-hppa-<release>-<init>.tar.xz.sha256
The --check
option instructs sha256sum to read a list of expected files and associated hashes, and then print an associated "OK" for each file that calculates correctly or a "FAILED" for files that do not.
Just like with the ISO file, the cryptographic signature of the tar.xz file can be verified using gpg to ensure no tampering has been performed on the tarball.
For official Gentoo live images, the sec-keys/openpgp-keys-gentoo-release package provides PGP signing keys for automated releases. The keys must first be imported into the user's session in order to be used for verification:
root #
gpg --import /usr/share/openpgp-keys/gentoo-release.asc
For all non-official live images which offer gpg and wget in the live environment, a bundle containing Gentoo keys can be fetched and imported:
root #
wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --import
Verify the signature of the tarball and, optionally, associated checksum files:
root #
gpg --verify stage3-hppa-<release>-<init>.tar.xz.asc
root #
gpg --verify stage3-hppa-<release>-<init>.tar.xz.DIGESTS
root #
gpg --verify stage3-hppa-<release>-<init>.tar.xz.sha256
If verification succeeds, "Good signature from" will be in the output of the previous command(s).
The fingerprints of the OpenPGP keys used for signing release media can be found on the release media signatures page.
Installing a stage file
Once the stage file has been downloaded and verified, it can be extracted using tar:
root #
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner -C /mnt/gentoo
Before extracting verify the options:
x
extract, instructs tar to extract the contents of the archive.p
preserve permissions.v
verbose output.f
file, provides tar with the name of the input archive.--xattrs-include='*.*'
Preserves extended attributes in all namespaces stored in the archive.--numeric-owner
Ensure that the user and group IDs of files being extracted from the tarball remain the same as Gentoo's release engineering team intended (even if adventurous users are not using official Gentoo live environments for the installation process).-C /mnt/gentoo
Extract files to the root partition regardless of the current directory.
Now that the stage file is unpacked, proceed with Configuring compile options.
Configuring compile options
Introduction
To optimize the system, it is possible to set variables which impact the behavior of Portage, Gentoo's officially supported package manager. All those variables can be set as environment variables (using export) but setting via export is not permanent.
Technically variables can be exported via the shell's profile or rc files, however that is not best practice for basic system administration.
Portage reads in the make.conf file when it runs, which will change runtime behavior depending on the values saved in the file. make.conf can be considered the primary configuration file for Portage, so treat its content carefully.
A commented listing of all possible variables can be found in /mnt/gentoo/usr/share/portage/config/make.conf.example. Additional documentation on make.conf can be found by running man 5 make.conf.
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 /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="value"
syntax. Several of those variables are discussed in the next section.
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 misbehave (crash, or even worse, malfunction).
The Handbook will not explain all possible optimization options. To understand them all, read the GNU Online Manual(s) or the gcc info page (info gcc). 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 stage file archive should be good enough. The following one is just an example:
# Compiler flags to set for all languages
COMMON_FLAGS="-march=2.0 -O2 -pipe"
# Use the same settings for both variables
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
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.
RUSTFLAGS
Many programs are now written in Rust which has its own way of optimising. By default Rust optimizes to level 3 on all release builds unless a project changes it so this should be left as is. A full optimization list (known as codegen) that can be passed to the rust compiler is available at https://doc.rust-lang.org/rustc/codegen-options/index.html.
The most useful optimization would be to tell Rust to compile for your CPU using the following example:
RUSTFLAGS="${RUSTFLAGS} -C target-cpu=native"
To get a list of supported CPUs in Rust run:
root #
rustc -C target-cpu=help
This will show what the default and also which CPU will be selected with native.
The above command only works on desktop stage3 tarballs or after emerging dev-lang/rust-bin or dev-lang/rust.
MAKEOPTS
The MAKEOPTS variable defines how many parallel compilations should occur when installing a package. As of Portage version 3.0.31[1], if left undefined, Portage's default behavior is to set the MAKEOPTS jobs value to the same number of threads returned by nproc.
Further, as of Portage 3.0.53[2], if left undefined, Portage's default behavior is to set the MAKEOPTS load-average value to the same number of threads returned by nproc.
A good choice is the smaller of: the number of threads the CPU has, or the total amount of system RAM divided by 2 GiB.
Using a large number of jobs can significantly impact memory consumption. A good recommendation is to have at least 2 GiB of RAM for every job specified (so, e.g.
-j6
requires at least 12 GiB). To avoid running out of memory, lower the number of jobs to fit the available memory.When using parallel emerges (
--jobs
), the effective number of jobs run can grow exponentially (up to make jobs multiplied by emerge jobs). This can be worked around by running a localhost-only distcc configuration that will limit the number of compiler instances per host.# If left undefined, Portage's default behavior is to:
# - set the MAKEOPTS jobs value to the same number of threads returned by `nproc`
# - set the MAKEOPTS load-average value slightly above the number of threads returned by `nproc`, due to it being a damped value
# Please replace '4' as appropriate for the system (min(RAM/2GB, threads), or leave it unset.
MAKEOPTS="-j4 -l5"
Search for MAKEOPTS in man 5 make.conf for more details.
Ready, set, go!
Update the /mnt/gentoo/etc/portage/make.conf file to match personal preference and save (nano users would press Ctrl+o to write the change and then Ctrl+x to quit).
References
Chrooting
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
If using Gentoo's install media, this step can be replaced with simply: arch-chroot /mnt/gentoo.
In a few moments, the Linux root will be changed towards the new location.
The filesystems that need to be made available are:
- /proc/ is a pseudo-filesystem. It looks like regular files, but is generated on-the-fly by the Linux kernel
- /sys/ 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 which contains all device. It is partially managed by the Linux device manager (usually udev)
- /run/ is a temporary file system used for files generated at runtime, such as PID files or locks
The /proc/ location will be mounted on /mnt/gentoo/proc/ whereas the others 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
root #
mount --bind /run /mnt/gentoo/run
root #
mount --make-slave /mnt/gentoo/run
The
--make-rslave
operations are needed for systemd support later in the installation.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 /run/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:
- The root location is changed from / (on the installation medium) to /mnt/gentoo/ (on the partitions) using chroot or arch-chroot, if available.
- Some settings (those in /etc/profile) are reloaded in memory using the source command
- 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.
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 re-partition 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.
Preparing for a bootloader
Now that the new environment has been entered, it is necessary to prepare the new environment for the bootloader. It will be important to have the correct partition mounted when it is time to install the bootloader.
DOS/Legacy BIOS systems
For DOS/Legacy BIOS systems, the bootloader will be installed into the /boot directory, therefore mount as follows:
root #
mount /dev/sda2 /boot
Configuring Portage
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:
root #
emerge-webrsync
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: Selecting mirrors
In order to download source code quickly it is recommended to select a fast, geographically close 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 multiple mirrors) close to the system's physical location (as those are most frequently the fastest ones).
A tool called mirrorselect provides a pretty text interface to more quickly query and select suitable mirrors. Just navigate to the mirrors of choice and press Spacebar to select one or more mirrors.
root #
emerge --ask --verbose --oneshot app-portage/mirrorselect
root #
mirrorselect -i -o >> /etc/portage/make.conf
Alternatively, a list of active mirrors are available online.
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 latest 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, such as certain frame buffers 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, Portage may output informational 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 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 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 news reader is available through its manual page:
root #
man news.eselect
Choosing the right profile
Desktop profiles are not exclusively for desktop environments. They are also suitable for minimal window managers like i3 or sway.
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.
To see what profile the system is currently using, run eselect using the profile
module:
root #
eselect profile list
Available profile symlink targets: [1] default/linux/hppa/23.0 * [2] default/linux/hppa/23.0/desktop [3] default/linux/hppa/23.0/desktop/gnome [4] default/linux/hppa/23.0/desktop/kde
The output of the command is just an example and evolves over time.
To use systemd, select a profile which has "systemd" in the name and vice versa, if not
There are also desktop sub-profiles available for some architectures which include software packages commonly necessary for a desktop experience.
Profile upgrades are not to be taken lightly. When selecting the initial profile, use the profile corresponding to the same version as the one initially used by the stage file (e.g. 23.0). Each new profile version is announced through a news item containing migration instructions; be sure to carefully follow the instructions before switching to a newer profile.
After viewing the available profiles for the hppa architecture, users can select a different profile for the system:
root #
eselect profile set 2
The
developer
sub-profile is specifically for Gentoo Linux development and is not meant to be used by casual users.Optional: Adding a binary package host
Since December 2023, Gentoo's Release Engineering team has offered an official binary package host (colloquially shorted to just "binhost") for use by the general community to retrieve and install binary packages (binpkgs).[1]
Adding a binary package host allows Portage to install cryptographically signed, compiled packages. In many cases, adding a binary package host will greatly decrease the mean time to package installation and adds much benefit when running Gentoo on older, slower, or low power systems.
Repository configuration
The repository configuration for a binhost is found in Portage's /etc/portage/binrepos.conf/ directory, which functions similarly to the configuration mentioned in the Gentoo ebuild repository section.
When defining a binary host, there are two important aspects to consider:
- The architecture and profile targets within the
sync-uri
value do matter and should align to the respective computer architecture (hppa in this case) and system profile selected in the Choosing the right profile section. - Selecting a fast, geographically close mirror will generally shorten retrieval time. Review the mirrorselect tool mentioned in the Optional: Selecting mirrors section or review the online list of mirrors where URL values can be discovered.
[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/
Installing binary packages
Portage will compile packages from code source by default. It can be instructed to use binary packages in the following ways:
- The
--getbinpkg
option can be passed when invoking the emerge command. This method of for binary package installation is useful to install only a particular binary package. - Changing the system's default via Portage's FEATURES variable, which is exposed through the /etc/portage/make.conf file. Applying this configuration change will cause Portage to query the binary package host for the package(s) to be requested and fall back to compiling locally when no results are found.
For example, to have Portage always install available binary packages:
# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"
Please also run getuto for Portage to set up the necessary keyring for verification:
root #
getuto
Additional Portage features will be discussed in the the next chapter of the handbook.
Optional: 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 for which a package should be compiled. 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 -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 system profiles, which will not be covered in depth during the installation process. 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 ..."
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.
root #
less /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:
root #
nano /etc/portage/make.conf
USE="-gtk -gnome qt5 kde dvd alsa cdr"
When a USE value is defined in /etc/portage/make.conf it is added to the system's USE flag list. USE flags can be globally removed by adding a - minus sign in front of the value in the the list. For example, to disable support for X graphical environments, -X
can be set:
USE="-X acl alsa"
Although possible, setting
-*
(which will disable all USE values except the ones specified in make.conf) is strongly discouraged and unwise. Ebuild developers choose certain default USE flag values in ebuilds in order to prevent conflicts, enhance security, and avoid errors, and other reasons. Disabling all USE flags will negate default behavior and may cause major issues.CPU_FLAGS_*
Some architectures (including AMD64/X86, ARM, PPC) have a USE_EXPAND variable called CPU_FLAGS_<ARCH>, where <ARCH> is replaced with the relevant system architecture name.
Do not be confused! AMD64 and X86 systems share some common architecture, so the proper variable name for AMD64 systems is CPU_FLAGS_X86.
This is used to configure the build to compile in specific assembly code or other intrinsics, usually hand-written or otherwise extra,
and is not the same as asking the compiler to output optimized code for a certain CPU feature (e.g. -march=
).
Users should set this variable in addition to configuring their COMMON_FLAGS as desired.
A few steps are needed to set this up:
root #
emerge --ask --oneshot app-portage/cpuid2cpuflags
Inspect the output manually if curious:
root #
cpuid2cpuflags
Then copy the output into package.use:
root #
echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags
VIDEO_CARDS_*
Below is an example of a properly set package.use for VIDEO_CARDS_*. Substitute the name of the driver(s) to be used.
*/* video_cards_amdgpu video_cards_radeonsi
Details for various GPU(s) can be found at the AMDGPU, Intel, Nouveau (Open Source), or NVIDIA (Proprietary) articles.
Optional: Configure the ACCEPT_LICENSE variable
Starting with Gentoo Linux Enhancement Proposal 23 (GLEP 23), a mechanism was created to allow system administrators the ability to "regulate the software they install with regards to licenses... Some want a system free of any software that is not OSI-approved; others are simply curious as to what licenses they are implicitly accepting."[2] With a motivation to have more granular control over the type of software running on a Gentoo system, the ACCEPT_LICENSE variable was born.
During the installation process, Portage considers the value(s) set within the ACCEPT_LICENSE variable to determine if the requested package(s) meet the sysadmin's determination of an acceptable license. Here in lies a problem: the Gentoo ebuild repository is filled with thousands of ebuilds which results in hundreds of distinct software licenses... Does this implicate sysadmin into individually approving each and every new software license? Thankfully no; GLEP 23 also outlines a solution to this problem, a concept called license groups.
For the convenience of system administration, legally-similar software licenses have been bundled together - each according to its like-kind. License group definitions are available for viewing and are managed by the Gentoo Licenses project. While an individual license is not, license groups are syntactically preceded with an @
symbol, enabling them to be easily distinguished in the ACCEPT_LICENSE variable.
Some common license groups include:
Name | Description |
---|---|
@GPL-COMPATIBLE |
GPL compatible licenses approved by the Free Software Foundation [a_license 1] |
@FSF-APPROVED |
Free software licenses approved by the FSF (includes @GPL-COMPATIBLE )
|
@OSI-APPROVED |
Licenses approved by the Open Source Initiative [a_license 2] |
@MISC-FREE |
Misc licenses that are probably free software, i.e. follow the Free Software Definition [a_license 3] but are not approved by either FSF or OSI |
@FREE-SOFTWARE |
Combines @FSF-APPROVED , @OSI-APPROVED , and @MISC-FREE .
|
@FSF-APPROVED-OTHER |
FSF-approved licenses for "free documentation" and "works of practical use besides software and documentation" (including fonts) |
@MISC-FREE-DOCS |
Misc licenses for free documents and other works (including fonts) that follow the free definition [a_license 4] but are NOT listed in @FSF-APPROVED-OTHER .
|
@FREE-DOCUMENTS |
Combines @FSF-APPROVED-OTHER and @MISC-FREE-DOCS .
|
@FREE |
Metaset of all licenses with the freedom to use, share, modify and share modifications. Combines @FREE-SOFTWARE and @FREE-DOCUMENTS .
|
@BINARY-REDISTRIBUTABLE |
Licenses that at least permit free redistribution of the software in binary form. Includes @FREE .
|
@EULA |
License agreements that try to take away your rights. These are more restrictive than "all-rights-reserved" or require explicit approval |
Currently set system wide acceptable license values can be viewed via:
user $
portageq envvar ACCEPT_LICENSE
@FREE
As visible in the output, the default value is to only allow software which has been grouped into the @FREE
category to be installed.
Specific licenses or licenses groups for a system can be defined in the following locations:
- System wide within the selected profile - this sets the default value.
- System wide within the /etc/portage/make.conf file. System administrators override the profile's default value within this file.
- Per-package within a /etc/portage/package.license file.
- Per-package within a /etc/portage/package.license/ directory of files.
The system wide license default in the profile is overridden within the /etc/portage/make.conf:
# Overrides the profile's ACCEPT_LICENSE default value
ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"
Optionally system administrators can also define accepted licenses per-package as shown in the following directory of files example. Note that the package.license directory will need created if it does not already exist:
root #
mkdir /etc/portage/package.license
Software license details for an individual Gentoo package are stored within the LICENSE variable of the associated ebuild. One package may have one or many software licenses, therefore it be necessary to specify multiple acceptable licenses for a single package.
app-arch/unrar unRAR
sys-kernel/linux-firmware linux-fw-redistributable
sys-firmware/intel-microcode intel-ucode
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. It is recommended to not solely rely on a ebuild developer's interpretation of a software package's license; but check the package itself in depth, including all files that have been installed to the system.
Optional: Updating the @world set
Updating the system's @world set is optional and will be unlikely to perform functional changes unless one or more of the following optional steps have been performed:
- A profile target different from the stage file has been selected.
- Additional USE flags have been set for installed packages.
Readers who are performing an 'install Gentoo speed run' may safely skip @world set updates until after their system has rebooted into the new Gentoo environment.
Readers who are performing a slow run can have Portage perform updates for package, profile, and/or USE flag changes at the present time:
root #
emerge --ask --verbose --update --deep --changed-use @world
Readers who added a binary host above can add --getbinpkg (or -g) in order to fetch packages from the binary host instead of compiling them:
root #
emerge --ask --verbose --update --deep --newuse --getbinpkg @world
Removing obsolete packages
It is important to always depclean after system upgrades to remove obsolete packages. Review the output carefully with emerge --depclean --pretend to see if any of the to-be-cleaned packages should be kept if personally using them. To keep a package which would otherwise be depcleaned, use emerge --noreplace foo.
root #
emerge --ask --pretend --depclean
If happy, then proceed with a real depclean:
root #
emerge --ask --depclean
If a desktop environment profile target has been selected from a non-desktop stage file, the @world update 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. E.g.:
- Selecting
default/linux/amd64/23.0
will likely require fewer packages to be updated, whereas - Selecting
default/linux/amd64/23.0/desktop/gnome/systemd
will likely require more packages to be installed since the profile target has a larger @system and @profile sets: dependencies supporting the GNOME desktop environment.
Timezone
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.
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.
Select the timezone for the system. Look for the available timezones in /usr/share/zoneinfo/:
root #
ls -l /usr/share/zoneinfo
total 352 drwxr-xr-x 2 root root 1120 Jan 7 17:41 Africa drwxr-xr-x 6 root root 2960 Jan 7 17:41 America drwxr-xr-x 2 root root 280 Jan 7 17:41 Antarctica drwxr-xr-x 2 root root 60 Jan 7 17:41 Arctic drwxr-xr-x 2 root root 2020 Jan 7 17:41 Asia drwxr-xr-x 2 root root 280 Jan 7 17:41 Atlantic drwxr-xr-x 2 root root 500 Jan 7 17:41 Australia drwxr-xr-x 2 root root 120 Jan 7 17:41 Brazil -rw-r--r-- 1 root root 2094 Dec 3 17:19 CET -rw-r--r-- 1 root root 2310 Dec 3 17:19 CST6CDT drwxr-xr-x 2 root root 200 Jan 7 17:41 Canada drwxr-xr-x 2 root root 80 Jan 7 17:41 Chile -rw-r--r-- 1 root root 2416 Dec 3 17:19 Cuba -rw-r--r-- 1 root root 1908 Dec 3 17:19 EET -rw-r--r-- 1 root root 114 Dec 3 17:19 EST -rw-r--r-- 1 root root 2310 Dec 3 17:19 EST5EDT -rw-r--r-- 1 root root 2399 Dec 3 17:19 Egypt -rw-r--r-- 1 root root 3492 Dec 3 17:19 Eire drwxr-xr-x 2 root root 740 Jan 7 17:41 Etc drwxr-xr-x 2 root root 1320 Jan 7 17:41 Europe ...
root #
ls -l /usr/share/zoneinfo/Europe/
total 256 -rw-r--r-- 1 root root 2933 Dec 3 17:19 Amsterdam -rw-r--r-- 1 root root 1742 Dec 3 17:19 Andorra -rw-r--r-- 1 root root 1151 Dec 3 17:19 Astrakhan -rw-r--r-- 1 root root 2262 Dec 3 17:19 Athens -rw-r--r-- 1 root root 3664 Dec 3 17:19 Belfast -rw-r--r-- 1 root root 1920 Dec 3 17:19 Belgrade -rw-r--r-- 1 root root 2298 Dec 3 17:19 Berlin -rw-r--r-- 1 root root 2301 Dec 3 17:19 Bratislava -rw-r--r-- 1 root root 2933 Dec 3 17:19 Brussels ...
Suppose the timezone of choice is Europe/Brussels, to select this timezone, a symlink can be created from this zoneinfo file to /etc/localtime:
root #
ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime
The target path with
../
at the start is relative to the link location, not the current directory.An absolute path can be used for the symlink, but a relative link is also created by systemd's timedatectl and is more compatible with alternate ROOTs.
Configure locales
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.
Locale generation
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.
root #
nano /etc/locale.gen
The following locales are an example to get both English (United States) and German (Germany/Deutschland) 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
Many applications require least one UTF-8 locale 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.
root #
locale-gen
To verify that the selected locales are now available, run locale -a.
On systemd installs, localectl can be used, e.g. localectl set-locale ... or localectl list-locales.
Locale selection
Once done, it is now time to set the system-wide locale settings. Again eselect is used, 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] C.utf8 [3] en_US [4] en_US.iso88591 [5] en_US.utf8 [6] de_DE [7] de_DE.iso88591 [8] de_DE.utf8 [9] POSIX [ ] (free form)
With eselect locale set <NUMBER> the correct locale can be selected:
root #
eselect locale set 2
Manually, this can still be accomplished through the /etc/env.d/02locale file and for systemd the /etc/locale.conf file:
LANG="de_DE.UTF-8"
LC_COLLATE="C.UTF-8"
Setting the locale will avoid warnings and errors during kernel and software compilations later in the installation.
Now reload the environment:
root #
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
For additional guidance through the locale selection process read also the Localization guide and the UTF-8 guide.
References
Optional: Installing firmware and/or microcode
Firmware
Suggested: Linux Firmware
On many systems, non-FOSS firmware is required for certain hardware to function. The sys-kernel/linux-firmware package contains firmware for many, but not all, devices.
Most wireless cards and GPUs require firmware to function.
root #
emerge --ask sys-kernel/linux-firmware
Installing certain firmware packages often requires accepting the associated firmware licenses. If necessary, visit the license handling section of the Handbook for help on accepting licenses.
Firmware Loading
Firmware files are typically loaded when the associated kernel module is loaded. This means the firmware must be built into the kernel using CONFIG_EXTRA_FIRMWARE if the kernel module is set to Y instead of M. In most cases, building-in a module which required firmware can complicate or break loading.
sys-kernel/installkernel
Installkernel may be used to automate the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default, systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.
Bootloader
Now is the time to think about which bootloader the user wants for the system, if unsure, follow the 'Traditional layout' subsection below.
GRUB
Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.
sys-kernel/installkernel grub
root #
emerge --ask sys-kernel/installkernel
Traditional layout, other bootloaders (e.g. (e)lilo, syslinux, etc.)
The traditional /boot layout (for e.g. (e)LILO, syslinux, etc.) is used by default if the grub, systemd-boot, efistub and uki USE flags are not enabled. No further action is required.
Initramfs
An initial ram-based file system, or initramfs, may be required for a system to boot. A wide of variety of cases may necessitate one, but common cases include:
- Kernels where storage/filesystem drivers are modules.
- Layouts with /usr/ or /var/ on separate partitions.
- Encrypted root filesystems.
Distribution kernels are designed to be used with an initramfs, as many storage and filesystem drivers are built as modules.
In addition to mounting the root filesystem, an initramfs may also perform other tasks such as:
- Running file system consistency check fsck, a tool to check and repair consistency of a file system in such events of uncleanly shutdown a system.
- Providing a recovery environment in the event of late-boot failures.
Installkernel can automatically generate an initramfs when installing the kernel if the dracut or ugrd USE flag is enabled:
sys-kernel/installkernel dracut
root #
emerge --ask sys-kernel/installkernel
Kernel configuration and compilation
It's can be a wise move to use the dist-kernel on the first boot as it provides a very simple method to rule out system issues and kernel config issues. Always having a known working kernel to fallback on can speed up debugging and alleviate anxiety when updating that your system will no longer boot.
Now it is time to configure and compile the kernel sources. For the purposes of the installation, three approaches to kernel management will be presented, however at any point post-installation a new approach can be employed.
Ranked from least involved to most involved:
- Full automation approach: Distribution kernels
- A Distribution Kernel is used to configure, automatically build, and install the Linux kernel, its associated modules, and (optionally, but enabled by default) an initramfs file. Future kernel updates are fully automated since they are handled through the package manager, just like any other system package. It is possible provide a custom kernel configuration file if customization is necessary. This is the least involved process and is perfect for new Gentoo users due to it working out-of-the-box and offering minimal involvement from the system administrator.
- Full manual approach
- New kernel sources are installed via the system package manager. The kernel is manually configured, built, and installed using the eselect kernel and a slew of make commands. Future kernel updates repeat the manual process of configuring, building, and installing the kernel files. This is the most involved process, but offers maximum control over the kernel update process.
- Hybrid approach: Genkernel
- We use the term hybrid here but, do note that the dist-kernel and manual sources, both include methods to achieve the same goal. New kernel sources are installed via the system package manager. System administrators may use Gentoo's genkernel tool to configure, build, and install the Linux kernel, its associated modules, and (optionally, but not enabled by default) an initramfs file. It is possible provide a custom kernel configuration file if customization is necessary. Future kernel configuration, compilation, and installation require the system administrator's involvement in the form of running eselect kernel, genkernel, and potentially other commands for each update. This option should only considered for users that know they have a need for genkernel
The core around which all distributions are built is the Linux kernel. It is the layer between the user's programs and the system hardware. Although the handbook provides its users several possible kernel sources, a more comprehensive listing with more detailed descriptions is available at the Kernel overview page.
Kernel installation tasks such as copying the kernel image to /boot or the EFI System Partition, generating an initramfs and/or Unified Kernel Image, updating bootloader configuration, can be automated with installkernel. Users may wish to configure and install sys-kernel/installkernel before proceeding. See the Kernel installation section below for more more information.
Distribution kernels
Distribution Kernels are ebuilds that cover the complete process of unpacking, configuring, compiling, and installing the kernel. The primary advantage of this method is that the kernels are updated to new versions by the package manager as part of @world upgrade. This requires no more involvement than running an emerge command. Distribution kernels default to a configuration supporting the majority of hardware, however two mechanisms are offered for customization: savedconfig and config snippets. See the project page for more details on configuration.
Optional: Signed kernel modules
The kernel modules in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) are already signed. To sign the modules of kernels built from source enable the modules-sign USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf:
USE="modules-sign"
# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512.
If MODULES_SIGN_KEY is not specified the kernel build system will generate a key, it will be stored in /usr/src/linux-x.y.z/certs. It is recommended to manually generate a key to ensure that it will be the same for each kernel release. A key may be generated with:
root #
openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
The MODULES_SIGN_KEY and MODULES_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
OpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.
Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:
root #
ls -l kernel_key.pem
-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
If this outputs anything other then the above, correct the permissions with:
root #
chown root:root kernel_key.pem
root #
chmod 400 kernel_key.pem
Installing a distribution kernel
To build a kernel with Gentoo patches from source, type:
root #
emerge --ask sys-kernel/gentoo-kernel
System administrators who want to avoid compiling the kernel sources locally can instead use precompiled kernel images:
root #
emerge --ask sys-kernel/gentoo-kernel-bin
Distribution Kernels, such as sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin, by default, expect to be installed alongside an initramfs. Before running emerge to install the kernel users should ensure that sys-kernel/installkernel has been configured to utilize an initramfs generator (for example Dracut) as described in the installkernel section.
Upgrading and cleaning up
Once the kernel is installed, the package manager will automatically update it to newer versions. The previous versions will be kept until the package manager is requested to clean up stale packages. To reclaim disk space, stale packages can be trimmed by periodically running emerge with the --depclean
option:
root #
emerge --depclean
Alternatively, to specifically clean up old kernel versions:
root #
emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin
By design, emerge only removes the kernel build directory. It does not actually remove the kernel modules, nor the installed kernel image. To completely clean-up old kernels, the app-admin/eclean-kernel tool may be used.
Post-install/upgrade tasks
An upgrade of a distribution kernel is capable of triggering an automatic rebuild for external kernel modules installed by other packages (for example: sys-fs/zfs-kmod or x11-drivers/nvidia-drivers). This automated behaviour is enabled by enabling the dist-kernel USE flag. When required, this same flag will also trigger re-generation of the initramfs.
It is highly recommended to enable this flag globally via /etc/portage/make.conf when using a distribution kernel:
USE="dist-kernel"
Manually rebuilding the initramfs or Unified Kernel Image
If required, manually trigger such rebuilds by, after a kernel upgrade, executing:
root #
emerge --ask @module-rebuild
If any kernel modules (e.g. ZFS) are needed at early boot, rebuild the initramfs afterward via:
root #
emerge --config sys-kernel/gentoo-kernel
root #
emerge --config sys-kernel/gentoo-kernel-bin
Installing the kernel sources
When installing and compiling the kernel for hppa-based systems, Gentoo recommends the sys-kernel/gentoo-sources package.
Choose an appropriate kernel source and install it using emerge:
root #
emerge --ask sys-kernel/gentoo-sources
This will install the Linux kernel sources in /usr/src/ using the specific kernel version in the path. It will not create a symbolic link by itself without the symlink USE flag being enabled on the chosen kernel sources package.
It is conventional for a /usr/src/linux symlink to be maintained, such that it refers to whichever sources correspond with the currently running kernel. However, this symbolic link will not be created by default. An easy way to create the symbolic link is to utilize eselect's kernel module.
For further information regarding the purpose of the symlink, and how to manage it, please refer to Kernel/Upgrade.
First, list all installed kernels:
root #
eselect kernel list
Available kernel symlink targets: [1] linux-6.6.13-gentoo
In order to create a symbolic link called linux, use:
root #
eselect kernel set 1
root #
ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.13-gentoo
Alternative: Manual configuration
In case it was missed, this section requires the kernel sources to be installed. Be sure to obtain the relevant kernel sources, then return here for the rest of section.
Manually configuring a kernel is commonly seen as one of the most difficult procedures a system administrator has to perform. Nothing is less true - after configuring a few kernels no one remembers that it was difficult! There are two ways for a Gentoo user to manage a manual kernel system, both of which are listed below:
Modprobed-db process
A very easy way to manage the kernel is to first install sys-kernel/gentoo-kernel-bin and use the sys-kernel/modprobed-db to collect information about what the system requires. modprobed-db is a tool which monitors the system via crontab to add all modules of all devices over the system's life to make sure it everything a user needs is supported. For example, if an Xbox controller is added after installation, then modprobed-db will add the modules to be built next time the kernel is rebuilt. More on this topic can be found in the Modprobed-db article.
Manual process
This method allows a user to have full control of how their kernel is built with as minimal help from outside tools as they wish. Some could consider this as making it hard for the sake of it.
However, with this choice 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
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.
root #
cd /usr/src/linux
The kernel has a method of autodetecting the modules currently being used on the installcd which will give a great starting point to allow a user to configure their own. This can be called by using:
root #
make localmodconfig
It's now time to configure using nconfig:
root #
make nconfig
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.
Enabling required options
When using sys-kernel/gentoo-sources, it is strongly recommend the Gentoo-specific configuration options be enabled. These ensure that a minimum of kernel features required for proper functioning is available:
Gentoo Linux --->
[*] Gentoo Linux support
[*] Linux dynamic and persistent device naming (userspace devfs) support
[*] Select options required by Portage features
Support for init systems, system and service managers --->
[*] OpenRC, runit and other script based systems and managers
[*] systemd
Naturally the choice in the last two lines depends on the selected init system (OpenRC vs. systemd). It does not hurt to have support for both init systems enabled.
When using sys-kernel/vanilla-sources, the additional selections for init systems will be unavailable. Enabling support is possible, but goes beyond the scope of the handbook.
Enabling support for typical system components
Make sure that every driver that is vital to the booting of the system (such as SATA controllers, NVMe block device support, filesystem support, etc.) is compiled in the kernel and not as a module, otherwise the system may 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):
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):
Device Drivers --->
SCSI device support --->
<*> SCSI device support
<*> SCSI disk support
Device Drivers --->
<*> Serial ATA and Parallel ATA drivers (libata) --->
[*] ATA ACPI Support
[*] SATA Port Multiplier support
<*> AHCI SATA support (ahci)
[*] ATA BMDMA support
[*] ATA SFF support (for legacy IDE and PATA)
<*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)
Verify basic NVMe support has been enabled:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
It does not hurt to enable the following additional NVMe support:
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
[*] NVMe Target Passthrough support
<M> NVMe loopback device support
<M> NVMe over Fabrics FC target driver
< > NVMe over Fabrics FC Transport Loopback Test driver (NEW)
<M> NVMe over Fabrics TCP target support
Now go to File Systems and select support for the filesystems that will be used by the system. Do not compile the file system that is used for the root filesystem as module, otherwise the system may 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:
File systems --->
<*> Second extended fs support
<*> The Extended 3 (ext3) filesystem
<*> The Extended 4 (ext4) filesystem
<*> Btrfs filesystem support
<*> XFS 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):
Device Drivers --->
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP over Ethernet
<*> 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):
Processor type and features --->
[*] Symmetric multi-processing support
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:
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
<*> Unified support for USB4 and Thunderbolt --->
Optional: Signed kernel modules
To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:
[*] Enable loadable module support
-*- Module signature verification
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
Optionally change the hash algorithm if desired.
To enforce that all modules are signed with a valid signature, enable CONFIG_MODULE_SIG_FORCE as well:
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
To use a custom key, specify the location of this key in CONFIG_MODULE_SIG_KEY. If unspecified, the kernel build system will generate a key. It is recommended to generate one manually instead. This can be done with:
root #
openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem
OpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.
Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:
root #
ls -l kernel_key.pem
-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
If this outputs anything other then the above, correct the permissions with:
root #
chown root:root kernel_key.pem
root #
chmod 400 kernel_key.pem
-*- Cryptographic API --->
Certificates for signature checking --->
(/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key
To also sign external kernel modules installed by other packages via linux-mod-r1.eclass
, enable the modules-sign USE flag globally:
USE="modules-sign"
# Optionally, when using custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate
MODULES_SIGN_HASH="sha512" # Defaults to sha512
MODULES_SIGN_KEY and MODULES_SIGN_CERT may point to different files. For this example, the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
Compiling and installing
To compile a 64-bit kernel, first emerge sys-devel/kgcc64. Running a 64-bit kernel used to be discouraged but should now be safe. If in doubt, only run a 64-bit kernel if the system has more than 4GB of RAM or if the server requires it, i.e. on the A500.
Now that the kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process:
root #
make && make modules_install
If building a 64-bit kernel, do this instead (it's necessary even for native builds, see here):
root #
CROSS_COMPILE=hppa64-unknown-linux-gnu- make && CROSS_COMPILE=hppa64-unknown-linux-gnu- make modules_install
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.When the kernel has finished compiling, copy the kernel image to /boot/. Use whatever name is appropriate for the kernel choice and remember it as it will be needed later on when configuring the bootloader. Remember to replace kernel-6.6.13-gentoo with the name and version of the installed kernel.
root #
cp vmlinux /boot/kernel-6.6.13-gentoo
Deprecated: Genkernel
Genkernel should only be considered by users with a required need that only Genkernel can meet. For others, it is recommended to use the Distribution kernel or manually compile their own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods; for example, Unified Kernel Images will need to be created manually when using Genkernel.
Users still wishing to use Genkernel should see the Genkernel article for more information.
Kernel modules
Listing available kernel modules
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 modules that will be automatically loaded to be listed. Modules cannot be loaded twice; they are either loaded or unloaded. Sometimes exotic hardware requires help to load their drivers.
The modules that need to be loaded during each boot in can be added to /etc/modules-load.d/*.conf files in the format of one module per line. When extra options are needed for the modules, they should be set in /etc/modprobe.d/*.conf files instead.
To view all modules available for a specific kernel version, issue the following find command. Do not forget to substitute "<kernel version>" with the appropriate version of the kernel to search:
root #
find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less
Force loading particular kernel modules
To force load the kernel to 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 within it.
root #
mkdir -p /etc/modules-load.d
root #
nano -w /etc/modules-load.d/network.conf
Note that the module's .ko file suffix is insignificant to the loading mechanism and left out of the configuration file:
3c59x
Continue the installation with Configuring the system.
Filesystem information
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
If the filesystem inside a partition is wiped, then the filesystem label and the UUID values will be subsequently altered or removed.
For uniqueness, readers who are using MBR-style partition tables are advised to use UUIDs rather than labels to specify mountable volumes in /etc/fstab.
UUIDs of the filesystem on a LVM volume and its LVM snapshots are identical, therefore using UUIDs to mount LVM volumes should be avoided.
Partition labels and UUIDs
Systems with GPT disklabel support offer additional 'robust' options 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/or PARTUUID prefixes and can be viewed nicely in the terminal by running the blkid command.
Output for an amd64 EFI system using the Discoverable Partition Specification UUIDs may like the following:
root #
blkid
/dev/sr0: BLOCK_SIZE="2048" UUID="2023-08-28-03-54-40-00" LABEL="ISOIMAGE" TYPE="iso9660" PTTYPE="PMBR" /dev/loop0: TYPE="squashfs" /dev/sda2: PARTUUID="0657fd6d-a4ab-43c4-84e5-0933c84b4f4f" /dev/sda3: PARTUUID="1cdf763a-5b4c-4dbf-99db-a056c504e8b2" /dev/sda1: PARTUUID="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
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 is changed or re-written in the future. Using the older default block device files (/dev/sd*N) for defining the partitions in fstab is risky for systems that have SATA block devices regularly added or removed.
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 the system administrator intends to constantly fiddle with the disk ordering, using default block device files is a simple and straightforward approach.
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
If the init system being used is systemd, the partition UUIDs conform to the Discoverable Partition Specification as given in Preparing the disks, and the system uses UEFI, then creating an fstab can be skipped, since systemd auto-mounts partitions that follow the spec.
The /etc/fstab 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:
- 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.
- The second field shows the mount point at which the partition should be mounted.
- The third field shows the type of filesystem used by the partition.
- The fourth field shows the mount options used by mount when it wants to mount the partition. As every filesystem has its own mount options, so system admins are encouraged to read the mount man page (man mount) for a full listing. Multiple mount options are comma-separated.
- The fifth field is used by dump to determine if the partition needs to be dumped or not. This can generally be left as
0
(zero). - The sixth field is used by fsck to determine the order in which filesystems should be checked if the system wasn't shut down properly. The root filesystem should have
1
while the rest should have2
(or0
if a filesystem check is not necessary).
The default /etc/fstab file provided in Gentoo stage files is not a valid fstab file but instead a template that can be used to enter in relevant values.
root #
nano /etc/fstab
DOS/Legacy BIOS systems
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 the hppa partitioning example, /boot is usually the /dev/sda2 partition, with xfs recommended for the filesystem. It needs to be checked during boot, so we would write down:
# Adjust for any formatting differences and/or additional partitions created from the "Preparing the disks" step
/dev/sda2 /boot ext2 defaults 0 2
Some system administrators want the /boot partition to not be mounted automatically to improve their system's security. Those people should substitute the 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:
# Adjust for any formatting differences and/or additional partitions created from the "Preparing the disks" step
/dev/sda2 /boot ext2 defaults 0 2
/dev/sda3 none swap sw 0 0
/dev/sda4 / xfs defaults,noatime 0 1
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
DPS UEFI PARTUUID
Below is an example of an /etc/fstab file for a disk formatted with a GPT disklabel and Discoverable Partition Specification (DPS) UUIDs set for UEFI firmware:
# Adjust any formatting difference and additional partitions created from the "Preparing the disks" step.
# This example shows a GPT disklabel with Discoverable Partition Specification (DSP) UUID set:
PARTUUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b /efi vfat 0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f none sw 0 0
PARTUUID=1aacdb3b-5444-4138-bd9e-e5c2239b2346 / xfs defaults,noatime 0 1
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 are not registered (those are not needed generally anyway). This is also recommended for systems with solid state drives (SSDs). Users may wish to consider lazytime
instead.
Due to degradation in performance, defining the
discard
mount option in /etc/fstab is not recommended. It is generally better to schedule block discards on a periodic basis using a job scheduler such as cron or a timer (systemd). See Periodic fstrim jobs for more information.Double-check the /etc/fstab file, then 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.
Hostname
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.
Set the hostname (OpenRC or systemd)
root #
echo tux > /etc/hostname
systemd
To set the system hostname for a system currently running systemd, the hostnamectl utility may be used. During the installation process however, systemd-firstboot command must be used instead (see later on in handbook).
For setting the hostname to "tux", one would run:
root #
hostnamectl hostname tux
View help by running hostnamectl --help or man 1 hostnamectl.
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:
root #
emerge --ask net-misc/dhcpcd
To enable and then start the service on OpenRC systems:
root #
rc-update add dhcpcd default
root #
rc-service dhcpcd start
To enable the service on systemd systems:
root #
systemctl enable dhcpcd
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.
netifrc (OpenRC)
This is one particular way of setting up the network using Netifrc on OpenRC. Other methods exist for simpler setups like Dhcpcd.
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.
More detailed information about networking, including advanced topics like bonding, bridging, 802.1Q VLANs or wireless networking is covered in the advanced network configuration section.
All networking information is gathered in /etc/conf.d/net. 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 /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 /etc/conf.d/net
Set both config_eth0 and routes_eth0 to enter IP address information and routing information:
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 the Network interface naming section.
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:
config_eth0="dhcp"
Please read /usr/share/doc/netifrc-*/net.example.bz2 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.
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, it is discovered the network interface name (which is currently documented as eth0
) was wrong, then execute the following steps to rectify:
- Update the /etc/conf.d/net file with the correct interface name (like
enp3s0
orenp5s0
, instead ofeth0
). - Create new symbolic link (like /etc/init.d/net.enp3s0).
- Remove the old symbolic link (rm /etc/init.d/net.eth0).
- Add the new one to the default runlevel.
- Remove the old one using rc-update del net.eth0 default.
The hosts file
An important next step may be to inform this new system about other hosts in its network environment. Network host names can be defined in the /etc/hosts file. Adding host names here will enable host name to IP addresses resolution for hosts that are not resolved by the nameserver.
root #
nano /etc/hosts
# 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.
System information
Root password
Set the root password using the passwd command.
root #
passwd
Later an additional regular user account will be created for daily operations.
Init and boot configuration
OpenRC
When using OpenRC with Gentoo, it 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 /etc/rc.conf
Next, open /etc/conf.d/keymaps to handle keyboard configuration. Edit it to configure and select the right keyboard.
root #
nano /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 /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.
systemd
First, it is recommended to run systemd-machine-id-setup and then systemd-firstboot 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:
root #
systemd-machine-id-setup
root #
systemd-firstboot --prompt
Next users should run systemctl to reset all installed unit files to the preset policy values:
root #
systemctl preset-all --preset-mode=enable-only
It's possible to run the full preset changes but this may reset any services which were already configured during the process:
root #
systemctl preset-all
These two steps will help ensure a smooth transition from the live environment to the installation's first boot.
System logger
OpenRC
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 decision is a logging mechanism 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 a log file.
Gentoo offers several system logger utilities. A few of these include:
- sysklogd (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.
- syslog-ng (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 its logging potential; be aware additional configuration is a necessity for any kind of smart logging.
- metalog (app-admin/metalog) - A highly-configurable system logger.
There may be other system logging utilities available through the Gentoo ebuild repository as well, since the number of available packages increases on a daily basis.
If syslog-ng is going to be used, it is recommended to install and configure logrotate. syslog-ng does not provide any rotation mechanism for the log files. Newer versions (>= 2.0) of sysklogd however handle their own log rotation.
To install the system logger of choice, emerge it. On OpenRC, add it to the default runlevel using rc-update. The following example installs and activates app-admin/sysklogd as the system's syslog utility:
root #
emerge --ask app-admin/sysklogd
root #
rc-update add sysklogd default
systemd
While a selection of logging mechanisms are presented for OpenRC-based systems, systemd includes a built-in logger called the systemd-journald service. The systemd-journald service is capable of handling most of the logging functionality outlined in the previous system logger section. That is to say, the majority of installations that will run systemd as the system and service manager can safely skip adding a additional syslog utilities.
See man journalctl for more details on using journalctl to query and review the systems logs.
For a number of reasons, such as the case of forwarding logs to a central host, it may be important to include redundant system logging mechanisms on a systemd-based system. This is a irregular occurrence for the handbook's typical audience and considered an advanced use case. It is therefore not covered by the handbook.
Optional: Cron daemon
OpenRC
Although it is optional and not required for every system, it is wise to install a cron daemon.
A cron daemon executes commands on scheduled intervals. Internals could be daily, weekly, or monthly, once every Tuesday, once every other week, etc. A wise system administrator will leverage the cron daemon to automate routine system maintenance tasks.
All cron daemons support high levels of granularity for scheduled tasks, and generally include the ability to send an email or other form of notification if a scheduled task does not complete as expected.
Gentoo offers several possible cron daemons, including:
- cronie (sys-process/cronie) - cronie is based on the original cron and has security and configuration enhancements like the ability to use PAM and SELinux.
- dcron (sys-process/dcron) - This lightweight cron daemon aims to be simple and secure, with just enough features to stay useful.
- fcron (sys-process/fcron) - A command scheduler with extended capabilities over cron and anacron.
- bcron (sys-process/bcron) - A younger cron system designed with secure operations in mind. To do this, the system is divided into several separate programs, each responsible for a separate task, with strictly controlled communications between parts.
Default: cronie
The following example uses sys-process/cronie:
root #
emerge --ask sys-process/cronie
Add cronie to the default system runlevel, which will automatically start it on power up:
root #
rc-update add cronie default
Alternative: dcron
root #
emerge --ask sys-process/dcron
If dcron is the go forward cron agent, an additional initialization command needs to be executed:
root #
crontab /etc/crontab
Alternative: fcron
root #
emerge --ask sys-process/fcron
If fcron is the selected scheduled task handler, an additional emerge step is required:
root #
emerge --config sys-process/fcron
Alternative: bcron
bcron is a younger cron agent with built-in privilege separation.
root #
emerge --ask sys-process/bcron
systemd
Similar to system logging, systemd-based systems include support for scheduled tasks out-of-the-box in the form of timers. systemd timers can run at a system-level or a user-level and include the same functionality that a traditional cron daemon would provide. Unless redundant capabilities are necessary, installing an additional task scheduler such as a cron daemon is generally unnecessary and can be safely skipped.
Optional: File indexing
In order to index the file system to provide faster file location capabilities, install mlocate:
root #
emerge --ask sys-apps/mlocate
Optional: Remote shell access
opensshd's default configuration does not allow root to login as a remote user. Please create a non-root user and configure it appropriately to allow access post-installation if required, or adjust /etc/ssh/sshd_config to allow root.
To be able to access the system remotely after installation, sshd must be configured to start on boot.
For more in-depth details on the configuration of SSH, refer to the SSH article.
OpenRC
To add the sshd init script to the default runlevel on OpenRC:
root #
rc-update add sshd default
If serial console access is needed (which is possible in case of remote servers), agetty must be configured.
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
systemd
To enable the SSH server, run:
root #
systemctl enable sshd
To enable serial console support, run:
root #
systemctl enable getty@tty1.service
Optional: Shell completion
Bash
Bash is the default shell for Gentoo systems, and therefore installing completion extensions can aid in efficiency and convenience to managing the system. The app-shells/bash-completion package will install completions available for Gentoo specific commands, as well as many other common commands and utilities:
root #
emerge --ask app-shells/bash-completion
Post installation, bash completion for specific commands can managed through eselect. See the Shell completion integrations section of the bash article for more details.
Suggested: Time synchronization
It is important to use some method of synchronizing the system clock. This is usually done via the NTP protocol and software. Other implementations using the NTP protocol exist, like Chrony.
To set up Chrony, for example:
root #
emerge --ask net-misc/chrony
OpenRC
On OpenRC, run:
root #
rc-update add chronyd default
systemd
On systemd, run:
root #
systemctl enable chronyd.service
Alternatively, systemd users may wish to use the simpler systemd-timesyncd SNTP client which is installed by default.
root #
systemctl enable systemd-timesyncd.service
Filesystem tools
Depending on the filesystems used, it may be necessary to install the required file system utilities (for checking the filesystem integrity, (re)formatting file systems, etc.). Note that ext4 user space tools (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 tools will be needed in the installed environment.
Filesystem | Package |
---|---|
XFS | sys-fs/xfsprogs |
ext4 | sys-fs/e2fsprogs |
VFAT (FAT32, ...) | sys-fs/dosfstools |
Btrfs | sys-fs/btrfs-progs |
F2FS | sys-fs/f2fs-tools |
NTFS | sys-fs/ntfs3g |
ZFS | sys-fs/zfs |
It's recommended that sys-block/io-scheduler-udev-rules is installed for the correct scheduler behavior with e.g. nvme devices:
root #
emerge --ask sys-block/io-scheduler-udev-rules
For more information on filesystems in Gentoo see the filesystem article.
Networking tools
If networking was previously configured in the Configuring the system step and network setup is complete, then this 'networking tools' section can be safely skipped. In this case, proceed with the section on Configuring a bootloader.
Installing a DHCP client
Most users will need a DHCP client to connect to their network. If none were installed, then the system might not be able to get on the network thus making it impossible to download a DHCP client afterwards without statically configuring an IP address.
A DHCP client obtains automatically an IP address for one or more network interface(s) using netifrc scripts. We recommend the use of net-misc/dhcpcd (see also dhcpcd):
root #
emerge --ask net-misc/dhcpcd
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.
Installing PALO
On the PA-RISC platform, the boot loader is called palo. First merge this bootloader to the system:
root #
emerge --ask sys-boot/palo
The configuration file will be found at /etc/palo.conf. Below is a sample configuration:
This configuration must be changed after running palo for the first time! See below for after first setup.
--commandline=2/kernel-6.6.13-gentoo root=/dev/sda4
--recoverykernel=/vmlinux.old
# DELETE this line after running palo for the first time!
--init-partitioned=/dev/sda
# --format-as has two meanings depending on whether --init-partitioned or --update-partitioned is used. Keep this line.
--format-as=4
The first line tells palo the location of the kernel and which boot parameters it must use. The string 2/kernel-6.6.13-gentoo
means the kernel named /kernel-6.6.13-gentoo resides on the second partition. Beware, the path to the kernel is relative to the boot partition, not to the root partition.
The second line indicates which recovery kernel to use. If it is the first install and there is no recovery kernel (yet), please comment this out. The third line indicates on which disk palo will reside.
To format the disk, palo must be run with certain arguments. This example uses ext4 for the first partition:
root #
palo --format-as=4 --init-partitioned=/dev/sda
When configuration is done, simply run the palo command:
root #
palo
The configuration must then be updated for post-first-install use:
--commandline=2/kernel-6.6.13-gentoo root=/dev/sda4
--recoverykernel=/vmlinux.old
# Don't throw away the old partition, just update the existing one on `palo` runs.
--update-partitioned=/dev/sda
# --format-as has two meanings depending on whether --init-partitioned or --update-partitioned is used. Keep this line.
--format-as=4
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.
(chroot) livecd #
exit
livecd~#
cd
livecd~#
umount -l /mnt/gentoo/dev{/shm,/pts,}
livecd~#
umount -R /mnt/gentoo
livecd~#
reboot
Do not forget to remove the live image, otherwise it may be targeted again instead of the newly installed Gentoo system!
Once rebooted in the fresh Gentoo environment, it is wise to finish 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 one or more standard user account(s) 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 | Enable the user account to access the audio devices. |
cdrom | Enable the user account to directly access optical devices. |
cron | Enable the user account to access time-based job scheduling via cron. Note: user accounts on systems running the systemd service system can use systemd timers and user service files instead of cron jobs. |
floppy | Enable the user account to directly access ancient mechanical devices known floppy as drives. This group is not generally used on modern systems. |
usb | Enable the user account able to access USB devices. |
video | Enables the user account to access video capturing hardware and hardware acceleration. |
wheel | Enables the user account able to use the su (substitute user) command, which allows switching to the root account or other accounts. For single user systems that include a root account, it is a good idea to add this group for the primary standard user. |
For instance, to create a user called larry who is a 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)
When setting passwords for standard user accounts, it is good security practice to avoid using the same or a similar password as set for the root user.
Handbook authors recommended to use a password at least 16 characters in length, with a value fully unique from every other user on the system.
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)
Temporarily elevating privileges
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 (app-admin/sudo) or doas (app-admin/doas) utilities which are, if correctly configured, very secure.
Disabling root login
Before disabling the root login, ensure that a user account is a member of the wheel group and that a method to elevate user privilege exists; otherwise root access will be locked and system administration will be impossible without performing recovery. Some common methods to elevate user privilege include: app-admin/sudo, app-admin/doas, or systemd's run0.
To prevent possible threat actors from logging in as root, deleting the root password and/or disabling root login can help improve security.
To disable root login:
root #
passwd -l root
To delete the root password and disable login:
root #
passwd -dl root
Disk cleanup
Removing installation artifacts
With the Gentoo installation finished and the system rebooted, if everything has gone well, the stage file and other installation artifacts - such as DIGEST, CONTENT, or *.asc (PGP signature) files - can now be safely removed.
The files are located in the / directory and can be removed with the following command:
root #
rm /stage3-*.tar.*
Where to go from here
Not sure where to go from here? There are many paths to explore... Gentoo provides its users with lots of possibilities and therefore has lots of documented (and less documented) features to explore here on the wiki and on other Gentoo related sub-domains (see the Gentoo online section below).
Additional documentation
It is important to note that, due to the number of choices available in Gentoo, the documentation provided by the handbook is limited in scope - it mainly focuses on the basics of getting a Gentoo system up and running and basic system management activities. The handbook intentionally excludes instructions on graphical environments, details on hardening, and other important administrative tasks. That being stated, there are more sections of the handbook to assist readers with more basic functions.
Readers should definitely take a look at the next part of the 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, and various other informative topics relating to managing a Gentoo system post-installation.
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).
The majority of users with desktop use cases will setup graphical environments in which to work natively. There are many community maintained 'meta' articles for supported desktop environments (DEs) and window managers (WMs). Readers should be aware that each DE will require slightly different setup steps, which will lengthen add complexity to bootstrapping.
Many other Meta articles exist to provide our readers with high level overviews of available software within Gentoo.
Gentoo online
Readers should note that all official Gentoo sites online are governed by Gentoo's code of conduct. Being active in the Gentoo community is a privilege, not a right, and users should be aware that the code of conduct exists for a reason.
With the exception of the Libera.Chat hosted internet relay chat (IRC) network and the mailing lists, most Gentoo websites require an account on a per site basis in order to ask questions, open a discussion, or enter a bug.
Forums and IRC
Every user is welcome on our Gentoo forums or on one of our internet relay chat channels. It is easy to search for the forums to see if an issue experienced on a fresh Gentoo install has been discovered in the past and resolved after some feedback. The likelihood of other users experiencing the installation issues by first-time Gentoo can be surprising. It is advised users search the forums and the wiki before asking for assistance in Gentoo support channels.
Mailing lists
Several mailing lists are available to the community members who prefer to ask for support or feedback over email rather than create a user account on the forums or IRC. Users will need to follow the instructions in order to subscribe to specific mailing lists.
Bugs
Sometimes after reviewing the wiki, searching the forums, and seeking support in the IRC channel or mailing lists there is no known solution to a problem. Generally this is a sign to open a bug on Gentoo's Bugzilla site.
Development guide
Readers who desire to learn more about developing Gentoo can take a look at the Development guide. This guide provides instructions on writing ebuilds, working with eclasses, and provides definitions for many general concepts behind Gentoo development.
Closing thoughts
Gentoo is a robust, flexible, and excellently maintained distribution. The developer community is happy to hear feedback on how to make Gentoo an even better distribution.
As a reminder, any feedback for this handbook should follow the guidelines detailed in the How do I improve the Handbook? section at the beginning of the handbook.
We look forward to seeing how our users will choose to implement Gentoo to fit their unique use cases and needs.
Warning: Display title "Gentoo Linux hppa Handbook: Installing Gentoo" overrides earlier display title "Manual de Gentoo: HPPA/Todo/Instalación".