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.
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:
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 interface.
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 version.
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.
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:
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:
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 UDP:
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.
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.