Most of the initrd generation functionality in dracut is provided by a bunch
of generator modules that are sourced by the main dracut script to install
-specific functionality into the initrd. They live in the modules.d subdirectory,
-and use functionality provided by dracut-functions to do their work.
+specific functionality into the initrd. They live in the modules.d
+subdirectory, and use functionality provided by dracut-functions to do their
+work.
+
Some general rules for writing modules:
* Use one of the inst family of functions to actually install files
on to the initrd. They handle mangling the pathnames and (for binaries,
Git Repository:
http://dracut.git.sourceforge.net/
-git://dracut.git.sourceforge.net/gitroot/dracut
+git://dracut.git.sourceforge.net/gitroot/dracut/dracut
Trac Instance:
http://apps.sourceforge.net/trac/dracut/
The git tree can be found at
-git://dracut.git.sourceforge.net/gitroot/dracut for now. See the TODO
+git://dracut.git.sourceforge.net/gitroot/dracut/dracut for now. See the TODO
file for things which still need to be done and HACKING for some
instructions on how to get started. There is also a mailing list that
is being used for the discussion -- initramfs@vger.kernel.org. It is
* mdadm
* net-tools iproute
+Generic initramfs'es are huge (usually over 10 megs in size uncompressed), but
+should be able to automatically boot any bootable configuration with appropriate
+boot flags (root device, network configuration information, etc.)
\ No newline at end of file
are present. It should exit with a 0 if they are, and a 1 if they are
not.
- When called with -H, it should perform the same check that it would
+ When called with -h, it should perform the same check that it would
without any options, and it should also check to see if the
functionality the module implements is being used on the host system.
For example, if this module handles installing support for LUKS
encrpted volumes are available and the host system has the root
partition on an encrypted volume, 1 otherwise.
+ When called with -d, it should output a list of dracut modules
+ that it relies upon. An example would be the nfs and iscsi modules,
+ which rely on the network module to detect and configure network
+ interfaces.
+
Check may take additional options in the future.
- We will most likely grow a module dependency checking system in the
- near future, and check will need to handle a -d option when we do.
Any other files in the module will not be touched by dracut directly.