Comment 6 for bug 1661629

> I'm not particularly familiar with this part of initramfs-tools, but it seems to me that essentials like the loading of the virtio_pci module would be short-circuited by your patch.

Yes, you're right, thanks for pointing that out. If the driver isn't built-in to the kernel, it would be omitted. I think what we need to do here is get a list of the devices that make up the root pool, probably from the output of `zpool list -vPL`, and then call 'block_dev_mod_add' on each device. I'll work on updating the patch.

> I was just pointed to https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS and told that ZFS filesystems aren't expected to be in /etc/fstab according to those instructions. Is this correct? I haven't checked but it seems that initramfs-tools wouldn't then fail under these conditions.

It's true that we don't have the filesystems listed in /etc/fstab. Can you elaborate on how you anticipate that would affect building the initramfs?

> Could you provide exact steps to reproduce your problem, please?
Once you have a machine with zfs on root, this should be reproducible by running `apt install kdump-tools`. The post install hooks fail while trying to build an initramfs for the crash kernel. We build these ubuntu images that use zfs on root using live-build (https://github.com/delphix/appliance-build/), but our process currently relies on some packages internal to our organization. If need be, we might be able to modify the build to be usable externally as well.

> Does this apply and work correctly on the current Ubuntu development release (Cosmic) please? We land changes there first and only once successful consider backporting to existing releases as appropriate.
Is it possible to upgrade my machine to the development release? If not, I might be able to modify our build process to build an Cosmic image that uses zfs on root.