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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1661629 Title: upgrade of kernel fails with mkinitramfs: failed to determine device for / To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1661629/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
