Understanding mkinitcpio, kernel parameters, and hooks.

EscapedNull · 2015-01-10 13:50:30

I have a fairly complex setup involving dm-crypt volumes being unlocked pre-boot, so I'm somewhat familiar with mkinitcpio.conf and grub.cfg. However, I still have a burning question: are kernel parameters actually interpreted by the kernel? For example, the ip= parameter is included in the kernel documentation, leading me to believe that the kernel interprets this parameter and acts upon it during boot. On the other hand, the cryptdevice= parameter appears to be specific to the mkinitcpio encrypt hook (does not appear in kernel documentation) which interprets it and runs cryptsetup in early userspace. In this case, are kernel parameters simply being used as a vehicle in order to pass information from the boot loader to early userspace? If so, why couldn't this be done by including a configuration file directly in the initcpio, which could be parsed at boot-time? Such a configuration file seems like a superior means of passing information to early userspace, as different files could be used for different hooks, they could be of different formats (i.e. contain linebreaks), and would not be subject to the maximum kernel command line length.

In fact, it looks like some hooks already do this. For example, the sd-encrypt hook includes a file /etc/crypttab file directly in the initcpio image. Why would other hooks use kernel parameters when the early userspace filesystem is available for use?

I'm primarily asking just for educational purposes. Explanations are appreciated.

Spider.007 · 2015-01-12 17:05:00

I'm pretty sure this is because kernel-parameters are a lot easier to edit from a bootloader that supplies only basic editing functionality. Moving this to config-files requires a text-editor which isn't as easy. Also; I think you can pass anything in the kernel-commandline and various applications make their own decisions based on this (eg. this one is pretty famous: https://bugs.freedesktop.org/show_bug.cgi?id=76935)

Last edited by Spider.007 (2015-01-12 17:05:16)

EscapedNull · 2015-01-13 17:02:57

Thanks for the input Spider.007. Before I began working with mkinitcpio, I thought the kernel command line was just for the kernel only. As you pointed out, it appears that any userspace applications (early userspace or otherwise) may read and parse the kernel command line (and act upon it) as they see fit. After reading the initcpio 'net' hook, it appears that the hook script itself actually parses the ip= parameter, not the kernel itself. That said, I'm still confused as to why it is in the kernel documentation at all. Perhaps these are artifacts left from the pre-initrd/initramfs era, when the kernel itself was responsible for all initialization necessary to mount a root filesystem?

As for kernel parameters versus config files, I see your point, and I agree that it is easier to edit the kernel command line on-the-fly compared to config files. I still feel that config files have their advantages, but there's probably no right answer. I guess this is analogous to the "arguments vs. environment variables" debate we see in shell scripts.

Spider.007 · 2015-01-13 17:30:03

I think the ip-parameter is coincidentally the same as the net-module uses. The kernel is still responsible for mounting the rootfs; what has changed is that most distro's switched to initcpio's for reasons that are repeated on the wiki:

https://wiki.archlinux.org/index.php/Mkinitcpio wrote:

The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root file systems and root file systems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.

EscapedNull · 2015-01-13 19:32:47

Spider.007 wrote:

I think the ip-parameter is coincidentally the same as the net-module uses.

I found this in the mkinitcpio-nfs-utils ipconfig README:

These [parameters] (along with the ugliness of the long form) are present for compatibility with the in-kernel ipconfig code from 2.4 and earlier kernels.

which supports the hypothesis that the kernel parameter is left over from a time when network configurations were done in kernel-space. The syntax remained the same in the initcpio hook to maintain backwards comparability with older bootloader configurations. At least that's the impression I'm under.

Spider.007 wrote:

The kernel is still responsible for mounting the rootfs; what has changed is that most distro's switched to initcpio's for reasons that are repeated on the wiki: ...

Yes, I believe the kernel itself performs the mount(2) which overwrites the / mountpoint with the real root filesystem after it is available. (But for all I know, a hook could be performing a mount(8) instead of the kernel!) What I meant was that the kernel no longer is responsible for all of the initializations necessary for the real root filesystem to become available (so the kernel can mount it), hence the need for initrd/initramfs/initcpio. Take dropbear_initrd_encrypt for example. Dropbear is a userspace SSH server. Without early userspace, an SSH server would have to be embedded in the kernel just for the 0.01% of users out there who need to be able to unlock volumes remotely. Early userspace allows complex systems like this (and other very different ones) to be configured without the need for patching the kernel.

I assume that some low-level kernel parameters (maxcpus= for example) are still relevant solely to the kernel, as things like SMP process scheduling can't easily be implemented in userspace.

Am I getting this right so far?

Last edited by EscapedNull (2015-01-13 19:40:50)

nomorewindows · 2015-01-13 20:10:23

You can actually look at the scripts that are being executed as part of the hooks. It is way more convenient that having to recompile the entire kernel to get a diskless workstation functionality. Even with FreeBSD or OpenBSD, or probably half of the Linux distributions (and it was this way in the past), you had to recompile the kernel to get some non-standard/non-stock functionality out of your kernel. Makes life so much easier and a reason to use Arch. Of course if this functionality isn't even compiled into your stock kernel, then you'd have to recompile. The hooks are aligned with the default stock kernel for Arch.

EscapedNull · 2015-01-14 11:37:20

nomorewindows wrote:

The hooks are aligned with the default stock kernel for Arch.

I'm not sure what exactly you mean by that. Early userspace is userspace after all. Shouldn't the hooks be more-or-less kernel version independent? Everything else makes perfect sense.

Awebb · 2015-01-14 12:10:08

Have you read the documentation? I found it on google with "kernel parameter linux", first hit. The text explains in detail, how the kernel parameters are parsed.

EscapedNull · 2015-01-14 18:12:12

Awebb wrote:

Have you read the documentation? I found it on google with "kernel parameter linux", first hit. The text explains in detail, how the kernel parameters are parsed.

Have you read the rest of this thread? I linked to that page in my original post. I wasn't asking for all of the possible kernel parameters, but rather where they are used (kernel or userspace) and how initcpio's hooks act upon them. For example, the cryptdevice= parameter isn't listed in the kernel documentation, but it must be present in order to use dm-crypt on a root volume. It turns out that sometimes kernel parameters aren't meant for the kernel at all.

nomorewindows · 2015-01-14 18:27:53

EscapedNull wrote:

nomorewindows wrote:
The hooks are aligned with the default stock kernel for Arch.
I'm not sure what exactly you mean by that. Early userspace is userspace after all. Shouldn't the hooks be more-or-less kernel version independent? Everything else makes perfect sense.

The hooks included in the initramfs image wouldn't have much use if the support for it wasn't already enabled in the kernel. In which case, you'd have to recompile the kernel to get those features. But most features are set in Arch's stock kernel.

Last edited by nomorewindows (2015-01-14 18:28:10)

alphaniner · 2015-01-14 18:41:34

nomorewindows wrote:

The hooks included in the initramfs image wouldn't have much use if the support for it wasn't already enabled in the kernel.

Still seems a bit ambiguous to me. Maybe better to say:

The hooks included in the initramfs image wouldn't have much use if the support for the related feature wasn't already enabled in the kernel.

Or maybe I'm just not understanding.

Awebb · 2015-01-14 21:31:40

EscapedNull wrote:

Awebb wrote:
Have you read the documentation? I found it on google with "kernel parameter linux", first hit. The text explains in detail, how the kernel parameters are parsed.
Have you read the rest of this thread? I linked to that page in my original post. I wasn't asking for all of the possible kernel parameters, but rather where they are used (kernel or userspace) and how initcpio's hooks act upon them. For example, the cryptdevice= parameter isn't listed in the kernel documentation, but it must be present in order to use dm-crypt on a root volume. It turns out that sometimes kernel parameters aren't meant for the kernel at all.

I knew this link-behind-text thing would come one day and bite my ass.

What I meant was this passage:

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.

Even after reading the rest of the thread, I am not sure I can follow the confusion.

EDIT: Nevermind. I see it now. Let's say I should refrain from trying to think after a day like this. Brainfart.

Last edited by Awebb (2015-01-14 21:37:24)

EscapedNull · 2015-01-15 12:07:27

Awebb wrote:

What I meant was this passage:
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.

That clears things up a little bit. That explains why the cryptdevice= parameter is passed into init's environment (and subsequently read by initcpoio's hooks). I'm still confused about net= though: that one is documented in the kernel, but it's still interpreted by the net hook as an environment variable. Maybe the Arch kernel is compiled without support for the net= parameter? Otherwise the kernel would setup the network interface, and the parameter would not be passed to init at all (unless you force it to be passed by placing a '--' before it). Also, I don't understand why the dot in the name has significance in the way the parameter is interpreted. Isn't it just a namespace separator? Sounds like a backwards-compatability hack that was just hacky enough to work. Even with this information, however, there still seems to be no obvious just-looking-at-it way to tell whether a kernel parameter will be parsed by the kernel, init, or userspace.

Awebb · 2015-01-15 12:41:17

You forgot about systemd. Since it is your init and does a lot of things the old init didn't do.

Then again, I am confused about what you mean. I don't see a net= parameter, only the NET parameter in the docs. I think those uppercase parameters are not really parameters, but rather a key for reading the list below. Example:

	rhash_entries=	[KNL,NET]
			Set number of hash buckets for route cache

To me this looks like rhash_entries= is only available if KNL and NET are valid, which is the case, if...

NET Appropriate network support is enabled.

Enabled as in enabled in the kernel at compile time. Then...

KNL Is a kernel start-up parameter.

...serves as further indication for that. Enabled as in enabled in the kernel at compile time.

I am by no means an expert, but this is how I understand it.

EDIT: You might want to have a look at this as well: http://en.wikipedia.org/wiki/Linux_startup_process

Last edited by Awebb (2015-01-15 12:46:30)

EscapedNull · 2015-01-15 16:12:36

Awebb wrote:

I don't see a net= parameter, only the NET parameter in the docs.

Sorry, I was confusing the 'net' hook with the 'ip=' kernel parameter. ip= is documented in the kernel, but is also (or exclusively?) used by the initcpio 'net' hook, using the included ipconfig userspace binary. This explains the parameter in better detail. The question was really about why the ip= kernel parameter is documented in the kernel, but is actually (presumably) passed as an environment variable to early userspace init, then read by the 'net' hook. If the kernel actually did understand the parameter, it wouldn't pass it to init, according to the documentation you cited previously. This is why I think it was removed from the kernel after version 2.4, and the 'net' hook kept the syntax for backwards compatibility.

Arch Linux

#1 2015-01-10 13:50:30

Understanding mkinitcpio, kernel parameters, and hooks.

#2 2015-01-12 17:05:00

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#3 2015-01-13 17:02:57

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#4 2015-01-13 17:30:03

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#5 2015-01-13 19:32:47

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#6 2015-01-13 20:10:23

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#7 2015-01-14 11:37:20

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#8 2015-01-14 12:10:08

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#9 2015-01-14 18:12:12

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#10 2015-01-14 18:27:53

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#11 2015-01-14 18:41:34

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#12 2015-01-14 21:31:40

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#13 2015-01-15 12:07:27

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#14 2015-01-15 12:41:17

Re: Understanding mkinitcpio, kernel parameters, and hooks.

#15 2015-01-15 16:12:36

Re: Understanding mkinitcpio, kernel parameters, and hooks.

Board footer