mkinitcpio (Français)
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-gitAUR.
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.
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.
- 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.
- 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, ajoutezext2
. 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.
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.
-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)
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 deinit
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
debase
est remplacé.
break
- Si
break
oubreak=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écifiantbreak=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
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.
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 unpassno
de2
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
.
/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-firmwareAUR. Pour wd719x, installez wd719x-firmwareAUR. Pour xhci_pci, installez upd72020x-fwAUR. 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.