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).
initrèglent.