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.
Related articles
systemd (Français)
Kernel modules
mkinitcpio/Minimal initramfs
Problèmes de démarrage
dracut
Booster
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
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
.