Skip to main content
Welcome guest. | Register | Login | Post

Need To Trap Kernel Parameter on Boot

4 replies [Last post]
supermike's picture
Joined: 2006-02-17

I have a need to catch a kernel option after the OS is loaded but before X is not yet started. I want to have a Bash script detect this option and use the appropriate xorg.conf file. That way, when I boot up, my Grub boot menu can display a menu that basically says, "Boot in Xinerama mode with attached monitor" and the other option says, "Boot as standalone laptop".

Is there a way I can edit my grub menu and then catch that setting on boot?

Joined: 2006-03-28
What exactly do you want

What exactly do you want that setting to do for you? Copy a preset config-file to the right place?
You might be able to use an init-script that runs before the script that starts X.
If that doesn't work I think using an InitRamFs might work, but is more complicated.

Joined: 2007-09-10
use your own pre-init init to catch parameters

>> You might be able to use an init-script that runs before the script that starts X.

Not sure if this is what you meant.. not sure if it works:

Pass 'init=...' to the bootloader. You set this to an init shell script of your choosing that saves the flag you want sent in. So init="/ flag" to grub might allow flags to be sent to your pre-init init. [I haven't looked at this closedly yet.]

Study /etc/inittab (eg, /etc/rc.d/rc.sysinit or whatever is the sysinit within inittab) to see if you need anything special done before saving the flag (you might just be able to copy to the root dir without probs). Then exec the real init from

Finally, from some other place within the initialization sequence or login sequence or wherever, go into that file you saved to see what the saved flag was and act accordingly.

Hope this makes sense since I haven't studied this well yet. [I glossed over and the grub manual.]

Update: I don't think you can pass flags this way (init=..). If there is no other way, then make a different init for each option, eg, / / / and have it save or set a flag (eg, exported to the environment?) and exec to the real init.

free-zombie's picture
Joined: 2006-03-08
I think that often the root

I think that often the root file system is mounted read-only before init. However, you could use a tmpfs, something like this (deliberately ignoring the FHS):



mount -t tmpfs none /supermike/conf
echo mono > /supermike/conf/x_setup

exec /sbin/init "$@"



mount -t tmpfs none /supermike/conf
echo di > /supermike/conf/x_setup

exec /sbin/init "$@"

Set the init script to be run by using the init=... kernel option, and use the information in your tmpfs later to use the correct xorg.conf. You could also create a symlink in the init script that is then used directly by

I don't know if it's possible to pass flags from grub to userspace directly.

Joined: 2007-09-10
I don't know if what you

I don't know if what you wrote is accurate (lack experience with tmpfs), but if it is, that is a good and clear example Smiling

>> I don't know if it's possible to pass flags from grub to userspace directly.

I didn't come across that in the grub manual. I wonder if it's even practical. However, indirectly it would be possible if the kernel would likewise pass along unknown (extra) parameters, in this case, to init.

It really is hard for me to imagine that this flexibility doesn't already exist somewhere without having to resort to using multiple inits.

If this truly doesn't exist, someone might want to bring up the use case in lkml (or in some other forum, perhaps a less formal forum, where someone with experience and reputation might be lurking). Those with experience could probably quickly code up a solution.

Another possible potential solution than pass-along:

Looking at the kernel parameters document (linked earlier), it appears the format of a value can potentially be a string, ie, you can use quotation marks to delimit a value (to protect whitespace).

Currently, init= has a value of type [full_path]. This means that changing this to a string (anchored by quotation marks) might break compatibility.

But maybe a new kernel param can be added easily:

I'd rather have a single intercepting init script accepting scores or hundreds of parameter permutations than to have to have each such permutation be matched by a separate init (meaning hundreds of inits polluting the filesystem).

But if stuck with this last case (and maybe it's actually better ??), then I would think that the examples given of the two scripts could be improved by changing them so that you have a general init script which would include the common parts (eg, mount.. echo/ln.. exec to real init) and the multitude of other inits would just be simple wrappers that exec to this common init using the proper parameters.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.