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

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

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 à . 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 , qui est une dépendance du paquet , 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 .

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 pour le paquet stable officiel 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 / suivie du préréglage à utiliser. Par exemple, pour le paquet , utilisez la commande :

# mkinitcpio -p linux

Pour (re)générer tous les préréglages existants, utilisez le paramètre /. 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 et l'enregistrera sous .

# 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 pour chaque noyau.

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

Images de noyau unifiées

Depuis la version 31, mkinitpcio 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 (par exemple ).

Les utilisateurs peuvent modifier six variables dans le fichier de configuration, consultez pour plus de détails :

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

MODULES

Le tableau 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.

BINARIES et FILES

Ces options permettent aux utilisateurs d'ajouter des fichiers à l'image. et 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 sont localisées automatiquement dans un standard et sont analysées en fonction des dépendances, ce qui signifie que toute bibliothèque requise sera également ajoutée. Les sont ajoutés tels quels. Par exemple :

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

BINARIES=(kexec)

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

HOOKS

Le tableau 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 du fichier de configuration.

Le paramètre par défaut 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 , les «hooks» de construction personnalisés peuvent être placés dans . Ces fichiers sont récupérés par le shell bash pendant l'exécution de mkinitcpio et doivent contenir deux fonctions : et . La fonction 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 fournit une description de ce que le «hook» accomplit.

Pour une liste de tous les «hooks» disponibles :

$ mkinitcpio -L

Utilisez l'option -H/ 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 , les «hooks» d'exécution personnalisés peuvent être placés dans . 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 . Les «hooks» d'exécution peuvent contenir plusieurs fonctions :

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

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

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

: 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 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)
colspan="2"	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.
	rowspan="3"	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.
	Ajoute la prise en charge de sur une partition séparée. Consultez #/usr sur une partition séparée pour plus de détails.	Monte la partition après que la racine réelle ait été montée.
		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 installé pour utiliser ceci. Ce «hook» n'est pas nécessaire pour utiliser Btrfs sur un seul périphérique.	Lance 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 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é.
colspan="2"	Inclut les fichiers de configuration modprobe de et .
colspan="2"	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.
		Ajoute les modules nécessaires pour un périphérique réseau. Vous devez avoir 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é 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 .
mdadm_udev		Fournit la prise en charge de l'assemblage de matrices RAID via udev. Vous devez avoir installé pour l'utiliser. Si vous utilisez ce «hook» avec une matrice FakeRAID, il est recommandé d'inclure dans . Consultez #Utiliser RAID pour plus de détails.
colspan="2"	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.
	sd-vconsole	Ajoute la keymap spécifiée dans à l'initramfs. Si vous utilisez le chiffrement système, en particulier le chiffrement de disque complet, assurez-vous de l'ajouter avant le «hook» .	Charge les keymaps spécifiés depuis au début de l'espace utilisateur.
	sd-vconsole	Ajoute la police de console spécifiée de à l'initramfs.	Charge la police de la console spécifiée depuis au début de l'espace utilisateur.
	sd-encrypt	Ajoute le module noyau et l'outil à l'image. Vous devez avoir installé pour l'utiliser.	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.
colspan="2"	Ajoute le module noyau mappeur de périphériques et l'outil `lvm` à l'image. Vous devez avoir installé pour l'utiliser. Ceci est nécessaire si vous avez votre système de fichiers racine sur LVM.
colspan="2"	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 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 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 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.
colspan="2"	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 .

COMPRESSION

Le noyau prend en charge plusieurs formats pour la compression de l'initramfs : , , lzma, xz, , et . 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 fourni contient les différentes options 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 dans le fichier de configuration ou utilisez sur la ligne de commande.

COMPRESSION_OPTIONS

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

COMPRESSION_OPTIONS=(-9)

Personnalisation de l'exécution

Les options de configuration durant l'exécution peuvent être transmises à 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

: 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 :
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é.

: Si ou est spécifié, 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 . 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 . Par exemple :

: Modifie l'ordre dans lequel les modules sont chargés en spécifiant les modules à charger précocement via . (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 .

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

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 peut apparaître seul comme valeur du paramètre (sans tous les caractères avant). Si la valeur est 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 .

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.

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é, 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 sera utilisé.

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

Exécutez 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 sur une partition séparée, vous devez respecter les exigences suivantes :

Ajouter le «hook» , marquer avec un de dans 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 soit vérifié au démarrage. Sans ce «hook», ne sera jamais vérifié.
Si vous n'utilisez pas le «hook» systemd, ajoutez le «hook» usr. Ceci montera la partition 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 et , é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é 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 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é .

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

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

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

(Évidemment, 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 . 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 . Pour xhci_pci, installez . 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 , ajoutez atkbd au tableau .

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

gollark: I think so.

gollark: Caddy also does that.

gollark: Caddy is nice in that it does a lot of the fiddly stuff automatically.

gollark: Træfik is a pretty cool newer alternative which autoconfigures itself from docker, but seems harder to use.

gollark: nginx.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.