Translations:Handbook:X86/Installation/Stage/2/fr
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-multilibNo-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 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 #dateMon 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 -gSystems 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 100313162021Ceux 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//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--<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--<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--<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.ascFor 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 --importVerify the signature of the tarball and, optionally, associated checksum files:
root #gpg --verify stage3--<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 --xattrs-include='*.*' --numeric-ownerAssurez-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).
xextract, instructs tar to extract the contents of the archive.ppreserve permissions.vverbose output.ffile, provides tar with the name of the input archive.--xattrs-include='*.*'Preserves extended attributes in all namespaces stored in the archive.--numeric-ownerEnsure 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.confEn 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=""
# 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