Comment 7 for bug 1661629

On Wed, Jul 04, 2018 at 01:21:35AM -0000, John Gallagher wrote:
> > 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.

That sounds like it might be the right approach, but I'm not sure. I'm a
bit confused as to exactly why update-initramfs fails here due to the
way it is being called - see below.

> > 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?

Ah - that won't be the issue then. I was suggesting that if you had the
filesystems in /etc/fstab, then that might be the cause of your problem.
It sounds like that isn't the case then.

> > 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.

I suggest that you test using VMs, and initially use development release
images rather than upgrading up to it. But yes, you can upgrade using
do-release-upgrade(8) (in steps, with '-d' for the final step).

It looks like kdump-tools might be causing the issue here, rather than
this being (directly, at least) being a problem in initramfs-tools.
kdump-tools drops in a kernel postinst.d/ script. This script calls
mkinitramfs but with a modified MODULES=dep configuration option:
https://git.launchpad.net/ubuntu/+source/makedumpfile/tree/debian/kernel-postinst-generate-initrd?h=applied/ubuntu/devel

It might be easier to resolve this by considering this as "mkinitramfs
fails on ZFS root without /etc/fstab lines for the ZFS filesystems when
MODULES=dep is used". If that's accurate (I haven't tested).

Could you perhaps see if you can remove kdump-tools from the equation
like this?