documentation update

master
Harald Hoyer 2010-10-15 13:14:08 +02:00
parent 6bde7a17be
commit 1b4a9d8ad8
4 changed files with 299 additions and 94 deletions

View File

@ -24,7 +24,10 @@ all: $(targets) $(manpages) dracut.html
xsltproc -o $@ -nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<

dracut.html: dracut.xml $(manpages)
xsltproc -o dracut.html --xinclude -nonet --stringparam draft.mode yes http://docbook.sourceforge.net/release/xsl/current/xhtml-1_1/docbook.xsl dracut.xml
xsltproc -o dracut.html --xinclude -nonet \
--stringparam draft.mode yes \
--stringparam html.stylesheet http://docs.redhat.com/docs/en-US/Common_Content/css/default.css \
http://docbook.sourceforge.net/release/xsl/current/xhtml-1_1/docbook.xsl dracut.xml

modules.d/99base/switch_root: switch_root.c
gcc -D _GNU_SOURCE -D 'PACKAGE_STRING="dracut"' -std=gnu99 -fsigned-char -g -O2 -o modules.d/99base/switch_root switch_root.c

View File

@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?>
<!-- This document was created with Syntext Serna Free. --><!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" []>
<refentry>
<refentry id="dracut8">
<refentryinfo>
<title>dracut</title>
<productname>dracut</productname>
@ -313,8 +313,7 @@ Thsi is useful when running dracut from a git checkout.</para>
the local host instead of a generic host.
<warning>
<para>If chrooted to another root other than the real root device, use &quot;--fstab&quot; and provide a valid <filename>/etc/fstab</filename>.</para>
</warning>
</para>
</warning></para>
</listitem>
</varlistentry>
<varlistentry>
@ -365,8 +364,7 @@ target directory in the final initramfs.</para>
<para>Compress the generated initramfs using bzip2.
<warning>
<para>Make sure your kernel has bzip2 decompression support compiled in, otherwise you will not be able to boot.</para>
</warning>
</para>
</warning></para>
</listitem>
</varlistentry>
<varlistentry>
@ -377,8 +375,7 @@ target directory in the final initramfs.</para>
<para>Compress the generated initramfs using lzma.
<warning>
<para>Make sure your kernel has lzma decompression support compiled in, otherwise you will not be able to boot.</para>
</warning>
</para>
</warning></para>
</listitem>
</varlistentry>
<varlistentry>

View File

@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?>
<!-- This document was created with Syntext Serna Free. --><!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" []>
<refentry>
<refentry id="dracutkernel7">
<refentryinfo>
<title>dracut.kernel</title>
<productname>dracut</productname>
@ -543,13 +543,13 @@ This is supported by dracut, but not recommended.</para>
</optional>:<replaceable>&lt;targetname&gt;</replaceable></term>
<listitem>
<para>protocol defaults to &quot;6&quot;, LUN defaults to &quot;0&quot;.</para>
<para>If the &quot;servername&quot; field is provided by BOOTP or DHCP, then that
<para>If the &quot;servername&quot; field is provided by <acronym>BOOTP</acronym> or <acronym>DHCP</acronym>, then that
field is used in conjunction with other associated fields to contact
the boot server in the Boot stage (Section 7). However, if the
the boot server in the Boot stage. However, if the
&quot;servername&quot; field is not provided, then the &quot;targetname&quot; field is
then used in the Discovery Service stage in conjunction with other
associated fields.</para>
<para><ulink url="http://tools.ietf.org/html/rfc4173">http://tools.ietf.org/html/rfc4173</ulink></para>
<para>See <ulink url="http://tools.ietf.org/html/rfc4173#section-5">http://tools.ietf.org/html/rfc4173</ulink>.</para>
<para>e.g.:<programlisting>root=iscsi:192.168.50.1::::iqn.2009-06.dracut:target0 </programlisting></para>
<para>If servername is an IPv6 address, it has to be put in brackets. e.g.:
<programlisting>root=iscsi:[2001:DB8::1]::::iqn.2009-06.dracut:target0 </programlisting></para>

View File

@ -39,7 +39,7 @@
</para>
<para>This then raises the problem of detecting and loading the modules necessary to mount the root file system at boot time (or, for that matter, deducing where or what the root file system is).
</para>
<para>To further complicate matters, the root file system may be on a software RAID volume, LVM, NFS (on diskless workstations), or on an encrypted partition. All of these require special preparations to mount.
<para>To further complicate matters, the root file system may be on a software <acronym>RAID</acronym> volume, <acronym>LVM</acronym>, <acronym>NFS</acronym> (on diskless workstations), or on an encrypted partition. All of these require special preparations to mount.
</para>
<para>Another complication is kernel support for hibernation, which suspends the computer to disk by dumping an image of the entire system to a swap partition or a regular file, then powering off. On next boot, this image has to be made accessible before it can be loaded back into memory. </para>
<para>To avoid having to hardcode handling for so many special cases into the kernel, an initial boot stage with a temporary root file system—now dubbed early user space—is used. This root file system would contain user-space helpers that would do the hardware detection, module loading and device discovery necessary to get the real root file system mounted.
@ -57,21 +57,21 @@
</para>
</listitem>
<listitem>
<para>A small ext2/ext3 or FAT-formatted partition on a local disk (a <emphasis>boot partition</emphasis>)</para>
<para>A small ext2/ext3 or <acronym>FAT</acronym>-formatted partition on a local disk (a <emphasis>boot partition</emphasis>)</para>
</listitem>
<listitem>
<para>A TFTP server (on systems that can boot from Ethernet) </para>
<para>A <acronym>TFTP</acronym> server (on systems that can boot from Ethernet) </para>
</listitem>
</itemizedlist>
<para>The bootloader will load the kernel and initial root file system image into memory and then start the kernel, passing in the memory address of the image.
</para>
<para>Depending on which algorithms were compiled statically into it, the kernel can currently unpack initrd/initramfs images compressed with gzip, bzip2 and LZMA. </para>
<para>Depending on which algorithms were compiled statically into it, the kernel can currently unpack initrd/initramfs images compressed with gzip, bzip2 and <acronym>LZMA</acronym>. </para>
</section>
<section>
<title>Mount preparations </title>
<para>dracut can generate a customized initrams image which contains only whatever is necessary to boot some particular computer, such as ATA, SCSI and filesystem kernel modules (host-only mode).</para>
<para>dracut can generate a customized initrams image which contains only whatever is necessary to boot some particular computer, such as <acronym>ATA</acronym>, <acronym>SCSI</acronym> and filesystem kernel modules (host-only mode).</para>
<para>dracut can also generate a more generic initramfs image (default mode). </para>
<para>dracut&apos;s initramfs starts only with the device name of the root file system (or its UUID) and must discover everything else at boot time. A complex cascade of tasks must be performed to get the root file system mounted: </para>
<para>dracut&apos;s initramfs starts only with the device name of the root file system (or its <acronym>UUID</acronym>) and must discover everything else at boot time. A complex cascade of tasks must be performed to get the root file system mounted: </para>
<itemizedlist>
<listitem>
<para>Any hardware drivers that the boot process depends on must be loaded. All kernel modules for common storage devices are packed onto the initramfs and then udev pulls in modules matching the computer&apos;s detected hardware. </para>
@ -91,20 +91,20 @@
<para>Extract the name of the NFS share and the address of the NFS server from the lease. </para>
</listitem>
<listitem>
<para>Mount the NFS share. </para>
<para>Mount the <acronym>NFS</acronym> share. </para>
</listitem>
</itemizedlist></para>
</listitem>
<listitem>
<para>If the root file system appears to be on a software RAID device, there is no way of knowing which devices the RAID volume spans; the standard MD utilities must be invoked to scan all available block devices with a raid signature and bring the required ones online. </para>
<para>If the root file system appears to be on a software <acronym>RAID</acronym> device, there is no way of knowing which devices the <acronym>RAID</acronym> volume spans; the standard <acronym>MD</acronym> utilities must be invoked to scan all available block devices with a raid signature and bring the required ones online. </para>
</listitem>
<listitem>
<para>If the root file system appears to be on a logical volume, the LVM utilities must be invoked to scan for and activate the volume group containing it. </para>
<para>If the root file system appears to be on a logical volume, the <acronym>LVM</acronym> utilities must be invoked to scan for and activate the volume group containing it. </para>
</listitem>
<listitem>
<para>If the root file system is on an encrypted block device: <itemizedlist>
<listitem>
<para>Invoke a helper script to prompt the user to type in a passphrase and/or insert a hardware token (such as a smart card or a USB security dongle). </para>
<para>Invoke a helper script to prompt the user to type in a passphrase and/or insert a hardware token (such as a smart card or a <acronym>USB</acronym> security dongle). </para>
</listitem>
<listitem>
<para>Create a decryption target with the device mapper. </para>
@ -112,7 +112,7 @@
</itemizedlist></para>
</listitem>
</itemizedlist>
<para>dracut uses udev, an event-driven hotplug agent, which invokes helper programs as hardware devices, disk partitions and storage volumes matching certain rules come online. This allows discovery to run in parallel, and to progressively cascade into arbitrary nestings of LVM, RAID or encryption to get at the root file system. </para>
<para>dracut uses udev, an event-driven hotplug agent, which invokes helper programs as hardware devices, disk partitions and storage volumes matching certain rules come online. This allows discovery to run in parallel, and to progressively cascade into arbitrary nestings of <acronym>LVM</acronym>, <acronym>RAID</acronym> or encryption to get at the root file system. </para>
<para>When the root file system finally becomes visible: <itemizedlist>
<listitem>
<para>Any maintenance tasks which cannot run on a mounted root file system are done. </para>
@ -121,7 +121,7 @@
<para>The root file system is mounted read-only. </para>
</listitem>
<listitem>
<para>Any processes which must continue running (such as the splash screen helper and its command FIFO) are hoisted into the newly-mounted root file system. </para>
<para>Any processes which must continue running (such as the splash screen helper and its command <acronym>FIFO</acronym>) are hoisted into the newly-mounted root file system. </para>
</listitem>
</itemizedlist></para>
<para>The final root file system cannot simply be mounted over /, since that would make the scripts and tools on the initial root file system inaccessible for any final cleanup tasks. On an initramfs, the initial root file system cannot be rotated away. Instead, it is simply emptied and the final root file system mounted over the top.
@ -144,7 +144,6 @@
<para>A shortcut to generate the image at the default location for a specific kernel version is:</para>
<screen># dracut &apos;&apos; 2.6.40-1.rc5.f20</screen>
<para>If you want to create lighter, smaller initramfs images, you may want to specify the <option>--host-only</option> or <option>-H</option> option. Using this option, the resulting image will contain only those dracut modules, kernel modules and filesystems, which are needed to boot this specific machine. This has the drawback, that you can&apos;t put the disk on another controller or machine, and that you can&apos;t switch to another root filesystem, without recreating the initramfs image. The usage of the <option>--host-only</option> option is only for experts and you will have to keep the broken pieces. At least keep a copy of a general purpose image (and corresponding kernel) as a fallback to rescue your system.</para>
<para/>
<section>
<title>Inspecting the Contents</title>
<para>To see the contents of the image created by dracut, you can use the <command>lsinitrd</command> tool.</para>
@ -155,31 +154,30 @@ include ld.so.conf.d/*.conf</screen>
</section>
<section>
<title>Adding dracut Modules</title>
<para>Some dracut modules are turned off by default and have to be activated manually. You can do this by adding the dracut modules to the configuration file <filename>/etc/dracut.conf</filename> or <filename>/etc/dracut.conf.d/myconf.conf</filename>. See the dracut.conf(5) man page. You can also add dracut modules on the command line by using the <option>-a</option> or <option>--add</option> option:</para>
<para>Some dracut modules are turned off by default and have to be activated manually. You can do this by adding the dracut modules to the configuration file <filename>/etc/dracut.conf</filename> or <filename>/etc/dracut.conf.d/myconf.conf</filename>. See the man page <xref linkend="dracutconf5"/>. You can also add dracut modules on the command line by using the <option>-a</option> or <option>--add</option> option:</para>
<screen># dracut --add bootchart initramfs-bootchart.img</screen>
<para>To see a list of available dracut modules, use the <option>--list-modules</option> option:</para>
<screen># dracut --list-modules</screen>
<para>or, if you have a dracut version earlier than 008, issue the command:</para>
<para>or, if you have a dracut version earlier than <literal>008</literal>, issue the command:</para>
<screen># for mod in /usr/share/dracut/modules.d/*; do echo ${mod##*/??}; done</screen>
</section>
<section>
<title>Omitting dracut Modules</title>
<para>Sometimes you don&apos;t want a dracut module to be included for reasons of speed, size or functionality. To do this, either specify the <envar>add_dracutmodules</envar> variable in the <filename>dracut.conf</filename> or <filename>/etc/dracut.conf.d/myconf.conf</filename> configuration file (see dracut.conf(5) man page), or use the <option>-o</option> or <option>--omit</option> option on the command line:</para>
<para>Sometimes you don&apos;t want a dracut module to be included for reasons of speed, size or functionality. To do this, either specify the <envar>add_dracutmodules</envar> variable in the <filename>dracut.conf</filename> or <filename>/etc/dracut.conf.d/myconf.conf</filename> configuration file (see man page <xref linkend="dracutconf5"/>), or use the <option>-o</option> or <option>--omit</option> option on the command line:</para>
<screen># dracut -o &quot;multipath lvm&quot; no-multipath-lvm.img</screen>
</section>
<section>
<title>Adding Kernel Modules</title>
<para>If you need a special kernel module in the initramfs, which is not automatically picked up by dracut, you have the use the <option>--add-drivers</option> option on the command line or the drivers vaiable in the <filename>/etc/dracut.conf</filename> or <filename>/etc/dracut.conf.d/myconf.conf</filename> configuration file (see dracut.conf(5) man page):</para>
<para>If you need a special kernel module in the initramfs, which is not automatically picked up by dracut, you have the use the <option>--add-drivers</option> option on the command line or the drivers vaiable in the <filename>/etc/dracut.conf</filename> or <filename>/etc/dracut.conf.d/myconf.conf</filename> configuration file (see man page <xref linkend="dracutconf5"/>):</para>
<screen># dracut --add-drivers mymod initramfs-with-mymod.img</screen>
<para/>
</section>
</section>
<section>
<title>Boot parameters</title>
<para>The generated initramfs.img file normally does not contain any system configuration files (except for some special exceptions), so the configuration has to be done on the kernel command line. With this flexibility, you can easily boot from a changed root partition, without the need to recompile the initramfs image. So, you could completly change your root partition (move it inside a md raid with encryption and LVM on top), as long as you specify the correct filesystem LABEL or UUID on the kernel command line for your root device, dracut will find it and boot from it.</para>
<para>The generated initramfs.img file normally does not contain any system configuration files (except for some special exceptions), so the configuration has to be done on the kernel command line. With this flexibility, you can easily boot from a changed root partition, without the need to recompile the initramfs image. So, you could completly change your root partition (move it inside a md raid with encryption and LVM on top), as long as you specify the correct filesystem <varname>LABEL</varname> or <varname>UUID</varname> on the kernel command line for your root device, dracut will find it and boot from it.</para>
<para>The kernel command line usually can be configured in <filename>/boot/grub/grub.conf</filename>, if grub is your bootloader and it also can be edited in the real boot process in the grub menu.</para>
<para>The kernel command line can also be provided by the dhcp server with the root-path option. See the &quot;Network Boot&quot; section.</para>
<para>For a full reference of all kernel command line parameters, see the dracut.kernel(5) or dracut(8) man page.</para>
<para>The kernel command line can also be provided by the dhcp server with the root-path option. See <xref linkend="NetworkBoot"/>.</para>
<para>For a full reference of all kernel command line parameters, see the <xref linkend="dracutconf5"/> or <xref linkend="dracut8"/> man page.</para>
<section>
<title>Specifying the root Device</title>
<para>This is the only option dracut really needs to boot from your root partition. Because your root partition can live in various environments, there are a lot of formats for the <envar>root=</envar> option. The most basic one is <envar>root=<replaceable>&lt;path to device node&gt;</replaceable></envar>:</para>
@ -188,12 +186,11 @@ include ld.so.conf.d/*.conf</screen>
<screen>root=UUID=19e9dda3-5a38-484d-a9b0-fa6b067d0331</screen>
<para>or</para>
<screen>root=LABEL=myrootpartitionlabel</screen>
<para>To see all UUIDs or LABELs on your system, do:</para>
<para>To see all <envar>UUID</envar>s or <envar>LABEL</envar>s on your system, do:</para>
<screen># ls -l /dev/disk/by-uuid</screen>
<para>or</para>
<screen># ls -l /dev/disk/by-label</screen>
<para>If your root partition is on the network see the &quot;Network Boot&quot; section.</para>
<para/>
<para>If your root partition is on the network see <xref linkend="NetworkBoot"/>.</para>
</section>
<section>
<title>Keyboard Settings</title>
@ -201,25 +198,25 @@ include ld.so.conf.d/*.conf</screen>
<para>A typical german kernel command would contain:</para>
<screen>vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=de_DE.UTF-8</screen>
<para>Setting these options can override the setting stored on your system, if you use a modern init system, like systemd.</para>
<para>For dracut versions prior to version 008 the line would look like:</para>
<para>For dracut versions prior to version <literal>008</literal> the line would look like:</para>
<screen>LANG=de_DE.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys</screen>
</section>
<section>
<title>Blacklisting Kernel Modules</title>
<para>Sometimes it is required to prevent the automatic kernel module loading of a specific kernel module. To do this, just add <envar>rd.blacklist=<replaceable>&lt;kernel module name&gt;</replaceable></envar>, with <replaceable>&lt;kernel module name&gt;</replaceable> not containing the .ko suffix, to the kernel command line. For example:</para>
<para>Sometimes it is required to prevent the automatic kernel module loading of a specific kernel module. To do this, just add <envar>rd.blacklist=<replaceable>&lt;kernel module name&gt;</replaceable></envar>, with <replaceable>&lt;kernel module name&gt;</replaceable> not containing the <filename>.ko</filename> suffix, to the kernel command line. For example:</para>
<screen>rd.blacklist=mptsas rd.blacklist=nouveau</screen>
<para>The option can be specified multiple times on the kernel command line.</para>
</section>
<section>
<title>Speeding up the Boot Process</title>
<para>If you want to speed up the boot process, you can specify as much information for dracut on the kernel command as possible. For example, you can tell dracut, that you root partition is not on a LVM volume or not on a raid partition, or that it lives inside a specific crypto LUKS encrypted volume. By default, dracut searches everywhere. A typical dracut kernel command line for a plain primary or logical partition would contain:</para>
<para>If you want to speed up the boot process, you can specify as much information for dracut on the kernel command as possible. For example, you can tell dracut, that you root partition is not on a <acronym>LVM</acronym> volume or not on a raid partition, or that it lives inside a specific crypto <acronym>LUKS</acronym> encrypted volume. By default, dracut searches everywhere. A typical dracut kernel command line for a plain primary or logical partition would contain:</para>
<screen>rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0</screen>
<para>on systems with dracut version prior to 008 the line would look like:</para>
<para>on systems with dracut version prior to <literal>008</literal> the line would look like:</para>
<screen>rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM</screen>
<para>This turns off every automatic assembly of LVM, MD raids, DM raids and crypto LUKS.</para>
<para>This turns off every automatic assembly of <acronym>LVM</acronym>, <acronym>MD</acronym> raids, <acronym>DM</acronym> raids and crypto <acronym>LUKS</acronym>.</para>
<para>Of course, you could also omit the dracut modules in the initramfs creation process, but then you would lose the posibility to turn it on on demand.</para>
</section>
<section>
<section id="Injecting">
<title>Injecting custom Files</title>
<para>To add your own files to the initramfs image, you have several possibilities.</para>
<para>The <option>--include</option> option let you specify a source path and a target path. For example</para>
@ -244,26 +241,24 @@ overlay/
<para>This will create an initramfs with the <command>strace</command>, <command>fsck.ext3</command> and <command>ssh</command> executables, together with the libraries needed to start those. The <option>--install</option> option can be specified multiple times.</para>
</section>
</section>
<section>
<section id="NetworkBoot">
<title>Network Boot</title>
<para>If your root partition is on a network drive, you have to have the network dracut modules installed to create a network aware initramfs image.</para>
<para>On a Red Hat Enterprise Linux or Fedora system, this means, you have to install the dracut-network rpm package:</para>
<para>On a Red Hat Enterprise Linux or Fedora system, this means, you have to install the <filename>dracut-network</filename> rpm package:</para>
<screen># yum install dracut-network</screen>
<para>The resulting initramfs image can be served by a boot manager residing on your local hard drive or it can be served by a PXE/TFTP server.</para>
<para>How to setup your PXE/TFTP server can be found in the Red Hat Enterprise Linux Storage Administration Guide http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/</para>
<para></para>
<para>If you specify <envar>rd.ip=auto</envar> on the kernel command line, then dracut asks a dhcp server about the ip adress for the machine. The dhcp server can also serve an additional root-path, which will set the root device for dracut. With this mechanism, you have static configuration on your client machine and a centralized boot configuration on your TFTP/dhcp server. If you can&apos;t pass a kernel command line, then you can inject <filename>/etc/cmdline</filename>, with a method described in the section &quot;Injecting custom files&quot;.
<para>The resulting initramfs image can be served by a boot manager residing on your local hard drive or it can be served by a <acronym>PXE</acronym>/<acronym>TFTP</acronym> server.</para>
<para>How to setup your <acronym>PXE</acronym>/<acronym>TFTP</acronym> server can be found in the <ulink url="http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/">Red Hat Enterprise Linux Storage Administration Guide</ulink>.</para>
<para>If you specify <envar>rd.ip=auto</envar> on the kernel command line, then dracut asks a dhcp server about the ip adress for the machine. The dhcp server can also serve an additional root-path, which will set the root device for dracut. With this mechanism, you have static configuration on your client machine and a centralized boot configuration on your <acronym>TFTP</acronym>/<acronym>DHCP</acronym> server. If you can&apos;t pass a kernel command line, then you can inject <filename>/etc/cmdline</filename>, with a method described in <xref linkend="Injecting"/>.
</para>
<section>
<title>Reducing the Image Size</title>
<para>To reduce the size of the initramfs, you should create it with by ommitting all dracut modules, which you know, you don&apos;t need to boot the machine.</para>
<para>You can also specify the exact dracut and kernel modules to produce a very tiny initramfs image.</para>
<para>For example for a NFS image, you would do:</para>
<para>For example for a <acronym>NFS</acronym> image, you would do:</para>
<screen># dracut -m &quot;nfs network base&quot; initramfs-nfs-only.img</screen>
<para>Then you would boot from this image with your target machine and reduce the size once more by creating it on the target machine with the <option>--host-only</option> option:</para>
<screen># dracut -m &quot;nfs network base&quot; --host-only initramfs-nfs-host-only.img</screen>
<para>This will reduce the size of the initramfs image significantly.</para>
<para/>
</section>
<section>
<title>NFS Root Device</title>
@ -280,87 +275,236 @@ overlay/
</para>
</section>
</section>
<section>
<title>Troubleshooting</title>
<para>If the boot process does not succeed, you have several options to debug the situation:</para>
<para>Follow the instructions on: <ulink url="http://fedoraproject.org/wiki/How_to_debug_Dracut_problems">http://fedoraproject.org/wiki/How_to_debug_Dracut_problems</ulink></para>
<para/>
<para>
<section><title>Identifying your problem area</title>
<para>
# Remove ''rhgb'' and ''quiet'' from the kernel command line
# Add ''rdshell'' to the kernel command line. This will present a shell should dracut be unable to locate your root device
# Add ''rdshell rdinitdebug'' to the kernel command line so that dracut shell commands are printed as they are executed
# With dracut >= 002-11 [http://koji.fedoraproject.org/koji/buildinfo?buildID=134721], you can inspect the rdinitdebug output with:
#:<pre># less /init.log</pre>
#:<pre># dmesg | less</pre>
</para>
</section>
== Logical Volume Management related problems ==

As well as the information from [[How_to_debug_Dracut_problems#AllInfo|the 'all bug reports' section]], include the following information:

* Include physical volume information by running the command: {{command|lvm pvdisplay}}
* Include volume group information by running the command: {{command|lvm vgdisplay}}
* Include logical volume information by running the command: {{command|lvm lvdisplay}}

== Software RAID related problems ==

As well as the information from [[How_to_debug_Dracut_problems#AllInfo|the 'all bug reports' section]], include the following information:

* If using software RAID disk partitions, please include the output of {{filename|/proc/mdstat}}

== Network root device related problems ==

This section details information to include when experiencing problems on a system whose root device is located on a network attached volume (e.g. iSCSI, NFS or NBD). As well as the information from [[How_to_debug_Dracut_problems#AllInfo|the 'all bug reports' section]], include the following information:

* Please include the output of {{command|ip addr show}}

{{Anchor|Debugging}}

= Debugging dracut =

== Configure a serial console ==

Successfully debugging dracut will require some form of console logging during the system boot. This section documents configuring a serial console connection to record boot messages.

# First, enable serial console output for both the kernel and the bootloader.
#* Open the file {{filename|/etc/grub.conf}} for editing. Below the line ''timeout=5'', add the following:
#*: <pre>
#*:serial --unit=0 --speed=9600
#*:terminal --timeout=5 serial console
#*:</pre>
#* Also in {{filename|/etc/grub.conf}}, add the following boot arguemnts to the ''kernel'' line:
#*: <pre>console=tty0 console=ttyS0,9600</pre>
#* When finished, the {{filename|/etc/grub.conf}} file should look similar to the example below.
#*:<pre>
#*:default=0
#*:timeout=5
#*:serial --unit=0 --speed=9600
#*:terminal --timeout=5 serial console
#*:title Fedora (2.6.29.5-191.fc11.x86_64)
#*: root (hd0,0)
#*: kernel /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 console=ttyS0,9600
#*: initrd /dracut-2.6.29.5-191.fc11.x86_64.img</pre>
#* More detailed information on how to configure the kernel for console output can be found at [http://www.faqs.org/docs/Linux-HOWTO/Remote-Serial-Console-HOWTO.html#CONFIGURE-KERNEL].

{{admon/tip|Redirecting non-interactive output|You can redirect all non-interactive output to /dev/kmsg and the kernel will put it out on the console when it reaches the kernel buffer by doing
<pre>exec >/dev/kmsg 2>&1 </dev/console</pre>}}

== Using the dracut shell ==

Dracut offers a shell for interactive debugging in the event dracut fails to locate your root filesystem. To enable the shell:
# Add the boot parameter ''rdshell'' to your bootloader configuration file (e.g. {{filename|/etc/grub.conf}}
# Remove the boot arguments ''rhgb'' and ''quiet''

A sample {{filename|/etc/grub.conf}} bootloader configuration file is listed below.

<pre>default=0
timeout=5
serial --unit=0 --speed=9600
terminal --timeout=5 serial console
title Fedora (2.6.29.5-191.fc11.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.29.5-191.fc11.x86_64 ro root=/dev/mapper/vg_uc1-lv_root console=tty0 rdshell
initrd /dracut-2.6.29.5-191.fc11.x86_64.img</pre>

If system boot fails, you will be dropped into a shell as seen in the example below.
<pre>
No root device found
Dropping to debug shell.

sh: can't access tty; job control turned off
#
</pre>

Use this shell prompt to gather the information requested above (see [[How_to_debug_Dracut_problems#AllInfo|the 'all bug reports' section]]).

== Accessing the root volume from the dracut shell ==

From the dracut debug shell, you can manually perform the task of locating and preparing your root volume for boot. The required steps will depend on how your root volume is configured. Common scenarios include:
* A block device (e.g. {{filename|/dev/sda7}})
* A LVM logical volume (e.g. {{filename|/dev/VolGroup00/LogVol00}})
* An encrypted device (e.g. {{filename|/dev/mapper/luks-4d5972ea-901c-4584-bd75-1da802417d83}})
* A network attached device (e.g. {{filename|netroot{{=}}iscsi:@192.168.0.4::3260::iqn.2009-02.org.fedoraproject:for.all}})

The exact method for locating and preparing will vary. However, to continue with a successful boot, the objective is to locate your root volume and create a symlink {{filename|/dev/root}} which points to the file system. For example, the following example demonstrates accessing and booting a root volume that is an encrypted LVM Logical volume.

# Inspect your partitions using {{command|parted}}
#: <pre>
#: parted /dev/sda -s p
#: Model: ATA HTS541060G9AT00 (scsi)
#: Disk /dev/sda: 60.0GB
#: Sector size (logical/physical): 512B/512B
#: Partition Table: msdos
#:
#: Number Start End Size Type File system Flags
#: 1 32.3kB 10.8GB 107MB primary ext4 boot
#: 2 10.8GB 55.6GB 44.7GB logical lvm</pre>
# You recall that your root volume was a LVM logical volume. Scan and activate any logical volumes
#: <pre>
#: lvm vgscan
#: lvm vgchange -ay</pre>
# You should see any logical volumes now using the command {{command|blkid}}:
#: <pre>
#: # blkid
#: /dev/sda1: UUID="3de247f3-5de4-4a44-afc5-1fe179750cf7" TYPE="ext4"
#: /dev/sda2: UUID="Ek4dQw-cOtq-5MJu-OGRF-xz5k-O2l8-wdDj0I" TYPE="LVM2_member"
#: /dev/mapper/linux-root: UUID="def0269e-424b-4752-acf3-1077bf96ad2c" TYPE="crypto_LUKS"
#: /dev/mapper/linux-home: UUID="c69127c1-f153-4ea2-b58e-4cbfa9257c5e" TYPE="ext3"
#: /dev/mapper/linux-swap: UUID="47b4d329-975c-4c08-b218-f9c9bf3635f1" TYPE="swap"
#: </pre>
# From the output above, you recall that your root volume exists on an encrypted block device. Following the guidance disk encryption guidance from the [http://docs.fedoraproject.org/install-guide/f{{FedoraVersion}}/en-US/html/apcs04s04.html {{FedoraVersion|long}} Installation Guide], you unlock your encrypted root volume.
#: <pre>
#: UUID=$(cryptsetup luksUUID /dev/mapper/linux-root)
#: cryptsetup luksOpen /dev/mapper/linux-root luks-$UUID
#: Enter passphrase for /dev/mapper/linux-root:
#: Key slot 0 unlocked. </pre>
# Next, make a symbolic link to the unlocked root volume
#: <pre>
#: ln -s /dev/mapper/luks-$UUID /dev/root</pre>
# With the root volume available, you may continue booting the system by exiting the dracut shell
#: <pre>
#: exit</pre>

== Additional dracut boot parameters ==

The following boot parameters are also available to further assist with debugging boot issues.

; rdshell : Drop to a shell, if the initramfs fails.
; rdinitdebug : set -x for the dracut shell.
; rdbreak=[pre-udev|pre-mount|mount|pre-pivot|] : drop the shell on defined breakpoint
; rdudevinfo : set udev to loglevel info
; rdudevdebug : set udev to loglevel debug
; rdnetdebug : debug network scripts in dracut. Output is written to /tmp

[[Category:Debugging|D]] [[Category:How to]]
</para>
</section>
</chapter>
<chapter>
<title>Developer Manual</title>
<section>
<title>dracut Components</title>
<para>
</para>
<para>dracut uses a modular system to build and extend the initramfs image. All modules are located in <filename>/usr/share/dracut/modules.d</filename> or in <filename><replaceable>&lt;git-src&gt;</replaceable>/modules.d</filename>. The most basic dracut module is <filename>99base</filename>. In <filename>99base</filename> the initial shell script <command>init</command> is defined, which gets run by the kernel after initramfs loading. Although you can replace <command>init</command> with your own version of <filename>99base</filename>, this is not encouraged. Instead you should use, if possible, the hooks of dracut. All hooks, and the point of time in which they are executed, are described in <xref linkend="stages"/>.</para>
<para>The main script, which creates the initramfs is <command>dracut</command> itsself. It parses all arguments and sets up the directory, in which everything is installed. It then executes all <command>check</command>, <command>install</command>, <command>installkernel</command> scripts found in the modules, which are to be processed. After everything is installed, the install directory is archived and compressed to the final initramfs image. All helper functions used by <command>check</command>, <command>install</command> and <command>installkernel</command> are found in in the file <filename>dracut-functions</filename>. These shell functions are available to all module installer (<command>install</command>, <command>installkernel</command>) scripts, without the need to source <filename>dracut-functions</filename>.</para>
<para>A module can check the preconditions for <command>install</command> and <command>installkernel</command> with the <command>check</command> script. Also dependencies can be expressed with <command>check</command>. If a module passed <command>check</command>, <command>install</command> and <command>installkernel</command> will be called to install all of the necessary files for the module. To split between kernel and non-kernel parts of the installation, all kernel module related parts have to be in <command>installkernel</command>. All other files found in a module directory are module specific and mostly are hook scripts and udev rules.</para>
</section>
<section>
<section id="stages">
<title>Boot Process Stages</title>
<para>
</para>
<para>The <command>init</command> script in <filename>99base</filename> is the main script, which prepares the root file system for usage, runs udev, mounts the real root device, kills the remaining processes, and switches to the real root device for further booting. dracut modules can insert custom script at various points, to control the boot process. These hooks are plain directories containing shell scripts ending with &quot;.sh&quot;, which are sourced by <command>init</command>.
Common used functions are in <filename>dracut-lib.sh</filename>, which can be sourced by any script. </para>
<section>
<title>Basic Setup</title>
<para>
</para>
<para>The first thing <command>init</command> does, is to mount <filename>/proc</filename> and <filename>/sys</filename> and manually create the basic device nodes and symbolic links in <filename>/dev</filename> needed to execute basic commands. Then logging is setup according to kernel command line arguments. <filename>/dev/pts</filename> and <filename>/dev/shm</filename> are mounted and the first hook is sourced.</para>
</section>
<section>
<title>Hook: cmdline</title>
<para>
</para>
<para>The <literal>
<function>cmdline</function>
</literal> hook is a place to insert scripts to parse the kernel command line and prepare the later actions, like setting up udev rules and configuration files.</para>
<para>In this hook the most important environment variable is defined: <envar>root</envar>. The second one is <envar>rootok</envar>, which indicates, that a module claimed to be able to parse the <envar>root</envar> defined. So for example, <envar>root=</envar><replaceable>iscsi:....</replaceable> will be claimed by the <function>iscsi</function> dracut module, which then sets <envar>rootok</envar>.</para>
</section>
<section>
<title>Hook: pre-udev</title>
<para>
</para>
<para>This hook is executed right after the <function>cmdline</function> hook and a check if <envar>root</envar> and <envar>rootok</envar> were set. Here modules can take action with the final <envar>root</envar>, and before <command>udev</command> has been run.</para>
</section>
<section>
<title>Start Udev</title>
<para>
</para>
<para>Now <command>udev</command> is started and the logging for <command>udev</command> is setup.</para>
</section>
<section>
<title>Hook: pre-trigger</title>
<para>
</para>
<para>In this hook, you can set udev environment variables with <code>udevadm control --property=<envar>KEY</envar>=<replaceable>value</replaceable></code> or control the further execution of <command>udev</command> with <command>udevadm</command>.</para>
</section>
<section>
<title>Trigger Udev</title>
<para>
<para><command>udev</command> is triggered by calling <command>udevadm trigger</command>, which sends <constant>add</constant> events for all devices and subsystems.
</para>
</section>
<section>
<title>Main Loop</title>
<para>
<para>Now the main loop of <command>99base/init</command> begins. Here we loop until <command>udev</command> has settled and all scripts in <filename>initqueue-finished</filename> returned true. In this loop there are three hooks, where scripts can be inserted by calling <command>/sbin/initqueue</command>.
</para>
<section>
<title>Initqueue</title>
<para>
</para>
<para>This hook gets executed every time a script is inserted here, regardless of the <command>udev</command> state.</para>
</section>
<section>
<title>Initqueue settled</title>
<para>
</para>
<para>This hooks gets executed every time <command>udev</command> has settled.</para>
</section>
<section>
<title>Initqueue finished</title>
<para>
</para>
<para>This hook is called after <command>udev</command> has settled and if all scripts herein return <errorcode>0</errorcode> the main loop will be ended.</para>
</section>
</section>
<section>
<title>Hook: pre-mount</title>
<para>
</para>
<para>Before the root device is mounted all scripts in the hook pre-mount are executed. In some cases (e.g. <acronym>NFS</acronym>) the real root device is already mounted, though.</para>
</section>
<section>
<title>Hook: mount</title>
<para>
</para>
<para>This hook is mainly to mount the real root device.</para>
</section>
<section>
<title>Hook: pre-pivot</title>
<para>
</para>
<para>This hook is the last hook and is called before init finally switches root to the real root device. This is a good place to clean up and kill processes not needed anymore.</para>
</section>
<section>
<title>Cleanup and switch_root</title>
<para>
</para>
<para>Init kills all <command>udev</command> processes, cleans up the environment, sets up the arguments for the real <command>init</command> process and finally calls <command>switch_root</command>. <command>switch_root</command> removes the whole filesystem hierarchy of the initramfs, chroot()s to the real root device and calls <command>/sbin/init</command> with the specified arguments.</para>
<para>To ensure all files in the initramfs hierarchy can be removed, all processes still running from the initramfs should not have any open file descriptors left.</para>
</section>
</section>
<section>
@ -370,22 +514,83 @@ overlay/
</section>
<section>
<title>Writing a Module</title>
<para>
</para>
<para>A simple example module is <filename>96insmodpost</filename>, which modprobes a kernel module after udev has settled and the basic device drivers have been loaded.</para>
<para>First we create a <filename>check</filename> script, which just exits with <errorcode>0</errorcode> indicating that this module should be included by default.</para>
<para><filename>check</filename>:</para>
<programlisting>exit 0</programlisting>
<para>The we create the install script, which installs a cmdline hook with priority number 20 called <filename>parse-insmodpost.sh</filename>. It also installs the <filename>insmodpost.sh</filename> script in <filename>/sbin</filename>.</para>
<para><filename>install</filename>:</para>
<programlisting>inst_hook cmdline 20 &quot;$moddir/parse-insmodpost.sh&quot;
inst_simple &quot;$moddir/insmodpost.sh&quot; /sbin/insmodpost.sh</programlisting>
<para>The <filename>pase-instmodpost.sh</filename> parses the kernel command line for a argument <envar>rdinsmodpost</envar>, blacklists the module from being autoloaded and installs the hook <filename>insmodpost.sh</filename> in the <filename>initqueue-settled</filename>.</para>
<para><filename>parse-insmodpost.sh</filename>:</para>
<programlisting>for p in $(getargs rdinsmodpost=); do
echo &quot;blacklist $p&quot; &gt;&gt; /etc/modprobe.d/initramfsblacklist.conf
_do_insmodpost=1
done

[ -n &quot;$_do_insmodpost&quot; ] &amp;&amp; /sbin/initqueue --settled --unique --onetime /sbin/insmodpost.sh
unset _do_insmodpost
</programlisting>
<para><filename>insmodpost.sh</filename>, which is called in the <filename>initqueue-settled</filename> hook will just modprobe the kernel modules specified in all <envar>rdinsmodpost</envar> kernel command line parameters. It runs after <command>udev</command> has settled and is only called once (<parameter>--onetime</parameter>).</para>
<para><filename>insmodpost.sh</filename>:</para>
<programlisting>. /lib/dracut-lib.sh

for p in $(getargs rdinsmodpost=); do
modprobe $p
done
</programlisting>
<section>
<title>Check</title>
<para>
</para>
<title>check</title>
<para><filename>check</filename> is called by dracut to evaluate the inclusion of a dracut module in the initramfs.</para>
<para><filename>check</filename> also can be called with arguments, which are described in the following list.</para>
<variablelist>
<varlistentry>
<term><filename>check</filename> -d</term>
<listitem>
<para>If <filename>check</filename> is called with parameter <parameter>-d</parameter>, then the stdout output is taken as the dracut module names of the dependencies this module needs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>check</filename> -h</term>
<listitem>
<para>If check is called with parameter <parameter>-h</parameter>, then the module check should be in &quot;hostonly&quot; mode, which means, that the check should only return 0, if the module is really needed to boot this specific host.</para>
</listitem>
</varlistentry>
</variablelist>
<para>If <filename>check</filename> is called without parameters, it should return the following exit codes.</para>
<variablelist>
<varlistentry>
<term>exit 0</term>
<listitem>
<para>Include the dracut module in the initramfs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>exit 1</term>
<listitem>
<para>Do not include the dracut module. The requirements are not fullfilled (missing tools, etc.)</para>
</listitem>
</varlistentry>
<varlistentry>
<term>exit 255</term>
<listitem>
<para>Only include the dracut module, if another module requires it or if explicitly specified in the config file or on the argument list.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Install</title>
<para>
</para>
<para>dracut_install</para>
<para>inst</para>
<para>inst_hook</para>
<para>inst_rules</para>
<para/>
</section>
<section>
<title>Installkernel</title>
<para>
</para>
<para>instmods</para>
</section>
<section>
<title>Creation Functions</title>
@ -406,15 +611,15 @@ overlay/
</chapter>
<appendix>
<title>Man Pages</title>
<section>
<section id="dracut.man">
<title>dracut</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dracut.8.xml" encoding="UTF-8" parse="xml"/>
</section>
<section>
<title>dracut.conf </title>
<section id="dracut.conf">
<title>dracut.conf</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dracut.conf.5.xml" encoding="UTF-8" parse="xml"/>
</section>
<section>
<section id="dracut.kernel">
<title>dracut.kernel</title>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dracut.kernel.7.xml" encoding="UTF-8" parse="xml"/>
</section>