mkinitcpio (Français)

État de la traduction: Cet article est la version francophone de Mkinitcpio. Date de la dernière traduction: 2022-01-27. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

mkinitcpio est un script Bash utilisé pour créer un environnement «ramdisk» initial. Extrait de la page de manuel mkinitcpio(8) :

Le «ramdisk» initial est par essence un très petit environnement (early userspace) qui charge divers modules du noyau et configure les choses nécessaires avant de céder le contrôle à init. Cela permet d'avoir, par exemple, des systèmes de fichiers racine chiffrés et des systèmes de fichiers racine sur une matrice RAID logicielle. mkinitcpio permet une extension facile avec des «hooks» personnalisés, a une autodétection à l'exécution, et beaucoup d'autres fonctionnalités.

Traditionnellement, le noyau était responsable de toutes les tâches de détection et d'initialisation du matériel au début du processus de démarrage avant de monter le système de fichiers racine et de passer le contrôle à init. Cependant, au fur et à mesure des progrès technologiques, ces tâches sont devenues de plus en plus complexes.

De nos jours, le système de fichiers racine peut se trouver sur un large éventail de matériel, des disques SCSI aux disques SATA en passant par les disques USB, contrôlés par une variété de contrôleurs de disques de différents fabricants. En outre, le système de fichiers racine peut être chiffré ou compressé, dans une matrice RAID logicielle ou un groupe de volumes logiques. La façon la plus simple de gérer cette complexité est de passer la gestion dans l'espace utilisateur : un «ramdisk» initial. Consultez également : /dev/brain0 » Blog Archive » L'espace utilisateur initial dans Arch Linux.

mkinitcpio a été développé par les développeurs d'Arch Linux et à partir de contributions de la communauté. Consultez le dépôt Git public.

Installation

Installez le paquet mkinitcpio, qui est une dépendance du paquet linux, donc la plupart des utilisateurs l'auront déjà installé.

Les utilisateurs avancés peuvent souhaiter installer la dernière version de développement de mkinitcpio depuis Git avec le paquet mkinitcpio-git^AUR.

Note: Il est fortement recommandé de suivre la mailing list arch-projects si vous utilisez mkinitcpio depuis Git!

Création et activation d'images

Génération automatique

Chaque fois qu'un noyau est installé ou mis à jour, un «hook» de pacman génère automatiquement un fichier .preset enregistré dans /etc/mkinitcpio.d/. Par exemple linux.preset pour le paquet stable officiel linux du noyau. Un preset est simplement une liste d'informations requises pour créer des images ramdisk initiales, au lieu de spécifier manuellement les différents paramètres et l'emplacement des fichiers de sortie. Par défaut, il contient les instructions pour créer deux images :

l'image ramdisk par défaut créée suivant les directives spécifiées dans la #Configuration de mkinitcpio, et
l'image ramdisk fallback, identique à la précédente sauf que le hook autodetect est ignoré pendant la création, incluant ainsi une gamme complète de modules qui prends en charge la plupart des systèmes.

Après avoir créé le preset, le hook pacman appelle le script mkinitcpio qui génère les deux images, en utilisant les informations fournies dans le preset.

Note: Les fichiers preset sont utilisés pour régénérer automatiquement les initramfs après une mise à jour du noyau ; soyez prudent lorsque vous les modifiez.

Génération manuelle

Pour exécuter le script manuellement, référez-vous à la page de manuel mkinitcpio(8) pour les instructions. En particulier, pour (re-)générer le préréglage fourni par un paquet du noyau, utilisez l'option -p/--preset suivie du préréglage à utiliser. Par exemple, pour le paquet linux, utilisez la commande :

# mkinitcpio -p linux

Pour (re)générer tous les préréglages existants, utilisez le paramètre -P/--allpresets. Ceci est typiquement utilisé pour régénérer toutes les images initramfs après un changement de la #Configuration globale :

# mkinitcpio -P

Les utilisateurs peuvent créer un nombre arbitraire d'images initramfs avec une variété de configurations différentes. L'image désirée doit être spécifiée dans le fichier de configuration du chargeur d'amorçage respectif.

Génération personnalisée

Les utilisateurs peuvent générer une image en utilisant un fichier de configuration alternatif. Par exemple, ce qui suit générera une image initiale de disque RAM selon les instructions de /etc/mkinitcpio-custom.conf et l'enregistrera sous /boot/initramfs-custom.img.

# mkinitcpio --config /etc/mkinitcpio-custom.conf --generate /boot/initramfs-custom.img

Si vous générez une image pour un noyau autre que celui en cours d'exécution, ajoutez la version du noyau à la ligne de commande. Les versions des noyaux installés peuvent être trouvées dans /usr/lib/modules/, la syntaxe est cohérente avec la sortie de la commande uname -r pour chaque noyau.

# mkinitcpio --generate /boot/initramfs-custom2.img --kernel 5.7.12-arch1-1

Images de noyau unifiées

Depuis la version 31, mkinitcpio peut également créer des images de noyau unifiées.

Configuration

Le principal fichier de configuration de mkinitcpio est /etc/mkinitcpio.conf. De plus, les définitions des «presets» sont fournies par les paquets du noyau dans le répertoire /etc/mkinitcpio.d (par exemple /etc/mkinitcpio.d/linux.preset).

Les utilisateurs peuvent modifier six variables dans le fichier de configuration, consultez mkinitcpio.conf(5) pour plus de détails :

MODULES: Modules du noyau à charger avant l'exécution des «hooks» de démarrage.
BINARIES: Binaires supplémentaires à inclure dans l'image initramfs.
FILES: Fichiers supplémentaires à inclure dans l'image initramfs.
HOOKS: Les «hooks» (crochets) sont des scripts qui s'exécutent dans le ramdisk initial.
COMPRESSION: Utilisé pour compresser l'image initramfs.
COMPRESSION_OPTIONS: Arguments supplémentaires à passer au programme ; COMPRESSION. L'utilisation de ce paramètre est fortement déconseillée. mkinitcpio gérera les exigences particulières des compresseurs (par exemple, passer --check=crc32 à xz) et une mauvaise utilisation peut facilement conduire à un système non amorçable.

Note:

Certains «hooks» qui peuvent être nécessaires à votre système comme lvm2, mdadm_udev, et encrypt ne sont PAS activés par défaut. Lisez attentivement la section #HOOKS pour obtenir des instructions.
Les utilisateurs avec plusieurs contrôleurs de disques matériels qui utilisent les mêmes noms de noeuds mais des modules de noyau différents (par exemple deux contrôleurs SCSI/SATA ou deux IDE) devraient utiliser le nommage persistant des périphériques de type bloc pour s'assurer que les bons périphériques sont montés. Sinon, l'emplacement du périphérique racine peut changer entre les démarrages, ce qui entraîne des paniques du noyau.

MODULES

Le tableau MODULES est utilisé pour spécifier les modules à charger avant toute autre chose.

Les modules suffixés par un ? ne lanceront pas d'erreur s'ils ne sont pas trouvés. Cela peut être utile pour les noyaux personnalisés qui compilent dans des modules qui sont listés explicitement dans un «hook» ou un fichier de configuration.

Note:

Si vous utilisez reiser4, il doit être ajouté au tableau MODULES.
Si vous utilisez le «hook» encrypt ou sd-encrypt, les modules clavier et/ou les systèmes de fichiers nécessaires pour déverrouiller le périphérique LUKS pendant le démarrage du système doivent être ajoutés au tableau MODULES lorsque le système cible diffère de celui utilisé pour exécuter mkinitcpio. Par exemple, si vous utilisez un fichier clé sur un système de fichiers ext2 mais qu'aucun système de fichiers ext2 n'est monté au moment où mkinitcpio s'exécute, ajoutez ext2. Consultez l'article anglais dm-crypt/System configuration#cryptkey pour plus de détails.
Si vous utilisez un clavier via un hub USB 3 et souhaitez l'utiliser pour déverrouiller un périphérique LUKS, ajoutez usbhid xhci_hcd.
Si vous utilisez des écrans connectés à une station d'accueil, vous devrez peut-être ajouter un module pour votre carte graphique afin de rendre la sortie initrd visible (par exemple, i915 pour la plupart des cartes Intel).

BINARIES et FILES

Ces options permettent aux utilisateurs d'ajouter des fichiers à l'image. BINARIES et FILES sont ajoutées avant l'exécution des «hooks» et peuvent être utilisées pour remplacer les fichiers utilisés ou fournis par un «hook». Les BINARIES sont localisées automatiquement dans un PATH standard et sont analysées en fonction des dépendances, ce qui signifie que toute bibliothèque requise sera également ajoutée. Les FILES sont ajoutés tels quels. Par exemple :

FILES=(/etc/modprobe.d/modprobe.conf)

BINARIES=(kexec)

Notez que comme BINARIES et FILES sont des tableaux Bash, plusieurs entrées peuvent être ajoutées en étant délimitées par des espaces.

HOOKS

Le tableau HOOKS est le paramètre le plus important du fichier. Les «hooks» sont de petits scripts qui décrivent ce qui sera ajouté à l'image. Pour certains d'entre eux, ils contiennent également un composant d'exécution qui fournit un comportement supplémentaire, comme le démarrage d'un daemon ou l'assemblage d'un périphérique à blocs empilés. Les «hooks» sont désignés par leur nom, et exécutés dans l'ordre où ils existent dans le tableau HOOKS du fichier de configuration.

Le paramètre par défaut HOOKS devrait être suffisant pour la plupart des configurations simples, à un seul disque. Pour les périphériques racine qui sont empilés ou multi-blocs tels que LVM, RAID, ou dm-crypt, consultez les pages wiki respectives pour la configuration nécessaire.

Hooks de construction

Les «hooks» de construction se trouvent dans /usr/lib/initcpio/install/, les «hooks» de construction personnalisés peuvent être placés dans /etc/initcpio/install/. Ces fichiers sont récupérés par le shell bash pendant l'exécution de mkinitcpio et doivent contenir deux fonctions : build et help. La fonction build décrit les modules, fichiers et binaires qui seront ajoutés à l'image. Une API, documentée par mkinitcpio(8), sert à faciliter l'ajout de ces éléments. La fonction help fournit une description de ce que le «hook» accomplit.

Pour une liste de tous les «hooks» disponibles :

$ mkinitcpio -L

Utilisez l'option -H/--hookhelp de mkinitcpio pour afficher l'aide d'un «hook» spécifique, par exemple :

$ mkinitcpio -H udev

Hooks d'exécution

Les «hooks» d'exécution se trouvent dans /usr/lib/initcpio/hooks/, les «hooks» d'exécution personnalisés peuvent être placés dans /etc/initcpio/hooks/. Pour tout «hook» d'exécution, il devrait toujours y avoir un «hook» de construction du même nom, qui appelle add_runscript pour ajouter le «hook» d'exécution à l'image. Ces fichiers sont utilisés par le shell busybox ash au début de l'espace utilisateur. À l'exception des «hooks» de nettoyage, ils seront toujours exécutés dans l'ordre indiqué dans le paramètre HOOKS. Les «hooks» d'exécution peuvent contenir plusieurs fonctions :

run_earlyhook : Les fonctions avec ce nom seront exécutées une fois que les systèmes de fichiers de l'API auront été montés et que la ligne de commande du noyau aura été analysée. C'est généralement à partir de là que sont lancés les daemons supplémentaires, tels que udev, qui sont nécessaires au processus de démarrage rapide.

run_hook : Les fonctions avec ce nom sont exécutées peu après les «hooks» précoces. Il s'agit du point d'accrochage le plus courant, et des opérations telles que l'assemblage de périphériques à blocs empilés devraient avoir lieu ici.

run_latehook : Les fonctions avec ce nom sont exécutées après le montage du périphérique racine. Elle doit être utilisée, avec parcimonie, pour une configuration plus poussée du périphérique racine, ou pour monter d'autres systèmes de fichiers, tels que /usr.

run_cleanuphook : Les fonctions avec ce nom sont exécutées le plus tard possible, et dans l'ordre inverse de celui dans lequel elles sont listées dans le tableau HOOKS du fichier de configuration. Ces «hooks» doivent être utilisés pour tout nettoyage de dernière minute, comme l'arrêt de tout daemon lancé par un «hook» précédent.

Note: Les «hooks» d'exécution ne sont utilisés que par l'init busybox. Le «hook» systemd déclenche un init basé sur systemd, qui n'exécute pas de «hooks» d'exécution mais utilise des unités systemd à la place.

Hooks communs

Voici un tableau des «hooks» communs et de la manière dont ils affectent la création et l'exécution des images. Notez que ce tableau n'est pas complet, car les paquets peuvent fournir des «hooks» personnalisés.

busybox init	systemd init	Hooks de construction	Hooks d'exécution (busybox init only)
base		Configure tous les répertoires initiaux et installe les utilitaires de base et les bibliothèques. Conservez toujours ce "hook" comme premier "hook" à moins que vous ne sachiez ce que vous faites, car il fournit un init busybox critique lorsque vous n'utilisez pas le «hook» systemd. Optionnel lors de l'utilisation du «hook» systemd car il fournit juste un shell de récupération busybox. Note: Le shell de récupération n'est pas utilisable car le compte root dans l'initramfs est verrouillé. See FS#70408.	–
udev	systemd	Ajoute udevd, udevadm, et un petit sous-ensemble de règles udev à votre image.	Démarre le daemon udev et traite les uevents du noyau, en créant des nœuds de périphériques. Comme il simplifie le processus de démarrage en ne demandant pas à l'utilisateur de spécifier explicitement les modules nécessaires, son utilisation est recommandée.
usr		Ajoute la prise en charge de `/usr` sur une partition séparée. Consultez #/usr sur une partition séparée pour plus de détails.	Monte la partition `/usr` après que la racine réelle ait été montée.
resume		–	Tente de reprendre à partir de l'état "suspend to disk". Consultez Hibernation pour plus de configuration.
btrfs	--	Définit les modules requis pour activer Btrfs afin d'utiliser plusieurs périphériques avec Btrfs. Vous devez avoir btrfs-progs installé pour utiliser ceci. Ce «hook» n'est pas nécessaire pour utiliser Btrfs sur un seul périphérique.	Lance `btrfs device scan` pour assembler un système de fichiers racine Btrfs multi-périphérique lorsque le «hook» udev ou le «hook» systemd n'est pas présent. Le paquet btrfs-progs est nécessaire pour ce «hook».
autodetect		Réduit votre initramfs à une taille plus petite en créant une liste blanche de modules à partir d'une analyse de sysfs. Assurez-vous de vérifier que les modules inclus sont corrects et qu'aucun n'est manquant. Ce «hook» doit être exécuté avant les autres «hooks» du sous-système afin de profiter de l'auto-détection. Tous les «hooks» placés avant 'autodetect' seront installés dans leur intégralité.	–
modconf		Inclut les fichiers de configuration modprobe de `/etc/modprobe.d/` et `/usr/lib/modprobe.d/`.	–
block		Ajoute tous les modules de périphérique de type bloc, auparavant fournis séparément par les «hooks» fw, mmc, pata, sata, scsi, usb, et virtio.	–
net	pas mis en œuvre	Ajoute les modules nécessaires pour un périphérique réseau. Vous devez avoir mkinitcpio-nfs-utils installé pour utiliser ceci, consultez #Utiliser net pour plus de détails.	Fournit la gestion d'un système de fichiers racine basé sur NFS.
dmraid	?	Fournit la prise en charge des périphériques racine fakeRAID. Vous devez avoir installé dmraid pour l'utiliser. Notez qu'il est préférable d'utiliser mdadm avec le «hook» mdadm_udev avec fakeRAID si votre contrôleur le prends en charge. Consultez #Utiliser RAID pour plus de détails.	Localise et assemble les périphériques blocs fakeRAID en utilisant `dmraid`.
mdadm_udev		Fournit la prise en charge de l'assemblage de matrices RAID via udev. Vous devez avoir mdadm installé pour l'utiliser. Si vous utilisez ce «hook» avec une matrice FakeRAID, il est recommandé d'inclure `mdmon` dans `BINARIES`. Consultez #Utiliser RAID pour plus de détails.	–
keyboard		Ajoute les modules nécessaires pour les périphériques clavier. Utilisez ceci si vous avez un clavier USB ou série et que vous en avez besoin dans le premier espace utilisateur (soit pour entrer des mots de passe de chiffrement, soit pour l'utiliser dans un shell interactif). Par effet de bord, des modules pour certains périphériques d'entrée autres que le clavier peuvent être ajoutés également, mais il ne faut pas s'y fier. Remplace l'ancien «hook» usbinput. Note: Pour les systèmes qui sont démarrés avec différentes configurations matérielles (par exemple, les ordinateurs portables avec un clavier externe ou un clavier interne ou «headless»), ce «hook» doit être placé avant autodetect afin de pouvoir utiliser le clavier au moment du démarrage, par exemple pour déverrouiller un périphérique chiffré lorsque le «hook» `encrypt` est utilisé.	–
keymap	sd-vconsole	Ajoute la keymap spécifiée dans `/etc/vconsole.conf` à l'initramfs. Si vous utilisez le chiffrement système, en particulier le chiffrement de disque complet, assurez-vous de l'ajouter avant le «hook» `encrypt`.	Charge les keymaps spécifiés depuis `/etc/vconsole.conf` au début de l'espace utilisateur.
consolefont	sd-vconsole	Ajoute la police de console spécifiée de `/etc/vconsole.conf` à l'initramfs.	Charge la police de la console spécifiée depuis `/etc/vconsole.conf` au début de l'espace utilisateur.
encrypt	sd-encrypt	Ajoute le module noyau `dm_crypt` et l'outil `cryptsetup` à l'image. Vous devez avoir installé cryptsetup pour l'utiliser. Note: Tenez compte des remarques concernant le «hook» clavier ci-dessus pour déverrouiller un périphérique chiffré au démarrage, et/ou des remarques concernant le système de fichiers dans #MODULES lorsque vous utilisez un fichier à déverrouiller.	Détecte et déverrouille une partition racine chiffrée. Consultez #Personnalisation de l'exécution pour la suite de la configuration. Pour sd-encrypt consultez dm-crypt/System configuration#Using systemd-cryptsetup-generator.
lvm2		Ajoute le module noyau mappeur de périphériques et l'outil `lvm` à l'image. Vous devez avoir lvm2 installé pour l'utiliser. Ceci est nécessaire si vous avez votre système de fichiers racine sur LVM.	–
fsck		Ajoute le binaire fsck et les aides spécifiques au système de fichiers pour permettre l'exécution de fsck sur votre périphérique racine (et `/usr` si séparé) avant le montage. Si il est ajouté après le «hook» autodetect, seule l'aide spécifique à votre système de fichiers racine sera ajoutée. L'utilisation de ce «hook» est fortement recommandée, et il est requis avec une partition `/usr` séparée. Il est fortement recommandé, si vous incluez ce «hook», d'inclure également tous les modules nécessaires pour que votre clavier fonctionne dans l'espace utilisateur primitif. L'utilisation de ce «hook» nécessite que le paramètre `rw` soit défini sur la ligne de commande du noyau. (discussion). Consultez Fsck (Français)#Vérification au démarrage pour plus de détails.	–
filesystems		Ceci inclut les modules de système de fichiers nécessaires dans votre image. Ce «hook» est requis à moins que vous ne spécifiez vos modules de système de fichiers dans `MODULES`.	–

COMPRESSION

Le noyau prend en charge plusieurs formats pour la compression de l'initramfs : gzip, bzip2, lzma, xz, lzo, lz4 et zstd. mkinitcpio utilise des images compressées zstd par défaut, notez que la compression zstd fonctionne en mode multi-cœur (avec l'option -T0 qui génère autant de processus que de cœurs détectés).

Le fichier mkinitcpio.conf fourni contient les différentes options COMPRESSION commentées. Décommentez l'une d'entre elles si vous souhaitez passer à une autre méthode de compression et assurez-vous d'avoir installé l'utilitaire de compression correspondant. Si aucune option n'est spécifiée, la méthode par défaut de zstd est utilisée. Si vous souhaitez créer une image non compressée, spécifiez COMPRESSION='cat dans le fichier de configuration ou utilisez -z cat sur la ligne de commande.

Astuce: Avec un taux de compression typiquement autour de 2,5 sur l'image dans son mode de compression élevé (-9), lz4 atteint la vitesse de décompression la plus rapide au prix d'une compression plus lente en mode mono-cœur. Pour une compression légèrement meilleure, lzo est toujours rapide à décompresser. zstd offre une solution polyvalente, avec une compression multi-cœur et une large gamme de niveaux de compression grâce à ses options - consultez zstd(1) § Operation modifiers. xz atteint la plus petite taille avec un facteur de réduction autour de 5 dans son préréglage de haute compression (-9), au prix d'une vitesse de décompression beaucoup plus lente.

COMPRESSION_OPTIONS

Il s'agit d'options supplémentaires transmises au programme spécifié par COMPRESSION, par exemple :

COMPRESSION_OPTIONS=(-9)

Note: Cette option peut être laissée vide, mkinitcpio s'assurera que toute méthode de compression prise en charge possède les paramètres nécessaires pour produire une image fonctionnelle. D'un autre côté, une mauvaise utilisation de cette option peut conduire à un système non amorçable si le noyau est incapable de décompresser l'archive résultante.

Personnalisation de l'exécution

Les options de configuration durant l'exécution peuvent être transmises à init et à certains «hooks» via la ligne de commande du noyau. Les paramètres de la ligne de commande du noyau sont souvent fournis par le chargeur d'amorçage. Les options présentées ci-dessous peuvent être ajoutées à la ligne de commande du noyau pour modifier le comportement par défaut. Consultez Paramètres du noyau (en) et Processus de démarrage pour plus d'informations.

init avec le «hook» base

root

C'est le paramètre le plus important spécifié sur la ligne de commande du noyau, car il détermine le périphérique qui sera monté comme votre périphérique racine. mkinitcpio est assez flexible pour permettre une grande variété de formats, par exemple :

 root=/dev/sda1 # /dev node
 root=LABEL=CorsairF80 # label
 root=UUID=ea1c4959-406c-45d0-a144-912f4e86b207 # UUID
 root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 # UUID de la partition GPT

Note: Les paramètres de démarrage suivants modifient le comportement par défaut de init dans l'environnement initramfs. Consultez /usr/lib/initcpio/init pour plus de détails. Ils ne fonctionneront pas lorsque le «hook» systemd est utilisé puisque le «hook» init de base est remplacé.

break: Si break ou break=premount est spécifié, init met en pause le processus de démarrage (après le chargement des «hooks», mais avant le montage du système de fichiers racine) et lance un shell interactif qui peut être utilisé à des fins de dépannage. Ce shell peut être lancé après le montage de la racine en spécifiant break=postmount. Le démarrage normal se poursuit après avoir quitté le shell.

disablehooks

Désactive les «hooks» au moment de l'exécution en ajoutant disablehooks=hook1[,hook2,...]. Par exemple :

disablehooks=resume

earlymodules: Modifie l'ordre dans lequel les modules sont chargés en spécifiant les modules à charger précocement via earlymodules=mod1[,mod2,...]. (Cela peut être utilisé, par exemple, pour assurer l'ordre correct de plusieurs interfaces réseau).

Consultez Problèmes de démarrage et mkinitcpio(8) pour d'autres paramètres.

Utiliser RAID

Consultez RAID#Configure mkinitcpio.

Utiliser net

Note: NFSv4 n'est pas encore pris en charge FS#28287.

Paquets requis

net nécessite le paquet mkinitcpio-nfs-utils.

Paramètres du noyau

Des informations complètes et à jour peuvent être trouvées dans la documentation officielle documentation du noyau.

ip=

Ce paramètre indique au noyau comment configurer les adresses IP des périphériques et aussi comment configurer la table de routage IP. Il peut prendre jusqu'à neuf arguments séparés par des deux-points : ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>.

Si ce paramètre est absent de la ligne de commande du noyau, tous les champs sont supposés être vides, et les valeurs par défaut mentionnées dans la documentation du noyau s'appliquent. En général, cela signifie que le noyau essaie de tout configurer en utilisant l'autoconfiguration.

Le paramètre <autoconf> peut apparaître seul comme valeur du paramètre ip (sans tous les caractères : avant). Si la valeur est ip=off ou ip=none, aucune autoconfiguration n'aura lieu, sinon l'autoconfiguration aura lieu. La façon la plus courante d'utiliser ce paramètre est ip=dhcp.

Pour une explication des paramètres, consultez la documentation du noyau.

Exemples :

ip=127.0.0.1:::::lo:none  --> Enable the loopback interface.
ip=192.168.1.1:::::eth2:none --> Enable static eth2 interface.
ip=:::::eth0:dhcp --> Enable dhcp protocol for eth0 configuration.

Note: Veillez à utiliser les noms de périphériques du noyau (par exemple, eth0) pour le paramètre <device>, les noms persistants (par exemple, enp2s0) ne fonctionneront pas. Consultez Network configuration#Network interfaces pour plus d'informations.

BOOTIF=

Si vous avez plusieurs cartes réseau, ce paramètre peut inclure l'adresse MAC de l'interface à partir de laquelle vous démarrez. Ceci est souvent utile lorsque la numérotation des interfaces peut changer, ou en conjonction avec l'option pxelinux IPAPPEND 2 ou IPAPPEND 3. S'il n'est pas donné, eth0 sera utilisé.

Exemple :

BOOTIF=01-A1-B2-C3-D4-E5-F6 # Notez le préfixe "01-" et les lettres majuscules.

nfsroot=

Si le paramètre nfsroot n'est PAS donné sur la ligne de commande, le paramètre par défaut /tftpboot/%s sera utilisé.

nfsroot=[<server-ip> :]<root-dir>[,<nfs-options>]

Exécutez mkinitcpio -H net pour l'explication des paramètres.

Utiliser LVM

Si votre périphérique racine est sur LVM, consultez Install Arch Linux on LVM#Adding mkinitcpio hooks.

Utiliser une partition système chiffrée

Si vous utilisez une partition système chiffrée, consultez dm-crypt/System configuration#mkinitcpio pour des informations détaillées sur les «hooks» à inclure.

/usr sur une partition séparée

Si vous conservez /usr sur une partition séparée, vous devez respecter les exigences suivantes :

Ajouter le «hook» fsck, marquer /usr avec un passno de 2 dans /etc/fstab pour exécuter la vérification sur la partition au démarrage. Bien que recommandé pour tout le monde, il est obligatoire si vous voulez que votre partition /usr soit vérifié au démarrage. Sans ce «hook», /usr ne sera jamais vérifié.
Si vous n'utilisez pas le «hook» systemd, ajoutez le «hook» usr. Ceci montera la partition /usr après que la racine soit monté.

Dépannage

Extraction de l'image

Si vous êtes curieux de savoir ce que contient l'image initramfs, vous pouvez l'extraire et consulter les fichiers qu'elle contient.

L'image initramfs est une archive CPIO SVR4, générée par les commandes find et bsdcpio, éventuellement compressée avec un schéma de compression compris par le noyau. Pour plus d'informations sur les schémas de compression, consultez #COMPRESSION.

mkinitcpio inclut un utilitaire appelé lsinitcpio(1) qui listera et/ou extraira le contenu des images initramfs.

Vous pouvez lister les fichiers de l'image avec :

# lsinitcpio /boot/initramfs-linux.img

Et pour les extraire tous dans le répertoire courant :

# lsinitcpio -x /boot/initramfs-linux.img

Vous pouvez également obtenir une liste plus conviviale des parties importantes de l'image :

# lsinitcpio -a /boot/initramfs-linux.img

Recompression d'une image extraite modifiée

Invoquer la fonction build_image du script /usr/bin/mkinitcpio avec comme paramètres

build_image outfile compression

On peut le faire en créant un nouveau script avec le contenu de la fonction build_image et en l'exécutant avec les paramètres ci-dessus. Cela permettra de compresser le contenu présent dans le répertoire courant dans un fichier nommé outfile.

Attention: C'est une bonne idée de renommer le fichier généré automatiquement /boot/initramfs-linux.img avant de le remplacer, afin de pouvoir facilement annuler vos modifications. Soyez prêt à faire une erreur qui empêchera votre système de démarrer. Si cela se produit, vous devrez démarrer à travers le fallback, ou un CD de démarrage, pour restaurer votre original, exécuter mkinitcpio pour écraser vos changements, ou les corriger vous-même et recompresser l'image.

"/dev must be mounted" alors qu'il l'est déjà

Le test utilisé par mkinitcpio pour déterminer si /dev est monté est de consulter si /dev/fd/ est présent. Si tout le reste semble correct, il peut être "créé" manuellement par :

# ln -s /proc/self/fd /dev/

(Évidemment, /proc doit aussi être monté. mkinitcpio le requiert de toute façon, et c'est la prochaine chose qu'il vérifiera).

Possibly missing firmware for module XXXX

Lorsque les initramfs sont reconstruits après une mise à jour du noyau, vous pouvez obtenir ces avertissements ou des avertissements similaires :

==> WARNING: Possibly missing firmware for module : wd719x
==> WARNING: Possibly missing firmware for module : aic94xx
==> WARNING: Possibly missing firmware for module : xhci_pci.

Ceux-ci apparaissent à la plupart des utilisateurs d'Arch Linux, car le microprogramme n'est pas inclus dans le paquet linux-firmware. Si vous n'utilisez pas de matériel qui utilise ces microprogrammes, vous pouvez ignorer ce message sans risque. Actuellement, la seule solution pour supprimer les avertissements pour les modules wd719x et aic94xx est d'installer les paquets de firmware pour ces modules. Pour aic94xx, installez aic94xx-firmware^AUR. Pour wd719x, installez wd719x-firmware^AUR. Pour xhci_pci, installez upd72020x-fw^AUR. Consultez la discussion correspondante ici.

Pour les microprogrammes les plus courants, installez le paquet linux-firmware. Pour les autres paquets fournissant des microprogrammes, essayez de chercher le nom du module dans les dépôts officiels ou AUR.

No PS/2 controller found

Sur certaines cartes mères (surtout les anciennes, mais aussi quelques nouvelles), le contrôleur i8042 ne peut pas être détecté automatiquement. C'est rare, mais certaines personnes se retrouveront sûrement sans clavier. Vous pouvez détecter cette situation à l'avance. Si vous avez un port PS/2 et obtenez le message i8042: PNP: No PS/2 controller found. Probing ports directly, ajoutez atkbd au tableau MODULES.

Procédures de secours standard

Avec un disque RAM initial inadéquat, un système est souvent impossible à démarrer. Suivez donc une procédure de sauvetage du système comme ci-dessous :

Le démarrage réussit sur une machine et échoue sur une autre

Le hook autodetect de mkinitcpio filtre les modules du noyau inutiles dans l'analyse primaire de l'initramfs /sys et les modules chargés au moment de son exécution. Si vous transférez votre répertoire /boot sur une autre machine et que la séquence de démarrage échoue au début de l'espace utilisateur, cela peut être dû au fait que le nouveau matériel n'est pas détecté en raison de modules du noyau manquants. Notez que les USB 2.0 et 3.0 nécessitent des modules de noyau différents.

Pour corriger ce problème, essayez d'abord de choisir l'image fallback à partir de votre chargeur d'amorçage, car elle n'est pas filtrée par autodetect. Une fois démarré, exécutez mkinitcpio sur la nouvelle machine pour reconstruire l'image primaire avec les modules corrects. Si l'image de repli échoue, essayez de démarrer sur un CD/USB live Arch Linux, chrootez dans l'installation, et exécutez mkinitcpio sur la nouvelle machine. En dernier recours, essayez manuellement d'ajouter des modules à l'initramfs.

Voir aussi

Documentation du noyau Linux sur initramfs, "What is rootfs ?".
Documentation du noyau Linux sur initrd
Article de Wikipedia sur initrd.