This is openSUSE-SU-2017:1844-1.

I can confirm that I was bitten by this same bug, which left me locked out completely. Even though there is an easy (once you know how) workaround, I would raise the priority/severity.

I think this might be related to Tumbleweed bug
https://bugzilla.suse.com/show_bug.cgi?id=1047598

For your information, the format should be
  /dev/disk/by-id/nvme-${model}_${serial}-part?
where any spaces in model (or serial) must be replace by underscores and the final question mark obviously needs to be the right part.

You can probably get both via
  udevadm info --query=all --name=/dev/nvme0
use the resulting MAJOR and MINOR values to get the model and serial:
  cat /sys/dev/char/${major}:${minor}/model
  cat /sys/dev/char/${major}:${minor}/serial
Alternatively, you can use a new smartctl -a /dev/nvme0

Raising priority. This has been synced from SUSE-SU-2017:1773-1. So also SLES12-SP2 is affected.

(In reply to Mischa Salle from comment #2)
I think it's easier to use the new EUI-64/128 WWID symlink.

In my case it would have been editing:
> /dev/disk/by-id/nvme-20025386261008f3a-part5
to
> /dev/disk/by-id/nvme-eui.0025386261008f3a-part5

The first '2' is the type of ID and means EUI-64 here.
So that "2" became "-eui.".

Add me to the list.

I have managed to boot from the rescue system (Leap 42.2 installer USB stick, boot using "More..." and then "Rescue system").

I made a backup of the /boot folder to an USB stick. Use blkid to identify which partition to mount. It's one without TYPE="crypto_LUKS"

Now I have the initrd images on a laptop.

I know that the entries are in /etc/crypttab but how do I modify this file? How can I unpack the initrd image, change a file and pack it again?

(In reply to Aaron Digulla from comment #5)
> I know that the entries are in /etc/crypttab but how do I modify this file?
> How can I unpack the initrd image, change a file and pack it again?

See https://bugzilla.suse.com/show_bug.cgi?id=1047598#c7 for a workaround.

Would it be possible to check that the disks exist which are listed in /etc/crypttab?

The first check should be when running mkinitrd. That wouldn't have caught this problem early but it would catch similar problems.

The second check should be when the ramdisk tries to mount the devices. If the links aren't there, fail with a good error message (and stop dracut from printing 100 "Warning: dracut-initqueue timeout" messages while I try to fix the problem).

And a tiny script to chroot (with the mount --bind). If you forget the three mount --bind, then chroot will fail with "/bin/sh: No such file or directory" which is confusing.

folding into earlier bug

*** This bug has been marked as a duplicate of bug 1047598 ***

Created attachment 732968 [details]
restore old nvme by-id symlinks

Sebastian, could you try the patch from comment #9 and check if both following symlinks are present after rebooting ?

  /dev/disk/by-id/nvme-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887-part5
  /dev/disk/by-id/nvme-20025386261008f3a-part5

Thanks

I've patched /usr/lib/udev/rules.d/60-persistent-storage.rules and regenerated the initrd. After a reboot, only the broken

  /dev/disk/by-id/-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887

symlinks were gone. The link /dev/disk/by-id/nvme-20025386261008f3a-part5 isn't there.

> $ ls -l /dev/disk/by-id/* | grep nvme | grep -o "\/dev\/.*"
> /dev/disk/by-id/nvme-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887 -> ../../nvme0n1
> /dev/disk/by-id/nvme-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887-part1 -> ../../nvme0n1p1
> /dev/disk/by-id/nvme-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887-part2 -> ../../nvme0n1p2
> /dev/disk/by-id/nvme-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887-part5 -> ../../nvme0n1p5
> /dev/disk/by-id/nvme-SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887-part6 -> ../../nvme0n1p6
> /dev/disk/by-id/nvme-eui.0025386261008f3a -> ../../nvme0n1
> /dev/disk/by-id/nvme-eui.0025386261008f3a-part1 -> ../../nvme0n1p1
> /dev/disk/by-id/nvme-eui.0025386261008f3a-part2 -> ../../nvme0n1p2
> /dev/disk/by-id/nvme-eui.0025386261008f3a-part5 -> ../../nvme0n1p5
> /dev/disk/by-id/nvme-eui.0025386261008f3a-part6 -> ../../nvme0n1p6

Any chance I can have access to your system ? Thanks.

Ok after debugging this on Sebastian's setup, I'm attaching a new patch which seems to work.

Thanks Sebastian for your help.

Created attachment 733098 [details]
patch that restores the old by-id symlinks for NVME devices

Thomas, could you double check the last patch before we merge it on the affected branches (v228, v233 at least) ? Thanks.

Aaron, could you please give the second patch a try ?

(In reply to Franck Bui from comment #15)
> Thomas, could you double check the last patch before we merge it on the
> affected branches (v228, v233 at least) ? Thanks.

Hm, you are not using the --export parameter to scsi_id to export the environment variables for an nvme device, but create your own one (ID_NVME_SERIAL_COMPAT) instead.
What was the problem using --export? Wouldn't be:

KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $devnode"

sufficient?
At least this would fit better into the scheme used for the other disk types.

(In reply to Thomas Blume from comment #17)
> (In reply to Franck Bui from comment #15)
> > Thomas, could you double check the last patch before we merge it on the
> > affected branches (v228, v233 at least) ? Thanks.
> 
> Hm, you are not using the --export parameter to scsi_id to export the
> environment variables for an nvme device, but create your own one
> (ID_NVME_SERIAL_COMPAT) instead.
> What was the problem using --export? Wouldn't be:
> 
> KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*",
> IMPORT{program}="scsi_id --export --whitelisted -d $devnode"
> 
> sufficient?
> At least this would fit better into the scheme used for the other disk types.

I'll check. The problem was that /sys/bus/nvme doesn't exist I guess.

(In reply to Thomas Blume from comment #17)
> What was the problem using --export? Wouldn't be:
> 
> KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*",
> IMPORT{program}="scsi_id --export --whitelisted -d $devnode"
> 
> sufficient?
> At least this would fit better into the scheme used for the other disk types.

That doesn't work it picks up "SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887" instead of "20025386261008f3a". And that link already exists.

The rule in line 23 shouldn't set the environment variable ID_SERIAL otherwise.

(In reply to Sebastian Parschauer from comment #19)
> (In reply to Thomas Blume from comment #17)
> > What was the problem using --export? Wouldn't be:
> > 
> > KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*",
> > IMPORT{program}="scsi_id --export --whitelisted -d $devnode"
> > 
> > sufficient?
> > At least this would fit better into the scheme used for the other disk types.
> 
> That doesn't work it picks up "SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887"
> instead of "20025386261008f3a". And that link already exists.

Actually scsi_id --export creates multiple environment variables.
ID_SERIAL ist only one of them and on your machine apparently "SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887". 
"20025386261008f3a" must be stored in another variable and this is the one that should be used in the rule.

However, in my test, calling scsi_id without --export outputs the value of ID_SERIAL. That doesn't seem to be the case on your machine.

(In reply to Thomas Blume from comment #22)
> Actually scsi_id --export creates multiple environment variables.
> ID_SERIAL ist only one of them and on your machine apparently
> "SM951_NVMe_SAMSUNG_256GB__S27ENYAH202887". 
> "20025386261008f3a" must be stored in another variable and this is the one
> that should be used in the rule.
> 
> However, in my test, calling scsi_id without --export outputs the value of
> ID_SERIAL. That doesn't seem to be the case on your machine.

It is the case on my machine:

# /usr/lib/udev/scsi_id --whitelisted -d /dev/nvme0n1
20025386261008f3a

/usr/lib/udev/scsi_id --export --whitelisted -d /dev/nvme0n1
ID_SCSI=1
ID_VENDOR=NVMe
ID_VENDOR_ENC=NVMe\x20\x20\x20\x20
ID_MODEL=SM951_NVMe_SAMSU
ID_MODEL_ENC=SM951\x20NVMe\x20SAMSU
ID_REVISION=4D0Q
ID_TYPE=disk
ID_SERIAL=20025386261008f3a
ID_SERIAL_COMPAT=
ID_SERIAL_SHORT=0025386261008f3a
ID_SCSI_SERIAL=      S27ENYAH202887

This is how line 23 sets something different for ID_SERIAL:
> KERNEL=="nvme*[0-9]n*[0-9]p*[0-9]", ENV{DEVTYPE}=="partition", ATTRS{model}=="?*", ENV{ID_SERIAL_SHORT}=="?*", ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}-part%n"

To summarize: There are two bugs in the current compat rule for NVMe:

1. /sys/bus/nvme is assumed which doesn't exist
2. ID_SERIAL is used which is set to something different in line 23 of the persistent storage rules. So not getting the actual ID_SERIAL.

(In reply to Sebastian Parschauer from comment #23)
> This is how line 23 sets something different for ID_SERIAL:
> > KERNEL=="nvme*[0-9]n*[0-9]p*[0-9]", ENV{DEVTYPE}=="partition", ATTRS{model}=="?*", ENV{ID_SERIAL_SHORT}=="?*", ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}-part%n"

Indeed, overwriting ID_SERIAL with ID_SERIAL_SHORT looks really broken.
Not sure what would be the use of this.

(In reply to Thomas Blume from comment #17)
> (In reply to Franck Bui from comment #15)
> > Thomas, could you double check the last patch before we merge it on the
> > affected branches (v228, v233 at least) ? Thanks.
> 
> Hm, you are not using the --export parameter to scsi_id to export the
> environment variables for an nvme device, but create your own one
> (ID_NVME_SERIAL_COMPAT) instead.
> What was the problem using --export? Wouldn't be:
> 
> KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*",
> IMPORT{program}="scsi_id --export --whitelisted -d $devnode"
> 
> sufficient?
> At least this would fit better into the scheme used for the other disk types.

As you already noted "--export" defines several env vars and I think it's better if we avoid to overwrite those from the compat rule that might have been already defined by the "upstream" rule.

Without "--export", scsi_id outputs the serial number we're interested in, i.e. the one used to create the old symlink.

Hope that makes sense.

Let's re-open this bug as it's different from bug 1047598 which is about the absence of /usr/lib/udev/compat-symlink-generation in the installation system.

(In reply to Sebastian Parschauer from comment #24)
> To summarize: There are two bugs in the current compat rule for NVMe:
> 
> 1. /sys/bus/nvme is assumed which doesn't exist

Hmm, I don't see where this one comes from.

> 2. ID_SERIAL is used which is set to something different in line 23 of the
> persistent storage rules. So not getting the actual ID_SERIAL.

I think this is addressed by the patch, no ?

(In reply to Franck Bui from comment #28)
> > 1. /sys/bus/nvme is assumed which doesn't exist
> 
> Hmm, I don't see where this one comes from.

I mean the 'ENV{UD_BUS}="nvme"' in
> KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $tempnode", ENV{ID_BUS}="nvme"
 
> > 2. ID_SERIAL is used which is set to something different in line 23 of the
> > persistent storage rules. So not getting the actual ID_SERIAL.
> 
> I think this is addressed by the patch, no ?

Yes, both these issues are addressed by your patch. I just had to explain everything for Thomas again why/how your patch fixes this.

(In reply to Sebastian Parschauer from comment #30)
> (In reply to Franck Bui from comment #28)
> > > 1. /sys/bus/nvme is assumed which doesn't exist
> > 
> > Hmm, I don't see where this one comes from.
> 
> I mean the 'ENV{UD_BUS}="nvme"' in
> > KERNEL=="nvme*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $tempnode", ENV{ID_BUS}="nvme"
>  
> > > 2. ID_SERIAL is used which is set to something different in line 23 of the
> > > persistent storage rules. So not getting the actual ID_SERIAL.
> > 
> > I think this is addressed by the patch, no ?
> 
> Yes, both these issues are addressed by your patch. I just had to explain
> everything for Thomas again why/how your patch fixes this.

Hm, the patch makes sure that ID_SERIAL is used, but this looks like a workaround.
Shouldn't we rather find out why ID_SERIAL gets overwritten by ID_SERIAL_SHORT? I don't see any reason therefore in the initial upstream request at: https://github.com/systemd/systemd/issues/1453
Why should nvme device treated differently from other block devices (e.g. scsi or cciss)?
Hannes, according to the header of 60-persistent-storage.rules you are the creator of the Linux persistent device names scheme. Could you give a statement about the usage of ID_SERIAL_SHORT versus ID_SERIAL?

(In reply to Thomas Blume from comment #34)
> Shouldn't we rather find out why ID_SERIAL gets overwritten by
> ID_SERIAL_SHORT? I don't see any reason therefore in the initial upstream
> request at: https://github.com/systemd/systemd/issues/1453
> Why should nvme device treated differently from other block devices (e.g.
> scsi or cciss)?

According to https://github.com/systemd/systemd/issues/1453#issuecomment-145231313, no SCSI is involved and the kernel is supposed to export the relevant bit in sysfs and systemd should use them.

(In reply to Franck Bui from comment #35)
> (In reply to Thomas Blume from comment #34)
> > Shouldn't we rather find out why ID_SERIAL gets overwritten by
> > ID_SERIAL_SHORT? I don't see any reason therefore in the initial upstream
> > request at: https://github.com/systemd/systemd/issues/1453
> > Why should nvme device treated differently from other block devices (e.g.
> > scsi or cciss)?
> 
> According to
> https://github.com/systemd/systemd/issues/1453#issuecomment-145231313, no
> SCSI is involved and the kernel is supposed to export the relevant bit in
> sysfs and systemd should use them.

Exporting the information via sysfs doesn't seem to be implemtend in the kernel yet. 
But thanks for pointing this out, in this light, scsi_id is probably not the right tool to extract the device information for nvme disks.
I've checked on an orthos machine and saw this:

cage:/sys/block/nvme0n1/:[127]# /lib/udev/scsi_id --export --whitelisted -d /dev/nvme0n1 
ID_SCSI=1
ID_VENDOR=NVMe
ID_VENDOR_ENC=NVMe\x20\x20\x20\x20
ID_MODEL=Linux
ID_MODEL_ENC=Linux
ID_REVISION=73-5
ID_TYPE=disk
ID_SERIAL=SNVMe_Linux
ID_SERIAL_COMPAT=
ID_SERIAL_SHORT=
ID_SCSI_SERIAL=54893f3e68f807f6

So, neither ID_SERIAL or ID_SERIAL_SHORT seem to be the best to provide an uniqe identifier. Questions is whether ID_SCSI_SERIAL is present on all nvme devices.

Running scsi_id without --export seems to be worse:

cage:~/:[0]# /lib/udev/scsi_id --whitelisted -d /dev/nvme0n1 
SNVMe    Linux
cage:~/:[0]#

(In reply to Thomas Blume from comment #36)
> cage:/sys/block/nvme0n1/:[127]# /lib/udev/scsi_id --export --whitelisted -d
> /dev/nvme0n1 
> ID_SCSI=1
> ID_VENDOR=NVMe
> ID_VENDOR_ENC=NVMe\x20\x20\x20\x20
> ID_MODEL=Linux
> ID_MODEL_ENC=Linux
> ID_REVISION=73-5
> ID_TYPE=disk
> ID_SERIAL=SNVMe_Linux
> ID_SERIAL_COMPAT=
> ID_SERIAL_SHORT=
> ID_SCSI_SERIAL=54893f3e68f807f6
> 
> So, neither ID_SERIAL or ID_SERIAL_SHORT seem to be the best to provide an
> uniqe identifier. Questions is whether ID_SCSI_SERIAL is present on all nvme
> devices.

Please ignore system "cage". This is "NVMe over Fabrics" which is in development. So there is no physical NVMe SSD in this system.

> systool -vc nvme

shows the "rdma" transport.

(In reply to Thomas Blume from comment #36)
> 
> So, neither ID_SERIAL or ID_SERIAL_SHORT seem to be the best to provide an
> uniqe identifier. Questions is whether ID_SCSI_SERIAL is present on all nvme
> devices.

I'm not sure to follow you.

The point is not to provide the best by-id symlink for NVME devices but it's to restore the old one.

And the old one was basically given by ID_SERIAL from "scsi_id --export". This can also retrieve by "scsi_id --replace-whitespace" and that's what the patch is using.

(In reply to Thomas Blume from comment #37)
> Running scsi_id without --export seems to be worse:
> 
> cage:~/:[0]# /lib/udev/scsi_id --whitelisted -d /dev/nvme0n1 
> SNVMe    Linux

This command returns the same value as the content of ID_SERIAL that "--export" returns except that you need to use "--replace-whitespace" as well.

I'd like to try the patch but I need more instructions how. Can I do that on the running system? If so, what commands do I need to run after patching the file?

That said, here is my output of scsi_id:

ID_SCSI=1
ID_VENDOR=NVMe
ID_VENDOR_ENC=NVMe\x20\x20\x20\x20
ID_MODEL=Samsung_SSD_960
ID_MODEL_ENC=Samsung\x20SSD\x20960\x20
ID_REVISION=CXE7
ID_TYPE=disk
ID_SERIAL=20025385171b02e7b
ID_SERIAL_COMPAT=
ID_SERIAL_SHORT=0025385171b02e7b
ID_SCSI_SERIAL=S3EUNX0J105448H

Something that I noticed: Some links in /dev/disk/by-id/ are missing the leading "2": nvme-eui.0025385171b02e7b. That's confusing.

Also, please patch the boot scripts. The script should read /etc/crypttab and check whether the devices in there actually exist. If one doesn't exist, I'd like a menu:

"Device .... not found. Please select one from the list below:

1. ...
2. ...
"

I think the output of "lsblk" would be easier to use to pick a device than the device IDs.

(In reply to Aaron Digulla from comment #59)
> I'd like to try the patch but I need more instructions how. Can I do that on
> the running system? If so, what commands do I need to run after patching the
> file?

Yes, you can patch the file on a running system.

Once done you can run "mkinitrd" to include the patched rule file in initrd.

Then you can reboot and see if the old symlinks in /dev/by-id are restored.

Thanks.

@Mischa: Can you please also provide the output of the following command:

> /usr/lib/udev/scsi_id --export --whitelisted -d /dev/nvme0n1

? TIA

(In reply to Sebastian Parschauer from comment #61)
> @Mischa: Can you please also provide the output of the following command:
> 
> > /usr/lib/udev/scsi_id --export --whitelisted -d /dev/nvme0n1
> 
> ? TIA

sure, hereby:

ID_SCSI=1
ID_VENDOR=NVMe
ID_VENDOR_ENC=NVMe\x20\x20\x20\x20
ID_MODEL=INTEL_SSDPEKKW01
ID_MODEL_ENC=INTEL\x20SSDPEKKW01
ID_REVISION=109C
ID_TYPE=disk
ID_SERIAL=20000000001000000e4d25c96229a4d01
ID_SERIAL_COMPAT=
ID_SERIAL_SHORT=0000000001000000e4d25c96229a4d01
ID_SCSI_SERIAL=BTPY65320H8F1P0H

(In reply to Mischa Salle from comment #63)
Thanks, your Intel NVMe device uses an EUI-128 ID for ID_SERIAL. There are other Intel NVMe devices which use a SCSI name string instead.

(In reply to Sebastian Parschauer from comment #64)
> (In reply to Mischa Salle from comment #63)
> Thanks, your Intel NVMe device uses an EUI-128 ID for ID_SERIAL. There are
> other Intel NVMe devices which use a SCSI name string instead.

Hi,

just for your information: originally my LEAP installation was using
nvme-20000000001000000e4d25c96229a4d01-part2
as ID, and did *not* have the -INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2 ID (i.e. the ones without nvme). With the update, the original one disappeared, and I now have
  -INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2
  nvme-eui.0000000001000000e4d25c96229a4d01-part2
  nvme-INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2
missing the original one. I've change my crypttab to use the last one (nvme-INTEL...), but that's of course up to taste.
It's fine to add more IDs, just not to remove the existing ones (-;

By the way, any thoughts on my remark about making a backup of the initrd?

(In reply to Mischa Salle from comment #66)
> just for your information: originally my LEAP installation was using
> nvme-20000000001000000e4d25c96229a4d01-part2
> as ID, and did *not* have the -INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2 ID
> (i.e. the ones without nvme). With the update, the original one disappeared,
> and I now have
>   -INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2
>   nvme-eui.0000000001000000e4d25c96229a4d01-part2
>   nvme-INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2
> missing the original one. I've change my crypttab to use the last one
> (nvme-INTEL...), but that's of course up to taste.
> It's fine to add more IDs, just not to remove the existing ones (-;

The link "-INTEL_SSDPEKKW010T7_BTPY65320H8F1P0H-part2" is broken. It was ment to provide the nvme-20000000001000000e4d25c96229a4d01-part2 compatibility symlink with scsi_id but that doesn't work as the compat rules conflict with the upstream rules. See the attached patch.

> By the way, any thoughts on my remark about making a backup of the initrd?

That would be a feature request (https://features.opensuse.org/).

(In reply to Sebastian Parschauer from comment #67)
> (In reply to Mischa Salle from comment #66)
>
> > By the way, any thoughts on my remark about making a backup of the initrd?
> 
> That would be a feature request (https://features.opensuse.org/).

Good point, hereby https://features.opensuse.org/323795

*** Bug 1050299 has been marked as a duplicate of this bug. ***

While discussing all this, of course you are aware that scsi_id is about to be deprecated (and removed) upstream, right?

We already _do_ provide complete alternative functionality via the sg3_utils rules, so we can well live without scsi_id here.

And for NVMe we should be providing compability symlinks to keep existing setups intact; but there's no need to use scsi_id here, sysfs should provide all the required information. If not we should be making it so.

(In reply to Hannes Reinecke from comment #78)
> 
> We already _do_ provide complete alternative functionality via the sg3_utils
> rules, so we can well live without scsi_id here.
> 

So why not submitting a patch to upstream that removes the SCSI rules from 60-persistent-storage.rules and explaining that sg3_utils has taken over ? 

BTW scsi_id is also used by cciss devices. Can sg3_utils take care of them ?

Otherwise we would need to change the relevant rules to replace scsi_id with a tool provided by sg3_utils. That would make udev depend on sg3_utils but since the number of deps of the later is low that wouldn't be a problem I think.

Also are the rules/tools shipped by sg3_utils also deals with those compat symlinks ?

  https://github.com/openSUSE/systemd/commit/f2eb26c05621748795c69122530b8800d0507104

> And for NVMe we should be providing compability symlinks to keep existing
> setups intact; but there's no need to use scsi_id here, sysfs should provide
> all the required information. If not we should be making it so.

Apparently this is the case, please see the previous comments.

You can take a look on blueshark4 machine.

(In reply to Franck Bui from comment #81)
> (In reply to Hannes Reinecke from comment #78)
> > 
> > We already _do_ provide complete alternative functionality via the sg3_utils
> > rules, so we can well live without scsi_id here.
> > 
> 
> So why not submitting a patch to upstream that removes the SCSI rules from
> 60-persistent-storage.rules and explaining that sg3_utils has taken over ? 
> 
> BTW scsi_id is also used by cciss devices. Can sg3_utils take care of them ?
> 
Yes. scsi_id and sg3_utils both use the same ioctl, so there no difference to the driver.

> Otherwise we would need to change the relevant rules to replace scsi_id with
> a tool provided by sg3_utils. That would make udev depend on sg3_utils but
> since the number of deps of the later is low that wouldn't be a problem I
> think.
> 
> Also are the rules/tools shipped by sg3_utils also deals with those compat
> symlinks ?
> 
>  
> https://github.com/openSUSE/systemd/commit/
> f2eb26c05621748795c69122530b8800d0507104
> 
It should be, but I'll take a look.

I discussed with Thomas and we came to the conclusion that it's safer and quicker for now to restore the old NVMe symlinks via scsi_id like it was done before.

So we'll have more time to implement and test the replacement of scsi_id with the use of the sysfs attributes.

(In reply to Hannes Reinecke from comment #84)
> (In reply to Franck Bui from comment #81)
> > 
> > BTW scsi_id is also used by cciss devices. Can sg3_utils take care of them ?
> > 
> Yes. scsi_id and sg3_utils both use the same ioctl, so there no difference
> to the driver.
> 

Could you let us know when you'll take over the cciss devices so we can suggest to upstream the removal of scsi_id since cciss seems to be the last user of scsi_id ?

*** Bug 1049359 has been marked as a duplicate of this bug. ***

The fix posted in comment #14 has been merged in v228 and v234 so I think this  bug can be closed.

However the use of scsi_id for generating the compat symlinks for NVMe devices still needs to be replaced. I think Thomas will work on that.

Thomas, could you give the relevant links in case you'll open a new issue to address this ? Thanks.

*** Bug 1051741 has been marked as a duplicate of this bug. ***

SUSE-RU-2017:2172-1: An update that has two recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1048679,874665
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 12-SP3 (src):    systemd-228-150.12.4
SUSE Linux Enterprise Software Development Kit 12-SP2 (src):    systemd-228-150.12.4
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    systemd-228-150.12.4
SUSE Linux Enterprise Server 12-SP3 (src):    systemd-228-150.12.4
SUSE Linux Enterprise Server 12-SP2 (src):    systemd-228-150.12.4
SUSE Linux Enterprise Desktop 12-SP3 (src):    systemd-228-150.12.4
SUSE Linux Enterprise Desktop 12-SP2 (src):    systemd-228-150.12.4
SUSE Container as a Service Platform ALL (src):    systemd-228-150.12.4
OpenStack Cloud Magnum Orchestration 7 (src):    systemd-228-150.12.4

openSUSE-RU-2017:2191-1: An update that has two recommended fixes can now be installed.

Category: recommended (important)
Bug References: 1048679,874665
CVE References: 
Sources used:
openSUSE Leap 42.3 (src):    systemd-228-32.2, systemd-mini-228-32.2
openSUSE Leap 42.2 (src):    systemd-228-25.12.1, systemd-mini-228-25.12.1

*** Bug 1051354 has been marked as a duplicate of this bug. ***

SUSE-SU-2017:2470-1: An update that solves 18 vulnerabilities and has 46 fixes is now available.

Category: security (important)
Bug References: 1004995,1009745,1014471,1017420,1019637,1026825,1027079,1027688,1027908,1028281,1028723,1029523,1031756,1032706,1033236,1035062,1036659,1038132,1038444,1038984,1042392,1043218,1043333,1044095,1044107,1044175,1044840,1045384,1045735,1045987,1046268,1046417,1046659,1046853,1046858,1047008,1047236,1047240,1047310,1047379,1047785,1047964,1047965,1048315,1048483,1048605,1048679,1048715,1049344,1050396,1050484,1051626,1051643,1051644,1052030,1052759,1053409,874665,902364,938657,944903,954661,960820,963041
CVE References: CVE-2013-7459,CVE-2016-9063,CVE-2017-1000100,CVE-2017-1000101,CVE-2017-10684,CVE-2017-10685,CVE-2017-11112,CVE-2017-11113,CVE-2017-3308,CVE-2017-3309,CVE-2017-3453,CVE-2017-3456,CVE-2017-3464,CVE-2017-7435,CVE-2017-7436,CVE-2017-8872,CVE-2017-9233,CVE-2017-9269
Sources used:
SUSE Container as a Service Platform ALL (src):    caasp-container-manifests-0.0.0+git_r155_93e40ab-2.3.3, container-feeder-0.0.0+20170901.git_r55_17ecbd3-2.3.3, sles12-mariadb-docker-image-1.1.0-2.3.10, sles12-pause-docker-image-1.1.0-2.3.11, sles12-pv-recycler-node-docker-image-1.1.0-2.3.10, sles12-salt-api-docker-image-1.1.0-2.3.9, sles12-salt-master-docker-image-1.1.0-4.3.10, sles12-salt-minion-docker-image-1.1.0-2.3.8, sles12-velum-docker-image-1.1.0-4.3.9