Passer des paramètres au noyau au démarrage

Certains réglages ne s'appliquent qu'au tout début du démarrage, avant que le moindre service ne tourne : ils passent par la ligne de commande du noyau. C'est le cas d'un durcissement comme audit=1, d'un contournement matériel, ou du passage en mode secours. Ce guide montre comment ajouter un tel paramètre de façon persistante, sur RHEL et dérivées comme sur Debian et Ubuntu, et surtout pourquoi la méthode que l'on lit partout, éditer /etc/default/grub puis régénérer, échoue en silence sur la famille Red Hat. Toutes les sorties viennent d'un test sur AlmaLinux 10.2, redémarrage réel inclus.

Ce que vous allez apprendre

• Lire la ligne de commande du noyau en cours avec /proc/cmdline
• Ajouter un paramètre persistant avec grubby (RHEL) ou update-grub (Debian)
• Comprendre ce qu'est le BLS et pourquoi il change la méthode
• Prouver le résultat après un redémarrage réel
• Retirer proprement un paramètre, sans laisser de trace

Prérequis

• Un accès root (ou sudo) sur une VM jetable, jamais une machine de production pour un premier essai
• Savoir redémarrer proprement une machine
• Un accès console de secours (console cloud, hyperviseur) : un paramètre fautif peut empêcher le démarrage

Compétence RHCSA

Ajouter un paramètre noyau persistant fait partie des gestes attendus au RHCSA. Le jury évalue la persistance : un paramètre saisi au menu GRUB ne vaut aucun point, seule compte la modification qui survit au redémarrage.

Lire la ligne de commande en cours

Avant de modifier quoi que ce soit, regardez ce que le noyau a réellement reçu. Cette information vit dans un fichier virtuel :

cat /proc/cmdline

BOOT_IMAGE=(hd0,gpt3)/vmlinuz-6.12.0-211.34.1.el10_2.x86_64
root=UUID=1f5fce98-2902-4ac3-b784-b4f10857f44e ro console=tty0
console=ttyS0,115200n8 no_timer_check biosdevname=0 net.ifnames=0

C'est la seule source de vérité. Tout ce que vous écrirez dans des fichiers de configuration n'a de valeur que si le paramètre finit par apparaître ici, après un redémarrage. Gardez ce réflexe : à la fin de toute manipulation, on relit /proc/cmdline.

Le piège : quatre emplacements, un seul compte

Sur RHEL 8 et suivantes, AlmaLinux et Rocky, la ligne de commande du noyau peut apparaître dans quatre fichiers différents, et un seul est lu au démarrage. C'est ce qui rend le sujet confus.

La cause est le BLS, pour Boot Loader Specification, activé par défaut :

grep '^GRUB_ENABLE_BLSCFG' /etc/default/grub

GRUB_ENABLE_BLSCFG=true

Sous BLS, chaque noyau installé possède son propre fichier d'entrée sous /boot/loader/entries/, et c'est la ligne options de ce fichier qui est réellement lue :

ls /boot/loader/entries/

553eb47a42cb4c30822993b5a845ff06-6.12.0-211.34.1.el10_2.x86_64.conf
8516cfdc80ee46979f9d40b76524701f-6.12.0-211.7.3.el10_2.x86_64.conf

Deux noyaux installés, donc deux fichiers, chacun avec sa propre ligne de paramètres. Toute méthode qui n'écrit pas dans ces fichiers ne changera rien au prochain démarrage.

`/etc/default/grub` + `grub2-mkconfig` ne touche pas les noyaux installés

C'est la méthode que l'on trouve dans la quasi-totalité des tutoriels, et elle échoue silencieusement sur cette famille de distributions. Mesuré sur AlmaLinux 10.2 :

sudo sed -i 's/^GRUB_CMDLINE_LINUX="\(.*\)"$/GRUB_CMDLINE_LINUX="\1 audit=1"/' /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

La commande sort en rc=0, tout paraît normal. Voici pourtant où le paramètre a atterri :

Emplacement	audit=1 présent ?	Lu au démarrage ?
/etc/default/grub	oui, vous venez de l'écrire	non, ce n'est qu'un modèle
/boot/grub2/grub.cfg (repli kernelopts)	oui	non, ignoré quand BLS est actif
/boot/loader/entries/*.conf	non	oui, c'est le seul qui compte
/etc/kernel/cmdline	non	non, modèle des futurs noyaux

Glissez pour voir

grubby --info=ALL | grep -c 'audit=1' renvoie 0 : aucune entrée de démarrage ne porte le paramètre. Au redémarrage, /proc/cmdline est inchangé, et rien n'explique pourquoi.

Ajouter un paramètre, la bonne méthode

La commande diffère selon la famille de distribution. Choisissez le bon onglet, les deux ne sont pas interchangeables.

RHEL / AlmaLinux / Rocky / Fedora

L'outil qui agit sur les noyaux déjà installés est grubby, présent d'office.

1. Ajouter le paramètre sur tous les noyaux installés.

   sudo grubby --update-kernel=ALL --args="audit=1"

   La commande ne dit rien quand elle réussit : c'est normal, elle rend 0 en silence.

2. Vérifier ce qui a été écrit, avant tout redémarrage.

   sudo grubby --info=ALL | grep '^args'

   args="ro console=tty0 console=ttyS0,115200n8 no_timer_check biosdevname=0
   net.ifnames=0 $tuned_params audit=1"

   Le paramètre figure bien en fin de ligne, sur chaque entrée.

3. Redémarrer, puis prouver le résultat.

   sudo systemctl reboot

   grep -o 'audit=1' /proc/cmdline

   audit=1

`ALL` fait plus que son nom ne le dit

grubby --update-kernel=ALL écrit dans trois emplacements à la fois, ce qui est précisément ce qu'on veut : les entrées BLS (pour les noyaux actuels), /etc/default/grub et /etc/kernel/cmdline (pour les futurs). Un seul geste couvre donc les noyaux d'aujourd'hui et ceux de demain.

Les autres cibles sont plus étroites, et c'est parfois utile :

Cible	Portée
--update-kernel=ALL	tous les noyaux installés et les modèles pour les futurs
--update-kernel=DEFAULT	uniquement l'entrée du noyau par défaut
--update-kernel=/boot/vmlinuz-<version>	un seul noyau, désigné par son chemin

Glissez pour voir

Vérifié : --update-kernel=DEFAULT ne touche que l'entrée par défaut, et laisse /etc/default/grub intact. Pratique pour tester un paramètre sur un seul noyau en gardant les autres comme filet de secours.

Debian / Ubuntu

Pas de BLS ici, donc la méthode classique est la bonne : le fichier /etc/default/grub alimente directement les entrées générées.

1. Éditer la variable GRUB_CMDLINE_LINUX.

   sudo nano /etc/default/grub

   GRUB_CMDLINE_LINUX="audit=1"

   Deux variables coexistent : GRUB_CMDLINE_LINUX s'applique à toutes les entrées, GRUB_CMDLINE_LINUX_DEFAULT seulement aux entrées normales, pas au mode secours. Pour un durcissement, utilisez la première.

2. Régénérer la configuration.

   sudo update-grub

   Generating grub configuration file ...
   Found linux image: /boot/vmlinuz-6.8.0-136-generic
   done

3. Redémarrer, puis vérifier dans /proc/cmdline.

   sudo systemctl reboot
   grep -o 'audit=1' /proc/cmdline

grubby n'existe pas sur Debian et Ubuntu : n'y cherchez pas la commande.

Comprendre /etc/kernel/cmdline

Ce fichier passe souvent inaperçu, alors qu'il explique pourquoi éditer /etc/default/grub finit quand même par compter sur RHEL.

cat /etc/kernel/cmdline

root=UUID=1f5fce98-2902-4ac3-b784-b4f10857f44e ro console=tty0
console=ttyS0,115200n8 no_timer_check biosdevname=0 net.ifnames=0

C'est le modèle appliqué aux futurs noyaux. Lors de l'installation d'un nouveau noyau, le script /usr/lib/kernel/install.d/20-grub.install le lit pour composer la ligne options de la nouvelle entrée BLS, en le resynchronisant depuis /etc/default/grub si celui-ci est plus récent.

La conséquence est utile à connaître : un paramètre écrit uniquement dans /etc/default/grub n'aura aucun effet aujourd'hui, mais apparaîtra au prochain noyau installé. C'est ce décalage qui donne l'impression que « ça a fini par marcher », des semaines plus tard, après une mise à jour.

Ce que vous voulez	Ce qu'il faut écrire
Le paramètre maintenant, sur les noyaux installés	grubby --update-kernel=ALL
Le paramètre sur les futurs noyaux	/etc/default/grub, qui alimente /etc/kernel/cmdline
Les deux, cas le plus courant	grubby --update-kernel=ALL, qui fait tout

Glissez pour voir

Vérifier qu'un paramètre est bien pris en compte

Un paramètre peut arriver jusqu'au noyau sans que celui-ci le comprenne, par exemple à cause d'une faute de frappe ou d'une option retirée d'une version à l'autre. Le noyau le signale au démarrage :

journalctl -k -b | grep -i 'unknown kernel command line'

kernel: Unknown kernel command line parameters "BOOT_IMAGE=(hd0,gpt3)/vmlinuz-…
biosdevname=0", will be passed to user space.

Lisez bien cette ligne avant de vous inquiéter : elle est normale sur la plupart des machines. BOOT_IMAGE est posé par GRUB, et biosdevname est traité par l'espace utilisateur, pas par le noyau. La mention will be passed to user space indique que ces paramètres ne sont pas perdus, simplement transmis plus loin.

Ce qui doit vous alerter, c'est votre propre paramètre dans cette liste : cela signifie que le noyau ne le connaît pas, et qu'il ne fera rien.

Deux noyaux installés, un seul qui tourne

Le sujet réserve une confusion supplémentaire. Une machine héberge plusieurs noyaux, et celui qui s'exécute n'est pas forcément celui que grubby désigne par défaut :

sudo grubby --default-kernel
uname -r

Mesuré sur la machine de test avant redémarrage : le noyau par défaut était le 6.12.0-211.34.1, alors qu'uname -r répondait 6.12.0-211.7.3. Un noyau plus récent était installé, mais jamais démarré faute de redémarrage.

C'est une raison de plus de préférer --update-kernel=ALL : avec DEFAULT, vous risquez de configurer une entrée qui n'est pas celle que vous observez.

Retirer un paramètre

Le retrait suit la même logique que l'ajout, et il faut le vérifier partout.

RHEL / AlmaLinux / Rocky

sudo grubby --update-kernel=ALL --remove-args="audit=1"

Contrôlez les trois emplacements que grubby avait touchés :

sudo grubby --info=ALL | grep -c 'audit=1'
grep -c 'audit=1' /etc/default/grub /etc/kernel/cmdline

Les trois compteurs doivent retomber à 0. Si l'un d'eux résiste, corrigez-le à la main : grubby ne nettoie que ce qu'il a lui-même écrit, et un paramètre ajouté auparavant à l'éditeur peut subsister.

Debian / Ubuntu

Retirez le paramètre de la variable dans /etc/default/grub, puis régénérez :

sudo nano /etc/default/grub
sudo update-grub

Dans les deux cas, le retrait n'est effectif qu'après un redémarrage : la ligne de commande d'un noyau en cours d'exécution ne peut pas être modifiée.

Tester sans rien casser

Sur une machine à laquelle vous tenez, il existe une méthode sans persistance : éditer l'entrée au menu GRUB. Au démarrage, sélectionnez l'entrée, pressez e, ajoutez le paramètre en fin de ligne linux, puis démarrez avec Ctrl+X. Le changement ne vaut que pour ce démarrage-là.

C'est le bon réflexe pour valider qu'un paramètre produit l'effet attendu avant de le rendre permanent. Notez toutefois deux limites : cette édition demande un accès console, et elle est bloquée si un mot de passe GRUB a été posé, ce qui est justement recommandé en production.

Une variante intermédiaire consiste à ne modifier qu'un seul noyau, en gardant l'autre intact comme filet de secours :

sudo grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="essai=1"

Si la machine ne démarre plus, le menu GRUB permet de choisir l'autre noyau, resté sain.

Dépannage

Ces symptômes couvrent l'essentiel de ce qui coince, classés par ce que vous observez.

Symptôme	Cause probable	Solution
Le paramètre n'apparaît pas dans /proc/cmdline après redémarrage	Sur RHEL, /etc/default/grub + grub2-mkconfig n'écrit pas dans les entrées BLS	sudo grubby --update-kernel=ALL --args="…"
grubby: command not found	Vous êtes sur Debian ou Ubuntu, où l'outil n'existe pas	Éditer /etc/default/grub puis sudo update-grub
Le paramètre apparaît chez un noyau mais pas chez l'autre	--update-kernel=DEFAULT ne touche qu'une entrée	Utiliser ALL
Unknown kernel command line parameters "<le vôtre>" au démarrage	Faute de frappe, ou option absente de cette version du noyau	Vérifier l'orthographe et la documentation du noyau installé
Le paramètre apparaît des semaines plus tard, sans intervention	Il n'était que dans /etc/default/grub, et un nouveau noyau a été installé	Comportement normal de /etc/kernel/cmdline
La machine ne démarre plus après ajout	Paramètre incompatible avec le matériel ou le stockage	Au menu GRUB, choisir un autre noyau, ou presser e et retirer le paramètre pour ce démarrage
Impossible d'éditer l'entrée au menu GRUB	Un mot de passe GRUB protège l'édition	S'authentifier avec le superuser déclaré, voir le guide de durcissement GRUB

Glissez pour voir

À retenir

• /proc/cmdline est la seule preuve : tout le reste n'est que configuration.
• Sur RHEL, AlmaLinux et Rocky, le BLS est actif : c'est la ligne options de /boot/loader/entries/*.conf qui est lue au démarrage.
• /etc/default/grub + grub2-mkconfig ne touche pas les noyaux installés sur ces distributions. La commande rend 0, et rien ne change.
• L'outil correct y est grubby --update-kernel=ALL --args="…", qui écrit à la fois dans les entrées BLS, /etc/default/grub et /etc/kernel/cmdline.
• Sur Debian et Ubuntu, pas de BLS : GRUB_CMDLINE_LINUX puis update-grub est la bonne méthode, et grubby n'existe pas.
• /etc/kernel/cmdline est le modèle des futurs noyaux : c'est lui qui fait qu'un réglage oublié finit par s'appliquer après une mise à jour.
• Un paramètre inconnu du noyau est signalé par Unknown kernel command line parameters dans journalctl -k -b.
• Pour tester sans risque, éditez l'entrée au menu GRUB (non persistant), ou ne modifiez qu'un seul noyau et gardez l'autre en secours.

Pour aller plus loin

• Protéger GRUB par mot de passe : durcir le bootloader, et l'effet de ce mot de passe sur l'édition des entrées.
• Durcir le noyau avec sysctl : les réglages noyau modifiables à chaud, complémentaires de ceux du démarrage.
• Notions fondamentales Linux : la séquence de démarrage complète, du firmware à systemd.

×

📖 Voir la documentation →