I want to reformulate a very interesting Q by Thelostcause ("Splash in PID =1"):
How does and how can "/sbin/init splash" show up in the ps command?
I also ask: aren't we (we who are running a "Linux system") moving from
"init [2]" in old sysvinit, to
"/sbin/init vmlinuz" in new systemd init ?
Where [2] means a sysv runlevel, and vmlinuz stands for the first argument of the KCL (kernel command line).
Does anybody see any other or fancy names for PID=1 aka init process on their system with the ps command?
careful: "ps" is quite tricky: ps -p1 gives me just "systemd" as CMD, and ps p1 gives me "/sbin/init arch5\vmlinuz-linux" in the COMMAND ouput field. I use ps axf to get an overview.
I admit I have some hypothesis to my question. The "splash" incident is something between grub and systemd, a early (well, the first) KCL argument that got ignored by kernel and initrd until systemd decided to pretty up it's ps output with a second name (see third example below).
ADDED (directly from Documentation/x86/boot.rst):
Boot loader authors who need additional command line options for the boot loader itself should get them registered in Documentation/admin-guide/kernel-parameters.rst to make sure they will not conflict with actual kernel options now or in the future.
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.
In addition, some boot loaders add the following options to the user-specified command line:
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.
If these options are added by the boot loader, it is highly recommended that they are located first, before the user-specified or configuration-specified command line. Otherwise, "init=/bin/sh" gets confused by the "auto" option.
...or init=[link to systemd] by the "splash" option!
And notice how initrd= and init= are mentioned nearby in boot.rst.
kernel.org, boot-parameters.html: here, initrd= boot option is marked [BOOT] ("boot loader parameter"). It's the only option with nothing but [BOOT] (except for one of the locktorture.x and rcuperf.x). And also vga= seems to be a special case:
This is actually a boot loader parameter; the value is passed to the kernel using a special protocol.
The normal kernel parameters have [KNL] ("kernel start-up parameter)": root=, rw, init=, rdinit=, audit, debug and many more -- EVEN "S"
No wonder me and Stephen got confused: bootloader, initrd=, init= and this "splash" really are closely related.
S [KNL] Run init in single mode
That doesn't make sense to me. Or does the kernel search for an "S" to actively pass it to init?
And you know what: I am NOT going to test (right now) what systemd does with an "S". I had a bad crash (no message) and after restart "Authentication error" (this time easily fixed by pacman -S pam at least). And all I did was rdinit=xxxxx (defaults to /init). Shouldn't the KERNEL tell me: "required RDINIT not found" or so, just like with init=xxxx ? "NO INIT FOUND" is also a panic, but a controlled one with a message.
end of ADDED part
One of my real Qs is:
How can you explain this? My init started a next init!
(this Q is a bit off topic to my own Q, but I want to show all these examples)
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
And this is how I had booted my NUC from the Uefi shell. "S" for this special emergency sysvinit runlevel (that has no inittab entry, and should be entered if there is no /etc/inittab). And HELLO just to see where it goes:
fedora\vmlinuz root=/dev/sda3 init=/usr/bin/sysvinit S HELLO
This KCL appears untouched in dmesg and /proc/cmdline. Here 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
I don't see this double "[Kernel] Command line" with my kernel now. It's just "Command line". In case they changed that on purpose, they were right I'd say. (the fedora kernel is not antique...it's something like 4.18)
This is a normal runlevel with four 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
Old sysvinit shows up as "init [2]". "2" is of course the (default) runlevel, and also the argument to /sbin/init, but the brackets must have been added by sysvinit to look nice. In this ps output you can see the difference between just "/bin/bash" and "/bin/bash -l".
Under systemd and with a 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
... ...
Where someone got "splash", which is nonense, I get "arch5\vmlinuz-linux". arch5 is the directory I made on my EFI boot partition, and vmlinuz-linux is how I found the kernel in /boot after installation. I just had to cp it to arch5, together with the initrd-file.
If you boot a systemd init from a real bootloader (like grub): what do you get then after "/sbin/init" ? Also the kernel's filename like me? Or splash or quiet or just anything leftover?
@Stephen: I wonder what you mean when you say the kernel "consumes" a parameter? In my initrd= example, the kernel consumes nothing at all: it gets loaded by a bootloader or Uefi Shell together WITH the initrd-File.
(here I got a bit lost arguing with Stephen who takes care of initrd=, root= and init= in the Command Line while booting)
OK so initrd= is in this case loaded by kernel himself (EFI stub, using Uefi support), but is the parameter "consumed"? No it is still there. Everything is still there and "ends up" in /proc/cmdline. Aren't modules told to look there for their command line options?
My conclusion at the moment is: sbin/init splash? Who cares! There are rules for the boot parameters, and if init gets an unconsumed "splash" as an argument, ps will show it.
I think this answer is quite wrong...but if there was a good explanation of the Command line aka Boot options, and of the boot procedure from bootloader/Uefi shell up to /sbin/init, I guess I would have found it.
The reason I am here btw is:
I had a lot of problems booting from my disk for the first time (my NUC was a kit, so it was really empty when I started out). I started with a GPT partitioning, and even though you get this 'protective MBR' so you can use "Legacy BIOS" to boot, I of course wanted to leave Legacy/MBR behind and use pure Uefi/GPT. But the grub installation for GPT confused me too much! And my "visual" BIOS showed nothing to boot. Now I know: Uefi doesn't boot devices, it boots EFI applications like BOOTX64.EFI that you first have to register with efibootmgr (from Linux) or bcfg (from Uefi Shell).
I was about to repartition my SSD to MBR.
Then I found a very short post (here or stackoverflow) saying:
"You don't need a bootloader if you have Uefi BIOS"
I could hardly believe it was so simple. I activated "Uefi Shell" as boot option, booted into it, typed "fs0:" to really "enter" the boot partition, and then just "vmlinuz" --- voila quick kernel panic because of missing root=, but has anybody ever been happier than me to see a kernel panic?
Only maybe me some days later when I got "no init found". (I gave him /bin/bash first just to keep the tradition).
initit’s been dealt with. – Stephen Kitt Jun 24 '19 at 07:45