0

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).

  • Relating https://unix.stackexchange.com/q/18209/117549 – Jeff Schaller Jun 23 '19 at 14:19
  • @Stephen: yes, you are right in that point. I deleted that part soon...is it still around??? But I still could maintain this is NOT the kernel, but the Uefi Shell together with this EFI stub doing the job. Anyway, it does not change my point of view: initrd is loaded very early, and the kernel can not do that alone: it needs some kind of bootloader help.. –  Jun 24 '19 at 07:33
  • @sam68 you can have whatever point of view you want. I’m not sure I understand what difference it makes in relation to the initial question — whether the bootloader loads the initrd, or the kernel, by the time things get to init it’s been dealt with. – Stephen Kitt Jun 24 '19 at 07:45
  • I shortened the examples to emphasize the original Q (and not this double init [S])...but now the text is longer! Stephen I hope you agree more or less with my new formulation. I added some perso-technical story at the end. I got to know (and like) Linux in about 1997 (SuSE 1.2 on two CDs I bought in a store). But for about 15 years (!!!) I wasn't active any more. So now after replacing a 2006 Windows 7 laptop with a 2018 i5 NUC (with a power saving "U" CPU) I am quite enthusiastic, but also confused: some things are exactly the same as 20 years ago, others have totally changed... –  Jun 24 '19 at 12:13
  • I don’t understand why you think my answer is wrong, but I get the impression in general that it’s hard to convince you of anything! It would probably be more productive if you could ask a new question describing what problems you’re actually trying to solve. – Stephen Kitt Jun 24 '19 at 12:30
  • yes I feel the same. Main problem is: no good information --- all these links in the web to old old given up documentation projects etc. And the kernel guys obviously have other things to do than keep files in documentation up to date... I might come back to these three main options: initrd=, root= and init=. I don't agree with you when you say: with a initrd, root= is consumed by the kernel. I say, with a initrd the kernel has no opportunity to use root=, because the kernel has handed over to /init (which is default rdinit=). –  Jun 24 '19 at 13:02
  • "it’s hard to convince you of anything!" ---- Just keep on trying! –  Jun 25 '19 at 14:45

1 Answers1

2

The (new) behaviour you’re seeing is explained in the answers to Are all kernel argument really used by the kernel?

When booted using a boot loader such as Grub, the kernel command line usually looks similar to

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

You can see this in /proc/cmdline, which always shows the full kernel command line, regardless of how it’s processed afterwards. Modules parameters are parsed from there by modprobe (see the kernel documentation for details).

The root value and the ro option are “consumed” by the kernel. The BOOT_IMAGE value is set in init’s environment (see /proc/1/environ). single is passed as an argument to init, as described in the kernel documentation:

The kernel parses parameters from the kernel command line up to “--”; if it doesn’t recognize a parameter and it doesn’t contain a ‘.’, the parameter gets passed to init: parameters with ‘=’ go into init’s environment, others are passed as command line arguments to init. Everything after “--” is passed as an argument to init.

Since root and ro are meaningful for the kernel, it keeps them for itself and doesn’t pass them on to init.

In your case, you’re booting from the UEFI shell. The Arch scenario matches the above description exactly: your arch5\vmlinuz-linux initrd=arch5\initramfs-linux.img root=/dev/sda3 command line results in initrd and root being consumed by the kernel, and arch5\vmlinuz-linux being passed as-is to init as an argument. The initrd is loaded by the EFI stub inside the kernel, using EFI services to find the file. The error messages which are “clearly not from the kernel” are produced by the kernel’s EFI support, see here for “Failed to open file” and here for “Trying to load files to higher address”. efi_printk outputs text using EFI.

In the Fedora case, you’re using sysvinit, and that changes its command line (as shown by ps) to indicate the current runlevel.

In Thelostcause’s case, splash is part of the kernel command line built by Grub, and ends up passed to init following the same rules.

In your dual init scenario, it looks like the second init is a session manager, not a system-wide init.

Stephen Kitt
  • 434,908
  • I reworked my question (see comment there). trying to go back to the original question. So your BOOT_IMAGE=/boot/vmlinuz goes to init's enviromment and my fedora\vmlinuz is passed to init as argument? I'm glad old sysvinit didn't try to enter THAT runlevel, and only used the "S". Maybe systemd should also be more picky with it's arguments. And if they shorten 'splash' to 's' or 'S' you can get a splashscreen and runlevel single with one parameter? –  Jun 24 '19 at 12:41
  • I edited - check "ADDED" half a page from the top. –  Jun 25 '19 at 10:26