genkernel/fr
genkernel est un outil créé par Gentoo et utilisé pour automatiser le processus de compilation du noyau et du système de fichiers virtuel de démarrage (initramfs). Parmi ses fonctionnalités, on peut citer :
- Configurer les sources du noyau
- Compiler le noyau, le compresser bzImage, et le copier dans /boot.
- Créer un système de fichiers virtuels de démarrage (initramfs) dans /boot.
- Créer les liens symboliques dans /boot.
- Ajouter du contenu personnalisé dans le fichier initramfs comme les fichiers spécifiques à l’encryption, une image pour l'écran de chargement, des modules supplémentaires, et plus encore.
- Compresser le fichier initramfs.
- Configure le système d'amorçage pour démarrer sur le nouveau noyau et fichier initramfs.
To use /efi instead of /boot for newer UEFI systems, see Changing the boot directory to /efi.
C'est une erreur courante de croire que genkernel va "automatiquement" générer une configuration du noyau personnalisée. genkernel automatise le processus de compilation du noyau et assemble le fichier initramfs, mais ne génère pas un fichier de configuration du noyau personnalisé. Il utilise une configuration générique qui fournit une support pour les sous-systèmes couramment utilisés en fonction de l'architecture. Les détails des défauts utilisés pour chaque architecture peuvent être retrouvés sur le répertoire en amont. Choisir l'architecture voulue puis choisir le fichier kernel-config.
Installation
Options de la variable USE
USE flags for sys-kernel/genkernel Gentoo automatic kernel building scripts
Emerge
Procéder à l'installation du paquet genkernel :
root #
emerge --ask sys-kernel/genkernel
Utilisation
La forme générale de l'invocation de genkernel est la suivante :
root #
genkernel [options ...] action
Options
Le comportement réel de genkernel dépend d'une grande variété d'options, dont la majorité peut être activée/désactivée dans le fichier /etc/genkernel.conf ou passée avec la commande genkernel. Les options passées en ligne de commande prévalent sur celles définies dans /etc/genkernel.conf. Le fichier de configuration est très bien documenté, cependant les options les plus courantes seront vues dans cet article. Le but est pour le lecteur d'être familier avec les invocations courantes de genkernel. Pour une information plus complète, se reporter aux commentaires du fichier /etc/genkernel.conf ou à la sortie de la commande man genkernel.
Certaines options possèdent une variante qui déclenche un comportement inverse. Elle sont notées sous la forme
--[no-]option_name
, et l'effet inverse est noté entre crochets comme dans cet exemple :
--[no]menuconfig : Activates [deactivates]…
no-
, ainsi que son effet, qui ne sont pas optionnels dans ce cas là, sont notés sans les crochets.Options agissant sur l'interactivité de l'utilisateur
Les options de configuration listées ci-dessous aident l'utilisateur à décider comment interagir avec le processus de configuration. L'utilisateur peut même décider si le fichier de configuration sera sauvegardé. Les options suivantes sont les options de configuration de premier ordre :
--config=/path/to/genkernel.conf
- Pointe vers le fichier de configuration de Genkernel à utiliser (par défaut sur /etc/genkernel.conf).
--[no-]menuconfig
- Active (ou désactive) la commande make menuconfig (qui invoque un menu de configuration interactif) avant de compiler le noyau.
--gconfig
- Propose un outil de configuration du noyau qui dépend des librairies GTK+. L'avantage de cette option et que la plupart des utilisateurs trouvent plus facile et plus claire la configuration du noyau en utilisant cet outil, vu qu'il dépend du système de fenêtres X. L'inconvénient de cette option est que le système de fenêtres X est requis pour l'utiliser, et ne marchera donc pas en ligne de commande.
--xconfig
- Propose un outil de configuration du noyau qui dépend des librairies Qt. L'avantage de cette option et que la plupart des utilisateurs trouvent plus facile et plus claire la configuration du noyau en utilisant cet outil, vu qu'il dépend du système de fenêtres X. L'inconvénient de cette option est que le système de fenêtres X est requis pour l'utiliser, et ne marchera donc pas en ligne de commande.
--[no-]save-config
- Enregistrer [ou non] la configuration du noyau dans un fichier dans le répertoire /etc/kernels pour un usage ultérieur.
--kernname=NickName
- Permet la modification du nom du noyau et des images initrd dans le répertoire /boot, de façon à ce que les images générées soient pas kernel-surnom-version et initramfs-surnom-version.
Options agissant sur le système résultant
Les options définies ici définissent quelles fonctionnalités, seront, ou ne seront pas, incluses dans le noyau et le système de fichiers virtuel de démarrage résultants.
--[no-]splash
- Active (ou désactive) le support pour Fbsplash (framebuffer splash) dans l'image initrd générée par genkernerl. Pour outrepasser le thème par défaut utilisé par fbsplash, utilisez
--splash=PreferredTheme
(oùPreferredTheme
est le nom d'un des répertoires dans /etc/splash). --splash-res=PreferredResolution
- Cette option permet de sélectionner les résolutions qui seront supportées par l'écran de chargement dans le fichier initrd lors du démarrage du système. C'est utile pour deux raisons. D'abord, pour permettre de ne sélectionner seulement que les résolutions pertinentes au système. Deuxièmement, pour éviter les augmentations inutiles de l'espace disque requis par le fichier initrd (vu que le fichier initrd n'a pas besoin de prendre un compte les résolutions qui ne sont pas supportées par le système). Cependant, il est préférable d'omettre l'option si le noyau est compilé pour une image CD ; cela permet de supporter toutes les résolutions possibles pour l'écran de chargement.
--do-keymap-auto
- Force la sélection d'un dispositif de clavier lors du démarrage.
--lvm
- Inclut le support pour le stockage via Logical Volume Management (LVM2) depuis les fichiers binaires statiques, si disponibles sur le système. Les fichiers LVM2 binaires nécessaires seront compilés s'ils ne sont pas disponibles. Être sur d'avoir le paquet sys-fs/lvm2 installé sur le système (emerge sys-fs/lvm2) avant d'activer cette option, puis se reporter à l'article sur LVM du wiki Gentoo.
--dmraid
- Inclut le support pour DMRAID ; l'utilitaire qui crée des mappages RAID à l'aide du sous-système mappeur de périphérique du noyau. DMRAID découvre, active, désactive et affiche les propriétés des jeux logiciels RAID (ATARAID, par exemple) et partitions DOS.
--luks
- Inclut le support pour Linux Unified Key Setup ou LUKS. Cela permettra d'utiliser une partition encryptée comme système de fichiers racine. Dans le système d'amorçage, mettre cette partition comme valeur de
crypt_root
(etroot
doit désigner la partition décryptée créée par LUKS). --disklabel
- Ajoute le support pour les labels et identifiants universels uniques (UUID) à l'image initrd.
--iscsi
- Ajoute le support pour iSCSI à l'image initrd.
--multipath
- Ajoute le support pour Multipath à l'image initrd.
--linuxrc=/path/to/the/linuxrc_file
- Spécifie un fichier linuxrc créé par l'utilisateur — un script initialisé pendant le démarrage du noyau, avant l'actuel processus de démarrage. Un script linuxrc par défaut peut être trouvé dans le répertoire /usr/share/genkernel/. Ce script permet de démarrer dans un petit noyau modulaire; il essaye de ne charger que le minimum des pilotes nécessaires (en tant de modules) au système.
--cachedir=/path/to/alt/dir
- Modifie l'emplacement par défaut du cache utilisé lors de la compilation du noyau.
--tempdir=/path/to/new/tempdir
- Spécifie l'emplacement du répertoire temporaire utilisé par genkernel lors de la compilation du noyau.
--unionfs
- Inclut le support pour Unification File System (UFS) dans l'image initrd.
--mountboot
- Détecte si le répertoire /boot doit être monté sur une partition séparée. Il regardera dans le script /etc/fstab pour les instructions sur comment monter la partition boot sur un système de fichiers (si nécessaire).
Options agissant sur le choix des outils utilisés pour la compilation
Les options suivantes sont prises en charge par genkernel, et sont passées aux applications concernées lors de la compilation et de l'assemblage du noyau. Ces options influent sur le choix des outils utilisés pendant le processus de compilation, quoi qu'à un niveau assez bas.
--kernel-cc=someCompiler
- Spécifie le compilateur utilisé lors du processus de compilation du noyau.
--kernel-ld=someLinker
- Spécifie l'éditeur de liens utilisé lors du processus de compilation du noyau.
--kernel-as=someAssembler
- Spécifie l'assembleur utilisé lors du processus de compilation du noyau.
--kernel-make=someMake
- Spécifie une alternative à l'utilitaire GNU make utilisé lors du processus de compilation du noyau.
--utils-cc=someCompiler
- Spécifie le compilateur utilisé lors du processus de la compilation des utilitaires de support.
--utils-ld=someLinker
- Spécifie l'éditeur de liens utilisé lors du processus de la compilation des utilitaires de support.
--utils-as=someAssembler
- Spécifie l'assembleur utilisé lors du processus de la compilation des utilitaires de support.
--utils-make=someMake
- Spécifie une alternative à l'utilitaire GNU make utilisé lors de la compilation des utilitaires de support.
--makeopts=-jX
- Spécifie le nombre de threads simultanés que l'utilitaire make peut mettre en œuvre alors que le noyau (et les utilitaires) sont compilés. La variable
X
est un nombre à choisir librement, bien que les valeurs les plus courantes soient obtenues en ajoutant un (1) au nombre de cœurs utilisés par le système ou simplement en utilisant le nombre de cœurs du système. Ainsi, pour un système avec un seul cœur, les valeurs d'option les plus courantes sont-j2
ou-j1
; Un système à deux cœurs utilise très probablement les options-j3
ou-j2
, etc. (Un système avec un processeur prenant en charge la technologie Hyper-Threading ™ (HT) peut être supposé avoir deux cœurs, à condition que le support Symmetric Multi-Processing (SMP) soit activé dans le noyau.)
Options agissant sur le processus de compilation
Les options suivantes ont généralement un effet lors de la compilation réelle.
--kerneldir=/path/to/sources/
- Spécifie un emplacement alternatif du noyau plutôt que l'emplacement par défaut /usr/src/linux/.
--kernel-config=/path/to/config-file
- Spécifie une configuration alternative du noyau à utiliser plutôt que le fichier par défaut /path/to/sources/.config.
--module-prefix=/path/to/prefix-directory/
- Spécifie un préfixe pour le répertoire dans lequel les modules du noyau seront installés (le chemin par défaut est le répertoire /lib/modules.)
--[no-]clean
- Active (ou désactive) la commande make clean avant la compilation du noyau. La commande make clean supprime tous les fichiers objets et les dépendances de l'arbre source du noyau.
--[no-]mrproper
- Active (désactive) la commande make mrproper avant la compilation du noyau. Comme la commande make clean listée ci-dessus, make mrproper supprime tous les fichiers objets et les dépendances de l'arbre source du noyau. Cependant, les fichiers de configuration précedents (dans /path/to/sources/.config ou /path/to/sources/.config.old) seront aussi supprimés de l'arbde source du noyau. Si la disparition du fichier de configuration du noyau .config n'est pas souhaitée, désactiver cette option.
--oldconfig
- Exécute la commande make oldconfig, qui essaye de collecter des informations pour la configuration du noyau en fonction de l'architecture du système depuis un script générique dans /usr/share/genkernel. C'est un processus non-interactif ; aucune entrée utilisateur n'est demandée. Aussi, si l'option
--oldconfig
est utilisée conjointement avec l'option--clean
, cette dernière est annulée, résultant en l'activation de l'option--no-clean
. --callback="echo hello"
- Appelle paramètres spécifiés (echo hello, dans ce cas) après que le noyau et les modules aient été compilés, mais avant l'installation de l'image initrd. Cela peut être utile quand des modules externes sont installés dans l'image initrd, permettant d'installer les items nécessaires avant de redéfinir une groupe de modules genkernel.
--[no-]install
- Active (ou désactive) la commande make install, qui installe la nouvelle image du noyau, le fichier de configuration, l'image initrd et la carte du système sur la partition boot. Chaque module compilé sera également installé. Par défaut, genkernel essaiera de monter /boot si présent sur une partition séparée avant d'exécuter la commande.
--no-ramdisk-modules
- Évite de copier les modules dans l'image initrd créée par genkernel. Cette option est une exception à la règle sur l'utilisation du préfixe
no-
; l'oubli de ce préfixe créer une option de genkernel invalide. --all-ramdisk-modules
- Copie tous les modules disponibles dans l'image initrd créée par genkernel.
--genzimage
- Créé l'image initrd, avant l'image du noyau (cette astuce ne s'applique actuellement qu'aux systèmes PPC Pegasos).
Options de débogage
L'utilisation d'options de débogage pendant la compilation du noyau contrôle le nombre d'informations reportées, ainsi que la présentation de celles-ci.
--loglevel=<0|1|2|3|4|5>
- Contrôle le niveau de verbosité de l'information donnée par genkernel. La variable
<verblevel>
est un entier entre 0 et 5. Le niveau '0' représente une verbosité minimale, alors que '5' donne autant d'information que possible à propos de l'activité de genkernel durant le processus de compilation du noyau. --logfile=/path/to/output_file
- Ignore la valeur fixée par l'option
--loglevel
(ci-dessus) et envoie toutes les informations de débogage produites par genkernel dans fichier spécifié. Le fichier par défaut est /var/log/genkernel.log. --[no-]color
- Active (ou désactive) la sortie colorée des informations de débogage (générées par genkernel) en utilisant des séquences d'échappement.
--[no-]debug-cleanup
- Active (ou désactive) le nettoyage complet d'après exécution pour un débogage plus facile.
Actions
Une action passée avec la commande genkernel [options …] action indique à genkernel ce qu'il faut faire. Les actions prises en charge sont :
Action | Description |
---|---|
all | Compile toutes les étapes — le fichier initrd, l'image du noyau et les modules. |
bzImage | Ne compiler que l'image du noyau. |
kernel | Ne compiler que l'image du noyau et les modules. |
initramfs | Ne compiler que l'image initramfs/ramdisk. |
ramdisk | Ne compiler que l'image initramfs/ramdisk. |
Configuration
Démarrer
Bien qu'il y ait plusieurs façons de lancer genkernel, la plus simple reste genkernel all. Une configuration générique qui marche correctement pour tous les systèmes sera alors utilisée. Comme mentionné précédemment, cette méthode n'est pas sans inconvénients. La plupart des modules compilés ne seront pas utilisés et la compilation prendra beaucoup de temps. L'illustration suivante montre une approche plus efficace, en passant certains paramètres à genkernel en tant qu'utilisateur root:
root #
genkernel --splash --no-install --no-clean --menuconfig all
Cette opération indique à genkernel de créer un noyau avec un écran de démarrage (--splash
) en tampon de trames (framebuffer) qui devra être installé à la main (--no-install
). Dans la phase préparatoire de compilation, genkernel n'effacera pas les objets déjà compilés (--no-clean
). Enfin, un menu de configuration sera affiché, permettant à l'utilisateur de choisir quels modules seront compilés (--menuconfig
).
Remplacer --no-install
par --install
pour qu'il installe automatiquement le nouveau noyau dans /boot et spécifier --symlink
pour qu'il crée les liens symboliques. En utilisant le paramètre -- --mountboot
, la partition /boot sera montée par genkernel automatiquement, si nécessaire.
Ne pas oublier que le fichier /etc/genkernel.conf est lu par la commande genkernel lorsqu'elle démarre, et que toutes les options qui y sont définies, seront appliquées, sauf quand une option en ligne de commande contradictoire est passée.
Changing the boot directory to /efi
It is now recommended to mount the UEFI system boot partition (ESP) under /efi instead of /boot.
By default, the kernel is written to /boot, which used to be the ESP in certain configurations, but is now on the root partition. Reasons to write the kernel to /efi include:
- Secure Boot expecting a hard coded ESP kernel path
- Making GRUB2 independent of the root partition for stability or security
- GRUB2 not supporting the root file-system (bcachefs)
- Using a grub.cfg not generated by grub-mkconfig
To point genkernel to /efi, either add --bootdir=/efi
to the genkernel
command or BOOTDIR="/efi"
to /etc/genkernel.conf.
# Set the boot directory, default is /boot
BOOTDIR="/efi"
Changer le noyau
La première chose à faire est d'autoriser le lancement de make menuconfig dans le fichier /etc/genkernel.conf :
# Lancer 'make menuconfig' avant de compiler le noyau
MENUCONFIG="yes"
Gestion des fichiers
Quand il utilise genkernel, l'utilisateur doit être conscient de quelques aspects concernant la gestion des fichiers de configuration et des fichiers image du noyau, ainsi que de la façon dont les sources du noyau sont manipulées par le système.
Fichiers sources
Après une commande emerge -u gentoo-sources,, chaque fois que de nouvelles sources sont disponibles, un nouveau répertoire est créé pour les sources du noyau dans /usr/src/ pour les héberger. Normalement, le dossier des sources actives est pointé par le lien symbolique /usr/src/linux.
Le répertoire /usr/src pourrait ressembler à ceci :
user $
ls -l /usr/src
total 16 lrwxrwxrwx 1 root root 19 21 Mar 2013 linux -> linux-3.7.10-gentoo drwxr-xr-x 24 root root 4096 25 Aug 10:39 linux-3.10.7-gentoo drwxr-xr-x 20 root root 4096 21 Apr 19:42 linux-3.7.10-gentoo drwxr-xr-x 21 root root 4096 14 Mar 2013 linux-3.7.9-gentoo
Le lien symbolique /usr/src/linux peut être changé de différentes manières.
- Si l'option
symlink
de la variable USE est définie le lien symbolique /usr/src/linux est automatiquement mis à jour pour pointer sur les nouvelles sources installées par la commandeemerge
.
- Si l'option de la variable USE
symlink
n'est pas définie, l'utilisateur peut changer la destination du lien symbolique en utilisant la commande eselect kernel list suivie de la commande eselect kernel set.
genkernel utilisera toujours (exclusivement) les sources pointées par le lien symbolique /usr/src/linux.
Fichiers de configuration du noyau
Si une compilation du noyau a déjà été faite à partir des sources actives du noyau, il devrait y avoir un fichier dans le dossier /etc/kernels qui contient la configuration du noyau qui a été appliquée lors de la création de la dernière bzimage du noyau. Ce fichier est nommé par exemple kernel-config-x86_64-3.7.9-gentoo-r1 ; nom dans lequel il faut remplacer x86_64
par l'architecture du système, 3.7.9
par la version des sources utilisées et r1
par le numéro de divulgation des sources.
C'est ce fichier kernel-config-x86_64-3.7.9-gentoo-r1 qui est utilisé comme point de départ de la configuration lorsque genkernel --menuconfig all est lancé.
Si c'est la première fois que genkernel est exécuté avec les nouvelles sources du noyau, ou si la précédente configuration n'a pas été sauvegardée, ce fichier est remplacé par une configuration par défaut qui réside dans usr/share/genkernel/arch/x86_64/kernel-config (nom dans lequel x86_64 doit être remplacé par l'architecture réelle).
Le chemin vers ce fichier de configuration par défaut peut être changé en définissant la variable DEFAULT_KERNEL_CONFIG dans le fichier /etc/genkernel.conf.
Sauvegarder la configuration compilée
Si l'option --save-config
de genkernel est activée, soit depuis la ligne de commande, soit dans /etc/genkernel.conf, la configuration compilée du noyau est sauvegardée (avec le nom donné ci-dessus) dans le dossier /etc/kernels. En même temps, la configuration est sauvegardée dans le fichier .config dans le dossier /usr/src/linux mais ce n'est pas ce fichier qui est réutilisé lors de la prochaine exécution de genkernel all.
Il faut être conscient que, à chaque fois que genkernel est exécuté avec l'option
--save-config
de genkernel définie, le fichier de configuration dans /etc/kernels est écrasé. En conséquence, il est fortement recommandé de dupliquer ce fichier sous un nouveau nom avant d'exécuter genkernel pour le préserver.Installer le noyau et le disque virtuel de démarrage dans le dossier /boot
Spécifier l'option all
lors de l'invocation de genkernel, demandera à genkernel d'installer les images du noyau et du système de fichiers virtuel de démarrage (initramfs) dans le dossier /boot. Afin d'exécuter --install
d'une manière appropriée, définir ce qui suit dans le fichier /etc/genkernel.conf :
# Monter BOOTDIR automatiquement s'il n'est pas monté ?
MOUNTBOOT="yes"
# Sauvegarder la nouvelle configuration dans /etc/kernels si
# la compilation réussit
SAVE_CONFIG="yes"
# Créer les liens symbolique dans BOOTDIR automatiquement ?
SYMLINK="yes"
# Ajouter le nouveau noyau à grub2?
#BOOTLOADER="grub2"
- Le premier paramètre parle de lui-même.
- Le second paramètre dit à genkernel de sauvegarder la configuration du noyau compilé dans /etc/kernels.
- Les deux dernières options indiquent à genkernel de mettre la configuration de grub à jour. En pratique, voilà ce qui se passe :
- Si une image précédente du noyau avec le même nom existe déjà, elle est renommée en ajoutant .old à son nom. Un lien symbolique qui pointe sur lui kernel.old est automatiquement créé.
- Le nouveau noyau prend la place de tout noyau de même nom dans le dossier /boot. Si c'est la première fois que le noyau est compilé, un lien symbolique qui pointe sur le nouveau noyau est automatiquement créé.
Après l'exécution de la commande genkernel --menuconfig all, le dossier /boot pourrait ressembler à ceci :
user $
ls -al /boot
total 41336 drwxr-xr-x 3 root root 4096 20 avril 17:23 . drwxr-xr-x 24 root root 4096 15 sept. 12:31 .. lrwxrwxrwx 1 root root 1 24 févr. 2013 boot -> . drwxr-xr-x 2 root root 4096 24 févr. 2013 grub lrwxrwxrwx 1 root root 40 20 avril 17:23 initramfs -> initramfs-genkernel-x86_64-3.7.10-gentoo -rw-r--r-- 1 root root 1314412 20 avril 17:23 initramfs-genkernel-x86_64-3.7.10-gentoo -rw-r--r-- 1 root root 1313548 21 mars 2013 initramfs-genkernel-x86_64-3.7.10-gentoo.old -rw-r--r-- 1 root root 1295344 25 févr. 2013 initramfs-genkernel-x86_64-3.7.9-gentoo -rw-r--r-- 1 root root 3310324 25 févr. 2013 initramfs-genkernel-x86_64-3.7.9-gentoo.old lrwxrwxrwx 1 root root 44 20 avril 17:23 initramfs.old -> initramfs-genkernel-x86_64-3.7.10-gentoo.old lrwxrwxrwx 1 root root 37 20 avril 17:23 kernel -> kernel-genkernel-x86_64-3.7.10-gentoo -rw-r--r-- 1 root root 4866656 20 avril 17:23 kernel-genkernel-x86_64-3.7.10-gentoo -rw-r--r-- 1 root root 4866560 21 mars 2013 kernel-genkernel-x86_64-3.7.10-gentoo.old -rw-r--r-- 1 root root 4552288 25 févr. 2013 kernel-genkernel-x86_64-3.7.9-gentoo -rw-r--r-- 1 root root 3400736 25 févr. 2013 kernel-genkernel-x86_64-3.7.9-gentoo.old lrwxrwxrwx 1 root root 41 20 avril 17:23 kernel.old -> kernel-genkernel-x86_64-3.7.10-gentoo.old
Configurer le programme d'amorçage
extlinux
TODO
GRUB Legacy
The following text is about GRUB Legacy which was removed in Gentoo in February 2019. If at all possible, please migrate to GRUB2 as soon as possible.
Les liens symboliques présentées plus haut peuvent être utilisés pour configurer le programme d'amorçage, de telle manière que même si le nouveau noyau n'est pas amorçable, l'utilisateur puisse toujours redémarrer sur l'ancien.
Pour permettre au nouveau noyau et au nouveau système de fichiers virtuel initrd produit par genkernel de fonctionner correctement, il faut fournir un minimum d'informations dans le fichier de configuration du programme d'amorçage :
- Ajouter
root=/dev/sdaN
aux paramètres du noyau passés à l'image du noyau, où /dev/sdaN pointe sur le partition root (N
est le numéro de la partition si une partition existe.). - Si un écran de chargement est utilisé, ajouter une ligne pour le mode approprié tel que
vga=0x317
aux paramètres passés au noyau et ajouter aussisplash=verbose
ousplash=silent
en fonction du niveau de verbosité voulu tout au long du processus de démarrage. - Ajouter l'information sur l'image initrd comme requis par le système d'amorçage. Consulter le chapitre sur la Configuration du Système d'amorçage du manuel Gentoo pour plus de détails sur comment rendre le système d'amorçage au courant de l'existence du fichier initrd.
Voici à quoi le fichier grub.conf pourrait ressembler.
# This is a sample grub.conf for use with Genkernel, per the Gentoo handbook
# http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=10#doc_chap2
# If you are not using Genkernel and you need help creating this file, you
# should consult the handbook. Alternatively, consult the grub.conf.sample that
# is included with the Grub documentation.
default 0
timeout 5
splashimage=(hd1,0)/boot/grub/splash.xpm.gz
title Gentoo Linux
root (hd0,6)
kernel /boot/kernel initrd=/dev/ram0 root=/dev/sda7 rootfstype=ext4
initrd /boot/initramfs
title Gentoo Linux old kernel
root (hd0,6)
kernel /boot/kernel.old initrd=/dev/ram0 root=/dev/sda7 rootfstype=ext4
initrd /boot/initramfs.old
GRUB
TODO
systemd-boot
TODO
Préserver les fichiers qui fonctionnent
L'application genkernel sauvegarde automatiquement les changements des fichiers. Si les changements précédents doivent être sauvegardés, les actions suivantes sont à envisager.
- Le premier fichier à préserver est le fichier de configuration du noyau dans /etc/kernels/. Si les sources n'ont pas changées avant la recompilation du noyau, le nom utilisé précédemment pour ce fichier sera utilisé à nouveau. C'est pourquoi dupliquer le fichier de configuration précédent avec un nouveau nom aide à préserver l'information tout en laissant l'ancien fichier disponible comme point de départ de la nouvelle configuration.
- La deuxième chose importante à préserver est les images des noyaux et initramfs déjà amorçables. La manière de le faire dépend du contexte :
- Si le dernier noyau compilé est amorçable, exécuter genkernel renommera cette image du noyau(et de façon similaire celle de l'image initramfs) en kernel-genkernel-ARCH-X.Y.Z-gentoo-rx.old et créera une nouvelle image kernel-genkernel-ARCH-X.Y.Z-gentoo-rx. Ceci signifie que, même si le nouveau noyau n'est pas amorçable, l'utilisateur sera toujours en mesure de démarrer sur l'ancien.
- Si le dernier noyau compilé n'est pas amorçable et si les sources n'ont pas été changées depuis que l'utilisateur en a compilé un qui était amorçable, avant d'exécuter genkernel, commencer par effacer la nouvelle image du noyau et supprimer le suffixe .old du nom du dernier noyau amorçable. Sans cela si le nouveau noyau n'est pas amorçable pour la deuxième fois, le kernel-genkernel-ARCH-X.Y.Z-gentoo-rx.old amorçable sera évincé par le renommage du kernel-genkernel-ARCH-X.Y.Z-gentoo-rx, laissant l'utilisateur avec un système non amorçable. Tenir le même raisonnement pour initramfs.
Since genkernel-4, it is recommended to create new, independent revisions each with its own kernel image, initramfs and installed modules in /lib/modules using genkernel --kernel-append-localversion=-my-new-revision all.
Utiliser la configuration précédente du noyau tout en changeant les sources
La configuration précédente peut être utilisée via la variable make menuconfig dans le fichier /etc/genkernel.conf comme ci-après :
# Exécuter 'make menuconfig' avant de compiler le noyau ?
MENUCONFIG="yes"
Il n'est pas nécessaire d'exécuter make oldconfig quand genkernel est utilisé, même si les sources ont été changées de kernel-genkernel-ARCH-version-gentoo-rx en kernel-genkernel-ARCH-version-gentoo-r(x+1) ou de kernel-genkernel-ARCH-version-gentoo en kernel-genkernel-ARCH-(version+1)-gentoo parce que make menuconfig va essayer de charger la configuration précédente au mieux dans le menu. Néanmoins, une revue minutieuse de chacune des options et des nouvelles sections est recommandée.
Checking that initramfs includes necessary modules/utilities before booting
Before booting the system, it might be wise checking that initramfs includes necessary utilities and modules. For example, to utilize remote unlock capabilities for a headless system using LUKS, ensure that kernel modules for the network interface card, dropbear, and cryptsetup have been included.
Using lsinitrd
Since genkernel-4, created initramfs can be processed using the lsinitrd command from the sys-kernel/dracut package:
user $
lsinitrd /boot/initramfs-5.3.14-gentoo-r1-x86_64-wifitest2.img
Image: /boot/initramfs-5.3.14-gentoo-r1-x86_64-wifitest2.img: 4,5M ======================================================================== Version: Genkernel 4.0.1 (2019-12-16 00:48:10 UTC) Arguments: --boot-font=none --keymap --compress-initramfs --no-microcode-initramfs --ramdisk-modules --busybox --no-btrfs --no-iscsi --no-multipath --no-dmraid --mdadm --lvm --no-unionfs --no-zfs --no-splash --no-strace --no-gpg --luks --no-firmware --firmware-dir=/lib/firmware --ssh --no-e2fsprogs --no-xfsprogs dracut modules: ======================================================================== drwxr-xr-x 16 root root 0 Dec 16 01:49 . drwxr-xr-x 2 root root 0 Dec 16 01:49 bin lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/ash -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/[ -> busybox -rwxr-xr-x 1 root root 2351376 Dec 16 01:49 bin/busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/cat -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/cut -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/echo -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/mknod -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/mount -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/sh -> busybox lrwxrwxrwx 1 root root 7 Dec 16 01:49 bin/uname -> busybox drwxr-xr-x 2 root root 0 Dec 16 01:49 dev drwxr-xr-x 8 root root 0 Dec 16 01:49 etc -rw-r--r-- 1 root root 24 Dec 16 01:49 etc/build_date -rw-r--r-- 1 root root 16 Dec 16 01:49 etc/build_id drwxr-xr-x 2 root root 0 Dec 16 01:49 etc/dropbear -rw------- 1 root root 140 Dec 16 01:49 etc/dropbear/dropbear_ecdsa_host_key -rw------- 1 root root 806 Dec 16 01:49 etc/dropbear/dropbear_rsa_host_key prw-r--r-- 1 root root 0 Dec 16 01:49 etc/dropbear/fifo_root prw-r--r-- 1 root root 0 Dec 16 01:49 etc/dropbear/fifo_swap -rw-r--r-- 1 root root 97 Dec 16 01:49 etc/fstab -rw-r--r-- 1 root root 14 Dec 16 01:49 etc/group -rw-r--r-- 1 root root 3742 Dec 16 01:49 etc/initrd.defaults -rw-r--r-- 1 root root 69232 Dec 16 01:49 etc/initrd.scripts -rw-r--r-- 1 root root 441 Dec 16 01:49 etc/ld.so.cache -rw-r--r-- 1 root root 78 Dec 16 01:49 etc/ld.so.conf drwxr-xr-x 2 root root 0 Dec 16 01:49 etc/ld.so.conf.d -rw-r--r-- 1 root root 81 Dec 16 01:49 etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf -rw-r--r-- 1 root root 2298 Dec 16 01:49 etc/localtime drwxr-xr-x 3 root root 0 Dec 16 01:49 etc/lvm drwxr-xr-x 2 root root 0 Dec 16 01:49 etc/lvm/cache -rw-r--r-- 1 root root 95231 Dec 16 01:49 etc/lvm/lvm.conf -rw-r--r-- 1 root root 2882 Dec 16 01:49 etc/mdadm.conf drwxr-xr-x 3 root root 0 Dec 16 01:49 etc/mdev -rw-r--r-- 1 root root 1172 Dec 16 01:49 etc/mdev.conf drwxr-xr-x 2 root root 0 Dec 16 01:49 etc/mdev/helpers -rwxr-xr-x 1 root root 666 Dec 16 01:49 etc/mdev/helpers/nvme -rwxr-xr-x 1 root root 1295 Dec 16 01:49 etc/mdev/helpers/storage-device drwxr-xr-x 2 root root 0 Dec 16 01:49 etc/modprobe.d -rw-r--r-- 1 root root 1186 Dec 16 01:49 etc/modprobe.d/aliases.conf -rw-r--r-- 1 root root 122 Dec 16 01:49 etc/modprobe.d/i386.conf drwxr-xr-x 2 root root 0 Dec 16 01:49 etc/modules -rw-r--r-- 1 root root 24 Dec 16 01:49 etc/modules/ataraid -rw-r--r-- 1 root root 21 Dec 16 01:49 etc/modules/block -rw-r--r-- 1 root root 180 Dec 16 01:49 etc/modules/crypto -rw-r--r-- 1 root root 26 Dec 16 01:49 etc/modules/dmraid -rw-r--r-- 1 root root 23 Dec 16 01:49 etc/modules/firewire -rw-r--r-- 1 root root 123 Dec 16 01:49 etc/modules/fs -rw-r--r-- 1 root root 86 Dec 16 01:49 etc/modules/hyperv -rw-r--r-- 1 root root 40 Dec 16 01:49 etc/modules/iscsi -rw-r--r-- 1 root root 437 Dec 16 01:49 etc/modules/lvm -rw-r--r-- 1 root root 194 Dec 16 01:49 etc/modules/mdadm -rw-r--r-- 1 root root 75 Dec 16 01:49 etc/modules/multipath -rw-r--r-- 1 root root 214 Dec 16 01:49 etc/modules/net -rw-r--r-- 1 root root 56 Dec 16 01:49 etc/modules/nvme -rw-r--r-- 1 root root 519 Dec 16 01:49 etc/modules/pata -rw-r--r-- 1 root root 83 Dec 16 01:49 etc/modules/pcmcia -rw-r--r-- 1 root root 158 Dec 16 01:49 etc/modules/sata -rw-r--r-- 1 root root 523 Dec 16 01:49 etc/modules/scsi -rw-r--r-- 1 root root 350 Dec 16 01:49 etc/modules/usb -rw-r--r-- 1 root root 133 Dec 16 01:49 etc/modules/virtio -rw-r--r-- 1 root root 15 Dec 16 01:49 etc/modules/waitscan -rw-r--r-- 1 root root 47 Dec 16 01:49 etc/passwd -rw-r----- 1 root root 22 Dec 16 01:49 etc/shadow -rw-r--r-- 1 root root 25 Dec 16 01:49 etc/shells -rwxr-xr-x 1 root root 32331 Dec 16 01:49 init drwxr-xr-x 2 root root 0 Dec 16 01:49 .initrd drwxr-xr-x 6 root root 0 Dec 16 01:49 lib lrwxrwxrwx 1 root root 3 Dec 16 01:49 lib32 -> lib lrwxrwxrwx 1 root root 3 Dec 16 01:49 lib64 -> lib drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/console drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/dracut -rw-r--r-- 1 root root 312 Dec 16 01:49 lib/dracut/build-parameter.txt -rw-r--r-- 1 root root 42 Dec 16 01:49 lib/dracut/dracut-gk-version.info drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/keymaps lrwxrwxrwx 1 root root 9 Dec 16 01:49 lib/keymaps/10.map -> croat.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/11.map -> cz.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/12.map -> de.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/13.map -> dk.map lrwxrwxrwx 1 root root 10 Dec 16 01:49 lib/keymaps/14.map -> dvorak.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/15.map -> es.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/16.map -> et.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/17.map -> fi.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/18.map -> fr.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/19.map -> gr.map lrwxrwxrwx 1 root root 10 Dec 16 01:49 lib/keymaps/1.map -> azerty.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/20.map -> hu.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/21.map -> il.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/22.map -> is.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/23.map -> it.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/24.map -> jp.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/25.map -> la.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/26.map -> lt.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/27.map -> mk.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/28.map -> nl.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/29.map -> no.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/2.map -> be.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/30.map -> pl.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/31.map -> pt.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/32.map -> ro.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/33.map -> ru.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/34.map -> se.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/35.map -> sf.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/36.map -> sg.map lrwxrwxrwx 1 root root 8 Dec 16 01:49 lib/keymaps/37.map -> sk-y.map lrwxrwxrwx 1 root root 8 Dec 16 01:49 lib/keymaps/38.map -> sk-z.map lrwxrwxrwx 1 root root 11 Dec 16 01:49 lib/keymaps/39.map -> slovene.map lrwxrwxrwx 1 root root 8 Dec 16 01:49 lib/keymaps/3.map -> bepo.map lrwxrwxrwx 1 root root 7 Dec 16 01:49 lib/keymaps/40.map -> trf.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/41.map -> ua.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/42.map -> uk.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/43.map -> us.map lrwxrwxrwx 1 root root 10 Dec 16 01:49 lib/keymaps/44.map -> wangbe.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/4.map -> bg.map lrwxrwxrwx 1 root root 8 Dec 16 01:49 lib/keymaps/5.map -> br-a.map lrwxrwxrwx 1 root root 8 Dec 16 01:49 lib/keymaps/6.map -> br-l.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/7.map -> by.map lrwxrwxrwx 1 root root 6 Dec 16 01:49 lib/keymaps/8.map -> cf.map lrwxrwxrwx 1 root root 11 Dec 16 01:49 lib/keymaps/9.map -> colemak.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/azerty.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/be.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/bepo.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/bg.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/br-a.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/br-l.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/by.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/cf.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/colemak.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/croat.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/cz.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/de.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/dk.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/dvorak.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/es.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/et.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/fi.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/fr.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/gr.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/hu.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/il.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/is.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/it.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/jp.map -rw-r--r-- 1 root root 518 Dec 16 01:49 lib/keymaps/keymapList -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/la.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/lt.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/mk.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/nl.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/no.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/pl.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/pt.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/ro.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/ru.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/se.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/sf.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/sg.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/sk-y.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/sk-z.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/slovene.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/trf.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/ua.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/uk.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/us.map -rw-r--r-- 1 root root 2823 Dec 16 01:49 lib/keymaps/wangbe.map -rwxr-xr-x 1 root root 169376 Dec 16 01:49 lib/ld-linux-x86-64.so.2 -rwxr-xr-x 1 root root 1913648 Dec 16 01:49 lib/libc.so.6 -rwxr-xr-x 1 root root 26800 Dec 16 01:49 lib/libnss_dns.so lrwxrwxrwx 1 root root 13 Dec 16 01:49 lib/libnss_dns.so.2 -> libnss_dns.so -rwxr-xr-x 1 root root 51536 Dec 16 01:49 lib/libnss_files.so lrwxrwxrwx 1 root root 15 Dec 16 01:49 lib/libnss_files.so.2 -> libnss_files.so -rwxr-xr-x 1 root root 88736 Dec 16 01:49 lib/libresolv.so.2 drwxr-xr-x 3 root root 0 Dec 16 01:49 lib/modules drwxr-xr-x 3 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2 drwxr-xr-x 5 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/crypto -rw-r--r-- 1 root root 7152 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/crypto/algif_rng.ko drwxr-xr-x 6 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers drwxr-xr-x 3 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/hid drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/hid/usbhid -rw-r--r-- 1 root root 66448 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/hid/usbhid/usbhid.ko drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/md -rw-r--r-- 1 root root 19024 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/md/dm-log.ko -rw-r--r-- 1 root root 27256 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/md/dm-mirror.ko -rw-r--r-- 1 root root 49200 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/md/dm-raid.ko -rw-r--r-- 1 root root 16536 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/md/dm-region-hash.ko drwxr-xr-x 3 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/net drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/net/intel drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/net/intel/e1000 -rw-r--r-- 1 root root 70480 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/net/intel/e1000/e1000.ko drwxr-xr-x 6 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/common -rw-r--r-- 1 root root 6584 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/common/usb-common.ko drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/core -rw-r--r-- 1 root root 308944 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/core/usbcore.ko drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/host -rw-r--r-- 1 root root 60416 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/host/ehci-hcd.ko -rw-r--r-- 1 root root 10616 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/host/ehci-pci.ko -rw-r--r-- 1 root root 46072 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/host/ohci-hcd.ko -rw-r--r-- 1 root root 35896 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/host/uhci-hcd.ko drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/storage -rw-r--r-- 1 root root 126512 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/drivers/usb/storage/usb-storage.ko drwxr-xr-x 3 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/fs drwxr-xr-x 2 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/fs/fat -rw-r--r-- 1 root root 95664 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/fs/fat/fat.ko -rw-r--r-- 1 root root 16104 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/kernel/fs/fat/msdos.ko -rw-r--r-- 1 root root 32434 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.alias -rw-r--r-- 1 root root 42356 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.alias.bin -rw-r--r-- 1 root root 8132 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.builtin -rw-r--r-- 1 root root 11529 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.builtin.bin -rw-r--r-- 1 root root 15196 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.dep -rw-r--r-- 1 root root 23748 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.dep.bin -rw-r--r-- 1 root root 0 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.devname -rw-r--r-- 1 root root 8320 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.order -rw-r--r-- 1 root root 117 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.softdep -rw-r--r-- 1 root root 24707 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.symbols -rw-r--r-- 1 root root 29469 Dec 16 01:49 lib/modules/5.3.14-gentoo-r1-x86_64-wifitest2/modules.symbols.bin lrwxrwxrwx 1 root root 4 Dec 16 01:49 linuxrc -> init drwxr-xr-x 2 root root 0 Dec 16 01:49 mnt drwxr-xr-x 2 root root 0 Dec 16 01:49 proc drwxr-xr-x 3 root root 0 Dec 16 01:49 root drwx------ 2 root root 0 Dec 16 01:49 root/.ssh -rw------- 1 root root 742 Dec 16 01:49 root/.ssh/authorized_keys drwxr-xr-x 2 root root 0 Dec 16 01:49 run -rw-r--r-- 1 root root 0 Dec 16 01:49 run/utmp drwxr-xr-x 2 root root 0 Dec 16 01:49 sbin -rwxr-xr-x 1 root root 1105720 Dec 16 01:49 sbin/blkid -rwxr-xr-x 1 root root 2813384 Dec 16 01:49 sbin/cryptsetup lrwxrwxrwx 1 root root 19 Dec 16 01:49 sbin/dmsetup -> ../usr/sbin/dmsetup lrwxrwxrwx 1 root root 19 Dec 16 01:49 sbin/dmstats -> ../usr/sbin/dmstats lrwxrwxrwx 1 root root 7 Dec 16 01:49 sbin/init -> ../init lrwxrwxrwx 1 root root 15 Dec 16 01:49 sbin/lvm -> ../usr/sbin/lvm -rwxr-xr-x 1 root root 1510360 Dec 16 01:49 sbin/mdadm -rwxr-xr-x 1 root root 1267904 Dec 16 01:49 sbin/mdmon drwxr-xr-x 2 root root 0 Dec 16 01:49 sys drwxrwxrwt 2 root root 0 Dec 16 01:49 tmp drwxr-xr-x 6 root root 0 Dec 16 01:49 usr drwxr-xr-x 2 root root 0 Dec 16 01:49 usr/bin lrwxrwxrwx 1 root root 13 Dec 16 01:49 usr/bin/dropbearconvert -> dropbearmulti lrwxrwxrwx 1 root root 13 Dec 16 01:49 usr/bin/dropbearkey -> dropbearmulti -rwxr-xr-x 1 root root 1365144 Dec 16 01:49 usr/bin/dropbearmulti -rwxr-xr-x 1 root root 2881 Dec 16 01:49 usr/bin/login-remote.sh lrwxrwxrwx 1 root root 13 Dec 16 01:49 usr/bin/scp -> dropbearmulti drwxr-xr-x 2 root root 0 Dec 16 01:49 usr/lib lrwxrwxrwx 1 root root 3 Dec 16 01:49 usr/lib32 -> lib lrwxrwxrwx 1 root root 3 Dec 16 01:49 usr/lib64 -> lib drwxr-xr-x 2 root root 0 Dec 16 01:49 usr/sbin lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/cache_check -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/cache_dump -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/cache_metadata_size -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/cache_repair -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/cache_restore -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/cache_writeback -> pdata_tools -rwxr-xr-x 1 root root 1262952 Dec 16 01:49 usr/sbin/dmsetup lrwxrwxrwx 1 root root 7 Dec 16 01:49 usr/sbin/dmstats -> dmsetup lrwxrwxrwx 1 root root 20 Dec 16 01:49 usr/sbin/dropbear -> ../bin/dropbearmulti lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/era_check -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/era_dump -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/era_invalidate -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/era_restore -> pdata_tools -rwxr-xr-x 1 root root 2905416 Dec 16 01:49 usr/sbin/lvm -rwxr-xr-x 1 root root 3061192 Dec 16 01:49 usr/sbin/pdata_tools -rwxr-xr-x 1 root root 609 Dec 16 01:49 usr/sbin/resume-boot lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_check -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_delta -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_dump -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_ls -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_metadata_size -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_repair -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_restore -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_rmap -> pdata_tools lrwxrwxrwx 1 root root 11 Dec 16 01:49 usr/sbin/thin_trim -> pdata_tools -rwxr-xr-x 1 root root 3076 Dec 16 01:49 usr/sbin/unlock-luks drwxr-xr-x 3 root root 0 Dec 16 01:49 usr/share drwxr-xr-x 2 root root 0 Dec 16 01:49 usr/share/udhcpc -rwxr-xr-x 1 root root 1098 Dec 16 01:49 usr/share/udhcpc/default.script drwxr-xr-x 3 root root 0 Dec 16 01:49 var drwxr-xr-x 2 root root 0 Dec 16 01:49 var/log -rw-r--r-- 1 root root 0 Dec 16 01:49 var/log/lastlog -rw-r--r-- 1 root root 0 Dec 16 01:49 var/log/wtmp lrwxrwxrwx 1 root root 6 Dec 16 01:49 var/run -> ../run ========================================================================
The output above shows the e1000.ko file for an Intel NIC, the dropbear executable (usr/bin/dropbearmulti), and the cryptsetup (sbin/cryptsetup) executable have been embedded into the initramfs file.
Manual extraction
To extract a generated initramfs to inspect its content:
root #
mkdir /tmp/initramfs
root #
cd /tmp/initramfs
root #
xzcat kernel-genkernel-x86_64-4.14.65-gentoo | cpio -idmv
root #
ls -l sbin/cryptsetup
-rwxr-xr-x 1 root root 67568 28 d’oct 18:55 sbin/cryptsetup
Manual extraction will be difficult if CPU microcode updates have been embedded into the initramfs.
Microcode loading
For microcode (ucode) updates, kernel must support (early-)microcode loading and microcode updates must be present early at boot. See Microcode article for more details.
Microcode loading support in kernel
By default, genkernel will enable microcode loading support in kernel for both, AMD and Intel processors. This behavior can be controlled through MICROCODE option in /etc/genkernel.conf or by using the --microcode=(no|all|amd|intel)
command-line parameter during invocation.
Embedding microcode updates into initramfs
To embed microcode (ucode) updates into initramfs, MICROCODE_INITRAMFS must be enabled in /etc/genkernel.conf or command-line parameter --microcode-initramfs
must be passed at invocation. This will cause genkernel to prepend microcode(s) for selected processor (see --microcode
option above) to initramfs in case sys-firmware/intel-microcode with the split-ucode
USE flag for Intel processors and/or sys-kernel/linux-firmware for AMD processors is installed.
The technique of embedding microcode updates into the initramfs has been deprecated for modern systems in favor of using bootloaders (like sys-boot/grub) which are capable of loading multiple initramfs files. When using GRUB, or another modern bootloader, it is recommended to install sys-firmware/intel-microcode for Intel and sys-kernel/linux-firmware for AMD processors, both require the
initramfs
USE flag to be enabled. Let the bootloader load /boot/amd-uc.img and/or /boot/intel-uc.img in addition to genkernel's initramfs. This will enable updating of the CPU microcode independently of kernel/initramfs updates.Firmware loading
Specific firmware files can be added to genkernel's automatically generated initramfs when listed, with relative paths, in the variable FIRMWARE_FILES in /etc/genkernel.conf. When sys-kernel/genkernel is installed with USE="firmware"
it will prefer firmware files from /lib/firmware.
# Add firmware(s) to initramfs
FIRMWARE="yes"
# Specify directory to pull from
FIRMWARE_DIR="/lib/firmware"
# Specify a comma-separated list of firmware files or directories to include,
# relative to FIRMWARE_DIR. If empty or unset, the full contents of
# FIRMWARE_DIR will be included (if FIRMWARE option above is set to YES).
FIRMWARE_FILES="<comma-separated list of firmware files here>"
In case sys-kernel/gentoo-sources is installed with USE="experimental" and the kernel is configured with CONFIG_GENTOO_PRINT_FIRMWARE_INFO=y
, the following command gets a comma-separated list of all currently loaded firmware files for the use in the FIRMWARE_FILES variable from /etc/genkernel.conf as illustrated above (the output is just an example):
root #
dmesg -t | grep '^Loading firmware*' | sed 's/^Loading\sfirmware:\s//' | echo $(cat) | tr ' ' ','
amdgpu/green_sardine_sdma.bin,amdgpu/green_sardine_asd.bin,amdgpu/green_sardine_ta.bin,amdgpu/green_sardine_pfp.bin,amdgpu/green_sardine_me.bin,amdgpu/green_sardine_ce.bin,amdgpu/green_sardine_rlc.bin,amdgpu/green_sardine_mec.bin,amdgpu/green_sardine_dmcub.bin,amdgpu/green_sardine_vcn.bin,regulatory.db,regulatory.db.p7s,rtw89/rtw8852a_fw.bin,rtl_bt/rtl8852au_fw.bin,rtl_bt/rtl8852au_config.bin,rtl_nic/rtl8168h-2.fw
It is also possible to incorporate the firmware into the kernel image directly, but be aware that CONFIG_EXTRA_FIRMWARE in the kernel configuration file .config (normally found in /usr/src/linux) requires a space-separated list (output example):
root #
dmesg -t | grep '^Loading firmware*' | sed 's/^Loading\sfirmware:\s//' | echo $(cat)
amdgpu/green_sardine_sdma.bin amdgpu/green_sardine_asd.bin amdgpu/green_sardine_ta.bin amdgpu/green_sardine_pfp.bin amdgpu/green_sardine_me.bin amdgpu/green_sardine_ce.bin amdgpu/green_sardine_rlc.bin amdgpu/green_sardine_mec.bin amdgpu/green_sardine_dmcub.bin amdgpu/green_sardine_vcn.bin regulatory.db regulatory.db.p7s rtw89/rtw8852a_fw.bin rtl_bt/rtl8852au_fw.bin rtl_bt/rtl8852au_config.bin rtl_nic/rtl8168h-2.fw
Such a list will only be complete if the drivers successfully load all the required firmware(s): In case a driver requires more than one firmware file but fails loading the first one, only this will be listed and thereby other required firmware filenames will be missing. A recommended procedure to find all required firmware files is to compile the respective drivers as modules first,
M
in the kernel configuration, and to notthe modules in initramfs. The modules will be loaded after switching to the real /
(root) directory, where all firmware files will be available from sys-kernel/linux-firmware (and others) under /lib/firmware. When a system boots successfully with this method, running the above command will gather a complete list of the required firmware files. The files can be included in the initramfs (or the kernel itself), allowing for the drivers to be compiled directly into the kernel, *
in the kernel configuration, or to include the drivers as kernel modules in the initramfs as well. In both cases loading the modules will be earlier and it will be successful with the availability of the firmware files in the initramfs, which must be loaded alongside the kernel e.g. using GRUB.Remote rescue shell
genkernel can embed the net-misc/dropbear SSH daemon into the initramfs which will allow fixing certain things on boot remotely when initramfs is at least able to load. The most common used feature will be remote unlock capability for LUKS-encrypted root or swap devices or ZFS volumes.
Pre-requirement for SSH daemon support in initramfs
A authorized_keys file must exist before genkernel will be invoked. By default, genkernel will look for /etc/dropbear/authorized_keys. Command-line argument --ssh-authorized-keys-file=/path/to/custom/authorized_keys
or genkernel configuration option SSH_AUTHORIZED_KEYS_FILE can be used to alter default value.
Create /etc/dropbear/authorized_keys as a symlink to /root/.ssh/authorized_keys for example to keep root access and remote rescue shell access in sync!
Adding SSH support to initramfs
To embed SSH daemon into genkernel's initramfs, run genkernel with --ssh
command-line argument or set SSH="yes" in genkernel configuration file. Needless to mention that this feature will require working network at boot. The following example will just (re-)build initramfs with SSH daemon embedded:
root #
genkernel --ssh initramfs
* Gentoo Linux Genkernel; Version 4.0.1 * Using genkernel configuration from '/etc/genkernel.conf' ... * Running with options: --ssh initramfs </div> <div lang="en" dir="ltr" class="mw-content-ltr"> * Working with Linux kernel 5.3.14-gentoo-r1-x86_64 for x86_64 * Using kernel config file '/etc/kernels/kernel-config-5.3.14-gentoo-r1-x86_64' ... </div> <div lang="en" dir="ltr" class="mw-content-ltr"> * initramfs: >> Initializing ... * >> Appending devices cpio data ... * >> Appending base_layout cpio data ... * >> Appending auxilary cpio data ... * >> Appending blkid cpio data ... * >> Appending busybox cpio data ... * >> Appending dropbear cpio data ... ================================================================= This initramfs' sshd will use the following host key(s): 256 MD5:a5:13:09:90:5b:f6:a1:95:49:9f:87:d9:fa:e5:d8:02 (ECDSA) 256 SHA256:5dxNGEOwH9hvX4+sV4WtzRV/9m8/hrhgnNtTplZf5x8 (ECDSA) 2048 MD5:1d:e6:cc:ce:c8:96:a0:73:3e:4c:2a:56:ce:b9:10:26 (RSA) 2048 SHA256:V4WrMKhfVSxSeW3XIbW8dSaAmXiwN6jiMA/geNKLcqA (RSA) ================================================================= * >> Appending modprobed cpio data ... * >> Appending modules cpio data ... * >> Appending linker cpio data ... * >> Deduping cpio ... * >> Pre-generating initramfs' /etc/ld.so.cache ... * >> Compressing cpio data (.xz) ... * * You will find the initramfs in '/boot/initramfs-5.3.14-gentoo-r1-x86_64.img'. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> * WARNING... WARNING... WARNING... * Additional kernel parameters that *may* be required to boot properly: * - Add "dosshd" to start SSH daemon in initramfs </div> <div lang="en" dir="ltr" class="mw-content-ltr"> * Do NOT report kernel bugs as genkernel bugs unless your bug * is about the default genkernel configuration... * * Make sure you have the latest ~arch genkernel before reporting bugs.
By default, genkernel will generate own, dedicated SSH host keys for any missing supported key algorithm for embedded SSH daemon. This will allow to differentiate between real system's SSH daemon and initramfs' SSH daemon. To use host's SSH host keys instead or generate new keys at runtime on each boot use
--ssh-host-keys
command-line option and see genkernel's man page for more details.Enabling SSH daemon on boot
Just adding SSH daemon to initramfs is not enough. Because exposing any network service could be a security risk, this feature must be enabled via the kernel command-line argument dosshd
! See Configure Network for how to configure network in genkernel.
Remote unlock
There are two possibilities to unlock LUKS-encrypted root and/or swap volume: A manual way, through an SSH connection, run a command and will get prompted for passphrase(s) or an automatic way where user passes passphrase through SSH as command.
This will require a kernel/initramfs generated with
--luks
command-line argument and kernel must be booted with crypt_root (and/or crypt_swap) kernel command-line argument.
ZFS user must generate kernel/initramfs with --zfs
command-line argument and kernel must be booted with dozfs kernel command-line argument.Manual unlock
Connect to the remote system through SSH and run the following commands:
user $
ssh root@remote-system-running-genkernel-initramfs-with-dosshd
>> Welcome to Genkernel 4.0.1 (2019-12-16 22:34:14 UTC) remote rescue shell! >> ...running Linux kernel 5.3.14-gentoo-r1-x86_64 </div> <div lang="en" dir="ltr" class="mw-content-ltr"> >> The lockfile '/tmp/remote-rescueshell.lock' was created. >> In order to resume boot process, run 'resume-boot'. >> Be aware that it will kill your connection which means >> you will no longer be able to work in this shell. >> To remote unlock LUKS-encrypted root device, run 'unlock-luks root'. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> remote rescueshell ~ # unlock-luks root >> Detected real_root as a md device. Setting up the device node ... Enter passphrase for /dev/md126: >> LUKS device /dev/md126 opened remote rescueshell ~ # resume-boot >> Resuming boot process ...
In this example, system was booted with just
crypt_root=
set in kernel command-line. In case system was booted with crypt_swap=
there will be an additional prompt regarding how to unlock swap.
ZFS user will get prompted to use unlock-zfs
command instead.Automatic unlock
It's basically the same like manual unlock just without the need to manually run resume-boot. In case user has both, encrypted root and swap volume, user must unlock swap volume first:
user $
cat /path/to/secret.key/on/local/disk | ssh root@remote-system-running-genkernel-initramfs-with-dosshd post root
>> Detected real_root as a md device. Setting up the device node ... >> LUKS device /dev/md126 opened >> Resuming boot process ...
Automatic unlock is not available for ZFS users.
Démarrer depuis le réseau
Depuis un CD-ROM d'installation
L'outil genkernel peut fabriquer des images de noyau et de disque virtuel initial (initrd) qui permettent de démarrer sur le réseau (netboot). Avec un peu de chance, il est possible de faire démarrer n'importe quel ordinateur récent par le réseau sur l'environnement fourni par le CD-ROM d'installation de Gentoo.
La magie de la chose réside dans le script linuxrc de genkernel : il va essayer de monter le CD-ROM d'installation par NFS via le réseau. Partant de là, les scripts d'initialisation du CD-ROM d'installation seront utilisés comme si le CD était présent en local.
Construire un noyau et un initrd qui prennent en charge le démarrage par le réseau
Pour activer le support du démarrage par le réseau, activer les options suivantes lors de la configuration du noyau :
Le support du démarrage par le réseau avec genkernel est expérimental et peut contenir quelques bogues.
Tout d'abord, l'image du noyau doit contenir les pilotes de la carte réseau du système. En principe, les pilotes pour ce genre de périphériques sont compilés en tant que modules. Pourtant, il est impératif ici (pour pouvoir démarrer avec) que ces pilotes soient intégrés dans le noyau et pas en modules.
Device Drivers --->
Networking Support --->
Ethernet (10 or 100Mbit) --->
[*] Ethernet (10 or 100Mbit)
<*> The driver(s) for each network card
S'assurer de choisir <*> et non pas <M>.
Ensuite, il est suggéré d'activer IP: kernel level autoconfiguration et IP: DHCP support. Cela évitera une couche supplémentaire de complexité si l'adresse IP et le chemin NFS du CD-ROM d'installation peuvent être spécifiés par un serveur DHCP. Bien sûr, cela signifie que la ligne de commande d'appel du noyau sera la même pour toutes les machines — ce qui est très important pour un démarrage via ethernet.
Device Drivers --->
Networking Support --->
Networking options
[*] TCP/IP networking--->
[*] IP: kernel level autoconfiguration
[*] IP: DHCP support
Ces options indiquent au noyau d'envoyer une requête DHCP au démarrage.
De plus, activer SquashFS car la majorité des CD-ROM d'installation récents de Gentoo l'utilisent. Le support de SquashFS n'est pas intégré aux sources génériques de Linux. Pour activer SquashFS, appliquer les correctifs nécessaires ou bien installer les gentoo-sources.
File systems--->
Miscellaneous filesystems --->
[*] SquashFS 2.X - Squashed file system support
Une fois que le processus de compilation est terminé, créer une archive compressée (.tar.gz) qui contient les modules du noyau. Cette étape n'est nécessaire que si la version du noyau ne correspond pas à la version de l'image située sur le CD-ROM d'installation.
Pour créer une archive contenant tous les modules :
root #
cd /
root #
tar -cf /tmp/modules-X.Y.Z.tar.gz /lib/modules/X.Y.Z/
Selon la méthode de démarrage par le réseau, l'une des étapes suivantes doit être exécutée :
Pour créer une image etherboot :
root #
emerge --ask net-misc/mknbi
root #
cd /boot
root #
mkelf-linux -params="root=/dev/ram0 init=/linuxrc ip=dhcp" kernel... initrd... > etherboot.img
Pour créer une image TFTP OpenBoot/SPARC64 :
root #
emerge --ask sys-apps/sparc-utils
root #
cd /boot
root #
elftoaout kernel... -o kernel.aout
root #
piggyback64 kernel.aout System.map-... initrd-...
root #
mv kernel.aout openboot.img
Le fichier openboot.img est l'image à démarrer.
Enfin, copier ce noyau sur le serveur TFTP. La manière de procéder dépend complètement de l'architecture et dépasse les limites de ce guide. Consulter la documentation spécifique de la plate-forme utilisée.
Configuration du NFS
Pour mettre en place un partage NFS qui contient le CD-ROM d'installation, utiliser un périphérique de bouclage (loop device) pour y monter l'image ISO et copier le contenu du CD dans le partage NFS. En bonus, le script initrd de genkernel désarchivera tous les fichiers .tar.gz situés dans le répertoire /nfs/livecd/add/. Tout ce qu'il reste à faire est de copier l'archive modules-X.Y.Z.tar.gz dans le répertoire /nfs/livecd/add/.
En supposant que /nfs/livecd soit un partage NFS :
root #
mount /tmp/gentoo-livecd.iso /mnt/cdrom -o loop
root #
cp -p /mnt/cdrom /nfs/livecd
root #
umount /mnt/cdrom
Copier modules.tar.gz dans /add
root #
mkdir /nfs/livecd/add
root #
cp /tmp/modules-X.Y.Z.tar.gz /nfs/livecd/add
Configuration du DHCP
Les images netboot demanderont une adresse IP et un chemin NFS au serveur DHCP ainsi qu'une option root-path
. Ces informations peuvent être configurées individuellement en utilisant l'adresse MAC pour identifier les machines :
# Ici, 192.168.1.2 est le serveur NFS alors que 192.168.1.10 sera l'adresse IP de la machine démarrée par le réseau
host netbootableMachine {
hardware ethernet 11:22:33:44:55:66;
fixed-address 192.168.1.10;
option root-path "192.168.1.2:/nfs/livecd";
}
Utilisation du démarrage par le réseau
Le démarrage par le réseau est encore une fois très spécifique à la plate-forme utilisée. Ce qui est important, c'est de spécifier les paramètres ip=dhcp
et init=/linuxrc
sur la ligne de commande du noyau. Cela activera la carte réseau et montera le CD-ROM d'installation via NFS. Voici quelques astuces pour certaines plates-formes :
Pous etherboot, insérer le disque etherboot dans le lecteur et redémarrer. La ligne de commande du noyau a été spécifiée lors de la construction de l'image. Avec Sparc64, appuyer sur Stop+A à l'invite de démarrage puis entrer :
ok
boot net ip=dhcp init=/linuxrc
Pour PXE, configurer pxelinux (qui fait partie de syslinux), puis créer un fichier pxelinux.cfg/default qui contient ces lignes :
DEFAULT gentoo
TIMEOUT 40
PROMPT 1
LABEL gentoo
KERNEL kernel-X.Y.Z
APPEND initrd=initrd-X.Y.Z root=/dev/ram0 init=/linuxrc ip=dhcp
</pre>
Amorcer un disque virtuel initial de genkernel
Introduction
Si un disque virtuel initial (initramfs) a été installé avec genkernel, alors regarder les options diverses et variées de boot que qui peuvent (ou doivent) être définies dans la configuration du système d'amorçage. Les plus courantes sont citées ici pour référence.
Chargement de LVM ou de software-RAID
Si le système utilise LVM ou RAID logiciel, le disque virtuel initial (initramfs) a du être construit en utilisant les options --lvm
et --mdadm
. Néanmoins, ne pas oublier d'activer la prise en charge au moment du démarrage. Ceci peut être fait en utilisant les options dolvm et domdadm.
# Exemple pour GRUB 1.x
title Gentoo Linux
root (hd0,0)
kernel /vmlinuz root=/dev/md3 dolvm domdadm
initrd /initramfs-genkernel-x86_64-3.4.3
Démarrer dans le mode utilisateur unique (single-user)
Si, pour une raison ou une autre, le démarrage échoue, récupérer le système en démarrant le mode utilisateur unique reste possible. Ceci ne chargera que les services réellement nécessaires et offrira à l'utilisateur un shell de récupération root.
# Exemple pour GRUB 1.x
title Gentoo Linux
root (hd0,0)
kernel /vmlinuz root=/dev/md3 init_opts=S
initrd /initramfs-genkernel-x86_64-3.4.3
Cross-compile support
To build kernel and/or initramfs for a different platform as genkernel is being executed on, kernel/initramfs must be cross-compiled.
root #
genkernel --mdadm --no-install --cross-compile=aarch64-linux-gnu all
The above command causes genkernel to create a kernel supporting MD raid and embed mdadm into initramfs (--mdadm
), both kernel and initramfs will have to be manually installed (--no-install
). The kernel and programs embedded into initramfs will run on arm64 (--cross-compile=aarch64-linux-gnu
).
--cross-compile=<target triplet>
- Target triple (i.e.
aarch64-linux-gnu
) to build for. Only needed when the system running genkernel has a different architecture like the system which should boot the created kernel/initramfs.
The recommended way to create a cross-compile environment is using sys-devel/crossdev. See the how to create a cross-compile environment article for more details.
Initramfs kernel command-line parameters
The following parameter list is just an excerpt. Always check the version relevant man genkernel.
root=<...>
- Specifies the device node of the root filesystem to mount. I.e.
root=/dev/sda3
,root=UUID=a1e5968c-bd1b-41ee-bf08-2d0ed376fa83
. cdroot
- This attempts to load livecd.squashfs and is used for loading live media.
crypt_root=<...>
- This specifies the device encrypted by LUKS, which contains the root filesystem to mount. Supports same syntax like
root
kernel command-line parameter from above.Remarque
Will require that at least initramfs was built with--luks
option set. crypt_swap=<...>
- This specifies the swap device encrypted by LUKS. For more details please see
crypt_root
kernel command-line parameter from above. root_trim=(yes|no)
- Enables TRIM support for a LUKS-based root device. Remarque
Will require that at least initramfs was built with--luks
option set and is only useful for flash-based volumes. ip=<dhcp,addr/cidr>
- Normally used to tell the kernel that it should start a network interface which can be specified using
gk.net.iface
kernel parameter. By default,dhcp
will be used. A specific IP address can be set usingaddr/CIDR
notation, i.e.1.2.3.4/24
. gk.net.dhcp.retries=<...>
- Sends up to 3 DHCP discovery requests by default.
gk.net.iface=<interface,macaddr>
- Use the interface named
eth0
by default. Use this kernel parameter to specify another interface.
A MAC address (00:00:00:00:00:00 format) can be specified instead of an interface name. gk.net.gw=<...>
- Optional gateway. If ip is set to dhcp, this kernel parameter will be ignored.
gk.net.routes=<...>
- Optional additional routes. If ip is set to dhcp, this kernel parameter will be ignored.
gk.net.timeout.dad=<...>
- Wait up to 10 seconds by default for IPv6's DAD to complete. At the moment, only wait for DAD while bringing down an interface to prevent a race condition.
gk.net.timeout.deconfiguration=<...>
- Wait up to 10 seconds by default while bringing down an interface to prevent a race condition.
gk.net.timeout.dhcp=<...>
- Wait up to 10 seconds by default for a DHCP server reply.
gk.net.timeout.interface=<...>
- Wait up to 10 seconds by default for interface to show up.
gk.prompt.timeout=<...>
- By default a prompt within genkernel initramfs like shown when set root could not be found will never timeout. Use this option to set a timeout. Remarque
When dosshd is used,gk.prompt.timeout
will be set to 30 seconds when not set. This will allow remote user to provide answer through GK_PROMPT_FILE which is set to /tmp/current_prompt by default. dosshd
- Will bring up an interface and start a SSH daemon within initramfs allowing to remotely unlock encrypted devices or just for debugging purpose. See ip option for how to configure network. Remarque
Will require that initramfs was built at least with--ssh
option set. gk.sshd.port=<...>
- By default, sshd will listen on port 22.
gk.sshd.wait=<...>
- Wait X seconds after setting up sshd. Useful for login (and thus pause boot process) before booting real system.
dolvm
- Activate LVM volumes on bootup. Remarque
Will require that initramfs was built at least with--lvm
option set. lvmraid=<...>
- Specify RAID devices to set up before the activation of LVM volumes. Implies option
dolvm
from above. domdadm
(Deprecated in Genkernel 4.2.0, udev rules now control MD assembly)- Scan for RAID arrays on bootup. Remarque
Will require that initramfs was built at least with--mdadm
option set. dozfs[=cache,force]
- Scan for bootable ZFS pools on bootup. Optionally use cachefile or force import if necessary or perform both actions. Remarque
Will require that initramfs was built at least with--zfs
option set. gk.log.disabled=<...>
- By default, any shown message and external command calls will be logged to /tmp/init.log in initramfs. Disables logging.
gk.log.keep=<...>
- When set to a boolean value, genkernel will preserve /tmp/init.log, see above, and copy file to /genkernel-boot.log on root device (see
root
orreal_root
kernel command-line parameter above). Customize to a file like /root/my-genkernel-boot.log to copy the log.Remarque
The default file /genkernel-boot.log on root was chosen because genkernel's initramfs will only mount root filesystem by default. To store the log file at /var/log/genkernel-boot.log, the mount point must be accessible (see /etc/initramfs.mounts). gk.hw.load-all=<...>
- By default, genkernel loads various module groups (nvme, sata, scsi, pata, usb...) until block device specified in
root
parameter (see above) becomes available. This boolean option can be used to force loading of all module groups regardless whether root device is already available when set to yes.
Dépannage
Can genkernel be used for systemd-based systems?
Yes.
Genkernel? Genkernel-next? Dracut?
sys-kernel/genkernel-next has been removed from the Gentoo repository as of August, 20, 2020
Gentoo is about choices. sys-kernel/genkernel-next was created as fork of sys-kernel/genkernel when genkernel development was stuck, booting a systemd-based system using kernel/initramfs created with sys-kernel/genkernel was a problem (systemd support in sys-kernel/genkernel is fixed for quite some time) and some developers wanted support for things like sys-boot/plymouth which requires sys-fs/udev which was not and still is not compatible with genkernel's main idea (see "Note" right at the beginning of this article). While the name suggests that sys-kernel/genkernel-next is or will be the successor of sys-kernel/genkernel, it is just misleading: Since 2013 there are some requests to merge genkernel-next back into genkernel but the process became stuck. Since the release of sys-kernel/genkernel-4 which changed a lot and the fact that there was no progress in sys-kernel/genkernel-next development since 2018, it's now very unlikely that genkernel-next will ever merge back into genkernel.
sys-kernel/dracut in comparison to sys-kernel/genkernel is just a generic tool for creating an initramfs. It does not create a kernel like genkernel does. I.e. while both, genkernel and dracut supports booting from LUKS-encrypted root volume, only genkernel will ensure that kernel will have all required options set. It's also worthwhile to mention that genkernel will compile most packages (LVM, cryptsetup, mdadm, sshd...) used in initramfs on its own whereas dracut will copy binaries from host system which can be a problem for some setups. Thus, genkernel supports kernel/initramfs creation for another system (cross-compile) unlike dracut or genkernel-next.
Can a separate kernel/initramfs be created for tests?
root #
genkernel --kernel-config=/proc/config.gz --kernel-append-localversion=-test42 --menuconfig all
The above command causes genkernel to build a new kernel and initramfs (all
) based on config from current running kernel (--kernel-config=/proc/config.gz
), invoke menuconfig (--menuconfig
) allowing user to adjust configuration and will append -test42
to kernel's LOCALVERSION variable (--kernel-append-localversion=-test42
) which will affect naming of kernel image, modules dir and initramfs by default.
How can external modules (such as xtables-addons, nvidia-drivers...) be rebuilt for a new kernel?
By default, genkernel will call emerge @module-rebuild when building a kernel to ensure that out-of-tree modules installed through the package manager are still present in new/rebuilt kernel. This feature can be toggled via --[no-]module-rebuild
command-line argument or MODULEREBUILD in /etc/genkernel.conf.
How can additional commands be run after building the kernel?
Genkernel provides a callback for that (before version 4, callback was used to rebuild external modules). See CMD_CALLBACK in /etc/genkernel.conf for more details.
How can ccache or distcc be used with genkernel?
Set up ccache or distcc the normal way like for sys-apps/portage. Set --kernel-cc
command-line parameter or adjust KERNEL_CC in /etc/genkernel.conf for the desired tool to use. Do the same for UTILS_CC (--utils-cc
) and UTILS_CXX (--utils-cxx
).
ERROR: compile_kernel(): compile_generic() failed to compile the "bzImage" target!
Check /var/log/genkernel.log first. In most cases, a root cause will appear like:
[...]
AR drivers/usb/built-in.a
AR drivers/built-in.a
GEN .version
CHK include/generated/compile.h
AR built-in.a
LD vmlinux.o
MODPOST vmlinux.o
ld: .tmp_vmlinux1: final close failed: No space left on device
make: *** [Makefile:1032: vmlinux] Error 1
* ERROR: compile_kernel(): compile_generic() failed to compile the "bzImage" target!
* Please consult '/var/log/genkernel.log' for more information and any
* errors that were reported above.
*
* Report any genkernel bugs to bugs.gentoo.org and
* assign your bug to genkernel@gentoo.org. Please include
* as much information as you can in your bug report; attaching
* '/var/log/genkernel.log' so that your issue can be dealt with effectively.
*
* Please do *not* report kernel compilation failures as genkernel bugs!
*
* mount: >> Boot partition state on '/boot' was not changed; Skipping restore boot partition state ...
>>> Ended on: 2019-12-16 02:30:19 (after 0 days 0 hours 07 minutes 49 seconds)
</pre>
In other words: The system has run out of disk space (No space left on device
) during compilation.
To guard against problems like this set CHECK_FREE_DISK_SPACE_BOOTDIR=50
and CHECK_FREE_DISK_SPACE_KERNELOUTPUTDIR=4000
in /etc/genkernel.conf in which case genkernel would fail early with a message like
root #
genkernel --kernel-config=/proc/config.gz all
* Gentoo Linux Genkernel; Version 4.0.1 * Using genkernel configuration from '/etc/genkernel.conf' ... * Running with options: --kernel-config=/proc/config.gz all * Working with Linux kernel 4.19.89-gentoo-x86_64 for x86_64 * Using kernel config file '/proc/config.gz' ... * * Note: The version above is subject to change (depends on config and status of kernel sources). * ERROR: 4000 MB free disk space is required in '/usr/src/linux' but only 1026 MB is available! [...]
Is the order of kernel command-line arguments important?
No.
Required kernel option 'CONFIG_MICROCODE_INTEL' or 'CONFIG_MICROCODE_AMD' which genkernel tried to set is missing!
Kernel v6.6 permanently applied the kernel config parameters (see this commit). This was fixed in version 4.3.10 of sys-kernel/genkernel.
Help! Something isn't working!
To report a problem, please always provide /var/log/genkernel.log (sometimes it maybe necessary to compress that file before sharing or attaching to bugs) which will help developers a lot. Even if the command is run with --loglevel=1
(default), the logfile will always contain complete output (no need to re-run with logging turned on) which will help developers to understand, reproduce and maybe fix a bug.
Voir aussi
- Configuration du noyau manuelle - Pour quand il est nécessaire de faire les choses manuellement.
- Dracut - Un autre outil de création des fichiers initramfs disponible dans Gentoo.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Tim Yamin, Jimi Ayodele, Thomas Seiler, Joshua Saddler (nightmorph), Sebastian Pipping (sping) , José Fournier (jaaf)
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.