ps axf affiche “/ sbin / init splash” pour PID1

Je veux reformuler un Q très intéressant par Thelostcause (" Splash in PID = 1 "):

Comment et comment "/ sbin / init splash" peut-il apparaître dans la commande ps ?

Je demande aussi: ne sommes-nous pas (nous qui exploitons un "système Linux") de passer de

"init [2]"               in old sysvinit, to

"/sbin/init vmlinuz"     in new systemd init ?

Où [2] signifie un niveau d'exécution sysv et vmlinuz représente le premier argument du KCL (ligne de commande du noyau).

Quelqu'un voit-il d'autres noms ou noms de fantaisie pour PID = 1, également appelé processus init sur leur système avec la commande ps?

attention: "ps" est assez délicat: ps -p1me donne simplement "systemd" en tant que CMD et ps p1me donne "/ sbin / init arch5 \ vmlinuz-linux" dans le champ de commande COMMAND. J'utilise ps axfpour avoir un aperçu.

J'avoue que j'ai une hypothèse à ma question. L'incident "splash" est quelque chose entre grub et systemd, un argument KCL précoce (bien, le premier) qui a été ignoré par kernel et initrd jusqu'à ce que systemd ait décidé de créer une sortie ps avec un second nom (voir le troisième exemple ci-dessous).

ADDED (directement depuis Documentation / x86 / boot.rst):

Les auteurs de programmes d'amorçage qui ont besoin d'options de ligne de commande supplémentaires pour le programme d'amorçage lui-même doivent les enregistrer dans Documentation / admin-guide / kernel-parameters.rst pour s'assurer qu'ils ne seront pas en conflit avec les options réelles du noyau, maintenant ou à l'avenir.

  initrd=<file>
    An initrd should be loaded.  The meaning of <file> is
    obviously bootloader-dependent, and some boot loaders
    (e.g. LILO) do not have such a command.

De plus, certains chargeurs de démarrage ajoutent les options suivantes à la ligne de commande spécifiée par l'utilisateur:

  BOOT_IMAGE=<file>
    The boot image which was loaded.  Again, the meaning of <file>
    is obviously bootloader-dependent.

  auto
    The kernel was booted without explicit user intervention.

Si ces options sont ajoutées par le chargeur de démarrage, il est vivement recommandé de les localiser en premier , avant la ligne de commande spécifiée par l'utilisateur ou par la configuration. Sinon, "init = / bin / sh" est confondu avec l'option "auto".

... ou init = [lien vers systemd] par l'option "splash"!

Et remarquez comment initrd = et init = sont mentionnés à proximité dans boot.rst.

kernel.org, boot-parameters.html: ici, l’ initrd=option de démarrage est marquée [BOOT] ("paramètre du chargeur de démarrage"). C'est la seule option avec rien d'autre que [BOOT] (sauf pour l'un des fichiers locktorture.x et rcuperf.x). Et vga=semble également être un cas particulier:

C'est en fait un paramètre du chargeur de démarrage; la valeur est transmise au noyau à l'aide d'un protocole spécial.

Les paramètres de noyau normaux ont [KNL] ("paramètre de démarrage du noyau)": root =, rw, init =, rdinit =, audit, debug et bien d’autres encore - EVEN "S"

Pas étonnant que Stephen et moi ayons confondu: le chargeur de démarrage, initrd =, init = et ce "splash" sont étroitement liés.

S               [KNL] Run init in single mode

Cela n'a pas de sens pour moi. Ou le noyau recherche-t-il un "S" pour le transmettre activement à init?

Et vous savez quoi: je ne vais pas tester (actuellement) ce que systemd fait avec un "S". J'ai eu un crash grave (pas de message) et après le redémarrage, "Erreur d'authentification" (cette fois-ci, nous avons facilement résolu le problème pacman -S pam). Et tout ce que j'ai fait était rdinit=xxxxx(par défaut, / init). Le KERNEL ne devrait-il pas me dire: "RDINIT requis non trouvé" ou presque, comme avec init=xxxx? "NO INIT FOUND" est aussi une panique, mais contrôlée avec un message.

fin de la partie ADDED

Un de mes vrais Qs est:

Comment pouvez-vous expliquer cela? Mon init a commencé un prochain init!

(Ce Q est un peu hors sujet par rapport à mon propre Q, mais je veux montrer tous ces exemples)

    1 ?        Ss     0:01 init [S]
  214 tty1     Ss     0:00 init [S]
  215 tty1     S      0:00  \_ bash
  238 tty1     R+     0:00      \_ ps axf
  239 tty1     R+     0:00      \_ tail

Et voici comment j’avais démarré mon NUC à partir du shell Uefi. "S" pour cette urgence spéciale sysvinit runlevel (qui n'a pas d'entrée inittab et doit être entré s'il n'y a pas de / etc / inittab). Et BONJOUR, juste pour voir où ça va:

fedora\vmlinuz root=/dev/sda3 init=/usr/bin/sysvinit S HELLO

Ce KCL semble intact dans dmesg et / proc / cmdline. Voici dmesg:

[    0.000000] Command line: fedora\vmlinuz root=/dev/sda3 init=/usr/bin/sysvinit S HELLO
[    0.000000] Kernel command line: fedora\vmlinuz root=/dev/sda3 init=/usr/bin/sysvinit S HELLO

Je ne vois pas ce double "[Kernel] Ligne de commande" avec mon noyau maintenant. C'est juste "Ligne de commande". Au cas où ils auraient changé exprès, ils avaient raison, je dirais. (Le noyau de Fedora n'est pas antique ... c'est quelque chose comme 4.18)

C'est un runlevel normal avec quatre tty:

    1 ?        Ss     0:00 init [2]
  286 tty1     Ss     0:00 /bin/bash -l
  303 tty1     R+     0:00  \_ ps axf
  304 tty1     D+     0:00  \_ /bin/bash -l
  287 tty2     Ss+    0:00 /sbin/agetty -J tty2
  288 tty3     Ss+    0:00 /bin/bash
  289 tty4     Ss+    0:00 /bin/bash

Ancien sysvinit apparaît comme "init [2]". "2" est bien sûr le niveau d'exécution (par défaut), ainsi que l'argument de / sbin / init, mais les crochets doivent avoir été ajoutés par sysvinit pour avoir une belle apparence. Dans cette sortie ps, vous pouvez voir la différence entre "/ bin / bash" et "/ bin / bash -l".

Sous systemd et avec un initrd (archlinux):

    1 ?        Ss     0:01 /sbin/init arch5\vmlinuz-linux

    ...        ..     .... snip systemd-journald etc.
  469 ?        Ss     0:00 login -- root
  484 tty1     Ss     0:00  \_ -bash
  922 tty1     S+     0:00      \_ xinit fvwm
  ...                           ...

Où quelqu'un a "splash" , ce qui est non-sens, je reçois "arch5 \ vmlinuz-linux" . arch5 est le répertoire que j'ai créé sur ma partition de démarrage EFI et vmlinuz-linux est la façon dont j'ai trouvé le noyau dans / boot après l'installation. Il me suffisait de le copier sur arch5 avec le fichier initrd.

Si vous démarrez un systemd init à partir d'un vrai chargeur de démarrage (comme grub): que obtenez-vous après "/ sbin / init"? Aussi le nom de fichier du noyau comme moi? Ou éclaboussures ou calme ou tout ce qui reste?

@Stephen: Je me demande ce que vous voulez dire quand vous dites que le noyau "consomme" un paramètre? Dans mon exemple initrd =, le noyau ne consomme rien du tout: il est chargé par un chargeur de démarrage ou Uefi Shell ensemble AVEC le fichier initrd.

(ici, je me suis un peu perdu en discutant avec Stephen qui prend en charge initrd =, root = et init = dans la ligne de commande lors du démarrage)

OK, initrd = est dans ce cas chargé par le noyau lui-même (talon EFI, utilisant le support Uefi), mais le paramètre est-il "consommé"? Non, il est toujours là. Tout est toujours là et "finit" dans / proc / cmdline. Les modules ne sont-ils pas invités à rechercher les options en ligne de commande?

Ma conclusion pour le moment est la suivante: sbin / init splash? On s'en fout! Il y a des règles pour les paramètres de démarrage, et si init obtient un "splash" non consommé en tant qu'argument, ps le montrera.

Je pense que cette réponse est tout à fait fausse ... mais s'il y avait une bonne explication de la ligne de commande aka options de démarrage, et de la procédure de démarrage à partir du shell bootloader / Uefi jusqu'à / sbin / init, je suppose que je l'aurais trouvée.

La raison pour laquelle je suis ici est:

J'ai eu beaucoup de problèmes à démarrer pour la première fois depuis mon disque (mon NUC étant un kit, il était donc vraiment vide à mes débuts). J'ai commencé avec un partitionnement GPT, et même si vous obtenez ce «MBR de protection» pour pouvoir utiliser le «BIOS hérité» au démarrage, je voulais bien sûr laisser Legacy / MBR derrière et utiliser du pur Uefi / GPT. Mais l'installation de grub pour GPT m'a confondu trop! Et mon BIOS "visuel" ne montre rien pour démarrer. Maintenant, je sais: Uefi ne démarre pas les périphériques, il démarre les applications EFI telles que BOOTX64.EFI que vous devez d’abord vous enregistrer auprès de efibootmgr (sous Linux) ou de bcfg (sous Uefi Shell).

J'étais sur le point de repartitionner mon SSD vers le MBR.

Ensuite, j'ai trouvé un très court post (ici ou stackoverflow) disant:

"Vous n'avez pas besoin d'un chargeur de démarrage si vous avez le BIOS Uefi"

J'avais du mal à croire que c'était si simple. J'ai activé "Uefi Shell" comme option de démarrage, démarré dedans, tapé "fs0:" pour vraiment "entrer" dans la partition de démarrage, puis juste "vmlinuz" jamais été plus heureux que moi de voir une panique du noyau?

Seulement peut-être moi quelques jours plus tard, quand je n'ai "aucun init trouvé". (Je lui ai donné / bin / bash en premier pour garder la tradition).

Le (nouveau) comportement que vous observez est expliqué dans les réponses à la question suivante: Tous les arguments du noyau sont-ils vraiment utilisés par le noyau?

Lors du démarrage à l'aide d'un chargeur de démarrage tel que Grub, la ligne de commande du noyau ressemble généralement à

BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=/dev/mapper/vg--fast-root ro single

Vous pouvez le voir dans /proc/cmdline, qui affiche toujours la ligne de commande complète du noyau, quelle que soit la manière dont elle est traitée par la suite. Les paramètres de modules sont ensuite analysés modprobe(voir la documentation du noyau pour plus de détails).

La rootvaleur et l' rooption sont «consommées» par le noyau. La BOOT_IMAGEvaleur est définie dans initl'environnement de (voir /proc/1/environ). singleest passé comme argument à init, comme décrit dans la documentation du noyau :

Le noyau analyse les paramètres de la ligne de commande du noyau jusqu'à «-»; s'il ne reconnaît pas un paramètre et qu'il ne contient pas de «. Tout ce qui suit «-» est passé comme argument à init.

Depuis rootet rosont significatifs pour le noyau, il les garde pour lui-même et ne les transmet pas init.

Dans votre cas, vous démarrez à partir du shell UEFI. Le scénario Arch correspond exactement à la description ci-dessus: votre arch5\vmlinuz-linux initrd=arch5\initramfs-linux.img root=/dev/sda3ligne de commande est utilisée initrdet rootconsommée par le noyau, puis arch5\vmlinuz-linuxtransmise telle quelle à initen tant qu'argument. Le initrd est chargé par le stub EFI à l'intérieur du noyau, à l'aide des services EFI pour trouver le fichier. Les messages d'erreur qui «ne proviennent manifestement pas du noyau» sont générés par le support EFI du noyau, voir ici pour «Échec de l'ouverture du fichier» et ici pour «Tentative de chargement de fichiers à une adresse plus élevée». efi_printkgénère du texte en utilisant EFI.

Dans le cas Fedora, vous utilisez sysvinit, et cela change sa ligne de commande (comme indiqué par ps) pour indiquer le niveau d'exécution actuel.

Dans le cas de Thelostcause, splashfait partie de la ligne de commande du noyau construite par Grub et finit par être passée aux initmêmes règles.

Dans votre double initscénario, il semble que le second initsoit un gestionnaire de session, et non un système init.