Ubuntu
initramfs-tools package

upgrade of kernel fails with mkinitramfs: failed to determine device for /

Bug #1661629 reported by Fredrik Tuomas
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Fix Released
Undecided
Unassigned
Bionic
Fix Released
Undecided
Unassigned

Bug Description

[Impact]
Ubuntu users who have installed on ZFS devices, and using MODULES=dep in initramfs.conf.

[Test case]
-- upgrade --
1) install 16.04 using ZFS as rootfs.
2) upgrade to 18.04

-- initramfs update --
1) install Ubuntu, using ZFS as a rootfs.
2) change 'MODULES=most' to 'MODULES=dep' in /etc/initramfs-tools/initramfs.conf
3) run "sudo update-initramfs -u"

Without the patch, you should see a warning from mkinitramfs:

mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /etc/initramfs-tools/

With initramfs-tools patched, you should not see the warning, and instead have additional kernel modules added to the initramfs that are required to support the block devices that host the ZFS pools.

[Regression Potential]
This change is limited to behavior for ZFS filesystems. Likely regressions might include loading a kernel module that conflicts with another that is required at boot but not blacklisted, causing unexpected behavior on the system, or failure to find the necessary kernel modules or ZFS pools, possibly leading to an initramfs that does not contain the necessary modules yet has not shown a warning on screen to indicate that might be the issue.

---

When upgrading packages with "apt upgrade" on Ubuntu 16.04.1 LTS with root on ZFS I get this error:

Setting up linux-image-4.4.0-59-generic (4.4.0-59.80) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-59-generic /boot/vmlinuz-4.4.0-59-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-59-generic /boot/vmlinuz-4.4.0-59-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-59-generic
run-parts: executing /etc/kernel/postinst.d/kdump-tools 4.4.0-59-generic /boot/vmlinuz-4.4.0-59-generic
kdump-tools: Generating /var/lib/kdump/initrd.img-4.4.0-59-generic
mkinitramfs: failed to determine device for /
mkinitramfs: workaround is MODULES=most, check:
grep -r MODULES /etc/initramfs-tools/

Error please report bug on initramfs-tools
Include the output of 'mount' and 'cat /proc/mounts'
update-initramfs: failed for with 1.
run-parts: /etc/kernel/postinst.d/kdump-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-4.4.0-59-generic.postinst line 1052.
dpkg: error processing package linux-image-4.4.0-59-generic (--configure):
 subprocess installed post-installation script returned error exit status 2

version of initramfs-tools is 0.122ubuntu8.8

Output of mount is:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8066020k,nr_inodes=2016505,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1623576k,mode=755)
rpool/ROOT/ubuntu on / type zfs (rw,relatime,xattr,noacl)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
rpool/home on /home type zfs (rw,nosuid,noatime,xattr,noacl)
rpool/home/fredrik on /home/fredrik type zfs (rw,nosuid,noatime,xattr,noacl)
rpool/home/root on /root type zfs (rw,nosuid,noatime,xattr,noacl)
rpool/srv on /srv type zfs (rw,noatime,xattr,noacl)
rpool/var/cache on /var/cache type zfs (rw,nosuid,noexec,noatime,xattr,noacl)
rpool/var/log on /var/log type zfs (rw,nosuid,noexec,noatime,xattr,noacl)
rpool/var/spool on /var/spool type zfs (rw,nosuid,noexec,noatime,xattr,noacl)
rpool/var/tmp on /var/tmp type zfs (rw,nosuid,noatime,xattr,noacl)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1623576k,mode=700,uid=1000,gid=1000)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)

cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=8066020k,nr_inodes=2016505,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=1623576k,mode=755 0 0
rpool/ROOT/ubuntu / zfs rw,relatime,xattr,noacl 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
rpool/home /home zfs rw,nosuid,noatime,xattr,noacl 0 0
rpool/home/fredrik /home/fredrik zfs rw,nosuid,noatime,xattr,noacl 0 0
rpool/home/root /root zfs rw,nosuid,noatime,xattr,noacl 0 0
rpool/srv /srv zfs rw,noatime,xattr,noacl 0 0
rpool/var/cache /var/cache zfs rw,nosuid,noexec,noatime,xattr,noacl 0 0
rpool/var/log /var/log zfs rw,nosuid,noexec,noatime,xattr,noacl 0 0
rpool/var/spool /var/spool zfs rw,nosuid,noexec,noatime,xattr,noacl 0 0
rpool/var/tmp /var/tmp zfs rw,nosuid,noatime,xattr,noacl 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=1623576k,mode=700,uid=1000,gid=1000 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0

See original description
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
Revision history for this message
bendikro (bendikro) wrote :

The problem is the bash function dep_add_modules_mount in /usr/share/initramfs-tools/hook-functions which doesn't handle zfs.

By adding "MODULES=most" to /usr/share/initramfs-tools/conf-hooks.d/zfs, the error goes away.

I'm still having trouble getting kdump to actually create a crash dump with ZFS on root.

Revision history for this message
John Gallagher (john.gallagher) wrote :

Maybe there is something better, but it seems like the simplest change that would fix this would be something along the lines of the patch below. This just assumes that if the filesystem type is listed as zfs then it actually is zfs, and it adds the zfs module. With this change I was able to build a image using "MODULES=dep" and successfully create a crash dump with zfs on root.

--- /usr/share/initramfs-tools/hook-functions.orig 2018-06-26 22:24:55.918498180 +0000
+++ /usr/share/initramfs-tools/hook-functions 2018-06-26 22:48:44.350437446 +0000
@@ -350,9 +350,12 @@
   return
  fi

- # handle ubifs and return since ubifs is mounted on char devices
- # but most of the commands below only work with block devices.
- if [ "${FSTYPE}" = "ubifs" ]; then
+ # Most of the commands below only work with block devices. Some
+ # file systems don't specify a block device:
+ # - ubifs is mounted on char devices
+ # - zfs specifies the name of a zfs dataset
+ # In these cases, just assume the listed fs type is correct.
+ if [ "${FSTYPE}" = "ubifs" -o "${FSTYPE}" = "zfs" ]; then
   manual_add_modules "${FSTYPE}"
   return
  fi

Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to file this patch and helping to make Ubuntu better.

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.

> With this change I was able to build a image using "MODULES=dep" and successfully create a crash dump with zfs on root.

What sort of block device was backing your filesystem in your test case please? 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. Do you have an opinion on this?

Revision history for this message
Robie Basak (racb) wrote :

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. Could you provide exact steps to reproduce your problem, please?

Revision history for this message
John Gallagher (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.

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

Revision history for this message
Robie Basak (racb) wrote : Re: [Bug 1661629] Re: upgrade of kernel fails with mkinitramfs: failed to determine device for /

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?

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I can reproduce this on my 18.04 laptop with zfs on root.

kdump-tools.postinst ends up calling /etc/kernel/postinst.d/kdump-tools 4.15.0-23-generic, which fails at this mkinitramfs line:
mkinitramfs -d /var/lib/kdump/initramfs-tools -o /var/lib/kdump/initrd.img-4.15.0-23-generic.new 4.15.0-23-generic
mkinitramfs: failed to determine device for /

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

My fstab has only an entry for /boot/efi. Everything else is zfs.

Revision history for this message
John Gallagher (john.gallagher) wrote :

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

Yes, that sounds like an accurate summary. I'm not sure I follow how /etc/fstab is related, though. Looking briefly through mkinitramfs, I don't see where that is being used.

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

Good idea. Here is a more minimal way to reproduce the issue: with ZFS on root
 - set 'MODULES=dep' in '/etc/initramfs-tools/initramfs.conf'
 - run 'sudo update-initramfs -u'

Below is an updated patch, which finds and adds the module for each device in the zfs pool containing the root filesystem. I've tested the patch on Bionic and Cosmic with both zfs and ext4 root filesystems. Note that I wasn't entirely sure if we need to handle the case where 'dev_node' is /dev/root. I'm not familiar with that setup, so I'm not sure whether that could even apply when using zfs on root.

--- hook-functions 2018-07-10 22:19:18.489142772 +0000
+++ /usr/share/initramfs-tools/hook-functions 2018-07-10 22:06:43.969661842 +0000
@@ -357,6 +357,21 @@
                return
        fi

+ if [ "${FSTYPE}" = "zfs" ]; then
+ manual_add_modules "${FSTYPE}"
+
+ # ZFS uses the name of a filesystem instead of a device. Find
+ # the devices that make up the pool containing the specified
+ # filesystem, and add the appropriate driver for each device.
+ local poolname="${dev_node%%/*}"
+ zpool list -vPL "$poolname" | while read dev ignored; do
+ # Ignore non-leaf vdevs by skipping anything that doesn't
+ # look like an absolute path
+ echo "$dev" | grep -q '^/' && block_dev_mod_add "$dev"
+ done
+ return
+ fi
+
        if [ "$dir" = / ] && [ "${dev_node}" = "/dev/root" ] ; then
                if [ -b "${dev_node}" ]; then
                        # Match it to the canonical device name by UUID

Revision history for this message
John Gallagher (john.gallagher) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "mkinitramfs.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Mathieu Trudel-Lapierre (cyphermox)
Changed in initramfs-tools (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

@John, I've uploaded initramfs-tools with your patch to both cosmic and 18.04. Now, for the process of stable release updates [1]; we do need test cases and what is likely to break in case of a regression. I've added this to the best of my knowledge, but I don't have any systems with ZFS -- given that you have run into this issue, could you check and make sure at least my test cases correctly capture how to test that this fix works?

Thanks.

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

description: updated
Mathieu Trudel-Lapierre (cyphermox)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.131ubuntu9

---------------
initramfs-tools (0.131ubuntu9) cosmic; urgency=medium

  [ John Gallagher ]
  * Work out the kernel modules required to support ZFS filesystems and add
    them as necessary. (LP: #1661629)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 20 Aug 2018 10:52:20 -0400

Changed in initramfs-tools (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Fredrik, or anyone else affected,

Accepted initramfs-tools into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.130ubuntu3.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in initramfs-tools (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed verification-needed-bionic
Revision history for this message
Fredrik Tuomas (tuomaz) wrote :

Thank you for your work. I will test.

Revision history for this message
John Gallagher (john.gallagher) wrote :

@Mathieu, thanks for your work on this.

Regarding the test cases, I think that the second case needs an additional step:

-- initramfs update --
1) install Ubuntu, using ZFS as a rootfs.
2) change 'MODULES=most' to 'MODULES=dep' in /etc/initramfs-tools/initramfs.conf
3) run "sudo update-initramfs -u"

Without the second step, 'update-initramfs -u' will succeed even without the fix because 'MODULES=most' will probably result in the zfs module and necessary drivers being included anyway. I ran through this updated version of the test case on 18.04 with the package from the -proposed repository, and verified that the new version of the package fixed the issue.

As far as the first test case, I'm not sure I have a simple way to test that one. I have a straightforward way of building with zfs on root for 18.04 and newer, but not 16.04. However, looking at the original bug report, it looks like the issue was building the initramfs for the kdump kernel, not the main kernel. I suspect that test case would need to include installing kdump-tools. This is for the same reason that test case #1 needs to be modified: by default, the initramfs for the main kernel is built with MODULES=most, whereas the kdump kernel by default is built with MODULES=dep, and this bug only affects making an initramfs with MODULES=dep.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Verification-done on bionic with initramfs-tools 0.130ubuntu3.3:

Verified that with the SRU applied, the initramfs configured to use MODULES=dep can still determine that the root is over ZFS, and accordingly add the files needed in the initramfs.

description: updated
tags: added: verification-done-bionic
removed: verification-needed verification-needed-bionic
Revision history for this message
Steve Langasek (vorlon) wrote : Update Released

The verification of the Stable Release Update for initramfs-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.130ubuntu3.3

---------------
initramfs-tools (0.130ubuntu3.3) bionic; urgency=medium

  [ Scott Moser ]
  * scripts/functions: write netplan config files to /run/netplan for
    network devices configured with configure_networking. (LP: #1769682)

  [ Mathieu Trudel-Lapierre ]
  * scripts/functions: add 'critical: true' parameter; requires netplan
    0.36.2. (LP: #1769682)
  * debian/rules: skip tests on non-x86 architectures, where they then to be
    false negatives (extra macaddress matching makes the tests fail to match
    expected values).

  [ John Gallagher ]
  * Work out the kernel modules required to support ZFS filesystems and add
    them as necessary. (LP: #1661629)

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 20 Aug 2018 11:01:52 -0400

Changed in initramfs-tools (Ubuntu Bionic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.