Provided by: yaird_0.0.12-3_i386
yaird - generate initial boot image as initramfs or initrd
yaird --output=dest [options...] [version]
yaird --test [options...] [version]
Yaird (Yet Another MkInitRD) generates initial boot images in initrd or
initramfs format. This is an intermediate step between the boot loader
and the init scripts on the root file system; it loads modules and
enables devices to a level where the kernel can access the real root
file system, and then hands over control to the init scripts. You need
a new boot image every time you install a new kernel, and when you
switch to a different root device. If you are using distribution
provided kernels, building the boot image is likely to be done
automatically by the installation software.
Most distributions include a distribution-specific tool called
mkinitrd(8) for the same task. The yaird alternative differs in that
it only supports 2.6 kernels: that means it can use the information
provided by newer kernels to build smaller images and if necessary
produce better error messages.
Another difference is that there is a clear separation between the code
that analyses the system and the templates that determine how these
actions are handled by the boot image; this separation makes it
relatively simple to customise the generated images.
The following configurations are supported: SATA, SCSI, IDE, USB
storage, DASD, LVM2, mdadm, cryptsetup, cryptsetup-luks, USB keyboards,
NFS root, EVMS.
Not yet supported: swsusp, firewire, loopback, loopaes, dmraid.
Produce the image in this format. Valid formats are: directory,
cramfs, cpio. Use the cpio format to get an image for use with
the ’initramfs’ model of booting; this is the preferred model
for 2.6 kernels. Use ’directory’ to leave the image as a
directory instead of packing it, either for debugging purposes
or to pack it in a file system format of your preference. Use
’cramfs’ to get an image in the cramfs file system format for
use with the older ’initrd’ model of booting. The default is
determined by the main configuration file.
Place result here. The destination must not exist yet. There
is no default for this option.
The configuration file that specifies what the initial boot
image should do. The default is .../etc/yaird/Default.conf
-h, -?, --help
Print help text and exit.
Print version and exit.
Print progress messages.
Print debugging information.
Suppress warning messages.
Print overview of system data and exit; used as basis for
Root privileges are required to use yaird.
When booting a yaird generated image, the presence of a kernel command
line parameter ’ydebug’ will trigger debugging options in the image:
showing commands as they are executed, an interactive shell before
control is handed over to the init scripts.
If you’re using mdadm(8), you may find that not all md devices are
created when booting with yaird. The solution is to add an "auto=md"
option to all devices in /etc/mdadm/mdadm.conf.
If you’re using cryptsetup(8) for your root device, you need a
configuration file /etc/crypttab in order to determine which hash
function is used and to verify that the passphrase will be supplied by
the controlling terminal. This file is a Debian invention; if your
distribution does not document it, consult your favourite search
engine. For an encrypted device /dev/mapper/crypted, the configuration
file should look more or less as follows:
# <target device> <source device> <key file> <options>
crypted /dev/sda3 none cipher=aes-cbc-plain
For cryptsetup-luks, the same configuration file is used.
If you want the generated initial image to boot into a file system
other than the root in the current /etc/fstab, or to do booting over
NFS, modify the main configuration file.
If you’re using an NFS root, note that your systems init scripts may
need changes to work properly. As an example, resetting a network
interface card to get it in a known state may be a good idea in
general, but not if your root file system is accessed via that
Although it is possible to generate initial boot images in initrd
format, there’s not much point in doing so: all kernels new enough to
work with yaird support initramfs, which allows simpler images.
Initramfs templates have undergone more testing than the initrd
Note that under certain conditions initramfs images can be appended to
the kernel, but often it is more convenient to keep the image as a
separate file that is loaded by the boot loader in the same manner as
the older initrd images; see your boot loader documentation.
Assuming the main configuration file holds something like:
TEMPLATE FILE "/usr/local/etc/yaird/Templates.cfg"
MOUNTDIR "/" "/mnt"
To generate an image in initramfs format for the current kernel and
current root disk:
To generate, with progress report, an image for kernel version 2.6.11:
yaird --verbose --output=/boot/initrd.img-2.6.11 2.6.11
To generate an image that will boot into /dev/vg0/root rather than the
default root, edit the configuration file to replace MOUNTDIR with
MOUNTDEV "/dev/vg0/root" "/mnt"
To generate an image that will boot over NFS using an ethernetcard
found on the current machine, edit the configuration file to replace
MOUNTDIR with the following:
To let grub load an initial boot image from local disk in combination
with an NFS root file system on a server that can only handle NFS over
title Linux 2.6.11 network boot
kernel /vmlinuz-2.6.11 ip=eth0 nfsroot=10.1.1.1:/dat/root,udp
There is a main configuration file .../etc/yaird/Default.cfg, that
— The default format of the generated image;
— A list of goals the image should achieve, such as loading a
module or mounting a device;
— The location of a secondary configuration file containing
This secondary configuration file, normally
.../etc/yaird/Templates.cfg, that determines what needs to be placed on
the boot image in order to achieve results such as mounting a device.
These templates are at a lower level than the goals specified in the
main configuration file: as an example the main configuration file can
specify that a module must be loaded, without specifying pathname,
extensions, dependencies or options, but the template file need only be
able to do a single insmod with all details spelled out. See the HTML
documentation for the format of these configuration files.
Additionally, a number of other files are used to determine what should
go on the boot image.
/sys Kernel-provided overview of hardware that needs to be supported.
Modules listed here will not be considered as possible drivers
for detected hardware.
Determines source of passphrase and which cryptographic
algorithms to use for cryptsetup or cryptsetup-luks.
Which device to use as root, file system modules, mount options.
Whether support for USB keyboards is needed.
Which drivers are compiled into the kernel, so that no
additional modules need to be loaded.
used indirectly via modprobe(8); determines which options to use
when loading a module into the kernel.
With VMware, you may need to add ’MODULE buslogic’ to the configuration
file to get the system to boot; a kernel patch to make the detection go
automatically is in the works; in 2.6.14 this still is not in mainline.
With the s390 architecture, you’ll need an option like dasd=autodetect
for the dasd_mod module in order to activate the devices and get a
bootable system. This is incompletely tested.
With SunBlade 1000, you may need to add ’MODULE qlogicfc’ to the
configuration file to get the system to boot.
Report bugs to <email@example.com>; adding the output
of yaird with the --test and --verbose options helps.
boot(7), cryptsetup(8), grub(8), lilo(8), mdadm(8), mkinitrd(8),