[Bug 1771557] Re: NVMe boot drives not supported - failing in generating initramfs

Eric Desrochers eric.desrochers at canonical.com
Wed May 16 19:56:46 UTC 2018


** Description changed:

  [Impact]
  
  When creating the initramfs image, mkinitramfs has multiple options on
  how to include modules. The default (and most common) one is the
  "MODULES=most", which includes the majority of filesystem modules and
  all the block device drivers. One other option is "MODULES=dep", which
  tries to descend in the sysfs hierarchy and guess modules to add, with
  the goal of reduce the size of initramfs.
  
  For the MODULES=dep case, the initramfs-tools hook-functions script
  cannot translate nvmeXnYpZ to nvmeXnY block device, so it's failing in
  the sysfs lookup, so it does not build the initram disk.
  
  Upstream solution is composed of at least 2 patches (it's a series, but
  the 2 below are really the needed ones):
  
  commit 3cb744c9
  Author: Ben Hutchings <ben at decadent.org.uk>
  hook-functions: Rewrite block device sysfs lookup to be generic
  
  commit 8ac52dc0
  Author: Ben Hutchings <ben at decadent.org.uk>
  hook-functions: Include modules for all components of a multi-disk device
  
  Instead of doing the huge backport, we added another sed substitution: currently the script has substitutions for sdX and hdX, in order to convert sda1 to sda, for example. The new substitution converts nvmeXnYpZ to nvmeXnY.
  It's less intrusive than the full backport, since this is a minimal SRU to Trusty only.
  
- 
  [Test Case]
  1. Install Trusty with rootfs in a multi-disk(md) array composed of two nvme partitions - in my tests, I've used a RAID1.
  
  (lsblk output of my test env:
  
- nvme0n1     259:0    0    10G  0 disk  
- └─nvme0n1p1 259:1    0    10G  0 part  
-   └─md0       9:0    0    10G  0 raid1 /
- nvme1n1     259:2    0    10G  0 disk  
- └─nvme1n1p1 259:3    0    10G  0 part  
-   └─md0       9:0    0    10G  0 raid1 /
+ nvme0n1     259:0    0    10G  0 disk
+ └─nvme0n1p1 259:1    0    10G  0 part
+   └─md0       9:0    0    10G  0 raid1 /
+ nvme1n1     259:2    0    10G  0 disk
+ └─nvme1n1p1 259:3    0    10G  0 part
+   └─md0       9:0    0    10G  0 raid1 /
  )
  
- 
- 2. Once system is booted, modify the "/etc/initramfs-tools/initramfs.conf", replacing "MODULES=most" to "MODULES=dep".
+ 2. Once system is booted, modify the "/etc/initramfs-
+ tools/initramfs.conf", replacing "MODULES=most" to "MODULES=dep".
  
  3. Update your initramfs by running something like:
  "update-initramfs -u -k <your kernel version>"
  
  The initramfs creating procedure will fail, unless the patch from this
  LP is present.
  
- 
  [Regression Potential]
  If the sed expression was somewhat broken, we could have an issue generating initiramfs when MODULES is set to "dep", even for generic block devices (like regular HDDs).
  
+ [Other Info]
+ * This issue is based on Debian bug #785147: 
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147
  
- [Other Info]
- This issue is based on Debian bug #785147: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147
+ * Only Trusty is affected, Xenial and late contains the full fix as
+ mentioned above :
+ 
+ $ git describe --contains  8ac52dc0
+ v0.121_rc1~11
+ 
+ $ git describe --contains 3cb744c9
+ v0.121_rc1~11
+ 
+ $ rmadison initramfs-tools
+ 
+  initramfs-tools | 0.103ubuntu4    | trusty           | source, all
+  ==> initramfs-tools | 0.103ubuntu4.10 | trusty-updates   | source, all
+  initramfs-tools | 0.122ubuntu8    | xenial           | source, all
+  initramfs-tools | 0.122ubuntu8.11 | xenial-updates   | source, all
+  initramfs-tools | 0.125ubuntu12   | artful           | source, all
+  initramfs-tools | 0.125ubuntu12.1 | artful-updates   | source, all
+  initramfs-tools | 0.130ubuntu3    | bionic           | source, all
+  initramfs-tools | 0.130ubuntu6    | cosmic           | source, all

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1771557

Title:
  NVMe boot drives not supported - failing in generating initramfs

Status in initramfs-tools:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  In Progress
Status in initramfs-tools source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  When creating the initramfs image, mkinitramfs has multiple options on
  how to include modules. The default (and most common) one is the
  "MODULES=most", which includes the majority of filesystem modules and
  all the block device drivers. One other option is "MODULES=dep", which
  tries to descend in the sysfs hierarchy and guess modules to add, with
  the goal of reduce the size of initramfs.

  For the MODULES=dep case, the initramfs-tools hook-functions script
  cannot translate nvmeXnYpZ to nvmeXnY block device, so it's failing in
  the sysfs lookup, so it does not build the initram disk.

  Upstream solution is composed of at least 2 patches (it's a series,
  but the 2 below are really the needed ones):

  commit 3cb744c9
  Author: Ben Hutchings <ben at decadent.org.uk>
  hook-functions: Rewrite block device sysfs lookup to be generic

  commit 8ac52dc0
  Author: Ben Hutchings <ben at decadent.org.uk>
  hook-functions: Include modules for all components of a multi-disk device

  Instead of doing the huge backport, we added another sed substitution: currently the script has substitutions for sdX and hdX, in order to convert sda1 to sda, for example. The new substitution converts nvmeXnYpZ to nvmeXnY.
  It's less intrusive than the full backport, since this is a minimal SRU to Trusty only.

  [Test Case]
  1. Install Trusty with rootfs in a multi-disk(md) array composed of two nvme partitions - in my tests, I've used a RAID1.

  (lsblk output of my test env:

  nvme0n1     259:0    0    10G  0 disk
  └─nvme0n1p1 259:1    0    10G  0 part
    └─md0       9:0    0    10G  0 raid1 /
  nvme1n1     259:2    0    10G  0 disk
  └─nvme1n1p1 259:3    0    10G  0 part
    └─md0       9:0    0    10G  0 raid1 /
  )

  2. Once system is booted, modify the "/etc/initramfs-
  tools/initramfs.conf", replacing "MODULES=most" to "MODULES=dep".

  3. Update your initramfs by running something like:
  "update-initramfs -u -k <your kernel version>"

  The initramfs creating procedure will fail, unless the patch from this
  LP is present.

  [Regression Potential]
  If the sed expression was somewhat broken, we could have an issue generating initiramfs when MODULES is set to "dep", even for generic block devices (like regular HDDs).

  [Other Info]
  * This issue is based on Debian bug #785147: 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147

  * Only Trusty is affected, Xenial and late contains the full fix as
  mentioned above :

  $ git describe --contains  8ac52dc0
  v0.121_rc1~11

  $ git describe --contains 3cb744c9
  v0.121_rc1~11

  $ rmadison initramfs-tools

   initramfs-tools | 0.103ubuntu4    | trusty           | source, all
   ==> initramfs-tools | 0.103ubuntu4.10 | trusty-updates   | source, all
   initramfs-tools | 0.122ubuntu8    | xenial           | source, all
   initramfs-tools | 0.122ubuntu8.11 | xenial-updates   | source, all
   initramfs-tools | 0.125ubuntu12   | artful           | source, all
   initramfs-tools | 0.125ubuntu12.1 | artful-updates   | source, all
   initramfs-tools | 0.130ubuntu3    | bionic           | source, all
   initramfs-tools | 0.130ubuntu6    | cosmic           | source, all

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/1771557/+subscriptions



More information about the foundations-bugs mailing list