Handbook:PPC64/Installation/Stage/fr

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:PPC64/Installation/Stage and the translation is 100% complete.
Sommaire du manuel
Installation
‎À propos de l'installation
Choix du support
Configurer le réseau
Préparer les disques
Installer l'archive stage3
Installer le système de base
Configurer le noyau
Configurer le système
Installer les outils
Configurer le système d'amorçage
Finaliser
Utiliser Gentoo
Introduction à Portage
Les options de la variable USE
Les fonctionnalités de Portage
Scripts d'initialisation systèmes
Variables d'environnement
Utiliser Portage
Fichiers et répertoires
Les variables
Mélanger plusieurs branches logicielles
Outils supplémentaires
Dépôt personnalisé
Fonctionnalités avancées
Configuration du réseau
Bien démarrer
Configuration avancée
Les modules réseau
Sans fil
Ajouter des fonctionnalités
Gestion dynamique


Conseil
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.

Important
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)

Remarque
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.

Conseil
Using multilib targets makes it easier to switch profiles later, compared to no-multilib

No-multilib (64 bits pur)

Attention !
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

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
Important
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.
Attention !
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

Accédez au point de montage de Gentoo où se trouve le système de fichier racine (probablement /mnt/gentoo) :

root #cd /mnt/gentoo

Navigateurs graphiques

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>

Navigateurs en ligne de commande

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/ppc64/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

Remarque
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-ppc64-<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-ppc64-<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-ppc64-<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-ppc64-<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.

Remarque
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.

Conseil
{{{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 :

CODE Exemple des variables CFLAGS et CXXFLAGS
# Options de compilation pour tous les langages
COMMON_FLAGS="-O2 -pipe"
# Utiliser les mêmes paramètres pour les deux variables
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
Conseil
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.

Attention !
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.
Conseil
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.
CODE Exemple de déclaration de MAKEOPTS dans make.conf
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).