Note: the workaround patch from comment 17 *will not* conflict with
whatever fix is implemented upstream. The patch changes *only* the NVMe
rules to force whitespace replacement. If upstream changes the default
behavior, to replace whitespace, then this workaround patch becomes
redundant/unneeded, but it will not conflict.
The issue is the behavior of udev for SYMLINK values, depending on the
"string_escape" option setting for each SYMLINK rule. There are 3
possible settings, 1) unset (the default), 2) "none", and 3) "replace".
As expected, when set to "none", udev does not replace any characters
(neither whitespace nor any other characters) in the SYMLINK value; and
when set to "replace", udev replaces all whitespace, as well as invalid
characters, with underscores. The default behavior (when unset) is what
may change upstream - currently, it replaces all invalid characters but
*does not* replace whitespace. This is a problem for SYMLINK values,
since the SYMLINK string is a whitespace-separated list of strings. No
rules that are included with udev currently want this behavior, but
there may be some custom udev rules that expect it. The NVMe rules do
not expect or want it. For reference, the NVMe udev rules are:
SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}"
SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}-part%n"
these rules expect one, and only one, symlink to be created for each new
NVMe drive (or NVMe partition) that is detected. Under no circumstances
do these rules ever want multiple symlinks created for a single
execution of the rule. So this workaround, to set
"string_escape=replace" only for these 2 NVMe rules, is appropriate. If
the default behavior upstream is changed later, so that any whitespace
in the ID_SERIAL string is replaced when "string_escape" is unset, then
the behavior of udev for these specific rules will be identical whether
"string_escape" is unset or set to "replace", and so at that point this
workaround patch can be left or reverted, as the udev behavior will be
identical either way. Until then, this workaround patch is needed for
the correct behavior.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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 systemd:
New
Status in systemd package in Ubuntu:
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"
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647485/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
