Comment 4 for bug 1422153

> /usr/bin/add-apt-repository ppa:zfs-native/trusty

The zpool-import job in this package does:

  start on ( starting mountall )

And mountall is 'start on startup' - which makes zpool-import the very first job to run on the system, *including* before udev. If this job does not correctly handle the underlying disks not yet being available, then that's entirely a bug in zpool-import.

> Even if ignoring details of zfs: I have booted the machine with nosplash
> to see the boot process messages. Opening these two encrypted disks
> happens very late, almost at the end of boot message. Which means that -
> beyond the zfs problem - regular services and daemons would fail to
> start if they had to access these disks instead of running from the boot
> device.

That's not at all true. The opening of encrypted disks is, at *latest*, done in /etc/rcS.d, which is called from /etc/init/rc-sysinit.conf before switching runlevels. And if the devices being mounted are part of the core filesystem, the rc-sysinit job will be triggered by the 'failsafe-boot' event, with the 'filesystem' event happening only after the disks have been unlocked and mounted. So both jobs configured to start on 'filesystem' and jobs configured to start on 'runlevel' will trigger after /etc/init/cryptdisks.conf.

Now, if the setup of those disks /after/ being decrypted is slow, there could be a race between 'runlevel' and mounting those disks. (Since we've been triggered by the 'failsafe-boot', everything at that point is best-effort.) However, /etc/init/cryptdisks.conf is itself a failsafe which is not expected to trigger in the normal case, and you haven't provided any direct evidence that it is being triggered here. All your problems here are is explained by the fact that zpool-import is run before mountall and don't cope with newly-discovered devices.