encrypted root fails without udev in initramfs

ParanoidAndroid · 2013-06-18 21:30:10

I'm trying to decrease my boot time on my new machine. After testing, I found the two biggest time-wasters on my system were Xorg and the initramfs. I can't do much about X, because I'm by no means highly skilled with code and I'd rather not use my inexpert skills to dissect and strip the Xorg binary. My focus, therefore, has been on removing udev from the initramfs to make it load faster.

I have tried this before, manually specifying the drivers and modules I need in the MODULES array and removing all hooks except base, encrypt, and fsck. My root partition is encrypted, but I may not even need the encrypt hook since I specify the dm_crypt and cryptsetup module/binary in the proper arrays. When I try and boot this, however, it hangs and then drops me to a prompt with the error "/dev/mapper/root not found." Here is my mkinitcpio.conf:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES="sd_mod ata_piix jfs dm_crypt"

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES="fsck.jfs fsck cryptsetup"

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No raid, lvm2, or encrypted root is needed.
#    HOOKS="base"
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS="base udev autodetect block filesystems"
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS="base udev block filesystems"
#
##   This setup assembles a pata mdadm array with an encrypted root FS.
##   Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
#    HOOKS="base udev block mdadm encrypt filesystems"
#
##   This setup loads an lvm2 volume group on a usb device.
#    HOOKS="base udev block lvm2 filesystems"
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr, fsck and shutdown hooks.
HOOKS="base udev modconf keyboard encrypt fsck"

# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
COMPRESSION="cat"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""

I'm assuming udev is needed to scan for the root device and/or find the encrypted partition for cryptsetup to unlock. Is there a way around this? I'd like to cut out udev, as it is the biggest time hog within initramfs.

I heard something about static /dev folders, but I'm not entirely sure how to go about setting that up or if it will work with an encrypted root...

EDIT:

I looked more closely at the initramfs shell on my latest test. Without udev, the /dev folder is still populated with my drive partitions and cryptsetup (when run manually from within initramfs) will unlock my root partition just fine. It seems to me that cryptsetup is failing to run initially for some reason. Thoughts?

Last edited by ParanoidAndroid (2013-06-18 21:51:11)

WonderWoofy · 2013-06-18 22:27:36

The encrypt hook requires the udev hook. If you had taken a look at the actual install file for the encrypt mkinitpcio hook, you would have seen that it functions by pulling in a few udev rules which are activated when the init script calles "udevadm trigger". If you want your initramfs to decrypt your filesystem without udev, you are going to have to write your own hook.

As a side note, I have tried using mdadm vs mdadm_udev, as well as udev vs no-udev/btrfs in my initramfs, and having udev is always faster. I think if you are so concerned about boot time, the best way to do that is to use a mush more simplified set up. But since you use encryption, it would seem that security must have some signifigance to you, so that may not be an option. You have to understand that the time spend in the initramfs also includes the time it takes for you to enter your password to decrypt your partition (if you use a password).

One non-obvious thing you can do to potentially speed up your initramfs load time is to not compress it. As far as compression is concerned, lzo is the fastest, and 3.9 brought some not insignifigant speed improvments. But having it just read the whole thing uncompressed I have foudn to be consistently faster.

Really though, I think the whole idea of speeding up boot time is not really something worth pursuing unless you have something that is making it horribly slow. What kind of time is systemd-analyze repotying anyway? (BTW, systemd-analyze is not really a true representation of experienced boot time as it only records time it takes to get to userspace, which is not what most people think it is)

falconindy · 2013-06-19 12:30:42

WonderWoofy wrote:

The encrypt hook requires the udev hook. If you had taken a look at the actual install file for the encrypt mkinitpcio hook, you would have seen that it functions by pulling in a few udev rules which are activated when the init script calles "udevadm trigger". If you want your initramfs to decrypt your filesystem without udev, you are going to have to write your own hook.

You're right, but for the wrong reasons. udev is needed so that DM can tag the device (systemd needs to know about it later on) -- it has no part at all in assembly.

WonderWoofy · 2013-06-19 14:54:17

Interesting, thanks falconindy.

Arch Linux

#1 2013-06-18 21:30:10

encrypted root fails without udev in initramfs

#2 2013-06-18 22:27:36

Re: encrypted root fails without udev in initramfs

#3 2013-06-19 12:30:42

Re: encrypted root fails without udev in initramfs

#4 2013-06-19 14:54:17

Re: encrypted root fails without udev in initramfs

Board footer