Handbook:PPC/Installation/Kernel/fr
Facultatif : Installation de micrologiciels
Microcode
Micrologiciel Linux
Sur beaucoup de systèmes, les micrologiciels non libres sont nécessaires pour le fonctionnement de certaines fonctions matérielles. Le paquet sys-kernel/linux-firmware contient des micrologiciels pour beaucoup, mais pas tous, ces périphériques.
La plupart des cartes sans fil et graphiques (GPU) ont besoin de micrologiciel pour fonctionner.
root #emerge --ask sys-kernel/linux-firmwareInstaller certains micrologiciels nécessite souvent d’accepter la licence associée. Si nécessaire, visitez la section gestion des licences du manuel pour de l’aide à propos des licences.
Chargement de micrologiciel
Les micrologiciels sont généralement chargés avec le module du noyau (kernel) associé. Cela signifie que le micrologiciel doit être compilé avec le noyau en utilisant « CONFIG_EXTRA_FIRMWARE » si le module est configuré avec « Y » (oui) à la place de « M » (module). Dans la plupart des situations, intégrer un module qui a besoin d’un micrologiciel peut être compliqué ou casser le chargement.
sys-kernel/installkernel
Installkernel peut être utilisé pour automatiser l’installation du noyau parmi la génération d’initramfs, unified kernel image ou la configuration du programme d’amorçage. sys-kernel/installkernel propose deux façons pour installer: le traditionnel installkernel originaire de Debian et kernel-install de systemd. Lequel choisir dépend, parmi d’autres critères, du système d’initialisation et du programme d’amorçage. Par défaut, kernel-install système est utilisé sur des profils systemd, tandis que le traditionnel installkernel est le choix par défaut pour les autres profils.
Programme d’amorçage (bootloader)
Il est temps maintenant de réfléchir au programme d’amorçage voulu par l’utilisateur pour son système. Si vous n’êtes pas sûr, choisir la « voie traditionnelle » ci-dessous.
GRUB
Les utilisateurs de GRUB peuvent utiliser au choix kernel-install de systemd ou le traditionnel installkernel de Debian. Le drapeau (USE) systemd permet de passer d’une implémentation à l’autre. Pour exécuter automatiquement grub-mkconfig lors de l’installation d’un noyau, activer grub USE flag.
/etc/portage/package.use/installkernelsys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel
Choix traditionnel et autres programmes d’amorçage ((e)lilo, syslinux, etc.)
Le traditionnel chemin /boot (pour LILO, syslinux, etc.) est utilisé par défaut si les drapeaux USE grub, systemd-boot, efistub et uki ne sont pas activés. Aucune action supplémentaire n’est nécessaire.
Initramfs
Un système de fichiers basés sur la RAM pour l’initialisation, ou initramfs, peut être nécessaire pour démarrer un système. Un large panel de cas en ont besoin, les cas courants incluent :
- noyaux où les pilotes pour le système de fichiers ou le stockage sont des modules ;
- un partitionnement séparés de /usr/ ou /var/ ;
- un système de fichiers racine chiffré.
Les noyaux distribués peuvent être utilisés avec initramfs, comme beaucoup de pilotes pour le système de fichiers ou le stockage sont des modules.
En plus de monter une partition racine, initramfs peut accomplir d’autres missions, comme :
- lancer une vérifier de la consistance d’un système de fichiers fsck, dans le cas d’un arrêt brutal du système ;
- fournir un environnement de secours en cas d’erreur au démarrage.
Installkernel peut générer automatiquement un initramfs en installant le noyau si les drapeaux USE dracut ou ugrd sont activés :
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut
root #emerge --ask sys-kernel/installkernel
Configuration et compilation du noyau
Il peut être judicieux d’utiliser un noyau distant au premier démarrage car cela fournit une méthode simple pour éviter les erreurs systèmes et de configuration du noyau. Ayez toujours un noyau fonctionnel en secours permet d’accélérer le débogage et réduit l’anxiété qu’une mise à jour système empêchera votre ordinateur de démarrer.
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.
Lors de l’installation de Gentoo, un seul type de noyau peut être installé à la fois. Soit le sys-kernel/gentoo-kernel-bin ou sys-kernel/gentoo-sources.
Classés du moins fréquent au plus courant :
- Approche automatique complète : les noyaux distribués
- Un noyau distribué est utilisé pour configurer automatiquement la compilation, installer le noyau Linux, ses modules associés, et (optionnellement, pas activé par défaut) un fichier initramfs. Les mises à jour du noyau sont totalement automatisées car elles sont gérés par le gestionnaire de paquets, comme pour n’importe quel autre paquet. Il est possible de fournir un fichier de configuration personnalisé si un paramètre est nécessaire. C’est la procédure la plus facile et elle est parfaite pour de nouveaux utilisateurs de Gentoo car elle est prête à l’emploi.
- Approche manuelle
- les nouvelles sources du noyau sont installées par le gestionnaire de paquets. Le noyau est manuellement configuré, compilé, installé en utilisant eselect kernel et un tas de commande make. Les mises à jour futures du noyau répéteront la même procédure de configuration, compilation et installation. Cette façon de faire implique le plus d‘opérations, mais offre un contrôle maximal sur la mise à jour du noyau.
- Approche hybride : Genkernel
- nous utilisons le terme « hybride » ici, mais notons que les noyaux distribués et la procédure manuelle partagent le même but. Les nouveaux noyaux sont installés via le gestionnaire de paquets. Les administrateurs systèmes peuvent utiliser le genkernel de Gentoo pour configurer, compiler et installer le noyau, ses modules associés, et (optionnellement, pas activé par défaut) un fichier initramfs. Il est possible de fournir un fichier de configuration du noyau si nécessaire. Les mises à jour futures du noyau auront besoin d’une implication de l’administrateur pour lancer eselect kernel, genkernel et potentiellement d’autres commandes à chaque mise à jour. Cette option ne devrait être choisie que par les utilisateurs qui ont besoin de genkernel
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 Vue d’ensemble des noyaux.
Les tâches d’installation du noyau comme copier l’image du noyau vers /boot ou l’EFI System Partition, générer un initramfs ou une Unified Kernel Image et mettre à jour la configuration du programme d’amorçage peuvent être automatisé avec installkernel. Les utilisateurs peuvent souhaiter installer et configurer sys-kernel/installkernel avant de continuer. Lisez ci-dessous la section d’installation du noyau pour davantage d’informations.
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:
/etc/portage/make.confEnable module signingUSE="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 -noenc -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pemThe 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.pemroot #chmod 400 kernel_key.pem
Installing a distribution kernel
To build a kernel with Gentoo patches from source, type:
root #emerge --ask sys-kernel/gentoo-kernelSystem administrators who want to avoid compiling the kernel sources locally can instead use precompiled kernel images:
root #emerge --ask sys-kernel/gentoo-kernel-binDistribution 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 --depcleanAlternatively, to specifically clean up old kernel versions:
root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-binBy 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:
/etc/portage/make.confEnabling USE=dist-kernelUSE="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-rebuildIf 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
After installing the Distribution Kernel successfully, it is now time to proceed to the next section: Configuring the system.
Installer les sources du noyau
Lors de l’installation et la compilation du noyau pour les systèmes basés sur ppc, Gentoo recommande le paquet sys-kernel/gentoo-sources.
Choisissez les sources du noyau appropriées et installez les en utilisant emerge :
root #emerge --ask sys-kernel/gentoo-sourcesCela installera les sources du noyau Linux dans le répertoire /usr/src/ dans un répertoire versionné. Un lien symbolique /usr/src/linux ne sera pas créé sans le drapeau USE symlink activé pour le paquet de sources du noyau choisi.
Il est usuelle d’avoir un lien symbolique /usr/src/linux pour pointer vers les sources du noyau actuel. Cependant, ce lien n’est pas créé par défaut. Un autre façon de créer ce lien est d’utiliser le module eselect kernel.
Pour davantage d’informations concernant le but du lien symbolique et comment le gérer, consultez Kernel/Upgrade/fr.
Premièrement, listons les noyaux installés :
root #eselect kernel listAvailable kernel symlink targets: [1] linux-6.6.21-gentoo
Pour créer un lien symbolique linux, copier :
root #eselect kernel set 1root #ls -l /usr/src/linuxlrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo
Approche manuelle
Pour éviter un oubli, cette section nécessite une installation des sources du noyau. Soyez sûr d’avoir bien le code source du noyau adéquat avant de continuer le reste de cette section.
Configurer manuellement un noyau est couramment vu comme la procédure la plus difficile pour un administrateur système. Rien n’est moins vrai… mais après avoir configuré quelques noyaux, plus personne ne se souvient que c’était difficile ! Il y a deux manières pour un utilisateur Gentoo de gérer un noyau manuellement, les deux sont listées ci-dessous :
Procédure modprobed-db
Une manière très simple pour gérer le noyau est d’installer d’abord sys-kernel/gentoo-kernel-bin puis d’utiliser sys-kernel/modprobed-db pour réunir les informations à propos des besoins du système. modprobed-db est un outil qui supervise le système via crontab et ajoute tous les modules de tous les périphériques branchés une fois sur le système pour s‘assurer que tous les besoins de l’utilisateur sont supportés. Par exemple, si un contrôleur Xbox est branché après l’installation, modprobed-db va ajouter les modules pour être compilés la prochaine fois que le noyau est reconstruit. Ce sujet est détaillé dans l’article Modprobed-db.
Procédure manuelle
Cette procédure permet à l’utilisateur d’avoir un contrôle total sur ses noyaux avec un minimum d’outils aidant comme il le désire. Certains considère que cela a un intérêt de rendre cela difficile.
Cependant, avec ce choix, 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 genre pcilib: cannot open /sys/bus/pci/devices) que lspci pourrait afficher.
Une 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.
root #cd /usr/src/linux
Pour consulter la liste complète des paramètres de make pour le noyau, lancez
make help.Le noyau a une auto-détection de modules utilisé par l’installcd qui permet un bon point de départ afin de configurer son propre noyau. Il peut être appelé avec :
root #make localmodconfigIl est maintenant temps de configurer avec nconfig :
root #make nconfigLa 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.
Activer les options nécessaires
Pour utiliser sys-kernel/gentoo-sources, il est vivement recommandé de laisser les configurations spécifiques à Gentoo activées. Cela assure que les fonctions minimales requises pour un noyau qui fonctionne sont disponibles :
Gentoo Linux --->
[*] Gentoo Linux support
[*] Linux dynamic and persistent device naming (userspace devfs) support
[*] Select options required by Portage features
Support for init systems, system and service managers --->
[*] OpenRC, runit and other script based systems and managers
[*] systemd
Naturellement, le choix des deux dernières lignes dépend du programme d’initialisation (OpenRC vs systemd). Il est possible d’avoir les deux supports activés.
Pour utiliser sys-kernel/vanilla-sources, les sélections pour le programme d’initialisation ne sont pas disponibles. Activer le support est possible, mais soit du périmètre de ce manuel.
Activer le support des composants usuels
Bien s’assurer que tous les pilotes indispensables au démarrage du système (comme le contrôleur SATA, les périphériques NVMe, les systèmes de fichiers) soient compilés dans le noyau et non en tant que module, sinon le système pourrait ne pas démarrer correctement.
Ensuite, sélectionner le type exact du processeur. Il est également recommandé d’activeer 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 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 des NVMe a bien été activé :
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
Cela ne coûte rien d’activer le support additionnel NVMe :
[*] 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 le système pourrait ne pas savoir 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 :
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 over Ethernet
<*> PPP support for async serial ports
<*> PPP support for sync tty ports
Les deux options de compression ne poseront pas de problème mais elles 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 multicœurs, 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 :
Device Drivers --->
HID support --->
-*- HID bus support
<*> Generic HID driver
[*] Battery level reporting for HID devices
USB HID support --->
<*> USB HID transport layer
[*] USB support --->
<*> xHCI HCD (USB 3.0) support
<*> EHCI HCD (USB 2.0) support
<*> OHCI HCD (USB 1.1) support
<*> Unified support for USB4 and Thunderbolt --->
Optionnel : modules noyaux signés
Pour automatiquement signer les modules noyaux, 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 signature (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) --->
Pour utiliser une clé personnalisée, spécifiez le chemin d’accès dans CONFIG_MODULE_SIG_KEY. Si non spécifié, le système de compilation du noyau générera une clé. Il est recommandé de la générer manuellement. Cela peut être fait avec :
root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pemOpenSSL vous posera quelques questions pour générer la clé, il est recommandé de donner des réponses aussi précises que possible.
Conservez la clé dans un répertoire sûr ; au plus, la clé devrait être lisible par l’utilisateur root. Vérifiez avec :
root #ls -l kernel_key.pem-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
Si la sortie est différente comparé à celle du dessus, corrigez les permissions avec :
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
Pour signer également des modules noyaux installés par d’autres paquets via linux-mod-r1.eclass, acitivez le drapeau USE modules-sign globalement :
/etc/portage/make.confActiver de la signature des modulesUSE="modules-sign"
# Optionnellement, en utilisant des clés de signatures personnalisées
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Nécessaire seulement si « MODULES_SIGN_KEY » ne contient pas également le certificat
MODULES_SIGN_HASH="sha512" # sha512 par défaut
MODULES_SIGN_KEY et MODULES_SIGN_CERT pourraient pointer sur différents fichiers. Par exemple, le PEM généré par OpenSSL inclus à la fois la clé et le certificat, et ces variables ont la même valeur.
Deprecated: Genkernel
Genkernel should only be considered by users with a required need that only Genkernel can meet. For others, it is recommended to use the Distribution kernel or manually compile their own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods; for example, Unified Kernel Images will need to be created manually when using Genkernel.
Users still wishing to use Genkernel should see the Genkernel article for more information.
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' | lessForcer 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
/etc/modules-load.d/network.confForcer le chargement du module 3c59x3c59x
Continuer l'installation avec Configuer le système.