KERNEL Boot Param : /proc/cmdline - Quel est son rôle ? Le sujet est résolu

Demande d'aide : c'est ici.
Répondre
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1018
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

06 août 2020, 12:03

Bonjour,

Pouvez-vous m'aider à lever un doute sur le rôle du fichier : /proc/cmdline

Sert-il à configurer de façon persistante une liste de paramètres à passer au noyau lors du boot ?

Ce que semble dire p.ex Boot Stages — cloud-init 20.2 documentation
qui indique que l'on peut désactiver cloud-init (globalement) au démarrage du système en ajoutant à : /proc/cmdline
une ligne avec : cloud-init=disabled

ou

Simplement /proc/cmdline affiche-t-il la liste des paramètres qui ont été fournis lors du dernier démarrage (instance en cours) ?

Comme semble le dire la doc de Redhat dans Important Linux /proc filesystem files you need to know...
/proc/cmdline

This file shows the parameters passed to the kernel at the time it is started.
....
The value of this information is in how the kernel was booted because any switches or special parameters will be listed here, too.
Ce qui se traduit par :
Ce fichier montre les paramètres passés au noyau au moment de son démarrage.
....
La valeur de ces informations réside dans la manière dont le noyau a été démarré, car tout commutateur ou paramètre spécial sera également répertorié ici.

Je vous pose la question car le manuel : kernel-command-line(7)
n'est pas limpide pour moi. :sad:

Merci.
Debian testing/stable - XFCE
MicP
Modérateur
Modérateur
Messages : 625
Enregistré le : 16 avr. 2016, 22:14
Status : Hors ligne

06 août 2020, 17:33

Bonjour

Le répertoire /proc/ est dans un pseudo système de fichiers <=> les fichiers et répertoires qu'il contient n'existent pas dans le système de fichiers <=> ils n'occupent aucun espace disque,
ils sont dynamiquement générés en RAM depuis le démarrage du système.

Le répertoire /proc/ contient donc la liste des processus en cours avec tout un tas d'informations les concernant.

Voir aussi : https://fr.wikipedia.org/wiki/Procfs
PascalHambourg
Contributeur
Contributeur
Messages : 426
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

06 août 2020, 17:48

dezix a écrit :
06 août 2020, 12:03
Sert-il à configurer de façon persistante une liste de paramètres à passer au noyau lors du boot ?
Non. Cela est géré par le chargeur d'amorçage.
dezix a écrit :
06 août 2020, 12:03
affiche-t-il la liste des paramètres qui ont été fournis lors du dernier démarrage (instance en cours) ?
Oui.
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1018
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

06 août 2020, 17:52

Merci
:023:
Debian testing/stable - XFCE
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1018
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

06 août 2020, 19:54

Pour aller un peu plus loin dans la compréhension de la gestion des paramètres de démarrage,

comme :
PascalHambourg a écrit :
06 août 2020, 17:48
Cela est géré par le chargeur d'amorçage.

Dans le cas le plus courant, c'est donc GRUB qui permet :

1. Pour 1 fois lors de la sélection de l'OS/noyau dans le "Menu GRUB" en tapant "e" pour ouvrir l'éditeur
et ajouter le(s) paramètre(s) supplémentaire(s) à la suite de ceux déjà présent sur la ligne débutant par "linux" puis [Ctrl + x] pour sortir et valider


2. De façon permanente en éditant dans /etc/default/grub la ligne GRUB_CMDLINE_LINUX_DEFAULT="param1 param2 mon_param"


À présent,
je découvre la commande : sysctl

Le manuel indique la possibilité de modification de paramètres "à chaud" depuis la commande ou via un fichier de configuration.

Il semble donc possible d'utiliser sysctl via un script qui serait exécuté après le démarrage,
p.ex. via une tâche de cron avec @reboot


Quels avantages ou risques présente cette pratique en comparaison de l'usage du chargeur d'amorçage ?
Debian testing/stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 426
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

08 août 2020, 11:23

dezix a écrit :
06 août 2020, 19:54
2. De façon permanente en éditant dans /etc/default/grub la ligne GRUB_CMDLINE_LINUX_DEFAULT="param1 param2 mon_param"
GRUB_CMDLINE_LINUX_DEFAULT ne s'applique qu'aux entrées de menu de démarrage en mode normal. Pour qu'un paramètre s'applique aussi aux entrées de de menu de démarrage en mode dépannage (recovery), il faut les ajouter à GRUB_CMDLINE_LINUX.
dezix a écrit :
06 août 2020, 19:54
Quels avantages ou risques présente cette pratique (sysctl) en comparaison de l'usage du chargeur d'amorçage ?
Ce n'est pas du tout la même chose. Les réglages sysctl n'ont aucun rapport avec les paramètres de la ligne de commande du noyau. Certains ont des équivalents, mais ce n'est pas une généralité.

Les réglages sysctl sont des pseudo-fichiers situés dans /proc/sys/ accessibles en lecture et écriture pour la plupart (certains servent à déclencher des actions et ne sont accessibles qu'en écriture, d'autres servent à publier une information et ne sont accessibles qu'en lecture).

Ceux des paramètres de la ligne de commande du noyau qui sont des paramètres de modules (de la forme <module>.<parametre>=<valeur>) peuvent se retrouver dans /sys/module/<module>/parameters/<parametre> mais d'une part ce n'est pas systématique, ça dépend des modules, et d'autre part ils ne sont pas toujours modifiables par ce biais.
dezix a écrit :
06 août 2020, 19:54
Il semble donc possible d'utiliser sysctl via un script qui serait exécuté après le démarrage,
p.ex. via une tâche de cron avec @reboot
La méthode habituelle consiste plutôt à ajouter les réglages dans /etc/sysctl.conf ou un fichier /etc/systctl.d/*.conf.

Attention : certains réglages sysctl sont liés à des modules et/ou des périphériques et ne sont disponibles que lorsque ces modules sont chargés et/ou ces périphériques sont présents, ce qui peut avoir lieu de façon asynchrone du démarrage, par exemple lorsqu'il s'agit de pilotes de périphériques chargés dynamiquement à la découverte du matériel (exemple : réglages IPv4 et IPv6 des interfaces réseau) ou de périphériques amovibles. Dans ce cas une règle udev peut être plus adaptée. D'autres modules sont chargés lorsque leur fonctionnalité est requise par un programme (exemple : réglages de netfilter utilisé par iptables). Dans ce cas on peut effectuer les réglages sysctl dans le même script que la commande. Il y a aussi la possibilité de charger des modules au démarrage de façon explicite en les listant dans le fichier /etc/modules ou un fichier /etc/modules-load.d/*.conf avec leurs éventuels paramètres.

Si on essaie de modifier un réglage sysctl lié à un module qui n'est pas chargé ou un périphérique qui n'est pas présent, cela provoque une erreur et le réglage n'est pas appliqué. Si le module est déchargé puis rechargé, la modification est oubliée et le réglage revient à sa valeur par défaut. Ce n'est pas le cas des paramètres de la ligne de commande du noyau qui sont mémorisés et appliqués le cas échéant chaque fois que le module correspondant est chargé ou le périphérique concerné est ajouté.
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1018
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

08 août 2020, 11:34

Merci pour toutes ces infos
Il y a de quoi m'occuper un bon moment avant de tout digérer,
c'est copieux !

:006:
Debian testing/stable - XFCE
Répondre