Differences between revisions 1 and 9 (spanning 8 versions)
Revision 1 as of 2007-05-11 04:50:53
Size: 1662
Comment: new page for drafting a proposal on the subject
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 1: Line 1:
(For now this is in spanish, will tranlate when it's settled) #language en
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[es/Passing_boot_options_to_modules|Espanol]]-~
----
= Overview =
Line 3: Line 6:
Problema:
 * Hay sistemas críticos que reciben opciones que pueden determinar el éxito de un booteo. Por ejemplo, opciones ide*= hd*=, que son pasadas a `drivers/ide/ide.c`.
 * Estas opciones se solían pasar en el cmdline del kernel.
 * La mayoría de estos sistemas ahora son compilados como módulos, por lo que ignoran el cmdline.
 * No hay manera simple de solucionar problemas de booteo. Es necesario interrumpir el initramfs (o equivalente) y cargar el módulo a mano con las opciones necesarias.
 * Bug mencionado en el [wiki:Self:DebianInstaller/FAQ#head-5b20dcd5dee6a153d3cc676e5c9d8424ce2ac83e FAQ]
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 [[DebianInstaller/FAQ#head-5b20dcd5dee6a153d3cc676e5c9d8424ce2ac83e|FAQ]]
Line 10: Line 13:
Soluciones:
 * d-i acepta opciones de la forma modname.opt=val que -aunque no es compatible para atrás- es una forma sencillamente parseable y elegante de resolverlo.
  * Hay que investigar cómo se hace. En particular el resultado de [http://bugs.debian.org/226057 226057].
  * Se podría implementar como un wrapper de modprobe, de modo que el comportamiento sea uniforme durante y luego del booteo (en la línea que marca initramfs, copiando `/etc/modprobe.d`).
  * Precedencia propuesta: user_cmdline > k_cmdline > /etc/modprobe.d/*
   * Se podría combinar con un chequeo de actualización del initrd.
 * Otra opción sería investigar el [http://lkml.org/lkml/2007/4/18/212 parche] de Kyle !McMartin para que los módulos lean el cmdline.
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.
  * We should investigate how is it done. In particular the result of [[http://bugs.debian.org/226057|226057]].
   * [[http://svn.debian.org/wsvn/d-i/trunk/packages/rootskel/src/lib/debian-installer-startup.d/S02module-params?op=file&rev=0&sc=0|here is the boot part]]
   * [[http://svn.debian.org/wsvn/d-i/trunk/packages/debian-installer-utils/register-module?op=file&rev=0&sc=0|here is the parsing of the parameters and it's registration on modprobe.d]].
  * A modprobe wrapper could be implemented, that way the behaviour would be uniform during and after the boot (following the line set by initramfs, copying `/etc/modprobe.d`).
  * Proposed precedence: user_cmdline ==> k_cmdline ==> /etc/modprobe.d/*
   * It could be combined with a check for an updated initrd.
 * Another option would be to investigate Kyle !McMartin's [[http://lkml.org/lkml/2007/4/18/212|patch]] so that modules read cmdline parameters.
Line 18: Line 23:
= 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 [[http://damianv.com.ar/debian/others/cmdline_params|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
Line 19: Line 31:
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.

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