25-30 second boot delay in Debian Stretch with zfs-initramfs (no delay with zfs-dracut)

[jwittlincohen]

System information

Distribution Name Debian
Distribution Version Stretch (9.0)
Linux Kernel 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u1 (2017-06-18)
Architecture AMD64
ZFS Version 0.6.5.9-5
SPL Version 0.6.5.9-1

Describe the problem you're observing

I followed the Debian Jessie Root on ZFS guide with minor tweaks for Debian Stretch (no need to install grub-pc from testing, no need to install zfs from backports etc.). The Howto uses zfs-initramfs to mount the root file system. While the system boots fine following the guide instructions, there is a 25-30 second delay prior to ZFS mounting my pool (mirrored pool using 2 SSDs). I see the message, "Begin: Running /scripts/local/block . . . done." for about 25 seconds, immediately after which ZFS mounts the pool. After discussing this issue with a ZFS developer, I was instructed to try zfs-dracut as the issue appears to be a delay caused by the initramfs.

Sure enough, installing zfs-dracut (which removes zfs-initramfs) resolved the issue, allowing the pool to be mounted without any perceived delay. systemd-analyze showed 31+ seconds dedicated to the kernel + initrd, versus about 2 seconds currently (now ~600 ms kernel, 1.4 seconds initrd).

Describe how to reproduce the problem

I was able to reproduce this issue on bare metal with my desktop system and in a virtual machine (using KVM + QEMU). I simply followed the Debian Jessie Root on ZFS Howto instructions, making the necessary changes for Stretch. After rebooting, I experienced the delay. Installing zfs-dracut resolved the issue.

Include any warning/errors/backtraces from the system logs

Dmesg does not show the "script/local/block" messages. It simply shows a 25-30 second period of time during which there is no activity beginning after hardware discovery. After the 25-30 seconds, ZFS mounts the pool.

[beren12]

Does it make a difference if you use a different init? openrc or sysvinit or something?

[gmelikov]

I confirm it, appeared after stretch upgrade.

[ryao]

@beren12 I am the developer @jwittlincohen cited. I can confirm that this delay is in the initramfs from the troubleshooting that we did. Changing the init system should not make a difference.

[Fabian-Gruenbichler]

This could potentially be a result of the RESUME (as in, "resume from suspend-to-disk") support in initramfs-tools, which was added pretty late in the Stretch release cycle. Try adding a new line containing "RESUME=none" to the end of /etc/initramfs-tools/initramfs.conf , followed up by running "update-initramfs -u". See "man initramfs.conf" for details.

[jwittlincohen]

Try adding a new line containing "RESUME=none" to the end of
/etc/initramfs-tools/initramfs.conf , followed up by running
"update-initramfs -u". See "man initramfs.conf" for details.

That fixed the issue for me. I tested on a Debian Stretch VM (KVM+QEMU) as well as my desktop system. No more delay on either.

[jwittlincohen]

Closing issue as the problem is resolved with the above fix.