Differences between revisions 8 and 9
Revision 8 as of 2011-03-26 23:52:48
Size: 2991
Editor: ?skizzhg
Comment: fixing header
Revision 9 as of 2013-05-19 02:12:02
Size: 2993
Editor: GeoffSimmons
Comment: Fix formatting.
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[es/Passing_boot_options_to_modules|Espanol]] ~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[es/Passing_boot_options_to_modules|Espanol]]-~

Translation(s): English - Espanol


Overview

Problem:

  • There are critical systems that receive options that could very well determine the success of a boot process. For example, the options ide*= hd*=, that are passed to drivers/ide/ide.c.

  • This options were usually passed in the kernel cmdline.
  • Most of this systems are now built as modules, effectively ignoring cmdline.
  • There is no simple way of solving boot problems. It's necessary to break into the initramfs and load the module by hand giving the necessary options.
  • Bug mentioned in the FAQ

Solutions:

  • d-i take options in the form of modname.opt=val that -although not backward compatible- is a simple, easily parseable and elegant way to solve it.
  • Another option would be to investigate Kyle McMartin's patch so that modules read cmdline parameters.

Proposed Solutions

Initramfs solution

The proposed solution of parsing a module.option=value as d-i does was implemented (mostly stolen from d-i, actually). To test it you should:

  • download the script

  • copy it to /usr/share/initramfs-tools/scripts/init-top/ and chmod it +x

  • run update-initramfs for the kernel you want to test
  • reboot and try passing some parameters to a module you know is loaded in initramfs, also breaking into initramfs with break={top,modules,premount,mount,bottom,init} might be nice to try and see what the script does

Maybe init-top is too drastic? would init-premount be enough? I don't think so, but maybe... Also, it would be ideal if any script that modprobe something predepends on this one, to ensure that cmdline parameters for that module are more significant than default /etc/modprobe/* parameters, as proposed.

Place new comments at the top

Add new comments, don't edit old ones