[Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings

[Robie Basak]

12:26 <slangasek> can I get expedited SRU review of the above systemd
SRU?  It's thought to address an emergent regression introduced by
changes in NVME support in the kernel, and blocks being able to run
MAAS-based CI against machines with NVME

12:26 <slangasek> there's an existing SRU in xenial-proposed which
hasn't been verified; we should just stack them

12:28 <sil2100> I could, but I am but a newb so someone would anyone
have to double-check before I can approve it

12:28 <sil2100> Since bdmurray said I still need to do some coordinated
reviews for now

12:31 <sil2100> slangasek: are all those patches present in systemd
323-10 from zesty? Or is that one not affected?

12:35 <rbasak> Is rharper happy to have the aging clock and verification
reset?

12:41 <rbasak> slangasek: I'm not convinced about the reason for the
urgency here. It looks like NVMe support was added in an SRU in
November, and was done wrong. So surely we need to take more time and
care this time, not less?

12:42 <rbasak> How long has this had time to bake in Zesty? It's not
marked Fix Released yet.

12:47 <slangasek> rbasak: the NVME support was added in the kernel
publication cycle that released to -updates at the beginning of this
year

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1647485

Title:
  NVMe symlinks broken by devices with spaces in model or serial strings

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Trusty:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in systemd source package in Yakkety:
  Confirmed
Status in systemd source package in Zesty:
  Confirmed
Status in systemd package in Debian:
  Unknown

Bug description:
  [Impact]

  After including the patch from bug 1642903, NVMe devices that include spaces in their model or serial strings result in incorrect symlinks, e.g. if the model string is "XYZ Corp NVMe drive" then instead of creating:
  /dev/disk/by-id/nvme-XYZ Corp NVMe drive_SERIAL -> ../../nvme0n1
  it creates:
  /dev/disk/by-id/nvme-XYZ -> ../../nvme0n1
  /dev/Corp -> nvme0n1
  /dev/NVMe -> nvme0n1
  /dev/drive_SERIAL -> nvme0n1

  This is because of the way udev handles the SYMLINK value strings; by
  default, it does not do any whitespace replacement.  To enable
  whitespace replacement of a symlink value, the rule must also include
  OPTIONS+="string_escape=replace".  This is done for 'md' and 'dm'
  devices in their rules.  However, there are no rules that actually
  want to specify multiple symlinks, and defaulting to not replacing
  whitespace makes no sense; instead, the default should be to replace
  all whitespace in each symlink value, unless the rule explicitly
  specifies OPTIONS+="string_escape=none".

  [Test Case]

  This assumes using udev with the patch from bug 1642903.

  Without this patch, when using a NVMe drive that contains spaces in
  its model and/or serial strings, check the /dev/disk/by-id/ directory.
  It should contain a partially-correct symlink to the NVMe drive, with
  the name up to the first space.  All following space-separated parts
  of the mode/serial string should have symlinks in the /dev/ directory.
  This is the incorrect behavior.

  With this patch, check the /dev/disk/by-id/ directory.  It should
  contain a fully-correct symlink to the NVMe drive, and no part of the
  drive's model/serial number string should be a link in the /dev
  directory.

  An example of the correct/incorrect naming is in the Impact section.

  There should be no other changes to any of the symlinks under /dev
  before and after this patch.  Typical locations for symlinks are
  /dev/, /dev/disk/by-name/, /dev/disk/by-id/, /dev/disk/by-uuid/,
  /dev/disk/by-label/

  [Regression Potential]

  Errors in udev rules can lead to an unbootable or otherwise completely
  broken system if they unintentionally break or clobber existing
  /dev/disks/ symlinks.

  [Other Info]

  This is also tracked with upstream systemd (udev) bug 4833:
  https://github.com/systemd/systemd/issues/4833

  Also note, this can be worked around in individual rules ONLY (i.e.
  not fixed for all rules) by appending OPTIONS+="string_escape=replace"
  to each of the NVMe rules with SYMLINK+="..." assignment, e.g.:

  KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*",
  ENV{ID_SERIAL_SHORT}=="?*",
  ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk
  /by-id/nvme-$env{ID_SERIAL}", OPTIONS+="string_escape=replace"

  Related bugs:
   * bug 1642903: introduce disk/by-id (model_serial) symlinks for NVMe drives
   * bug 1651602: NVMe driver regression for non-smp/1-cpu systems
   * bug 1649635: export nvme drive model/serial strings via sysfs (trusty)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647485/+subscriptions