2984
Comment: minor improvements
|
2991
fixing header
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
Translations: [[Passing_boot_options_to_modules|English]] - [[Passing_boot_options_to_modulesSpanish|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.
We should investigate how is it done. In particular the result of 226057.
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 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 |