Dracut is an initramfs infrastructure, as well as the name of tool needed to create initramfs images. It is also the name of the prompt/environment made available at boot time by choice or by error, allowing for troubleshooting of boot-time problems.

Building Initramfs Images

It always pays to make backups:

cd /boot
cp -a initramfs-3.12.8-300.fc20.i686.img initramfs-3.12.8-300.fc20.i686.img.backup

The dracut tool is used to build initramfs images:

dracut -f /boot/initramfs-3.12.8-300.fc20.i686.img 3.12.8-300.fc20.i686

Images are best built from within the intended root of the Linux system, and the tool can be run on a live system with no issues. If the system is in a state where this is unattainable, it is possible to build a clean environment by assembling the necessary mounts in rescue mode. Do not select “find drives automatically,” we will do so manually:

mkdir /mnt/sysimage
vgchange -ay
mount /dev/mapper/Volume00-root
mount /dev/sda1 /mnt/sysimage/boot
mount --bind /proc /mnt/sysimage/proc
mount --bind /dev /mnt/sysimage/dev
mount --bind /sys /mnt/sysimage/sys
chroot /mnt/sysimage

NOTE: Devices holding boot and root will vary from system to system.

Now run dracut.

The Dracut Shell

If the boot process fails due to an issue with the initial ram disk, we will likely be dropped to the dracut shell (this may require adding rd.shell as a kernel argument).

For example, failure due to a missing volume:

Warning: Could not boot.
Warning: /dev/mapper/luks-cc7e78ee-87a9-4ad0-9c82-31de01389b34 does not exist

The beauty of the dracut prompt is that we have nearly the full flexibility of Linux at our disposal, with whatever tools exist in the initramfs image.

This particular error is something I have commonly experienced when switching root, and is probably due to the systemd setup within the initramfs specifically looking for a device that did not exist when we created it (for instance, if we ran dracut while not within the final resting place of root).

We can see what is actually contained within the initrams image:

lsinitrd /boot/initramfs-3.12.8-300.fc20.i686.img

If a volume cannot be found, it is likely there is no entry for it in etc/systemd/system/initrd.target.wants. We can attempt to urge things along manually:

lvm vgchange -ay
cryptsetup luksOpen /dev/mapper/Volume00-root luks-cc7e78ee-87a9-4ad0-9c82-31de01389b34
Enter passphrase for /dev/mapper/Volume00-root:
exit

If this now boots the system, the path forward is to re-generate the initramfs image correctly, which usually entails doing so from within the appropriate root (as above).

Finally, here is a tidbit showing what kinds of things can be done for gathering intelligence for later followup:

debug=$(lvm pvdisplay; lvm vgdisplay; lvm lvdisplay; blkid; dmesg)
lvm vgchange -a y
cryptsetup luksOpen /dev/mapper/Volume00-root luks-cc7e78ee-87a9-4ad0-9c82-31de01389b34
Enter passphrase for /dev/mapper/Volume00-root:
mount /dev/mapper/luks-cc7e78ee-87a9-4ad0-9c82-31de01389b34 /mnt
echo "$debug" > /mnt/dracut.debug

NOTE: All this does is set an environment variable “debug” to the output of a bunch of commands, then activate storage somewhere to store that output, in this case showing how it is even possible to use a crypto-volume. Perhaps it is USB or simple volume instead.

Resources

  • http://wiki.centos.org/TipsAndTricks/CreateNewInitrd
  • http://lists.centos.org/pipermail/centos/2013-March/133604.html