https://bugzilla.redhat.com/show_bug.cgi?id=515589
It ends up installing the label.so control plugin which isn't supposed
to get installed into the initrd. this makes cairo and libX11 and all sorts of
things move into the initrd that aren't supposed to.
--kernel-only
only install kernel drivers and firmware files
--no-kernel
do not install kernel drivers and firmware files
All kernel module related install commands moved from "install"
to "installkernel".
For "--kernel-only" all installkernel scripts of the specified
modules are used, regardless of any checks, so that all modules
which might be needed by any dracut generic image are in.
The basic idea is to create two images. One image with the kernel
modules and one without. So if the kernel changes, you only have
to replace one image.
Grub and the kernel can handle multiple images, so grub entry can
look like this:
title Fedora (2.6.29.5-191.fc11.i586)
root (hd0,0)
kernel /vmlinuz-2.6.29.5-191.fc11.i586 ro rhgb quiet
initrd /initrd-20090722.img
initrd /initrd-kernel-2.6.29.5-191.fc11.i586.img
initrd /initrd-config.img
initrd-20090722.img
the image provided by the initrd rpm
one old backup version is kept like with the kernel
initrd-kernel-2.6.29.5-191.fc11.i586.img
the image provided by the kernel rpm
initrd-config.img
optional image with local configuration files
LVM
rd_NO_LVM
disable LVM detection
rd_LVM_VG=<volume group name>
only activate the volume groups with the given name
crypto LUKS
rd_NO_LUKS
disable crypto LUKS detection
rd_LUKS_UUID=<luks uuid>
only activate the LUKS partitions with the given UUID
MD
rd_NO_MD
disable MD RAID detection
rd_MD_UUID=<md uuid>
only activate the raid sets with the given UUID
DMRAID
rd_NO_DM
disable DM RAID detection
rd_DM_UUID=<dmraid uuid>
only activate the raid sets with the given UUID
init now has the following points to inject scripts:
/cmdline/*.sh
scripts for command line parsing
/pre-udev/*.sh
scripts to run before udev is started
/pre-trigger/*.sh
scripts to run before the main udev trigger is pulled
/initqueue/*.sh
runs in parallel to the udev trigger
Udev events can add scripts here with /sbin/initqueue.
If /sbin/initqueue is called with the "--onetime" option, the script
will be removed after it was run.
If /initqueue/work is created and udev >= 143 then this loop can
process the jobs in parallel to the udevtrigger.
If the udev queue is empty and no root device is found or no root
filesystem was mounted, the user will be dropped to a shell after
a timeout.
Scripts can remove themselves from the initqueue by "rm $job".
/pre-mount/*.sh
scripts to run before the root filesystem is mounted
NFS is an exception, because it has no device node to be created
and mounts in the udev events
/mount/*.sh
scripts to mount the root filesystem
NFS is an exception, because it has no device node to be created
and mounts in the udev events
If the udev queue is empty and no root device is found or no root
filesystem was mounted, the user will be dropped to a shell after
a timeout.
/pre-pivot/*.sh
scripts to run before the real init is executed and the initramfs
disappears
All processes started before should be killed here.
The behaviour of the dmraid module demonstrates how to use the new
mechanism. If it detects a device which is part of a raidmember from a
udev rule, it installs a job to scan for dmraid devices, if the udev
queue is empty. After a scan, it removes itsself from the queue.
Jobs are no longer handled inside the udev events.
/sbin/initqueue is called with the commands to queue.
init will work on these jobs sequentially, so that we prevent jobs
from being killed by udev timeouts.
This serialization also prevents some problems introduced by
the udev event parallelization.
If we purport to test booting to an md raid, we may as well test it.
We do not need the plymouth module and the normal crypt module to include
duplicate functionality.
Harald Hoyer