Gentoo Linux amd64 Handbook: Installing Gentoo
Ne pas essayer de suivre les instructions directement depuis les pages Handbook:Parts ou leurs sous-pages. Les pages Handbook:Parts sont un métamanuel utilisé pour transclure du texte dans d'autres manuels. Consulter un manuel spécifique à une architecture parmi ceux référencés dans la liste des manuels pour des instructions d'installation complètes.
Introduction
Bienvenue
Bienvenue sur Gentoo! Gentoo est un système d'exploitation basé sur Linux qui peut être automatiquement optimisé et customisé pour toute application et besoin. Gentoo est fondé sur un écosystème de logiciels libres et ne cache rien de ses utilisateurs.
Ouverture
Les outils principaux de Gentoo sont construits à partir de langages de programmation simples. Portage, le système de maintenance de paquets de Gentoo, est écrit en Python. Les Ebuilds, qui fournissent des définitions de paquets pour Portage sont écrits en bash. Nos utilisateurs sont encouragés à réviser, modifier et améliorer le code source de toutes les parties de Gentoo.
Par défaut, les paquets ne sont corrigés que lorsque cela est nécessaire pour corriger des bugs ou assurer l'interopérabilité au sein de Gentoo. Ils sont installés sur le système en compilant le code source fourni par les projets en amont au format binaire (bien que la prise en charge des paquets binaires précompilés soit également incluse). La configuration de Gentoo s'effectue via des fichiers texte.
Pour les raisons ci-dessus et d'autres : l'ouverture est intégrée en tant que principe de conception.
Choix
Le Choix est un autre 'principe de conception' de Gentoo.
En installant Gentoo, le choix est mis en valeur tout au long du Handbook. Les administrateurs système peuvent choisir entre deux systèmes d’initialisation (OpenRC de Gentoo et systemd de Freedesktop.org), la structure de partitions pour le(s) disque(s) de stockage, le(s) système(s) de fichiers à utiliser sur ce(s) disque(s), un profile système, supprimer ou ajouter des fonctionnalités sur le niveau global (système entier) ou spécifique au paquets en utilisant les drapeau USE, chargeur d’amorçage, les utilités de gestion réseau, et bien, bien plus!
En tant que philosophie de développement, auteurs de Gentoo essaient d'éviter de forcer les utilisateurs à utiliser un profil système ou un environnement de bureau spécifique. Si quelque chose est proposé dans l'écosystème GNU/Linux, il est probablement disponible dans Gentoo. Si ce n’est pas le cas, nous serions ravis qu’il en soit ainsi. Pour les demandes de nouveaux paquets, veuillez déposer un [rapport de bug https://bugs.gentoo.org] ou créer votre propre repo d'ebuilds.
Le Pouvoir
Être un système d'exploitation basé sur les sources permet à Gentoo d'être porté sur un nouvel ordinateur architectures de jeu d'instructions et permet également d'ajuster tous les packages installés. Cette force fait ressortir un autre principe de conception de Gentoo : le pouvoir .
Un administrateur système qui a installé et personnalisé Gentoo avec succès a compilé un système d'exploitation sur mesure à partir du code source. L'ensemble du système d'exploitation peut être réglé au niveau binaire via les mécanismes inclus dans le fichier make.conf de Portage. Si vous le souhaitez, des ajustements peuvent être effectués par paquet ou par groupe de paquets. En fait, des ensembles entiers de fonctionnalités peuvent être ajoutés ou supprimés à l’aide des drapeaux USE.
Il est très important que tout le monde comprenne que la liberté de choix est ce qui fait vivre Gentoo. Nous essayons de ne pas imposer des choix contre la volonté des utilisateurs. Si vous pensez différemment, s'il vous plaît, faites un rapport de bug !
Comment s'organise l'installation ?
L'installation de Gentoo se déroule en dix étapes couvertes par les chapitres suivants. Après chaque étape, le système sera dans un état bien défini :
Étape | Résultat |
---|---|
1 | L'utilisateur se trouve dans un environnement prêt pour installer Gentoo. |
2 | La connexion à Internet est configurée pour installer Gentoo. |
3 | Les disque durs sont initialisés pour accueillir l'installation de Gentoo. |
4 | L'environnement est prêt pour l'installation et l’utilisateur est prêt à chroot dans le nouvel environnement. |
5 | Les paquets de base, qui sont les mêmes sur toutes les installations de Gentoo, sont installés. |
6 | Le noyau Linux est installé. |
7 | La plupart des fichiers de configuration du système Gentoo sont créés. |
8 | Les outils indispensables au système sont installés. |
9 | Le chargeur d’amorçage (bootloader) est installé et configuré. |
10 | Le nouvel environnement Gentoo Linux est maintenant prêt à être utilisé. |
Lorsque plusieurs possibilités sont présentées, le manuel s’efforcera d'expliquer les avantages et les inconvénients de chaque option. Même si le texte continuera ensuite avec celle par défaut (identifiée par le texte « Défaut : » dans le titre), les autres possibilités seront également documentées (identifiées par « Alternative : » dans le titre). Ne pas croire que les choix par défaut représentent les recommandations de Gentoo. Ils indiquent simplement les choix que, selon Gentoo, la plupart des utilisateurs feront.
Parfois, l'utilisateur aura la possibilité de réaliser des actions facultatives. De telles étapes sont identifiées par le texte « Facultatif : » et ne sont pas essentielles pour installer Gentoo. Cependant, certaines options dépendent de choix faits plus tôt. Dans ce cas, les instructions informeront le lecteur au moment de faire le choix et au début de la description de l'étape.
Les options d'installation de Gentoo
Gentoo peut être installé de différentes façons. Il peut être téléchargé et installé depuis l'un des supports d'installation officiels tels que nos images ISO bootables. Le support d'installation peut être installé sur une clé USB ou accédé depuis un environnement réseau (netboot). Aussi, Gentoo peut être installé à partir d'un support non officiel tel qu'une autre distribution précédemment installée ou un disque bootable non Gentoo (comme Knoppix).
Ce manuel décrit l'installation à partir d'un support d'installation officiel de Gentoo ou, dans certains cas, à partir d'une autre machine du réseau.
Pour obtenir de l'aide sur d'autres approches d'installation, y compris les approches à l'aide de supports bootables non officiels Gentoo, veuillez lire notre guide sur les installations alternatives.
Nous fournissons aussi un document de trucs & astuces pour installer Gentoo qui peut se révéler utile.
Problèmes
Si un problème est rencontré lors de l'installation (ou dans la documentation), consultez notre système de gestion des bogues. Si le problème n'est pas déjà connu, créez un rapport de bogue pour que nous puissions le traiter. Ne soyez pas effrayé par les développeurs auxquels les bogues seront attribués, ils n'ont encore mangé personne.
Même si ce document est propre à une architecture, il peut contenir des références à d'autres architectures, car les manuels pour les différentes architectures ont de nombreuses sections communes (ceci évite le gaspillage d'efforts). De telles références ont été limitées au strict minimum, afin d'éviter toute confusion.
Si un doute existe quant à l'origine d'un problème qui est soit une erreur de l'utilisateur, bien que la documentation ait été soigneusement lue, soit une erreur de Gentoo malgré toute l'attention portée aux tests et à la documentation, tout le monde est le bienvenu sur les canaux #gentoo (webchat) ou #gentoofr (webchat) sur irc.libera.chat pour en discuter. Évidemment, tout le monde est toujours le bienvenu car notre canal de conversation couvre l'ensemble du spectre de Gentoo.
S'il vous reste une question relative à Gentoo, consultez la Template:FAQ/fr sur le Template:Main Page. Les FAQs sur les Forums de Gentoo sont également accessibles.
Pré-requis matériels
Avant de commencer, voici la liste des exigences concernant le matériel pour réussir l'installation de Gentoo sur un système amd64.
Support d'installation de Gentoo Linux
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.
CD minimal d'installation
Le CD minimal d'installation de Gentoo est une image d'un système Linux minimal autonome sur lequel il est possible de démarrer l'ordinateur. Pendant le chargement, le matériel est détecté et les pilotes appropriés sont chargés. L'image est maintenue par les développeurs de Gentoo et permet d'installer Gentoo via une connexion Internet active.
Le CD minimal d'installation est appelé install-amd64-minimal-<release>.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 has more kernel modules and firmware, which can help with using modern Wi-Fi chipsets.
The Gentoo LiveGUI USB image is built for amd64 and arm64 platforms weekly.
Qu’appelle-t-on les archives d'étapes (ou stage) ?
Une archive d'étape 3 contient un environnement Gentoo minimal à partir duquel il est possible d'installer Gentoo sur le système en suivant les instructions de ce manuel. Précédemment, le manuel de Gentoo décrivait l'installation en recourant à une archive parmi trois. Bien que Gentoo mette encore à disposition des archives d'étape 1 et 2, la méthode officielle d'installation utilise l'archive d'étape 3. Si vous tenez absolument à réaliser une installation à partir d'une des archives d'étape 1 ou 2, veuillez consulter la FAQ sur Comment installer Gentoo à partir d'une archive d'étape 1 ou 2 ?
L'archive d'étape 3 peut être téléchargée depuis releases/amd64/autobuilds/ sur l'un des miroirs Gentoo officiels. Ces archives sont mises à jour fréquemment et ne sont pas incluses dans les images d'installation officielles.
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.
Téléchargement
Obtenir le support d'installation
Le support d'installation par défaut que Gentoo Linux utilise est le CD minimal d'installation qui héberge un système Gentoo Linux très petit sur lequel il est possible de démarrer l'ordinateur. Cet environnement comprend tous les outils adaptés pour installer Gentoo. Les images CD peuvent être téléchargées depuis la page de téléchargements (recommandé) ou depuis l'un des nombreux miroirs disponibles.
Si le téléchargement s'effectue depuis un miroir, le CD minimal d'installation peut se trouver comme suit :
- Allez dans le répertoire releases/.
- Naviguez le répertoire correspondant à l'architecture souhaitée (tel que amd64/).
- Sélectionnez le répertoire autobuilds/.
- Pour les architectures amd64 et x86, sélectionnez soit le répertoire current-install-amd64-minimal/ ou current-install-x86-minimal/ (respectivement). Pour toutes les autres architectures, naviguez vers le répertoire current-iso/.
Certaines architectures comme arm, mips, et s390 n'ont pas de CD minimal d'installation. Pour l'instant, le Gentoo Release Engineering project ne propose pas d'image .iso pour ces architectures.
Dans cet emplacement, le fichier du support d'installation est le fichier avec l'extension .iso. Prendre pour exemple la liste suivante :
[DIR] hardened/ 05-Dec-2014 01:42 -
[ ] install-amd64-minimal-20141204.iso 04-Dec-2014 21:04 208M
[ ] install-amd64-minimal-20141204.iso.CONTENTS 04-Dec-2014 21:04 3.0K
[ ] install-amd64-minimal-20141204.iso.DIGESTS 04-Dec-2014 21:04 740
[TXT] install-amd64-minimal-20141204.iso.DIGESTS.asc 05-Dec-2014 01:42 1.6K
[ ] stage3-amd64-20141204.tar.bz2 04-Dec-2014 21:04 198M
[ ] stage3-amd64-20141204.tar.bz2.CONTENTS 04-Dec-2014 21:04 4.6M
[ ] stage3-amd64-20141204.tar.bz2.DIGESTS 04-Dec-2014 21:04 720
[TXT] stage3-amd64-20141204.tar.bz2.DIGESTS.asc 05-Dec-2014 01:42 1.5K
Dans l'exemple ci-dessus, le fichier install-amd64-minimal-20141204.iso correspond au CD d'installation. Il existe cependant d'autres fichiers qui lui sont relatifs :
- Un fichier .CONTENTS listant tous les fichiers existants dans le support d'installation. Cela permet de vérifier si un micrologiciel ou un pilote en particulier est disponible avant le téléchargement.
- Un fichier .DIGESTS qui contient le hachage du fichier ISO avec différents algorithmes et formats. Ce fichier peut permettre de savoir si l'ISO téléchargée est corrompue ou non.
Pour le moment, ne pas se soucier des autres fichiers – ils entreront en scène plus loin dans le processus d'installation. Téléchargez le fichier .iso et, s'il est nécessaire d'en vérifier l'intégrité, téléchargez aussi le fichier .DIGESTS.asc correspondant au fichier ISO. Il n'est pas nécessaire de télécharger le fichier .CONTENTS parce que les instructions d'installation n'y font plus référence et que le fichier .DIGESTS devrait contenir les mêmes informations. Le fichier .DIGESTS.asc contient en plus la signature.
The .DIGESTS file is only needed if the signature in the .iso.asc file is not verified.
Vérifier les fichiers téléchargés
Il s'agit là d'une opération facultative qui n'est pas nécessaire à l'installation de Gentoo Linux, mais elle est néanmoins recommandée.
- Tout d'abord, valider la signature cryptographique pour être sûr que le fichier provient bien de la « Gentoo Release Engineering team ».
- Si la signature est valide, alors vérifier l'empreinte (somme de contrôle) pour être sûr qu'aucune dégradation ne s'est produite pendant le téléchargement.
Vérifications sur un système Microsoft Windows
Pour vérifier la signature cryptographique, des outils tels que GPG4Win peuvent être utilisés. Après l'installation, les clés publiques de la « Gentoo Release Engineering team » doivent être importées. La liste des clés est disponible sur la page des signatures. Une fois l'importation terminée, l'utilisateur peut vérifier la signature contenue dans le fichier .DIGEST.asc.
Vérifications sur un système Linux
Sur un système GNU/Linux, la méthode la plus courante pour vérifier une signature cryptographique consiste à utiliser le logiciel app-crypt/gnupg. Quand ce paquet est installé, utiliser les commandes suivantes pour vérifier la signature contenue dans le fichier .DIGESTS.asc.
When importing Gentoo keys, verify that the fingerprint (
BB572E0E2D182910
) matches.Tout d'abord, téléchargez le jeu de clés adéquat disponible sur la page des signatures :
user $
gpg --keyserver hkps://keys.gentoo.org --recv-keys 0xBB572E0E2D182910
gpg: requesting key 0xBB572E0E2D182910 from hkp server pool.sks-keyservers.net gpg: key 0xBB572E0E2D182910: "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" 1 new signature gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 3 signed: 20 trust: 0-, 0q, 0n, 0m, 0f, 3u gpg: depth: 1 valid: 20 signed: 12 trust: 9-, 0q, 0n, 9m, 2f, 0u gpg: next trustdb check due at 2018-09-15 gpg: Total number processed: 1 gpg: new signatures: 1
Alternatively you can use instead the WKD to download the key:
user $
wget -O- https://gentoo.org/.well-known/openpgpkey/hu/wtktzo4gyuhzu8a4z5fdj3fgmr1u6tob?l=releng | gpg --import
--2019-04-19 20:46:32-- https://gentoo.org/.well-known/openpgpkey/hu/wtktzo4gyuhzu8a4z5fdj3fgmr1u6tob?l=releng Resolving gentoo.org (gentoo.org)... 89.16.167.134 Connecting to gentoo.org (gentoo.org)|89.16.167.134|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 35444 (35K) [application/octet-stream] Saving to: 'STDOUT' 0K .......... .......... .......... .... 100% 11.9M=0.003s 2019-04-19 20:46:32 (11.9 MB/s) - written to stdout [35444/35444] gpg: key 9E6438C817072058: 84 signatures not checked due to missing keys gpg: /tmp/test2/trustdb.gpg: trustdb created gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported gpg: key BB572E0E2D182910: 12 signatures not checked due to missing keys gpg: key BB572E0E2D182910: 1 bad signature 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
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
Ensuite, vérifiez la signature cryptographique du fichier .DIGESTS.asc :
user $
gpg --verify install-amd64-minimal-20141204.iso.DIGESTS.asc
gpg: Signature made Fri 05 Dec 2014 02:42:44 AM CET gpg: using RSA key 0xBB572E0E2D182910 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
Pour être absolument certain que tout est valide, vérifiez l'empreinte digitale affichée avec l'empreinte digitale disponible sur la page de signatures.
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
Bien sûr, avec juste un fichier ISO téléchargé, l'installation de Gentoo Linux ne peut pas être démarrée. Le fichier ISO doit être gravé sur un CD de démarrage, et d'une manière telle que son contenu soit gravé sur le CD, pas juste le fichier lui-même. Ci-dessous sont décrites quelques méthodes – des instructions plus élaborées sont disponible dans notre FAQ sur la gravure d'un fichier ISO.
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.
Graver un disque
A more elaborate set of instructions can be found in CD/DVD/BD_writing#Image_writing.
Gravure sous Microsoft Windows
Gravure sous Linux
Sur Linux, l'utilitaire cdrecord du paquet app-cdr/cdrtools peut graver des images ISO.
Pour graver le fichier ISO sur le CD du périphérique /dev/sr0 (c'est le premier lecteur de CD du système, remplacer le chemin vers le périphérique correspondant si besoin) :
user $
cdrecord dev=/dev/sr0 install-amd64-minimal-20141204.iso
Les utilisateurs qui préfèrent une interface graphique peuvent utiliser K3B, du paquet kde-apps/k3b. Dans K3B, allez dans Outils et choisissez Graver une Image CD.
Démarrage
This is a placeholder for architecture-specific booting information
Configuration matérielle supplémentaire
Lorsque le support d'installation démarre, il tente de détecter le matériel et charge les modules appropriés du noyau pour prendre en compte le matériel. Dans la grande majorité des cas, il fait un très bon travail. Toutefois, dans certains cas, il peut ne pas charger automatiquement les modules du noyau nécessaires au système. Si la détection automatique du bus PCI a oublié certains matériels du système, les modules appropriés du noyau doivent être chargées manuellement.
Dans l'exemple suivant, le module 8139too (qui prend en charge certains types d'interfaces réseau) est chargé :
root #
modprobe 8139too
Facultatif : Comptes utilisateurs
Si d'autres personnes ont besoin d'accéder à l'environnement d'installation, ou s'il est nécessaire d'exécuter des commandes en tant qu'utilisateur non-root sur le support d'installation (comme pour discuter sur IRC à l'aide de irssi sans être root pour des raisons de sécurité), alors un compte d'utilisateur supplémentaire doit être créé et un mot de passe root robuste défini.
Pour changer le mot de passe root, utilisez l'utilitaire passwd :
root #
passwd
Pour créer un compte d'utilisateur, entrez d'abord ses informations d'identification, suivies par le mot de passe du compte. Les commandes useradd et passwd sont utilisées pour ces tâches.
Dans l'exemple suivant, un utilisateur appelé jean est créé :
root #
useradd -m -G users jean
root #
passwd jean
New password: (Entrez le mot de passe de jean) Re-enter password: (Entrez de nouveau le mot de passe de jean)
Pour passer de l'utilisateur root à l'utilisateur fraîchement créé, utilisez la commande su :
root #
su - jean
Facultatif : Consulter la documentation pendant l'installation
TTYs
Pour afficher le manuel Gentoo lors de l'installation, créez tout d'abord un compte utilisateur, comme décrit ci-dessus. Puis appuyez sur Alt+F2 pour accéder à un nouveau terminal.
Lors de l'installation, la commande links peut être utilisée pour parcourir le manuel Gentoo - bien sûr cela nécessite que la connexion Internet fonctionne.
user $
links https://wiki.gentoo.org/wiki/Handbook:Parts/fr
Pour revenir au terminal d'origine, appuyez sur 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
L'utilitaire Screen est installé par défaut sur le support d'installation officiel de Gentoo. Il peut être plus efficace pour un utilisateur de Linux expérimenté d'utiliser screen afin de visualiser les instructions d'installation dans un cadre séparé plutôt que d'utiliser la technique des multiples TTY mentionnée ci-dessus.
Facultatif : démarrer le daemon SSH
Pour permettre à d'autres utilisateurs d'accéder au système lors de l'installation (peut-être pour obtenir de l'aide lors d'une installation, ou même la faire à distance), un compte utilisateur doit être créé (comme documenté plus tôt) et le serveur SSH doit être démarré.
Pour lancer le daemon SSH sur un système d'initialisation OpenRC, exécutez la commande suivante :
root #
rc-service sshd start
Si un utilisateur ouvre une session sur le système, il reçoit un message indiquant que la clé d'hôte pour ce système doit être confirmée (par le biais de ce qu'on appelle une empreinte digitale). Ceci est dû au fait que c'est la première fois que quelqu'un ouvre une session sur le système. Cependant, plus tard, lorsque le système est mis en place et que quelqu'un se connecte sur le nouveau système, le client SSH l'avertit que la clé de l'hôte a été changée. C'est parce que l'utilisateur – pour SSH – se connecte désormais à un serveur différent (à savoir le système Gentoo fraîchement installé plutôt qu'à l'environnement en cours d'utilisation pour l'installation ). Suivre alors les instructions données à l'écran pour remplacer la clé de l'hôte sur le système client.
Pour être en mesure d'utiliser sshd, le réseau a besoin de fonctionner correctement. Continuez l'installation avec le chapitre Configurer le réseau .
Détection automatique du réseau
Il est possible que la connexion au réseau soit déjà opérationnelle.
Si le système est connecté à un réseau Ethernet ayant un serveur DHCP, il est très probable que la connexion ait déjà été configurée automatiquement. Si tel est le cas, les nombreuses commandes réseau incluses sur le média d'installation, telles que ssh, scp, ping, irssi, wget, et links, fonctionneront immédiatement.
Utiliser DHCP
DHCP (Dynamic Host Configuration Protocol - Protocole de Configuration Dynamique des Hôtes) rend possible le fait de recevoir automatiquement des informations de mise en réseau (adresse IP, masque de sous-réseau, adresse de diffusion, passerelle, serveurs de noms, etc.). Cela ne fonctionne que si un serveur DHCP existe dans le réseau (ou si le fournisseur d'accès internet fournit un service DHCP). Pour qu'une interface réseau reçoive automatiquement ces informations, utilisez le daemon dhcpcd :
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 eth0
Certains administrateurs de réseau exigent que le nom d'hôte et le nom de domaine fourni par le serveur DHCP soient utilisés par le système. Dans ce cas, utilisez :
root #
dhcpcd -HD eth0
To stop dhcpcd, -x can be used:
root #
dhcpcd -x
sending signal Term to pid 10831 waiting for pid 10831 to exit
Dhcpcd usage
Tester le réseau
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
Si tout cela fonctionne, alors le reste de ce chapitre peut être ignoré pour passer directement à l'étape suivante de la procédure d'installation (Préparer les disques).
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.
Déterminer les noms des interfaces
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.
La commande ip peut être utilisée comme alternative à ifconfig pour déterminer les noms des interfaces. L'exemple suivant montre le résultat de la commande ip addr (d'un système différent que celui des exemples précédents) :
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 addr
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff inet 10.0.20.77/22 brd 10.0.23.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::ea40:f2ff:feac:257a/64 scope link valid_lft forever preferred_lft forever
The output of this command contains information for each network interface on the system. Entries begin with the device index, followed by the device name: enp1s0.
Si aucune interface n'est affichée lors de l'utilisation de la commande ifconfig, essayerz d'ajouter l'option
-a
. Cette option force l'utilitaire à afficher toutes les interfaces réseau détectées par le système quelque soit leur état d'activation. Si ifconfig -a ne produit aucun résultat alors le matériel est défectueux ou les pilotes de l'interface réseau n'ont pas été chargés dans le noyau. Ces deux cas ne sont pas couverts dans ce guide. Contactez le support #gentoo (webchat).Dans le reste de ce document, il sera assumé que l'interface réseau s'appelle eth0.
Suite à l'évolution vers des noms d'interfaces réseau prévisibles (EN), le nom des interfaces peut différer de l'ancien système de nommage en eth0. Les supports d'installation peuvent afficher des noms d'interface tels que eno0, ens1, ou encore enp5s0. Cherchez l'interface ayant une IP adresse liée au réseau local dans le résultat de la commande ifconfig.
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.
Facultatif : Configurer tous les proxys
Si l'Internet est accessible via un proxy, il est nécessaire de définir des informations de proxy lors de l'installation. Il est très facile de définir un proxy : il suffit de définir une variable qui contient les informations du serveur proxy.
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.
Dans la plupart des cas, il suffit de définir les variables à l'aide du nom d'hôte du serveur. Comme exemple, nous supposons que le proxy est appelé proxy.gentoo.org et le port 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.Pour configurer un proxy HTTP (pour le trafic HTTP et HTTPS) :
root #
export http_proxy="http://proxy.gentoo.org:8080"
Si le serveur proxy requiert un nom d'utilisateur et un mot de passe, utilisez la syntaxe suivante pour définir la variable :
http://username:password@proxy.gentoo.org:8080
Start links using the following parameters for proxy support:
user $
links -http-proxy ${http_proxy} -https-proxy ${https_proxy}
Pour configurer un proxy FTP :
root #
export ftp_proxy="ftp://proxy.gentoo.org:8080"
Start links using the following parameter for a FTP proxy:
user $
links -ftp-proxy ${ftp_proxy}
Pour configurer un proxy RSYNC :
root #
export RSYNC_PROXY="proxy.gentoo.org:8080"
Alternative : utilisation de PPP
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.
Alternative : utilisation de PPTP
Si le support PPTP est nécessaire, utilisez la commande pptpclient qui est fournie par le CD d'installation. Mais d'abord, assurez-vous que la configuration soit correcte. Modifiez le fichier /etc/ppp/pap-secrets ou /etc/ppp/chap-secrets pour qu'il contienne le bon nom d'utilisateur et mot de passe :
Edit /etc/ppp/pap-secrets or /etc/ppp/chap-secrets so it contains the correct username/password combination:
root #
nano -w /etc/ppp/chap-secrets
Puis peaufinez de/etc/ppp/options.pptp si nécessaire :
root #
nano -w /etc/ppp/options.pptp
Quand tout cela est fait, il suffit d'exécuter pptp (avec les options qui n'ont pu être définies dans options.pptp) pour se connecter au serveur :
root #
pptp <IPv4 du serveur>
Configurer l'accès sans fil
Do not use WEP unless it is the only option. WEP provides essentially no security over an open network.
La prise en charge de la commande iwconfig peut être spécifique à l'architecture. Si la commande n'est pas disponible, voir si le paquet net-wireless/iw est disponible pour l'architecture actuelle. La commande iw sera indisponible tant que le paquet net-wireless/iw n'aura pas été installé.
Lors de l'utilisation d'une carte réseau sans fil (802.11), les paramètres sans fil doivent être configurés avant d'aller plus loin. Pour voir les paramètres sans fil de la carte, on peut utiliser la commande iw. L'exécution de iw pourrait donner quelque chose qui ressemble à ceci :
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
Pour vérifier si une connexion active existe :
root #
iw dev wlp9s0 link
Not connected.
ou
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
Certaines cartes sans fil peuvent avoir un nom de périphérique wlan0 ou ra0 au lieu de wlp9s0. Exécutez ip link pour déterminer le nom correct du périphérique.
Pour la plupart des utilisateurs, il y a seulement deux paramètres importants pour se connecter, l'ESSID (ou nom du réseau sans fil) et, accessoirement, la clé WEP.
- S'assurer d'abord que l'interface soit activée :
root #
ip link set dev wlp9s0 up
- Pour se connecter à un réseau public portant le nom GentooNode :
root #
iw dev wlp9s0 connect -w GentooNode
- Pour se connecter avec une clé WEP hexadécimale, préfixez la clé avec
d:
:
root #
iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd
- Pour se connecter avec une clé WEP ASCII :
root #
iw dev wlp9s0 connect -w GentooNode key 0:<mot-de-passe>
Si le réseau sans fil est configuré avec WPA ou WPA2, alors wpa_supplicant doit être utilisé. Pour plus d'informations sur la configuration des réseaux sans fil sous Gentoo Linux, lire le chapitre sur les réseaux sans fil du manuel de Gentoo.
Confirmez les paramètres sans fil en utilisant la commande iw dev wlp9s0 link. Une fois que le réseau sans fil fonctionne, poursuivre avec la configuration des options réseau au niveau de l'adresse IP comme décrit dans la section suivante (Comprendre la terminologie réseau) ou utilisez l'outil net-setup comme décrit précédemment.
Configuration automatique du réseau
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 eth0
L'exécution de la commande net-setup posera quelques questions au sujet de l'environnement réseau. À la fin, la connexion réseau devrait fonctionner. Testez la connexion réseau comme indiqué précédemment. Si les tests sont positifs, félicitations ! Ignorez le reste de cette section et continuez avec Préparer les disques.
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.
Comprendre la terminologie réseau
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.
Configuration manuelle du réseau
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 -w /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 aux périphériques de type bloc
Les périphériques de type bloc
Étudions en détail les aspects de Gentoo et de Linux en général qui concernent les disques, incluant les périphériques de type bloc, les partitions, et les systèmes de fichiers de Linux. Une fois que les tenants et les aboutissants des disques seront compris, il sera possible d'établir les partitions et les systèmes de fichiers pour l'installation.
Pour commencer, intéressons-nous aux périphériques de type bloc. Les disques SCSI et Serial ATA sont tous les deux étiquetés avec des noms de périphérique tels que : /dev/sda, /dev/sdb, /dev/sdc, etc. Sur des machines plus modernes, les disques SSD NVMe basés sur PCI Express ont des noms de périphérique tels que : /dev/nvme0n1, /dev/nvme0n2, etc.
Le tableau suivant aidera les lecteurs à déterminer où trouver certaines catégories de périphériques de type bloc sur le système :
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. |
Les périphériques de type bloc ci-dessus représentent une interface abstraite pour le disque. Les programmes utilisateurs peuvent utiliser ces périphériques de type bloc pour interagir avec le disque sans se soucier de savoir s'il est SATA, SCSI ou quelque chose d'autre. Le programme peut simplement adresser le stockage sur le disque comme un groupe de blocs contigus de 4096 octets (4K), accessibles aléatoirement.
Introduction to block devices
Block devices
Placeholder for introduction to block devices specific to that architecture
Designing a partition scheme
Placeholder for designing a partition scheme specific to that architecture
Créer des systèmes de fichiers
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
Maintenant que les partitions ont été créées, il est temps d'y placer un système de fichiers. Dans la section suivante les différents systèmes de fichiers que Linux prend en charge seront décris. Les lecteurs qui connaissent déjà quel système de fichiers utiliser peuvent continuer avec Appliquer un système de fichiers à une partition. Les autres devraient continuer à lire pour en apprendre plus sur les systèmes de fichiers disponibles.
Les systèmes de fichiers
Plusieurs systèmes de fichiers sont disponibles. Certains d'entre eux sont considérés stables sur l'architecture amd64 - il est conseillé de se renseigner sur les systèmes de fichiers et leur prise en charge avant d'en choisir un plus expérimental pour les partitions importantes.
- btrfs
- Un système de fichiers de nouvelle génération offrant de nombreuses fonctionnalités avancées telles que l'instantané, l'auto-guérison via des sommes de contrôle, la compression transparente, les sous-volumes et le RAID intégré. Quelques distributions ont commencé à l'expédier comme une option prête à l'emploi, mais il n'est pas encore prêt pour la production. Les rapports de corruption du système de fichiers sont courants. Ses développeurs incitent les gens à utiliser la dernière version du noyau pour la sécurité car les plus anciens ont des problèmes connus. Cela a été le cas pendant des années et il est trop tôt pour dire si les choses ont changé. Les correctifs pour les problèmes de corruption sont rarement rétro-portés vers les noyaux plus anciens. Procéder avec prudence lors de l'utilisation de ce système de fichiers !
- ext2
- Il s'agit du système de fichiers Linux éprouvé, mais il n'a pas de journalisation des métadonnées, ce qui signifie que les vérifications de routine du système de fichiers ext2 au démarrage peuvent prendre beaucoup de temps. Il y a maintenant une grande sélection de systèmes de fichiers journalisés de nouvelle génération dont la cohérence peut être vérifiée très rapidement et qui sont donc généralement préférés à leurs homologues non journalisés. Les systèmes de fichiers journalisés empêchent les retards importants lorsque le système est démarré et que le système de fichiers se trouve dans un état incohérent.
- ext3
- La version journalisée du système de fichiers ext2, fournissant la journalisation des métadonnées pour une récupération rapide en plus d'autres modes de journalisation améliorés tels que les données complètes et la journalisation ordonnée des données. Il utilise un indice HTree qui permet des performances élevées dans presque toutes les situations. En bref, ext3 est un système de fichiers très bon et fiable.
- ext4
- Initialement créé en tant que fork de ext3, ext4 apporte de nouvelles fonctionnalités, des améliorations de performances et la suppression des limites de taille avec des modifications modérées du format sur le disque. Il peut couvrir des volumes allant jusqu'à 1 Eo, et avec une taille de fichier maximale de 16 To. Au lieu de l'allocation de blocs bitmap ext2/3 classique, ext4 utilise des extensions, ce qui améliore les performances des fichiers volumineux et réduit la fragmentation. Ext4 fournit également des algorithmes d'allocation de blocs plus sophistiqués (allocation différée et allocation multi-bloc) donnant au conducteur du système de fichiers plus de moyens d'optimiser la disposition des données sur le disque. Ext4 est le système de fichiers multi plate-forme tout usage recommandé.
- f2fs
- Le système de fichiers Flash-Friendly a été créé par Samsung pour l'utilisation avec la mémoire flash NAND. Depuis le deuxième trimestre 2016, ce système de fichiers est encore considéré comme immature, mais c'est un choix décent lors de l'installation de Gentoo sur des cartes microSD, des clés USB ou autres périphériques de stockage flash.
- JFS
- Le système de fichiers de journalisation hautes performances d'IBM. JFS est un système de fichiers basé sur l'arborescence B+ étantà la fois léger, rapide et fiable avec de bonnes performances dans diverses conditions.
- ReiserFS
- Un système de fichiers journalisé basé sur l'arborescence B+ qui a de bonnes performances globales, en particulier lorsqu'il s'agit de traiter de nombreux fichiers minuscules au prix de plusieurs cycles de processeur. ReiserFS semble être moins bien entretenu que les autres systèmes de fichiers.
- XFS
- Un système de fichiers avec journalisation des métadonnées, doté d'un ensemble de fonctionnalités robuste et optimisé pour l'évolutivité. XFS semble être moins indulgent dans le cas de problèmes matériels.
- vfat
- Également connu sous le nom FAT32, ce format est pris en charge par Linux mais ne prend pas en charge les paramètres d'autorisation. Il est principalement utilisé pour l'interopérabilité avec d'autres systèmes d'exploitation (principalement Microsoft Windows) mais est également une nécessité pour certains micrologiciels systèmes (comme UEFI).
- NTFS
- Ce système de fichiers New Technology est le système de fichiers phare de Microsoft Windows. Similaire à vfat ci-dessus, il ne stocke pas les paramètres d'autorisation ni les attributs étendus nécessaires au bon fonctionnement de BSD ou de Linux. Il ne peut donc pas être utilisé comme système de fichiers racine. Il devrait seulement être utilisé pour l'interopérabilité avec les systèmes Microsoft Windows (noter l'emphase sur seulement).
More extensive information on filesystems can be found in the community maintained Filesystem article.
Appliquer un système de fichiers à une 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.
Pour créer un système de fichiers sur une partition ou un volume, des outils sont disponibles pour chaque système de fichiers. Cliquer sur le nom du système de fichiers dans le tableau ci-dessous pour plus d'informations sur chaque système de fichiers :
Système de fichiers | Commande pour la création | Sur le CD minimal ? | Paquet |
---|---|---|---|
btrfs | mkfs.btrfs | Oui | sys-fs/btrfs-progs |
ext4 | mkfs.ext4 | Oui | sys-fs/e2fsprogs |
f2fs | mkfs.f2fs | Oui | sys-fs/f2fs-tools |
jfs | mkfs.jfs | Oui | sys-fs/jfsutils |
reiserfs | mkfs.reiserfs | Oui | sys-fs/reiserfsprogs |
xfs | mkfs.xfs | Oui | sys-fs/xfsprogs |
vfat | mkfs.vfat | Oui | sys-fs/dosfstools |
NTFS | mkfs.ntfs | Oui | sys-fs/ntfs3g |
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 few filesystem.
Par exemple, pour avoir la partition système EFI (/dev/sda1) en FAT32 et la partition racine (/dev/sda3) en ext4 comme utilisé dans l'exemple de structuration des partitions, les commandes suivantes doivent être utilisées :
root #
mkfs.ext4 /dev/sda3
EFI system partition filesystem
The EFI system partition (/dev/sda1) must be formatted as FAT32:
root #
mkfs.vfat -F 32 /dev/sda1
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/sda1
Small ext4 partitions
Lors de l'utilisation de ext4 sur une petite partition (moins de 8 Gio), le système de fichiers doit être créé avec les options appropriées pour réserver suffisamment de nœuds d'index ou inodes. Pour cela, utiliser la commande suivante :
root #
mkfs.ext4 -T small /dev/<device>
En général, ceci quadruple le nombre d' inodes pour un système de fichiers étant donné que son paramètre bytes-per-inode passe de un tous les 16 ko à un tous les 4 ko.
Activer la partition d'échange
mkswap est la commande à utiliser pour initialiser les partitions d'échange :
root #
mkswap /dev/sda2
Pour activer la partition d'échange, utilisez la commande swapon :
root #
swapon /dev/sda2
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.
Monter la partition racine
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
For EFI installs only, the ESP should be mounted under the root partition location:
root #
mkdir --parents /mnt/gentoo/efi
Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command.
Maintenant que les partitions ont été initialisées et hébergent un système de fichiers, il est temps de les monter. Utilisez la commande mount, mais n'oubliez pas de créer les points de montage nécessaires pour chaque partition. À titre d'exemple, nous montons la partition racine :
Mount the root partition:
root #
mount /dev/sda3 /mnt/gentoo
Continue mounting additional (custom) partitions as necessary using the mount command.
Si /tmp/ doit se trouver sur une partition séparée, pensez à changer ses droits d'accès après le montage :
root #
chmod 1777 /mnt/gentoo/tmp
Plus loin dans les instructions, le système de fichiers proc (une interface virtuelle avec le noyau) ainsi que d'autres pseudos systèmes de fichiers du noyau seront montés. Mais d'abord, nous devons installer les fichiers d'installation de Gentoo.
Choix d'une archive tar
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.La plupart des utilisateurs ne devrait pas utiliser les options d'archive tar 'avancées' ; elles existent pour des configurations logicielles et matérielles spécifiques.
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 et 64 bits)
Not every architecture has a multilib option. Many only run with native code. Multilib is most commonly applied to amd64.
Choisir une archive tar pour le système peut faire économiser beaucoup de temps plus tard dans le processus d'installation, notamment quand il est temps de choisir un profil système. Le choix d'une archive tar impactera directement la configuration future du système et peut éviter les maux de tête dans le futur. L'archive multilib utilise des bibliothèques 64 bits lorsque cela est possible et ne se replie que sur de versions 32 bits pour régler des problèmes de compatibilité. C'est une option excellente pour la majorité des installations car elle permet une grande flexibilité de personnalisation par le futur. Ceux qui souhaitent leur système capable de changer facilement de profil devraient télécharger l'archive tar multilib pour leur architecture de processeur respective.
Using
multilib
targets makes it easier to switch profiles later, compared to no-multilib
No-multilib (64 bits pur)
Les utilisateurs débutant avec Gentoo ne devraient pas choisir une archive tar no-multilib à moins que cela ne soit absolument nécessaire. La migration d'un système no-multilib vers un système multilib nécessite une connaissance avancée du fonctionnement de Gentoo et de la chaîne d'outils de niveau inférieur (cela peut même faire frémir nos développeurs Toolchain). Ce n'est pas pour les cœurs fragiles et cela dépasse largement la portée de ce guide.
Choisir une archive tar no-multilib en tant que base du système fournit un environnement de système d'exploitation 64 bits complet. Cela rend la capacité à passer vers des profils multilib improbable, bien que techniquement toujours possible.
Téléchargement de l'archive tar
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
Réglage de la date et de l'heure
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.
Vérifiez la date et l'heure actuelle avec la commande date :
root #
date
Mon Oct 3 13:16:22 PDT 2021
Si la date affichée est décalée de plus de quelques minutes, elle devrait être mise à jour avec précision en utilisant l'une des méthodes ci-dessous.
Automatiquement
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 #
ntpd -q -g
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.
Manuellement
When NTP access is unavailable, date can be used to manually set the system clock.
L'heure UTC est recommandée pour tous les systèmes Linux. Un fuseau horaire sera défini plus loin dans l'installation ; cela fera afficher l'heure locale par l'horloge.
Pour les systèmes n'ayant pas accès à un serveur de temps, la commande date peut également être utilisée pour effectuer un réglage manuel de l'horloge du système. Elle utilise le format suivant pour son argument : MMJJhhmmAAAA
(Mois, Jour, heure, minute, Année).
Par exemple, pour régler la date au 3 Octobre 2021 à 13:16 :
root #
date 100313162021
Ceux utilisant un environnement avec des navigateurs Internet graphiques n'auront aucun problème à copier l'adresse d'une archive tar depuis la section téléchargements du site principal. Sélectionnez simplement l'onglet approprié, clique-droit sur le lien vers l'archive tar, ensuite Copier l'adresse du lien pour copier le lien vers le presse-papiers, puis collez le lien à l'utilitaire wget en ligne de commande pour télécharger l'archive tar :
root #
wget <URL_DE_L_ARCHIVE_COLLEE>
Les lecteurs plus traditionnels ou utilisateurs de Gentoo 'vieux jeu', travaillant exclusivement depuis la ligne de commande peuvent préférer l'utilisation de links (www-client/links), un navigateur non graphique et orienté menus. Pour télécharger une archive tar, naviguez vers la liste des miroirs Gentoo comme suit :
root #
links https://www.gentoo.org/downloads/mirrors/
Pour utiliser un proxy HTTP avec links, passez l’URL avec l'option http-proxy
:
root #
links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/
Outre links, il y a également le navigateur lynx (www-client/lynx). Comme links c'est un navigateur non graphique mais celui-là n'est pas orienté menus.
root #
lynx https://www.gentoo.org/downloads/mirrors/
Si un proxy est nécessaire, exportez les variables http_proxy et/ou ftp_proxy :
root #
export http_proxy="http://proxy.server.com:port"
root #
export ftp_proxy="http://proxy.server.com:port"
Sur la liste de miroirs, choisissez-en un à proximité. En général les miroirs HTTP suffisent, mais d'autres protocoles sont également disponibles. Naviguez vers le répertoire releases/amd64/autobuilds/. Ici, toutes les archives tar disponibles sont affichées (elles peuvent être stockées dans des sous-répertoires nommés après les différents types d'architectures). Sélectionnez-en une et appuyez sur la touche d pour la télécharger.
Une fois le téléchargement de l'archive terminé, il es possible d'en vérifier l'intégrité et d'en valider son contenu. Les intéressés peuvent passer à la section suivante.
Ceux qui ne sont pas intéressés peuvent fermer le navigateur en ligne de commande en appuyant sur la touche q et peuvent aller directement à la section Extraction de l'archive tar.
Vérifier et valider
Most stages are now explicitly suffixed with the init system type (openrc or systemd), although some architectures may still be missing these for now.
Comme pour les CDs d'installation, il est possible de vérifier et de valider l'archive tar téléchargée. Bien que ces étapes peuvent être sautées, ces fichiers sont proposés pour les utilisateurs qui se soucient de la légitimité des fichiers qu'ils viennent de télécharger.
root #
wget https://distfiles.gentoo.org/releases/
- Un fichier .CONTENTS contient la liste de tous les fichiers contenus dans l'archive tar.
- Un fichier .DIGESTS contient les sommes de contrôle de l'archive tar dans plusieurs algorithmes différents.
- Un fichier .DIGESTS.asc qui, comme le fichier .DIGESTS, contient les sommes de contrôle de l'archive tar dans plusieurs algorithmes, mais qui est aussi signé de manière cryptographique afin de s'assurer qu'il soit bien fournit par le projet Gentoo.
Utilisez openssl et comparez les résultats avec les sommes de contrôle fournies par les fichiers .DIGESTS ou .DIGESTS.asc.
Par exemple, pour vérifier la somme de contrôle SHA512 :
root #
openssl dgst -r -sha512 stage3-amd64-<release>-<init>.tar.?(bz2|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.
Pour vérifier la somme de contrôle Whirlpool :
root #
openssl dgst -r -whirlpool stage3-amd64-<release>-<init>.tar.?(bz2|xz)
Comparez le résultat de ces commandes avec les valeurs enregistrées dans les fichiers .DIGESTS(.asc). Les valeurs doivent être identiques, sinon les fichiers téléchargés (ou le fichier digest) peuvent être corrompus.
Un autre façon de faire est d'utiliser la commande sha512sum :
root #
sha512sum stage3-amd64-<release>-<init>.tar.?(bz2|xz)
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.
Tout comme pour le fichier ISO, il est également possible de vérifier la signature cryptographique du fichier .DIGESTS.asc en utilisant gpg afin de s'assurer que les sommes de contrôle n'aient pas été modifiées :
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-amd64-<release>-<init>.tar.?(bz2|xz){.DIGESTS.asc,}
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.
Installation d'une archive tar
Maintenant, extraire l'archive téléchargée sur le système. Pour ce faire, utiliser la commande tar :
root #
tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner
Assurez-vous que les mêmes options (xpf
et --xattrs-include='*.*'
) sont utilisées. Le x
signifie extraire, le p
pour préserver les permissions et le f
pour signifier que l'on veut extraire un fichier (et non l'entrée standard). --xattrs-include='*.*'
permet de conserver les attributs étendus contenus dans tous les espaces de noms de l'archive. Finalement, --numeric-owner
est utilisé afin d'assurer que les identifiants de groupe et d'utilisateur des fichiers extraits de l'archive restent les mêmes que ceux voulus par l'équipe de Gentoo (même si certains utilisateurs aventureux n'utilisent pas les environnements live Gentoo officiels).
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).
Maintenant que l'archive est extraite, continuez avec la Configuration des options de compilation.
Configuration des options de compilation
Introduction
Pour optimiser le système, il est possible de configurer des variables qui influent sur le comportement de Portage, le gestionnaire de paquets officiel de Gentoo. Toutes ces variables peuvent être configurées en tant que variable d'environnement (en utilisant export), mais cela n'est pas 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.
{{{1}}}
Lancez un éditeur (dans ce guide nous utiliserons nano) pour modifier les variables d’optimisation décrites ci-dessous.
root #
nano -w /mnt/gentoo/etc/portage/make.conf
En regardant dans le fichier make.conf.example, la manière dans laquelle le fichier doit être structuré est évidente : les lignes commentées démarrent par #
, les autres lignes définissent des variables en utilisant la syntaxe VARIABLE="valeur"
. Plusieurs de ces variables sont présentées dans la section suivante.
CFLAGS et CXXFLAGS
Les variables CFLAGS et CXXFLAGS définissent les paramètres d'optimisation des compilateurs GCC C et C++, respectivement. Bien que ces variables soient généralement définies ici, il est possible, pour une performance maximale, d'optimiser ces paramètres pour chaque programme séparément. La raison pour cela est que chaque programme est différent. Cependant, ceci n'est pas gérable, d'où la définition de ces paramètres dans le fichier make.conf.
Dans make.conf il faut définir les paramètres d'optimisation qui rendront le système le plus réactif en général. Ne pas utiliser de configuration expérimentale dans cette variable ; trop d'optimisation peut faire que les programmes se comportent mal (plantage, ou pire, malfonctionnement).
Nous n'expliquerons pas toutes les options d'optimisation possibles. Pour les comprendre toutes, lire le manuel en ligne de GCC (en anglais) ou la page d'infos de gcc (info gcc - fonctionne seulement sur un système Linux). Le fichier make.conf.example contient également de lui-même beaucoup d'exemples et d'informations ; ne pas oublier de le lire également.
Un première configuration est le paramètre -march=
ou -mtune=
, qui spécifie le nom de l'architecture cible. Les options possibles sont décrites dans le fichier make.conf.example (en tant que commentaires). Une valeur souvent utilisée est native, qui informe au compilateur de sélectionner l'architecture cible du système utilisé (celui sur lequel est installé Gentoo).
Un second paramètre est -O
(un O majuscule et non un zéro), qui permet de spécifier la classe des paramètres d'optimisation de gcc. Les classes disponibles sont s (optimisé pour la taille), 0 (zéro - pour pas d'optimisations), 1, 2 ou même 3 pour plus d'optimisations de vitesse (chaque classe à les mêmes paramètres que la précédente plus quelques extras). -O2
est le défaut recommandé. -O3
est connu pour causer des problèmes quand utilisé pour tout le système, nous recommandons donc de rester avec -O2
.
Un autre paramètre d'optimisation populaire est -pipe
(qui permet l'utilisation de pipes à la place de fichiers temporaires pour la communication entre les différentes étapes de la compilation). Ce n'a aucun impact sur le code généré, mais utilise plus de mémoire. Sur des systèmes disposant de peu de mémoire vive, gcc peut être tué. Dans ce cas, ne pas utiliser ce paramètre.
Utiliser -fomit-frame-pointer
(qui ne garde pas la structure des pointeurs dans un registre pour les fonctions qui n'en ont pas besoin) peut avoir des répercussions importantes sur le débogage des programmes.
Quand les variables CFLAGS et CXXFLAGS sont définies, combinez les paramètres d'optimisation multiples dans une seule chaîne de caractères. Les valeurs par défaut contenues dans l'archive d'étape 3 qui est extraite devraient être suffisantes. Les valeurs suivantes ne sont qu'un exemple :
# Options de compilation pour tous les langages
COMMON_FLAGS="-march=native -O2 -pipe"
# Utiliser les mêmes paramètres pour les deux variables
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
Bien que l'article d'optimisation de GCC possède plus d'informations sur comment les différentes options de compilation affectent un système, l'article Safe CFLAGS peut se révéler plus pratique pour permettre aux débutants d'optimiser leurs systèmes.
MAKEOPTS
La variable MAKEOPTS définit combien de compilations parallèles peuvent se dérouler lors de l'installation d'un paquet. Un bon choix est le nombre de CPUs (ou cœurs du CPU) dans le système plus un, mais cette recommandation n'est pas toujours parfaite.
Further, as of Portage 3.0.53[1], 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.MAKEOPTS="-j2"
Search for MAKEOPTS in man 5 make.conf for more details.
A vos marques, prêts, partez !
Mettez à jour le fichier /mnt/gentoo/etc/portage/make.conf en fonction de vos préférences personnelles et enregistrez le (les utilisateurs de nano appuieront sur Ctrl+x).
References
Chrooting
Copier les informations DNS
Il reste une chose à faire avant d'entrer dans le nouvel environnement et c'est de copier les informations DNS dans /etc/resolv.conf. C'est nécessaire afin de s'assurer que le réseau fonctionne toujours même après être entré dans le nouvel environnement. /etc/resolv.conf contient les serveurs de nom pour le réseau.
Pour copier ces informations, il est recommandé de passer l'option --dereference
à la commande cp. Cela permet de s'assurer que, si /etc/resolv.conf est un lien symbolique, la cible du lien est copiée à la place du lien lui-même. Le lien symbolique dans le nouvel environnement ponterait autrement vers un fichier non existant (vu que la cible du lien n'existe probablement pas dans le nouvel environnement).
root #
cp --dereference /etc/resolv.conf /mnt/gentoo/etc/
Monter les systèmes de fichiers nécessaires
Dans quelques instants, la racine Linux sera modifiée vers le nouvel emplacement. Pour s'assurer que le nouvel environnement fonctionne correctement, certains systèmes de fichiers doivent également être mis à disposition.
Les systèmes de fichiers qui doivent être rendus disponibles sont:
- /proc/ qui est un pseudo système de fichiers (il ressemble à des fichiers normaux, mais est en fait généré à la volée) à partir duquel le noyau Linux expose des informations à l'environnement.
- /sys/ qui est un pseudo système de fichiers, comme /proc/ qu'il était autrefois sensé remplacer, et il est plus structuré que /proc/.
- /dev/ est un système de fichiers régulier, partiellement géré par le gestionnaire de périphérique de Linux (généralement udev) et qui contient tous les fichiers de périphériques.
L'emplacement /proc/ sera monté sur /mnt/gentoo/proc/ alors que les autres seront remontés ailleurs. Ce dernier signifie que, par exemple, /mnt/gentoo/sys/ sera en fait /sys/ (c'est juste un deuxième point d'entrée sur le même système de fichiers) alors que /mnt/gentoo/proc/ est un nouveau montage (nouvelle instance pour ainsi dire) du système de fichiers.
If using Gentoo's install media, this step can be replaced with simply: arch-chroot /mnt/gentoo.
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
Les opérations
--make-rslave
ne sont nécessaires que pour supporter systemd plus loin dans l'installation.Lorsqu'un support d'installation non officiel de Gentoo est utilisé, cela peut ne pas suffire. Certaines distributions font de /dev/shm un lien symbolique vers /run/shm/ qui, après le chroot, devient invalide. Faire de /dev/shm/ un montage tmpfs correct d'entrée permet de fixer ce problème :
root #
test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
root #
mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm
Assurez-vous également que le mode 1777 est appliqué :
root #
chmod 1777 /dev/shm /run/shm
Entrer dans le nouvel environnement
Maintenant que toutes les partitions sont initialisées et que l'environnement de base est installé, il est temps d'entrer dans le nouvel environnement d'installation en utilisant chroot. Cela signifie que la session changera de racine (emplacement de plus haut niveau pouvant être atteint) depuis l'environnement d'installation courant (cédérom d'installation ou autre support) vers le système d'installation (à savoir les partitions précédemment initialisées). D'où le nom change root ou chroot.
Ce processus de chroot se déroule en trois étapes:
- L'emplacement de la racine est changé de / (sur le support d'installation) à /mnt/gentoo/ (sur les partitions) en utilisant chroot.
- Certains paramètres (situés dans /etc/profile) sont rechargés en mémoire en utilisant la commande source.
- L'invite de commande principal est modifié afin de se rappeler plus facilement que cette session se situe dans un environnement chroot.
root #
chroot /mnt/gentoo /bin/bash
root #
source /etc/profile
root #
export PS1="(chroot) ${PS1}"
À partir de maintenant, toutes les actions réalisées le sont dans le nouvel environnement Gentoo. Bien sûr, c'est loin d'être fini, c'est pourquoi l'installation comporte encore de nombreuses sections !
Si l'installation de Gentoo est interrompue n'importe où après ce point, il devrait être possible de reprendre l'installation depuis cette étape. Il n'y a pas besoin de refaire le partitionnement des disques ! Il suffit simplement de monter la partition racine et d'exécuter les étapes ci-dessus depuis la copie des informations DNS pour réintégrer l'environnement de travail. Ceci est également utile pour résoudre les problèmes de chargeur d'amorçage. Plus d'informations peut être trouvé dans l'article sur chroot.
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.
UEFI systems
For UEFI systems, /dev/sda1 was formatted with the FAT32 filesystem and will be used as the EFI System Partition (ESP). Create a new /efi directory (if not yet created), and then mount ESP there:
root #
mkdir /efi
root #
mount /dev/sda1 /efi
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/sda1 /boot
Configurer Portage
Installer un instantané du dépôt ebuild Gentoo depuis le Web
L'étape suivant consiste à installer un instantané du dépôt ebuild Gentoo. Cet instantané contient une collection de fichiers qui informent Portage des logiciels disponibles (pour installation), quels profils l'administrateur système peut sélectionner, des informations spécifiques aux paquets ou profils, etc.
L'utilisation de la commande emerge-webrsync est recommandée pour ceux situés derrière des pare-feu restrictifs (elle utilise les protocoles HTTP/FTP pour télécharger l'instantané) et économise de la bande passante. Les lecteurs n'ayant pas de restriction de réseau ou de bande passante peuvent passer directement à la section suivante.
Ceci va récupérer le dernier instantané (qui est publié quotidiennement) depuis l'un des miroirs de Gentoo et l'installer sur le système:
root #
emerge-webrsync
Pendant cette opération, emerge-webrsync peut se plaindre d'un emplacement /var/db/repos/gentoo/ inexistant. Cela est à prévoir et n'est rien d'inquiétant - l'outil se chargera lui-même de créer l'emplacement.
À partir de ce moment, Portage peut mentionner que l'exécution de certaines mises à jour soit recommandée. Cela s'explique par le fait que certains paquets du système puissent avoir des versions plus récentes disponibles ; Portage est dès maintenant au courant des nouvelles versions en raison de l'installation de l'instantané. Les mises à jour peuvent être ignorées en toute sécurité pour l'instant ; les mises à jour peuvent être effectuées une fois l'installation de Gentoo terminée.
Facultatif : Sélectionner les miroirs
Afin de télécharger le code source rapidement, il est recommandé de sélectionner un miroir rapide. Portage cherche dans le fichier make.conf la variable GENTOO_MIRRORS et utilise les miroirs listés à l'intérieur. Il est possible de naviguer vers la liste des miroirs de Gentoo et de chercher pour ceux qui se situent le plus près de la position géographique du système (ce sont souvent les plus rapides). Cependant, nous offrons un outil appelé mirrorselect qui permet à l'utilisateur de sélectionner les miroirs nécessaires à l'aide d'une élégante interface. Il suffit juste de naviguer sur le miroir désiré et d'appuyer sur espace pour sélectionner un ou plusieurs miroirs.
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 #
mirrorselect -i -o >> /mnt/gentoo/etc/portage/make.conf
Alternatively, a list of active mirrors are available online.
Facultatif : Mettre à jour le dépôt ebuild de Gentoo
Il est possible de mettre à jour le dépôt ebuild de Gentoo vers la dernière version. La commande précédente emerge-webrsync aura installé un instantané récent (généralement moins de 24h) donc cette étape reste optionnelle.
S'il est cependant nécessaire d'avoir la version la plus récente du dépôt (moins d'une heure), utiliser emerge --sync. Cette commande utiliser le protocole rsync pour mettre à jour le dépôt ebuild de Gentoo (qui fut extrait plus tôt via emerge-webrsync) vers l'état le plus récent.
root #
emerge --sync
Sur les terminaux lents, comme certains framebuffers (tampon de trame) ou consoles série, il est recommandé d'utiliser l'option --quiet
pour accélérer le processus.
root #
emerge --sync --quiet
Lire les nouvelles
Quand le dépôt ebuild de Gentoo est synchronisé sur le système, Portage peut afficher des messages informatifs similaires à ceux-ci :
* IMPORTANT: 2 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.
Les nouvelles furent créées afin de fournir un moyen de communication permettant d'envoyer des messages critiques aux utilisateurs via le dépôt ebuild de Gentoo. Pour les gérer, utiliser eselect news. L'application eselect est un utilitaire spécifique à Gentoo qui permet d'avoir une interface de gestion commune pour l'administration système. Ici, eselect est invitée à utiliser son module de news
.
Pour le module de news
, trois opérations principales sont utilisées :
- Avec
list
, un aperçu des nouvelles disponibles s'affiche. - Avec
read
, les nouvelles peuvent être lues. - Avec
purge
, les nouvelles peuvent être supprimées une fois qu'elles ont été lues.
root #
eselect news list
root #
eselect news read
Plus d'information sur le lecteur de nouvelles est disponible via sa page de manuel :
root #
man news.eselect
Choisir le bon profil
Desktop profiles are not exclusively for desktop environments. They are also suitable for minimal window managers like i3 or sway.
Un profil est un élément de construction pour tout système Gentoo. Non seulement il spécifie des valeurs par défaut pour USE, CFLAGS, et autres variables importantes, il limite aussi aussi le système à une certaine gamme de version des paquets. Ces paramètres sont tous gérés par les développeurs Portage de Gentoo.
Pour voir quel profil le système utilise actuellement, lancer eselect avec le module profile
:
root #
eselect profile list
Available profile symlink targets: [1] default/linux/amd64/23.0 * [2] default/linux/amd64/23.0/desktop [3] default/linux/amd64/23.0/desktop/gnome [4] default/linux/amd64/23.0/desktop/kde
Le résultat de la commande n'est qu'un exemple et évolue avec le temps.
Comme on peut le voir, il existé également des sous-profils d'environnement de bureau disponibles pour certaines architecture.
Les mises à niveau de profil ne doivent pas être prises à la légère. Lors de la sélection du profil initial, veillez à utiliser le profil correspondant à la même version que celle initialement utilisée par stage3 (par exemple : 23.0). Chaque nouvelle version de profil est annoncée via une news contenant des instructions de migration. Assurez-vous de la lire et de suivre ces instructions avant de passer à un nouveau profil.
Après avoir visionné les profils disponibles pour l'architecture amd64, les utilisateurs peuvent sélectionner un profil différent pour le système :
root #
eselect profile set 2
This is a placeholder for architecture-specific profile information
Le sous-profil
developer
est spécifique au développement de Gentoo Linux et ne doit pas être utilisé par des utilisateurs normaux.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 (amd64 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.
Configuration de la variable USE
USE est l'une des variables les plus puissantes que Gentoo propose à l'utilisateur. Plusieurs programmes peuvent être compilés avec ou sans support facultatif pour certaines options. Par exemple, certains programmes peuvent être compilés avec le support pour GTK+ ou le support pour Qt. D'autres peuvent être compilés avec ou sans le support pour SSL. Certains programmes peuvent être compilés avec le support pour framebuffer (svgalib) au lieu du support pour X11 (X-server).
La plupart des distributions compilent leurs paquets avec autant de support que possible, augmentant la taille des programmes et les temps de démarrage, sans oublier de mentionner un nombre énorme de dépendances. Avec Gentoo, l'utilisateur peut choisir avec quelles options un package doit être compilé. C'est là que la variable USE entre en jeu.
Dans la variable USE, les utilisateurs définissent des mots-clés qui correspondent à des options du compilateur. Par exemple, ssl
ajoutera le support de SSL dans les programmes qui le supporte. -X
supprimera le support du serveur X (noter le signe moins devant). gnome gtk -kde -qt5
compilera les programmes avec le support de GNOME (et de GTK+), mais sans le support de KDE (et Qt), ce rend le système complètement adapté pour gnome (si l'architecture le permet).
Les paramètres par défaut de la variable USE sont placés dans le fichier make.defaults du profil Gentoo utilisé par le système. Gentoo utilise un système d'héritage (complexe) pour ses profils, qui ne sera pas expliqué plus en détail pour le moment. Le moyen le plus simple de vérifier les paramètres de la variable USE actuellement actifs est d'exécuter emerge --info et de sélectionner la ligne commençant par USE :
root #
emerge --info | grep ^USE
USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."
L'exemple ci-dessus est tronqué, la liste réelle des valeurs de la variable USE est beaucoup, beaucoup plus longue.
Un description complète des options de la variable USE peut se trouver sur le système dans /var/db/repos/gentoo/profiles/use.desc.
root #
less /var/db/repos/gentoo/profiles/use.desc
À l'intérieur de le commande less, le défilement peut s'effectuer à l'aide des touches ↑ et ↓, et le programme peut être fermé en appuyant sur q.
Par exemple, voici les paramètres de la variable USE pour un système basé sur KDE avec le support pour DVD, ALSA et l'enregistrement de CD :
root #
nano -w /etc/portage/make.conf
USE="-gtk -gnome qt4 qt5 kde dvd alsa cdr"
Quand la variable USE est définie dans /etc/portage/make.conf, les options sont ajoutées (ou supprimées si l'option commence par le signe -) de cette liste par défaut. Les utilisateurs qui souhaitent ignorer les paramètres par défaut de la variable USE et gérer toutes les options eux-mêmes doivent commencer la définition de la variable USE dans le fichier make.conf par -*
:
USE="-X acl alsa"
Bien que possible, utiliser
-*
(comme vu dans l'exemple ci-dessus) est découragé car les options par défaut de la variable USE, choisies avec soins, peuvent être configurées dans certains ebuild afin d'éviter les conflits et autres erreurs.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
The VIDEO_CARDS USE_EXPAND variable should be configured appropriately depending on the available GPU(s). Setting VIDEO_CARDS is not required for a console only install.
Below is an example of a properly set VIDEO_CARDS variable. Substitute the name of the driver(s) to be used.
VIDEO_CARDS="amdgpu radeonsi"
Details for various GPU(s) can be found at the AMDGPU, Intel, Nouveau (Open Source), or NVIDIA (Proprietary) articles.
Optionnel : Configurer la variable ACCEPT_LICENSE
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.
Gentoo est fourni avec des valeurs prédéfinies dans les profils, par exemple:
user $
portageq envvar ACCEPT_LICENSE
@FREE
Les groupes de licences définies dans le dépôt Gentoo, gérées par le projet Licences Gentoo, sont:
Nom du groupe | Description |
---|---|
@GPL-COMPATIBLE | Licences compatibles GPL approuvées par la Free Software Foundation [a_license 1] |
@FSF-APPROVED | Licences de logiciel libre approuvées par la FSF (contient @GPL-COMPATIBLE) |
@OSI-APPROVED | Licences approuvées par l'Open Source Initiative [a_license 2] |
@MISC-FREE | Licences diverses qui sont probablement des logiciels libre, c'est à dire qui suivent la Définition du logiciel libre [a_license 3] mais qui ne sont approuvées ni par la FSF ni par l'OSI. |
@FREE-SOFTWARE | Combine @FSF-APPROVED, @OSI-APPROVED et @MISC-FREE |
@FSF-APPROVED-OTHER | Licences approuvées par la FSF pour "documentation libre" et "œuvres à usage pratique autres que les logiciels et la documentation" (polices de caractères incluses) |
@MISC-FREE-DOCS | Licences diverses pour les documents libres et autres oeuvres (polices de caractères incluses) qui suivent la définition libre [a_license 4] mais qui NE sont PAS listées dans @FSF-APPROVED-OTHER |
@FREE-DOCUMENTS | Combine @FSF-APPROVED-OTHER et @MISC-FREE-DOCS |
@FREE | Méta-ensemble de toutes les licences avec liberté d'utilisation, partage, modification et partage de modifications.
Combine @FREE-SOFTWARE et @FREE-DOCUMENTS |
@BINARY-REDISTRIBUTABLE | Licences qui permettent au moins la libre redistribution du logiciel sous forme de binaire. Contient @FREE |
@EULA | Contrats de licences qui essaient de vous retirer des droits. Elles sont plus restrictives que "tous-droits-reservés" ou demandent un accord explicite. |
Some common license groups include:
Name | Description |
---|---|
@GPL-COMPATIBLE |
GPL compatible licenses approved by the Free Software Foundation [a_license 5] |
@FSF-APPROVED |
Free software licenses approved by the FSF (includes @GPL-COMPATIBLE )
|
@OSI-APPROVED |
Licenses approved by the Open Source Initiative [a_license 6] |
@MISC-FREE |
Misc licenses that are probably free software, i.e. follow the Free Software Definition [a_license 7] 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 8] 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 |
- ↑ https://www.gnu.org/licenses/license-list.html
- ↑ https://www.opensource.org/licenses
- ↑ https://www.gnu.org/philosophy/free-sw.html
- ↑ https://freedomdefined.org/
- ↑ https://www.gnu.org/licenses/license-list.html
- ↑ https://www.opensource.org/licenses
- ↑ https://www.gnu.org/philosophy/free-sw.html
- ↑ https://freedomdefined.org/
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.
Cela peut être customisé à l'échelle du système en éditant /etc/portage/make.conf. La valeur par défaut n'acceptera que les licences qui sont explicitement approuvées par la Free Software Foundation, l'Open Source Initiative, ou qui suivent la Définition du Logiciel Libre:
ACCEPT_LICENSE="-* @FREE"
Des dérogations par paquet peuvent alors être ajoutées si nécessaire et désiré, par exemple:
app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
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 @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
La variable LICENSE d'un ebuild n'est qu'une directive pour les développeurs Gentoo et les utilisateurs. Ce n'est pas une déclaration légale, et il n'y a aucune garantie que cela reflètera la réalité. Alors ne vous reposez pas dessus, mais vérifiez le paquet en profondeur, y compris tous les fichiers que vous utilisez.
Mettre à jour l'ensemble @world
L'étape suivante est nécessaire afin que le système puisse appliquer toutes les mises à jour ou modifications d'options de la variable USE apparues depuis la construction de l'archive de stage3 et de la sélection du profil :
- 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 --newuse @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
Si le profil d'un environnement de bureau complet a été choisi, ce processus pourrait augmenter considérablement le temps nécessaire à l'installation du système. Ceux en manque de temps peuvent utiliser cette règle de base : plus le nom du profil est court, moins l'ensemble @world du système ne sera spécifique ; moins l'ensemble @world n'est spécifique, moins de paquets ne seront requis par le système. Autrement dit :
- Choisir
default/linux/amd64/23.0
ne nécessitera la mise à jour que de peu de paquets, alors que - Choisir
default/linux/amd64/23.0/desktop/gnome/systemd
nécessitera l'installation de plusieurs paquets car le système d'initialisation changera de OpenRC vers systemd, et l'environnement de bureau GNOME sera installé.
Fuseau horaire
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.
Veuillez éviter les fuseaux horaires tels que /usr/share/zoneinfo/Etc/GMT* car leurs noms d'indiquent pas les zones attendues. Par exemple, GMT-8 est en réalité GMT+8.
Sélectionner le fuseau horaire pour le système. Rechercher les fuseaux horaires disponibles dans /usr/share/zoneinfo/ :
root #
ls /usr/share/zoneinfo
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 ...
Imaginons que le fuseau horaire choisi soit Europe/Brussels.
OpenRC
Écrire le nom du fuseau horaire dans le fichier /etc/timezone.
root #
echo "Europe/Brussels" > /etc/timezone
Ensuite, reconfigurer le paquet sys-libs/timezone-data, qui se chargera de mettre à jour le fichier /etc/localtime, en se basant sur le champ /etc/timezone. Le fichier /etc/localtime est utilisé par la bibliothèque C du système pour connaître dans quel fuseau horaire celui-ci se situe.
root #
emerge --config sys-libs/timezone-data
The /etc/localtime file is used by the system C library to know the timezone the system is in.
systemd
Une approche légèrement différente est employée quand systemd est utilisé. Un lien symbolique est généré :
root #
ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime
Later, when systemd is running, the timezone and related settings can be configured with the timedatectl command.
Configurer les paramètres régionaux
Cette étape ne s'applique pas aux utilisateurs de la libc musl. Les utilisateurs ne comprenant pas ce que cela signifie devraient suivre cette étape.
Génération des paramètres régionaux
La plupart des utilisateurs n'utiliseront qu'un ou deux paramètres régionaux sur leur système.
Les paramètres régionaux spécifient non seulement la langue que l'utilisateur doit utiliser pour interagir avec le système, mais aussi les règles pour trier les chaînes de caractères, afficher les dates et les heures, etc.
Les paramètres régionaux que le système doit supporter doivent être mentionnés dans /etc/locale.gen.
root #
nano -w /etc/locale.gen
Les paramètres régionaux suivant sont un exemple pour avoir et l'anglais (États-Unis) et le français (France) avec les formats de caractères correspondants (comme UTF-8).
en_US ISO-8859-1
en_US.UTF-8 UTF-8
fr_FR ISO-8859-1
fr_FR.UTF-8 UTF-8
Il est fortement recommandé d'utiliser au moins une option de paramètres régionaux en UTF-8 car beaucoup d'applications le requièrent.
L'étape suivante consiste à exécuter la commande locale-gen. Elle génère tous les paramètres régionaux spécifiés dans le fichier /etc/locale.gen.
root #
locale-gen
Pour vérifier que les paramètres régionaux sélectionnés sont maintenant disponibles, exécuter locale -a.
On systemd installs, localectl can be used, e.g. localectl set-locale ... or localectl list-locales.
Sélection du paramètre régional
Une fois terminé, il est maintenant temps de définir les paramètres régionaux du système. Encore une fois, eselect sera utilisé, cette fois avec le module locale
.
Avec eselect locale list, les choix disponibles sont affichés :
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] fr_FR [7] fr_FR.iso88591 [8] fr_FR.iso885915 [9] fr_FR.utf8 [10] POSIX [ ] (free form)
Avec eselect locale set <NOMBRE>, les paramètres régionaux corrects peuvent être sélectionnés :
root #
eselect locale set 9
Manuellement, cela peut être réalisé via le fichier /etc/env.d/02locale :
LANG="fr_FR.UTF-8"
LC_COLLATE="C.UTF-8"
Configurer un paramètre régional évitera des avertissements et erreurs lors des compilations du noyau et d'autres logiciels plus tard dans l'installation.
Mettre maintenant l'environnement à jour :
root #
env-update && source /etc/profile && export PS1="(chroot) ${PS1}"
Un guide complet sur les paramètres régionaux existe afin d'aider l'utilisateur lors de ce processus. Un autre article intéressant est l'article sur UTF-8 qui contient des informations spécifiques pour activer le support de l'UTF-8 sur le système.
References
Facultatif : Installation de micrologiciels
Microcode
Linux Firmware
Certains pilotes nécessite l'installation de micrologiciels supplémentaires sur le système pour fonctionner. C'est souvent le cas pour les interfaces réseau, notamment les interfaces réseau sans fil. Aussi, les cartes vidéos récentes, de vendeurs tels que AMD, NVidia, et Intel, nécessitent souvent des micrologiciels supplémentaires lors de l'utilisation du pilote libre. La plupart des micrologiciels se trouvent dans le paquet sys-kernel/linux-firmware :
Il est recommandé d'avoir le paquet sys-kernel/linux-firmware installé avant le premier redémarrage afin d'être sûr d'avoir tous les microcodes disponibles si nécessaire:
root #
emerge --ask sys-kernel/linux-firmware
Installer certains microcodes nécessite souvent d'accepter la licence associée. Si nécessaires, visitez la section gestion des licence du manuel pour de l'aide à propos des licences.
It is important to note that kernel symbols that are built as modules (M) will load their associated firmware files from the filesystem when they are loaded by the kernel. It is not necessary to include the device's firmware files into the kernel's binary image for symbols loaded as modules.
Architecture specific firmware
Placeholder for architecture-specific firmware information
Microcode
In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically this kind of firmware is referred to as microcode. Newer revisions of microcode are sometimes necessary to patch instability, security concerns, or other miscellaneous bugs in CPU hardware.
Microcode updates for AMD CPUs are distributed within the aforementioned sys-kernel/linux-firmware package. Microcode for Intel CPUs can be found within the sys-firmware/intel-microcode package, which will need to be installed separately. See the Microcode article for more information on how to apply microcode updates.
Configuration et compilation du noyau
Il est maintenant temps de configurer et de compiler les sources du noyau. Pour l'installation d'un système, trois approches pour la gestion du kernel vont être présentées, mais une approche différente pourra être utilisée une fois l'installation terminée.
Ranked from least involved to most involved:
- Le noyau est configuré et compilé manuellement.
- Un outil appelé genkernel est utilisé afin de configurer, compiler et installer automatiquement le noyau Linux.
Le cœur de toute distribution est le noyau Linux. C'est la couche située entre les programmes de l'utilisateur et le matériel du système. Même si le guide d'installation propose à ses utilisateurs plusieurs sources du noyau possibles, une liste complète des sources, avec description, est disponible sur la page Noyau - Vue d'ensemble.
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
Optional: Signing the kernel image (Secure Boot)
The kernel image in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) is already signed for use with Secure Boot. To sign the kernel image of kernels built from source enable the secureboot USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf. Note that signing the kernel image for use with secureboot requires that the kernel modules are also signed, the same key may be used to sign both the kernel image and the kernel modules:
USE="modules-sign secureboot"
# 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.
# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
The SECUREBOOT_SIGN_KEY and SECUREBOOT_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.
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second separate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.
See the above section for instructions on generating a new key, the steps may be repeated if a separate key should be used to sign the kernel image.
To successfully boot with Secure Boot enabled, the used bootloader must also be signed and the certificate must be accepted by the UEFI firmware or Shim. This will be explained later in the handbook.
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
Installer les sources
This section is only relevant when using the following genkernel (hybrid) or manual kernel management approach.
The use of sys-kernel/installkernel is not strictly required, but highly recommended. When this package is installed, the kernel installation process will be delegated to installkernel. This allows for installing several different kernel versions side-by-side as well as managing and automating several tasks relating to kernel installation described later in the handbook. Install it now with:
root #
emerge --ask sys-kernel/installkernel
When installing and compiling the kernel for amd64-based systems, Gentoo recommends the sys-kernel/gentoo-sources package.
Choisissez les sources du kernel appropriées et installez les en utilisant emerge :
root #
emerge --ask sys-kernel/gentoo-sources
Cela installera les sources du noyau Linux dans le répertoire /usr/src/, dans lequel un lien symbolique appelé linux pointera vers les sources du noyau installées :
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.21-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.21-gentoo
Configuration manuelle
Introduction
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.
Configurer manuellement un noyau est souvent considéré comme l'une des procédures des plus difficiles qu'un administrateur de systèmes Linux ait à réaliser. Rien n'est moins vrai - après avoir configuré quelques noyaux, plus personne ne se souviens que c'était difficile.
Cependant, une chose est vraie : c'est vital de connaître le système quand un noyau est configuré manuellement. La plupart des informations nécessaires peuvent être recueillies en installant le paquet sys-apps/pciutils qui contient la commande lspci :
root #
emerge --ask sys-apps/pciutils
À l'intérieur d'un chroot, il est possible d'ignorer sans risque toutes les mises en garde (du genrepcilib: cannot open /sys/bus/pci/devices) que lspci pourrait afficher.
Un autre source d'information est d'exécuter la commande lsmod pour voir quels modules du noyau sont utilisés par le média d'installation afin de savoir quoi activer plus tard.
Il est maintenant temps d'accéder au répertoire source du noyau et d'exécuter make menuconfig. Cela lancera un menu de configuration.
root #
cd /usr/src/linux
root #
make menuconfig
La configuration du noyau Linux comporte beaucoup, beaucoup de sections. Voici une liste des options qui doivent être activées (sinon Gentoo ne fonctionnera pas, ou incorrectement, sans modifications supplémentaires). Il existe également un Guide de configuration du noyau de Gentoo sur le wiki pouvant apporter plus d'informations.
Activation des options indispensables
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 --->
Generic Driver Options --->
[*] 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.
Activer le support pour les composants systèmes typiques
Bien s'assurer que tous les pilotes indispensables au démarrage du système (comme le contrôleur SCSI, etc.) soient compilés dans le noyau et non en tant que module, sinon le système de pourra pas démarrer correctement.
Ensuite, sélectionner le type exact du processeur. Il est également recommandé d'active les fonctionnalités MCE (si disponibles) afin que les utilisateurs puissent être notifiés de tout problème matériel. Sur certaines architectures (telles que x86_64), ces erreurs se sont pas affichées dans dmesg, mais dans /dev/mcelog. Cela nécessite le paquet app-admin/mcelog.
Aussi, sélectionner Maintain a devtmpfs file system to mount at /dev afin que le fichiers critiques des périphériques soient disponible au début du processus de démarrage. (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
Vérifier que le support pour les disques SCSI soit activé (CONFIG_BLK_DEV_SD):
Device Drivers --->
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)
Vérifiez que le support basique des NVMe a bien été activé :
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
Maintenant, aller dans File Systems et sélectionner la prise en charge des systèmes de fichiers qui seront utilisés. Attention, ne pas compiler le système de fichier utilisé par le système de fichier racine an tant que module, sinon Gentoo sera incapable de monter la partition. Aussi, sélectionner Virtual memory et /proc file system. Sélectionner également une ou plusieurs des options suivantes selon le système (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS) :
File systems --->
<*> Second extended fs support
<*> The Extended 3 (ext3) filesystem
<*> The Extended 4 (ext4) filesystem
<*> Reiserfs support
<*> JFS filesystem support
<*> XFS filesystem support
<*> Btrfs filesystem support
DOS/FAT/NT Filesystems --->
<*> MSDOS fs support
<*> VFAT (Windows-95) fs support
Pseudo Filesystems --->
[*] /proc file system support
[*] Tmpfs virtual memory file system support (former shm fs)
Si PPPoE, ou un modem analogique, est utilisé pour se connecter à Internet, activer les options suivantes(CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY) :
Device Drivers --->
Network device support --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
Les deux options de compression ne poseront pas de problème mais elle ne sont définitivement pas indispensables, pas plus que l'option de PPP sur Ethernet qui ne sera probablement utilisée que si configurée pour faire du mode PPPoE via le noyau.
Ne pas oublier d'inclure dans le noyau le support pour les cartes réseau (Ethernet ou sans fil).
La plupart des système possèdent également plusieurs cœurs à leur disposition, il est donc important d'activer l'option Symmetric multi-processing support (CONFIG_SMP) :
Processor type and features --->
[*] Symmetric multi-processing support
Dans les systèmes multi-cœur, chaque cœur compte comme un processeur.
Si des périphériques d'entrée USB (comme un clavier ou une souris), ou d'autres périphériques USB seront utilisés, ne pas oublier d'en activer le support (CONFIG_HID_GENERIC and CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD) :
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
Optionnel : Modules kernel signés
Pour automatiquement signer les modules kernels, activez l'option 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) --->
Vous pouvez changer l'algorithme de hash si vous le désirez.
Pour s'assurer que tous les modules signés le sont avec une signature valide, activez également l'option CONFIG_MODULE_SIG_FORCE :
[*] 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"
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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
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.
Optionnel: Signez l'image kernel (Secure Boot) ====
When signing the kernel image (for use on systems with Secure Boot enabled) it is recommended to set the following kernel config options:
General setup --->
Kexec and crash features --->
[*] Enable kexec system call
[*] Enable kexec file based system call
[*] Verify kernel signature during kexec_file_load() syscall
[*] Require a valid signature in kexec_file_load() syscall
[*] Enable ""image"" signature verification support
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] 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) --->
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
Security options --->
[*] Integrity subsystem
[*] Basic module for enforcing kernel lockdown
[*] Enable lockdown LSM early in init
Kernel default lockdown mode (Integrity) --->
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Digital signature verification using multiple keyrings
[*] Enable asymmetric keys support
-*- Require all keys on the integrity keyrings be signed
[*] Provide keyring for platform/firmware trusted keys
[*] Provide a keyring to which Machine Owner Keys may be added
[ ] Enforce Machine Keyring CA Restrictions
Where ""image"" is a placeholder for the architecture specific image name. These options, from the top to the bottom: enforces that the kernel image in a kexec call must be signed (kexec allows replacing the kernel in-place), enforces that kernel modules are signed, enables lockdown integrity mode (prevents modifying the kernel at runtime), and enables various keychains.
On arches that do not natively support decompressing the kernel (e.g. arm64 and riscv), the kernel must be built with its own decompressor (zboot):
Device Drivers --->
Firmware Drivers --->
EFI (Extensible Firmware Interface) Support --->
[*] Enable the generic EFI decompressor
After compilation of the kernel, as explained in the next section, the kernel image must be signed. First install app-crypt/sbsigntools and then sign the kernel image:
root #
emerge --ask app-crypt/sbsigntools
root #
sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --out /usr/src/linux-x.y.z/path/to/kernel-image
For this example the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second sperate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.
Then proceed with the installation.
To automatically sign EFI executables installed by other packages, enable the secureboot USE flag globally:
USE="modules-sign secureboot"
<div lang="en" dir="ltr" class="mw-content-ltr">
# 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
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
The SECUREBOOT_SIGN_KEY and SECUREBOOT_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.
When generating an Unified Kernel Image with systemd's
ukify
the kernel image will be signed automatically before inclusion in the unified kernel image and it is not necessary to sign it manually.Architecture specific kernel configurations
Placeholder for architecture-specific kernel build information
Compiling and installing
Placeholder for instructions for building and installing the kernel sources
Alternative : Utiliser genkernel
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.
Genkernel should only be considered by users that have a required need that only Genkernel can meet, otherwise it is recommended to use the Distribution kernel or manually compile your 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, such as Unified Kernel Images will need to be created manually when using Genkernel.
Genkernel provides a generic kernel configuration file and will compile the kernel and initramfs, then install the resulting binaries to the appropriate locations. This results in minimal and generic hardware support for the system's first boot, and allows for additional update control and customization of the kernel's configuration in the future.
Be informed: while using genkernel to maintain the kernel provides system administrators with more update control over the system's kernel, initramfs, and other options, it will require a time and effort commitment to perform future kernel updates as new sources are released. Those looking for a hands-off approach to kernel maintenance should use a distribution kernel.
For additional clarity, it is a misconception to believe genkernel automatically generates a custom kernel configuration for the hardware on which it is run; it uses a predetermined kernel configuration that supports most generic hardware and automatically handles the make commands necessary to assemble and install the kernel, the associate modules, and the initramfs file.
Binary redistributable software license group
If the linux-firmware package has been previously installed, then skip onward to the to the installation section.
As a prerequisite, due to the firwmare
USE flag being enabled by default for the sys-kernel/genkernel package, the package manager will also attempt to pull in the sys-kernel/linux-firmware package. The binary redistributable software licenses are required to be accepted before the linux-firmware will install.
This license group can be accepted system-wide for any package by adding the @BINARY-REDISTRIBUTABLE
as an ACCEPT_LICENSE value in the /etc/portage/make.conf file. It can be exclusively accepted for the linux-firmware package by adding a specific inclusion via a /etc/portage/package.license/linux-firmware file.
If necessary, review the methods of accepting software licenses available in the Installing the base system chapter of the handbook, then make some changes for acceptable software licenses.
If in analysis paralysis, the following will do the trick:
root #
mkdir /etc/portage/package.license
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Installation
Il est maintenant temps de voir comment utiliser genkernel. D'abord, installer sys-kernel/genkernel :
root #
emerge --ask sys-kernel/genkernel
Génération
Compilez les sources du noyau en exécutant genkernel all. Attention, vu que genkernel compile un noyau qui supporte presque tout type de matériel pour différentes architectures d'ordinateur, la compilation peut être longue.
SI la partition boot n'utilise pas le système de fichiers ext2 ou ext3, il peut être nécessaire de configurer le noyau en utilisant genkernel --menuconfig all et d'ajouter le support pour un système de fichiers spécifique dans le noyau (et non en tant que module). Les utilisateurs de LVM2 voudront probablement aussi ajouter l'argument
--lvm
.Les utilisateurs de LVM2 doivent ajouter
--lvm
comme argument à la commande genkernel ci-dessous.root #
genkernel --mountboot --install all
Une fois que gernkernel est terminé, un noyau, en ensemble complet de modules et une image initramfs seront créés. Le noyau et l'image initramfs seront utilisés plus tard lors de la configuration d'un système d'amorçage, il est donc bon de noter les noms du noyau et de l'image initramfs. L'image initramfs sera lancée immédiatement après le démarrage pour effectuer une détection automatique du matériel (comme pour le média d'installation) avant le démarrage réel du système.
root #
ls /boot/vmlinu* /boot/initramfs*
root #
ls /lib/modules
Installation du 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.
If unsure, follow the 'Traditional layout' subsection below.
systemd-boot
When using systemd-boot (formerly gummiboot) as the bootloader, systemd's kernel-install must be used. Therefore ensure the systemd and the systemd-boot USE flags are enabled on sys-kernel/installkernel, and then install the relevant package for systemd-boot.
Sur les systèmes OpenRC :
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #
emerge --ask sys-apps/systemd-utils
Sur les systèmes systemd :
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
root #
emerge --ask sys-apps/systemd
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. lilo, etc.)
The traditional /boot layout (for e.g. LILO, etc.) is used by default if the grub, systemd-boot and uki USE flags are not enabled. No further action is required.
Créer un initramfs
In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs. The default configuration of the Project:Distribution Kernel requires an initramfs.
Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass
--kernel-config=/path/to/kernel.config
to genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.Installkernel can automatically generate an initramfs when installing the kernel if the dracut USE flag is enabled:
sys-kernel/installkernel dracut
Alternatively, dracut may be called manually to generate an initramfs. Install sys-kernel/dracut first, then have it generate an initramfs:
root #
emerge --ask sys-kernel/dracut
root #
dracut --kver=6.6.21-gentoo
The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:
root #
ls /boot/initramfs*
Optionnel : Créer une image Kernel unifiée
An Unified Kernel Image (UKI) combines, among other things, the kernel, the initramfs and the kernel command line into a single executable. Since the kernel command line is embedded into the unified kernel image it should be specified before generating the unified kernel image (see below). Note that any kernel command line arguments supplied by the bootloader or firmware at boot are ignored when booting with secure boot enabled.
An unified kernel image requires a stub loader, currently the only one available is systemd-stub. To enable it:
Pour les systèmes systemd :
sys-apps/systemd boot
Pour les systèmes OpenRC :
sys-apps/systemd-utils boot kernel-install
Installkernel can automatically generate an unified kernel image using either dracut or ukify, by enabling the respective flag. The uki USE flag should be enabled as well to install the generated unified kernel image to the $ESP/EFI/Linux directory on the EFI system partition (ESP).
Pour dracut :
sys-kernel/installkernel dracut uki
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
Pour ukify:
sys-apps/systemd ukify # Pour les systèmes systemd
sys-apps/systemd-utils ukify # Pour les systèmes OpenRC
sys-kernel/installkernel dracut ukify uki
some-kernel-command-line-arguments
Note that while dracut can generate both an initramfs and an unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.
Image Kernel Générique Unifiée
The prebuilt sys-kernel/gentoo-kernel-bin can optionally install a prebuilt generic unified kernel image containing a generic initramfs that is able to boot most systemd based systems. It can be installed by enabling the generic-uki USE flag, and configuring installkernel to not generate a custom initramfs or unified kernel image:
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki
Secure Boot
The generic Unified Kernel Image optionally distributed by sys-kernel/gentoo-kernel-bin is already pre-signed. How to sign a locally generated unified kernel image depends on whether dracut or ukify is used. Note that the location of the key and certificate should be the same as the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT as specified in /etc/portage/make.conf.
Pour dracut :
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"
Pour ukify:
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem
Recompiler les modules kernel externes
External kernel modules installed by other packages via linux-mod-r1.eclass
must be rebuilt for each new kernel version. When the distribution kernels are used this may be automated by enabling the dist-kernel flag globally.
*/* dist-kernel
Les modules du kernel externes peuvent aussi être recompilés manuellement avec :
root #
emerge --ask @module-rebuild
Les modules du noyau
Lister les modules Kernels disponibles
Il est facultatif de lister manuellement les modules matériels. udev chargera normalement tous les modules pour les matériels détectés comme étant connectés dans la plupart des cas. Cependant, il n'est pas préjudiciable que les modules automatiquement chargés soient listés. Les modules ne peuvent pas être chargés deux fois: ils sont soit chargés, soit déchargés. Quelquefois, un matériel exotique nécessite de l'aide pour charger ses pilotes.
Les modules qui doivent être chargés automatiquement à chaque démarrage sont définis dans les fichiers /etc/modules-load.d/*.conf, un module par ligne. Cependant, lorsque des options supplémentaires doivent être ajoutées, elles doivent être ajoutés dans les fichiers /etc/modprobe.d/*.conf.
Pour voir tous les modules disponibles pour une version de kernel spécifiques, exécuter la commande find suivante. N'oubliez pas de remplacer "<version noyau>" par la version du noyau venant que vous souhaitez utiliser :
root #
find /lib/modules/<version noyau>/ -type f -iname '*.o' -or -iname '*.ko' | less
Forcer le chargement des modules kernel particuliers
Pour forcer le chargement du module 3c59x.ko (correspondant au pilote pour une carte réseau de la famille 3Com), éditez le fichier /etc/modules-load.d/network.conf et ajoutez-y le nom du module.
root #
mkdir -p /etc/modules-load.d
root #
nano -w /etc/modules-load.d/network.conf
Notez que le suffixe .ko des modules est insignifiant pour le mécanisme de chargement et n'apparaît pas dans le fichier de configuration
3c59x
Continuer l'installation avec Configuer le système.
Informations sur le système de fichiers
Étiquettes de systèmes de fichiers et UUIDs
MBR (BIOS) et GPT incluent tous les deux le support pour les étiquettes de système de fichiers et les UUIDs de système de fichiers. Ces attributs peuvent être définis dans /etc/fstab comme alternatives lors de l'utilisation de la commande mount pour détecter et monter les blocs de périphériques. Les étiquettes de système de fichiers et les UUIDs de système de fichiers sont identifiés par le préfixe LABEL et UUID et peuvent être visualisés grâce à la commande blkid :
root #
blkid
Si le système de fichiers à l'intérieur de la partition est supprimé, alors les valeurs d'étiquettes et d'UUIDs seront également modifiées ou supprimées.
En raison de leur unicité, les lecteurs utilisant des tables de partitions de type MBR sont recommandés d'utiliser les UUIDs à la place des étiquettes pour définir les volumes montables dans /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.
Étiquettes de partitions et UUIDs
Les utilisateurs qui opté pour l'utilisation de GPT ont quelques options plus robustes disponibles afin de définir les partitions dans /etc/fstab. Les étiquettes de partition et les UUIDs de partition peuvent être utilisés pour identifier les partitions individuelles du bloc de périphérique, quel que soit le système de fichiers choisi pour la partition elle-même. Les étiquettes de partition et les UUIDs sont identifiés par les préfixes PARTLABEL et PARTUUID respectivement et peuvent être consultés dans le terminal en exécutant la commande blkid :
Output for an amd64 EFI system using the Discoverable Partition Specification UUIDs may like the following:
root #
blkid
Bien que pas toujours vrai pour les étiquettes de partition, utiliser un UUID pour identifier une partition dans fstab garantit que le chargeur de démarrage ne sera pas confus en cherchant un volume spécifique, même si le système de fichiers change dans l'avenir. L'utilisation des anciens fichiers de bloc de périphériques par défaut (/dev/sd*N) pour définir les partitions dans fstab est risquée pour les systèmes qui sont redémarrés régulièrement et qui possèdent des blocs de périphériques SATA régulièrement ajoutés ou supprimés.
La dénomination des fichiers de périphériques de bloc dépend d'un certain nombre de facteurs, y compris comment et dans quel ordre les disques sont attachés au système. Ils peuvent également apparaître dans un ordre différent en fonction duquel les périphériques sont détectés par le noyau au cours du processus de démarrage. Cela étant dit, à moins que l'on ait l'intention de constamment jouer avec la commande de disque, l'utilisation des fichiers de périphériques par défaut est une approche simple et directe.
À propos de fstab
Sous Linux, toutes les partitions utilisées par le système doivent être listées dans /etc/fstab. Ce fichier contient les points de montage de ces partitions (où elles sont vues dans la structure du système de fichier), comment elles doivent être montées et avec quels paramètres (automatiquement ou non, si les utilisateurs peuvent les monter ou non, etc.)
Créer le fichier fstab
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.
Le fichier /etc/fstab utilise un format ressemblant à celui d'un tableau. Chaque ligne comporte six champs, séparés par des espaces blancs (espace, tabulation, ou les deux). Chaque champ à sa propre signification :
- Le premier champ indique le périphérique ou système de fichier distant à monter. Plusieurs types d'identificateurs sont disponibles pour les périphériques : chemin vers les fichiers du périphérique, étiquettes des systèmes de fichiers et UUIDs, étiquettes de partitions et UUIDs (Universally unique identifier - Identifiant universel unique).
- Le second champ indique le point de montage sur lequel la partition sera montée.
- Le troisième champ indique le système de fichier utilisé par la partition.
Le quatrième champ indique les options utilisées par mount lors du montage de la partition. Comme chaque système de fichiers à ses propres options de montage, les administrateurs système sont encouragés à lire la page de manuel de mount (man mount) pour une liste complète. Des options multiples sont séparées par une virgule.
- Le cinquième champ est utilisé par dump pour déterminer si la partition doit être sauvegardée ou non. Ce champ peut généralement être laissé à
0
. - Le sixième champ est utilisé par fsck pour déterminer dans quel ordre les systèmes de fichiers doivent être vérifiés si le système n'a pas été terminé correctement. Le système de fichier root devrait être à
1
et les autres à2
(ou0
si une vérification n'est pas nécessaire).
Le fichier /etc/fstab par défaut fourni par Gentoo n'est pas un fichier /etc/fstab valide, mais juste une sorte de modèle.
root #
nano -w /etc/fstab
DOS/Legacy BIOS systems
Regardons comment noter les options pour la partition /boot/. Ceci n'est qu'un exemple et doit être modifié en fonctions des décisions prises plus tôt dans l'installation. Dans notre exemple de partitionnement amd64, /boot/ est généralement la /dev/sda1 partition, avec ext2 comme système de fichier. Cette partition nécessite d'être vérifiée lors du délarrage et nous écrirons donc :
/dev/sda1 /boot ext2 defaults 0 2
Certains utilisateurs ne veulent pas que leur partition /boot/ soit montée automatiquement afin d'augmenter la sécurité de leur système. Ces personnes doivent remplacer defaults par noauto. Cela signifie que ces utilisateurs devront monter manuellement cette partition à chaque fois qu'ils voudront l'utiliser.
Ajouter les règles qui correspondent au schéma de partitionnement décidé précédemment et ajouter des règles pour les périphériques tels que les lecteurs de CD-ROM, et bien sûr, si d'autres partitions ou lecteurs sont utilisés, pour ceux-là également.
Ci-dessous est un exemple plus élaboré de fichier /etc/fstab :
/dev/sda1 /boot ext2 defaults,noatime 0 2
/dev/sda2 none swap sw 0 0
/dev/sda3 / ext4 noatime 0 1
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
/dev/cdrom /mnt/cdrom auto noauto,user 0 0 }}
UEFI systems
Below is an example of an /etc/fstab file for a system that will boot via UEFI firmware:
# Adjust for any formatting differences and/or additional partitions created from the "Preparing the disks" step
/dev/sda1 /efi vfat umask=0077 0 2
/dev/sda2 none swap sw 0 0
/dev/sda3 / xfs defaults,noatime 0 1
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
/dev/cdrom /mnt/cdrom auto noauto,user 0 0
Placeholder for architecture-specific fstab examples.
Quand auto
est utilisé en tant que troisième champ, cela fait deviner à la commande mount le système de fichiers utilisé. Cela est recommandé pour les supports amovibles car ils peuvent être créés avec des systèmes de fichiers différents. L'option user
dans le quatrième champ rend possible pour les utilisateurs non root de monter le 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.Bien vérifier le fichier /etc/fstab, sauvegarder, puis quitter avant de continuer.
Informations de mise en réseau
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.
Informations sur l'hôte et le domaine
L'un des choix qui incombe à l'administrateur système est de nommer son ordinateur. Cela peut sembler assez facile, mais la plupart des utilisateurs ont des difficultés à trouver un nom approprié pour le nom d'hôte. Pour aider, il est bon de savoir que cette décision n'est pas finale - cela peut être changé par la suite. Dans les exemples ci-dessous, le nom d'hôte tux est utilisé avec le domaine homenetwork.
Set the hostname (OpenRC or systemd)
root #
echo tux > /etc/hostname
systemd
Pour configurer le nom d'hôte du système, l'utilitaire hostnamectl est utilisé.
Pour définir le nom d'hôte à "tux", exécuter :
root #
hostnamectl hostname tux
Pour afficher l'aide, exécuter hostnamectl --help ou man 1 hostnamectl.
Réseau
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 (tout système d'initialisation)
Most LAN networks operate a DHCP server. If this is the case, then using the dhcpcd program to obtain an IP address is recommended.
Pour installer :
root #
emerge --ask net-misc/dhcpcd
Pour activer puis lancer le service sur un système OpenRC :
root #
rc-update add dhcpcd default
root #
rc-service dhcpcd start
Pour activer puis lancer le service sur un système systemd :
root #
systemctl enable --now 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)
Configurer le réseau
Lors de l'installation de Gentoo Linux, la mise en réseau a déjà été configurée. Cependant, c'était pour l'environnement live et non pour l'environnement installé. Ici, la configuration du réseau est réalisée pour le système Gentoo Linux installé.
Des informations plus détaillées sur la mise en réseau, incluant des sujets avancés tels que bonding, bridging, VLANs 802.1Q ou les réseaux sans fils se trouvent dans la section configuration réseau avancée.
Toutes les informations concernant la mise en réseau sont regroupées dans le fichier /etc/conf.d/net. Ce fichier utilise une syntaxe directe mais peu intuitive. Pas de panique, tout est expliqué plus bas. Un exemple complet et commenté couvrant plusieurs configurations possibles se trouve dans /usr/share/doc/netifrc-*/net.example.bz2.
D'abord, installer net-misc/netifrc :
root #
emerge --ask --noreplace net-misc/netifrc
DHCP est utilisé par défaut. Pour que DHCP fonctionne, un client DHCP doit être installé. Cela est expliqué plus tard lors de l'installation des outils systèmes nécessaires.
SI la connexion au réseau doit être configurée à cause d'options DHCP spécifiques or car DHCP n'est pas du tout utilisé, alors ouvrir le fichier /etc/conf.d/net :
root #
nano -w /etc/conf.d/net
Configurer les deux variables config_eth0 et routes_eth0 avec les informations d'adresse IP et de routage appropriées :
On suppose que l'interface réseau s’appellera eth0. Cela est, cependant, entièrement dépendant du système. Il est recommandé de supposer que l'interface portera la même nom que lors du démarrage depuis le support d'installation si le support d'installation utilisé est suffisamment récent. Plus d'informations sont accessibles dans la section Nommage de l'interface réseau.
config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"
Pour utiliser DHCP, définir la variable config_eth0>/var> :
config_eth0="dhcp"
Lire /usr/share/doc/netifrc-*/net.example.bz2 pour une liste d'options de configuration supplémentaires. Lire également la page de manuel de DHCP si des options DHCP spécifiques doivent être utilisées.
Si le système possède plusieurs interfaces réseau, répéter les étapes précédentes pour config_eth1, config_eth2, etc.
Sauvegarder la configuration et quitter avant de continuer.
Démarrer automatiquement la mise en réseau au démarrage
Pour activer les interfaces réseau lors du démarrage, elles doivent être ajoutées au runlevel par défaut.
root #
cd /etc/init.d
root #
ln -s net.lo net.eth0
root #
rc-update add net.eth0 default
Si le système possède plusieurs interfaces réseau, les fichiers appropriés net.* doivent être crées de la même manière que pour net.eth0.
Si, après le démarrage du système, il est découvert que le nom de l'interface réseau (qui est actuellement documentée comme eth0
) était erronée, exécuter les étapes suivantes afin de rectifier le problème :
- Mettre à jour le fichier /etc/conf.d/net avec le nom d'interface correct (comme
enp3s0
ouenp5s0
, au lieu deeth0
). - Créer un nouveau lien symbolique (comme /etc/init.d/net.enp3s0).
- Supprimer l'ancien lien symbolique (rm /etc/init.d/net.eth0).
- Ajouter le nouveau au runlevel par défaut.
- Supprimer l'ancien en utilisant la commande rc-update del net.eth0 default.
Le fichier d'hôtes
Ensuite, informer Linux sur l'environnement réseau. Cela se fait dans le fichier /etc/hosts et aide à la résolution des noms de domaines aux adresses IPs pour les hôtes qui ne sont pas résolus par les serveurs de noms.
root #
nano -w /etc/hosts
# Cela définie le système actuelle et doit être mis
127.0.0.1 tux.homenetwork tux localhost
# Définitions optionnelles d'autres systèmes sur le réseau
192.168.0.5 jenny.homenetwork jenny
192.168.0.6 benny.homenetwork benny
Sauvegarder et quitter l'éditeur pour continuer.
Informations système
Mot de passe root
Configurer le mot de passe root en utilisant la commande passwd.
root #
passwd
Le compte Linux root est un compte des plus puissants, il est donc important de choisir un mot de passe fort. Plus tard, un compte utilisateur régulier sera créé pour les utilisations quotidiennes.
Configuration de l'initialisation et du démarrage
OpenRC
Quand OpenRC est utilisé avec Gentoo, il utilise le fichier /etc/rc.conf pour configurer les services, le démarrage et l'arrêt d'un système. Ouvrir /etc/rc.conf et s'émerveiller devant tous les commentaires du fichier. Vérifier les configurations et les modifier si nécessaire.
root #
nano -w /etc/rc.conf
Ensuite, ouvrir le fichier /etc/conf.d/keymaps afin de gérer la configuration du clavier. Le modifier pour configurer et sélectionner le bon clavier.
root #
nano -w /etc/conf.d/keymaps
Prendre bien soin lors de la configuration de la variable keymap. Si le mauvais schéma de clavier est sélectionné, il se passera des choses bizarres lors de l'utilisation du clavier.
Finalement, modifier le fichier /etc/conf.d/hwclock afin de configurer les options d'horloge.
root #
nano -w /etc/conf.d/hwclock
Si l'horloge matérielle n'utilise pas UTC, il est nécessaire de configurer clock="local"
dans le fichier. Sinon le système peut montrer des comportements d'horloge faussés.
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-firstboot --prompt --setup-machine-id
Next users should run systemctl to reset all installed unit files to the preset policy values:
root #
systemctl preset-all
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.
Outil de journalisation du système
OpenRC
Quelques outils sont absents de l'archive tar d'étape 3 car plusieurs paquets fournissent la même fonctionnalité. Le choix est laissé à l'utilisateur de savoir quels paquets installer.
Le premier outil sur lequel un choix doit se faire est un outil de journalisation pour le système. Unix et Linux ont un historique excellent de capacités de journalisations - si besoin, tout ce qui se passe sur le système peut être enregistré dans des journaux.
Gentoo offre plusieurs utilitaires de journalisation, notamment :
- app-admin/sysklogd - Offre l'ensemble traditionnel des démons de journalisation système. La configuration par défaut fonctionne correctement ce qui fait de ce paquet une bonne option pour les débutants.
- app-admin/syslog-ng - Un système de journalisation avancé. Nécessite une configuration supplémentaire pour fonctionner au delà de la journalisation dans un seul gros fichier. Les utilisateurs avancés peuvent choisir ce système de journalisation du fait de son potentiel mais attention, un configuration est nécessaire pour une journalisation intelligente.
- app-admin/metalog - Un système de journalisation hautement configurable.
D'autres sont disponibles depuis Portage - le nombre de paquets disponibles augmente tous les jours.
Si syslog-ng sera utilisé, il est recommandé d'installer et de configurer logrotate par la suite car il ne fournit aucun mécanisme de rotation pour les fichiers du journal. Les nouvelles versions (>= 2.0) de sysklogd intègrent par contre leur propre mécanisme de rotation.
Pour installer l'outil de journalisation désiré, installez-le. Sur OpenRC, ajoutez-le au niveau d'exécution par défaut en utilisant rc-update. L'exemple suivant installe app-admin/sysklogd :
root #
emerge --ask app-admin/sysklogd
root #
rc-update add sysklogd default
systemd
Les utilisateurs de systemd peuvent normalement passer cette étape, à moins qu'ils souhaitent spécifiquement un outil de journalisation système. systemd inclut journald, qui fournit déjà cette fonctionnalité.
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.
Facultatif : daemon Cron
OpenRC
Ensuite viens le daemon cron. Bien que cela soit facultatif et pas nécessaire pour tous les systèmes, il est judicieux d'en installer un.
Un démon cron exécute des commandes programmées. Cela est très utile si certaines commandes doivent être exécutées régulièrement (à intervalle quotidienne, hebdomadaire ou mensuelle).
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 offre plusieurs démons cron possibles, notamment sys-process/bcron, sys-process/dcron, sys-process/fcron, et sys-process/cronie. Installer l'un d'entre eux est similaire à l'installation d'un système de journalisation. L'exemple suivant utilise sys-process/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.
- sys-process/dcron - This lightweight cron daemon aims to be simple and secure, with just enough features to stay useful.
- sys-process/fcron - A command scheduler with extended capabilities over cron and anacron.
- 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.
cronie
The following example uses sys-process/cronie:
root #
emerge --ask sys-process/cronie
Sur OpenRC :
root #
rc-update add cronie default
Sur systemd :
root #
systemctl enable cronie
root #
rc-update add cronie default
Alternative: dcron
root #
emerge --ask sys-process/dcron
Si dcron est utilisé, une commande d'initialisation supplémentaire doit être exécutée :
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.
Facultatif : Indexation des fichiers
Pour indéxer le système de fichiers afin de fournir des fonctions de recherche plus rapides, installez sys-apps/mlocate.
root #
emerge --ask sys-apps/mlocate
Facultatif : Accès distant
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.
Pour pouvoir accéder au système à distance après l'installation, sshd doit être configuré pour être lancé au démarrage.
OpenRC
Pour ajouter le script sshd au niveau d'exécution par défaut, sur OpenRC :
root #
rc-update add sshd default
Si l'accès à la console série est nécessaire (ce qui est possible dans le cas de serveurs distants), agetty doit être configuré.
Sur OpenRC, décommenter la section sur la console série dans /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
Sur systemd :
root #
systemctl enable sshd
Sur systemd :
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.
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.
Pour installer Chrony, par exemple :
root #
emerge --ask net-misc/chrony
OpenRC
Sur OpenRC :
root #
rc-update add chronyd default
systemd
Sur systemd :
root #
systemctl enable chronyd
Alternatively, systemd users may wish to use the simpler systemd-timesyncd SNTP client which is installed by default.
root #
systemctl enable systemd-timesyncd.service
Outils de systèmes de fichiers
En fonction des systèmes de fichiers utilisés, il est nécessaire d'installer les utilitaires de systèmes de fichiers requis (pour vérifier l'intégrité su système de fichiers, créer des systèmes de fichiers additionnels, etc.). Noter que les outils pour gérer les système de fichiers ext4 (sys-fs/e2fsprogs) sont déjà installé dans le cadre de l'ensemble @system.
Le tableau suivant liste les outils à installer si un certain système de fichiers est installé :
Système de fichiers | Paquet |
---|---|
Ext 4 | sys-fs/e2fsprogs |
XFS | sys-fs/xfsprogs |
ReiserFS | sys-fs/reiserfsprogs |
JFS | sys-fs/jfsutils |
VFAT (FAT32, ...) | sys-fs/dosfstools |
Btrfs | sys-fs/btrfs-progs |
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
Pour plus d'informations sur les systèmes de fichiers dans Gentoo, se réfrérer à l'article sur les systèmes de fichiers.
Outils de mise en réseau
Si il n'est pas nécessaire d'installer d'outils de mise en réseau supplémentaires, continuer immédiatement avec la section sur la Configuration d'un système d'amorçage
Installer un client DHCP
Bien que facultatif, la majorité des utilisateurs nécessitent un client DHCP pour se connecter au serveur DHCP de leur réseau. Profiter de cette opportunité pour installer un client DHCP. Ci cette étape est oubliée, le système peut alors être incapable de se connecter au réseau rendant ainsi impossible le téléchargement d'un client DHCP par la suite.
Pour que le système obtienne automatiquement une adresse IP pour un ou plusieurs interfaces réseau utilisant des scripts netifrc, il est nécessaire d'installer un client DHCP. Nous recommandons l'utilisation du paquet net-misc/dhcpcd même si de nombreux autres client DHCP sont disponibles dans le répertoire Gentoo :
root #
emerge --ask net-misc/dhcpcd
Facultatif : Installer un client PPPoE
SI PPP est utilisé pour se connecter à Internet, installer le paquet net-dialup/ppp :
root #
emerge --ask net-dialup/ppp
Facultatif : Installer des outils de réseau sans fil
Si le système doit se connecter à des réseaux sans fil, installez le paquet net-wireless/iw pour les réseaux Open ou WEP et/ou le paquet net-wireless/wpa_supplicant pour les réseaux WPA ou WPA2. . iw est également un outil de diagnostic utile pour scanner les réseaux sans fil.
root #
emerge --ask net-wireless/iw net-wireless/wpa_supplicant
Maintenant, continuer avec la Configuration du système d'amorçage
Placeholder for architecture-specific bootloader installation
Redémarrer le système
Quittez l'environnement et démontez toutes les partitions montées. Ensuite, exécutez cette commande magique qui lance le vrai test final : reboot.
root #
exit
cdimage ~#
cd
cdimage ~#
umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~#
umount -R /mnt/gentoo
cdimage ~#
reboot
N'oubliez pas de retirer le CD d'installation, sinon il pourrait être redémarré à la place du nouveau système Gentoo.
Une fois redémarré dans le nouvel environnement Gentoo, finir avec Finalisation de l’installation de Gentoo.
Gestion des utilisateurs
Ajouter un utilisateur pour un usage quotidien
Travailler en tant que root sur un système Unix/Linux est dangereux et doit être évité autant que possible. Par conséquent, il est fortement recommandé d'ajouter un utilisateur pour une utilisation quotidienne.
Les groupes auxquels appartient l'utilisateur définissent quelles activités ce dernier peut effectuer. Le tableau suivant liste un certain nombre de groupes importants :
Group | Description |
---|---|
audio | Possibilité d'utiliser les périphériques audio. |
cdrom | Possibilité d'accéder directement aux périphériques optiques. |
floppy | Possibilité d'accéder directement aux lecteurs de disquettes. |
games | Possibilité d'accéder aux jeux. |
portage | Possibilité d'accéder aux ressources restreintes de portage. |
usb | Possibilité d'accéder aux périphériques USB. |
video | Possibilité d'accéder aux périphériques de capture vidéo et d'utiliser l'accélération matérielle. |
wheel | Possibilité d'utiliser la commande su. |
Par exemple, pour créer un utilisateur appelé larry qui est membre des groupes wheel, users, et audio, se connecter d'abord en tant que root (seul root peut créer de nouveaux utilisateurs) puis exécuter useradd :
Login:
root
Password: (Entrer le mot de passe root)
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: (Entrer le mot de passe pour larry) Re-enter password: (Confirmer le mot de passe)
Temporarily elevating privileges
Si jamais un utilisateur a besoin d'effectuer une opération en tant que root, il peut utiliser su - pour recevoir temporairement les privilèges de root. Un autre moyen est d'utiliser les utilitaires sudo (app-admin/sudo) ou doas (app-admin/doas) qui, si configurés correctement, sont très sécurisés.
Disabling root login
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
Nettoyage du disque
Suppression des archives
Une fois l'installation de Gentoo terminée et le système redémarré, si tout s'est bien passé, il est possible de supprimer l'archive stage3 du disque dur. Rappelez-vous qu'elle se situe dans le répertoire racine /.
The files are located in the / directory and can be removed with the following command:
root #
rm /stage3-*.tar.*
Et maintenant ?
Et maintenant ? Que faire ? Que reste-t-il à explorer ? Gentoo offre à ses utilisateurs de nombreuses possibilités, et donc de nombreuses fonctionnalités, documentées pour la plupart.
Documentation supplémentaire
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.
Il est fortement conseillé de lire la prochaine partie du manuel Gentoo, intitulée Travailler avec Gentoo, qui explique comment maintenir le système à jour, comment installer de nouveaux logiciels, ce que sont les options de la variable USE, comment fonctionne le système d'initialisation de Gentoo, etc.
Outre le fait de lire ce manuel, il est recommandé d'explorer d'autres coins du wiki Gentoo afin de trouver une documentation supplémentaire proposée par la communauté. L'équipe du wiki Gentoo offre également un Aperçu de la documentation répertoriant une sélection des articles trouvés sur ce wiki. Par exemple, il référence le guide des paramètres régionaux pour faire en sorte qu'un système se sente comme à la maison.
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 sur le web
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 et IRC
Tout le monde est bien toujours le bienvenu sur nos forums Gentoo ou l'un de nos nombreux canaux IRC Gentoo
Listes de diffusion
Nous avons aussi plusieurs listes de diffusion ouvertes à tous nos utilisateurs. Les informations sur comment rejoindre se situent sur cette page.
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
Profitez de votre installation !
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 amd64 Handbook: Installing Gentoo" overrides earlier display title "Handbook:Parts/Full/Installation/fr".