[Bug 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings
Dan Streetman
dan.streetman+launchpad at canonical.com
Wed Jan 25 14:42:36 UTC 2017
So the only new autopkgtest failures are:
> Regression in autopkgtest for umockdev (armhf): test log
this fails with:
ERROR:tests/test-umockdev-record.c:706:t_system_single: assertion failed (_tmp10_ == ""): ("Cannot access device /dev/loop0: No such file or directory\n" == "")
this is the first test failure on trusty/armhf:
http://autopkgtest.ubuntu.com/packages/umockdev/trusty/armhf
however, it's failed for xenial, yakkety, and zesty on armhf for a long time, with the same failure:
http://autopkgtest.ubuntu.com/packages/umockdev/xenial/armhf
http://autopkgtest.ubuntu.com/packages/umockdev/yakkety/armhf
http://autopkgtest.ubuntu.com/packages/umockdev/zesty/armhf
so it seems like whatever was causing the failures for X/Y/Z on armhf is
now also causing the failure for trusty on armhf; I think it's unlikely
a systemd change caused the failure.
> Regression in autopkgtest for upstart (amd64): test log
this fails with:
test_state: tests/test_state.c:4048: test_upstart_with_apparmor_upgrade: Assertion `(state_from_string (json_string)) == 0' failed.
Closer looks shows it's complaining about the JSON data, the test was
expecting a comment:
(null): Detected invalid serialisation data: expected comment
test_state: tests/test_state.c:4048: test_upstart_with_apparmor_upgrade: Assertion `(state_from_string (json_string)) == 0' failed.
I can't tell why it's failing now but not before, but it's also hard to
see any relation between a systemd/udev update and upstart JSON
serialization failure.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1647485
Title:
NVMe symlinks broken by devices with spaces in model or serial strings
Status in maas-images:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Committed
Status in systemd source package in Trusty:
Confirmed
Status in systemd source package in Xenial:
Fix Released
Status in systemd source package in Yakkety:
Fix Committed
Status in systemd source package in Zesty:
Fix Committed
Status in systemd package in Debian:
New
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/maas-images/+bug/1647485/+subscriptions
More information about the foundations-bugs
mailing list