Problems getting WWID recognized

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems getting WWID recognized

Albert Chin
Hi. I am running multipath-tools 0.8.3 on Ubuntu 20.04.1. I can't get
WWIDs detected by multipathd. multipath -v4 -ll doesn't detect any
iSCSI WWIDs despite ID_SERIAL being correct according to "udevadm
info":

# udevadm info --query=all --path /sys/block/sdc | grep SERIAL
E: ID_SERIAL=3600144f0f4e106e711ff54b6b7820049
E: ID_SERIAL_SHORT=600144f0f4e106e711ff54b6b7820049

# multipath -v4 -ll 2>&1 | egrep 'sd.: serial'
Aug 24 16:00:01 | sda: serial = 00d4e61f3aa6f0ca26002b133720844a
Aug 24 16:00:01 | sdc: serial =    
Aug 24 16:00:01 | sdd: serial =    
Aug 24 16:00:01 | sdm: serial =    
Aug 24 16:00:01 | sdn: serial =    
Aug 24 16:00:01 | sdo: serial =    
...

# multipath -v4 -ll
...
Aug 24 16:02:32 | Discover device /sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/block/sdc
Aug 24 16:02:32 | sdc: dev not found in pathvec
Aug 24 16:02:32 | 8:32: dev_t not found in pathvec
Aug 24 16:02:32 | sdc: udev property ID_SERIAL whitelisted
Aug 24 16:02:32 | sdc: mask = 0x27
Aug 24 16:02:32 | sdc: dev_t = 8:32
Aug 24 16:02:32 | open '/sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/block/sdc/size'
Aug 24 16:02:32 | sdc: size = 1048576000
Aug 24 16:02:32 | sdc: vendor = OI
Aug 24 16:02:32 | sdc: product = COMSTAR
Aug 24 16:02:32 | sdc: rev = 1.0
Aug 24 16:02:32 | find_hwe: found match /OI:COMSTAR:(null)/ for 'OI:COMSTAR:1.0'
Aug 24 16:02:32 | find_hwe: found 1 hwtable matches for OI:COMSTAR:1.0
Aug 24 16:02:32 | sdc: h:b:t:l = 13:0:0:0
Aug 24 16:02:32 | sdc: tgt_node_name = iqn.2010-09.org.openindiana:02:4a7b9f0f-4777-631e-e19a-fb0b94963439
Aug 24 16:02:32 | sdc: (OI:COMSTAR) vendor/product whitelisted
Aug 24 16:02:32 | open '/sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/state'
Aug 24 16:02:32 | sdc: path state = running
Aug 24 16:02:32 | sdc: 65270 cyl, 255 heads, 63 sectors/track, start at 0
Aug 24 16:02:32 | open '/sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/vpd_pg80'
Aug 24 16:02:32 | sdc: serial =    
Aug 24 16:02:32 | sdc: detect_checker = yes (setting: multipath internal)
Aug 24 16:02:32 | failed to issue vpd inquiry for pgc9
Aug 24 16:02:32 | open '/sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/inquiry'
Aug 24 16:02:32 | open '/sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/vpd_pg83'
Aug 24 16:02:32 | sdc: path_checker = tur (setting: storage device autodetected)
Aug 24 16:02:32 | sdc: checker timeout = 30 s (setting: kernel sysfs)
Aug 24 16:02:32 | sdc: tur state = up
Aug 24 16:02:32 | Discover device /sys/devices/platform/host13/session1/target13:0:0/13:0:0:0/block/sdc/sdc1
...

Any ideas?

--
albert chin ([hidden email])

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Rafael David Tinoco-3
Are you able to inquiry VPD for the LUNs coming from the open solaris
storage server ?

Try querying the LUNs with:

$ sudo sg_vpd /dev/sda
Supported VPD pages VPD page:
  Supported VPD pages [sv]
  Unit serial number [sn]
  Device identification [di]

$ sudo sg_vpd --page=sn /dev/sda
Unit serial number VPD page:
  Unit serial number: 4C532000040912113260

OR

$ sudo sg_inq -e /dev/sda
VPD INQUIRY, page code=0x00:
   Supported VPD pages:
     0x0 Supported VPD pages
     0x80 Unit serial number
     0x83 Device identification

$ sudo sg_inq -e --page=0x80 /dev/sda
VPD INQUIRY: Unit serial number page
  Unit serial number: 4C532000040912113260

Make sure you're able to see the SCSI VPDs 0x80 and 0x83 for all
online paths (/dev/sd..). Then compare those VPDs with the ID_SERIAL
attribute for the device in question (/dev/sd..):

$ sudo sg_inq -e --page=0x80 /dev/sda
VPD INQUIRY: Unit serial number page
  Unit serial number: 4C532000040912113260

$ udevadm info -q all --path=/sys/block/sda | grep ID_SERIAL
E: ID_SERIAL=4C532000040912113260

---
Then check if ID_SERIAL is the same as the unit serial number set into
udev ID_SERIAL. It seems some paths didn't have the ID_SERIAL
correctly identified by udev (only /dev/sda had, possibly your
internal disk ?).

Aug 24 16:00:01 | sdc: serial =
Aug 24 16:00:01 | sdd: serial =
Aug 24 16:00:01 | sdm: serial =
Aug 24 16:00:01 | sdn: serial =
Aug 24 16:00:01 | sdo: serial =
--

If everything went far, check "multipath -T" for "uid_attribute" and
make sure it is set to ID_SERIAL (the udev parameter containing the
serial number for the disks).

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Albert Chin
On Wed, Aug 26, 2020 at 09:53:09AM -0300, Rafael David Tinoco wrote:
> Are you able to inquiry VPD for the LUNs coming from the open solaris
> storage server ?

Nope. Info below. So what happens if "udevadm info -q all
--path=/sys/block/sdc" shows ID_SERIAL but "sg_vpd --page=sn
/dev/sdc" does not?

> Try querying the LUNs with:
>
> $ sudo sg_vpd /dev/sda
> Supported VPD pages VPD page:
>   Supported VPD pages [sv]
>   Unit serial number [sn]
>   Device identification [di]
>
> $ sudo sg_vpd --page=sn /dev/sda
> Unit serial number VPD page:
>   Unit serial number: 4C532000040912113260

# sg_vpd /dev/sdc
Supported VPD pages VPD page:
  Supported VPD pages [sv]
  Unit serial number [sn]
  Device identification [di]
  Extended inquiry data [ei]
  Block limits (SBC) [bl]
  Logical block provisioning (SBC) [lbpv]

# sg_vpd --page=sn /dev/sdc
Unit serial number VPD page:
  Unit serial number:

> OR
>
> $ sudo sg_inq -e /dev/sda
> VPD INQUIRY, page code=0x00:
>    Supported VPD pages:
>      0x0 Supported VPD pages
>      0x80 Unit serial number
>      0x83 Device identification
>
> $ sudo sg_inq -e --page=0x80 /dev/sda
> VPD INQUIRY: Unit serial number page
>   Unit serial number: 4C532000040912113260

# sg_inq -e /dev/sdc
VPD INQUIRY, page code=0x00:
   Supported VPD pages:
     0x0        Supported VPD pages
     0x80       Unit serial number
     0x83       Device identification
     0x86       Extended INQUIRY data
     0xb0       Block limits (sbc2)
     0xb2       Logical block provisioning (sbc3)

# sg_inq -e --page=0x80 /dev/sdc
VPD INQUIRY: Unit serial number page
  Unit serial number:    

> Make sure you're able to see the SCSI VPDs 0x80 and 0x83 for all
> online paths (/dev/sd..). Then compare those VPDs with the ID_SERIAL
> attribute for the device in question (/dev/sd..):
>
> $ sudo sg_inq -e --page=0x80 /dev/sda
> VPD INQUIRY: Unit serial number page
>   Unit serial number: 4C532000040912113260
>
> $ udevadm info -q all --path=/sys/block/sda | grep ID_SERIAL
> E: ID_SERIAL=4C532000040912113260

# udevadm info -q all --path=/sys/block/sdc | grep ID_SERIAL
E: ID_SERIAL=3600144f0f4e106e711ff54b6b7820049
E: ID_SERIAL_SHORT=600144f0f4e106e711ff54b6b7820049

> ---
> Then check if ID_SERIAL is the same as the unit serial number set into
> udev ID_SERIAL. It seems some paths didn't have the ID_SERIAL
> correctly identified by udev (only /dev/sda had, possibly your
> internal disk ?).
>
> Aug 24 16:00:01 | sdc: serial =
> Aug 24 16:00:01 | sdd: serial =
> Aug 24 16:00:01 | sdm: serial =
> Aug 24 16:00:01 | sdn: serial =
> Aug 24 16:00:01 | sdo: serial =
> --
>
> If everything went far, check "multipath -T" for "uid_attribute" and
> make sure it is set to ID_SERIAL (the udev parameter containing the
> serial number for the disks).

Maybe "sg_vpd --page=sn /dev/sdc" not retrieving the serial number is
leading to the empty serial entries above.

--
albert chin ([hidden email])

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Rafael David Tinoco-3
>
> On Wed, Aug 26, 2020 at 09:53:09AM -0300, Rafael David Tinoco wrote:
> > Are you able to inquiry VPD for the LUNs coming from the open solaris
> > storage server ?
>
> Nope. Info below. So what happens if "udevadm info -q all
> --path=/sys/block/sdc" shows ID_SERIAL but "sg_vpd --page=sn
> /dev/sdc" does not?

The ID_SERIAL is filled by the udev rules file. You have to check
which rule is the one creating (or making it to skip the creation of)
the ID_SERIAL. So, if udevadm has the ID_SERIAL, but it is not coming
from the SCSI VPD page, it means that the serial was defined by some
other script/wrapper - then inquiring SCSI VPD pages.

From 60-persistent-storage.rules we have:

scsi_id --export --whitelisted -d ...

scsi_id comes from /lib/udev/scsi_id and it also gets information from
VPD pages 0x80, 0x83.

If you install sg3-utils-udev package it will create a file called:

/lib/udev/rules.d/55-scsi-sg3_id.rules

that will try to use VPD 0x80 and 0x83 pages for the ID_SERIAL
attribute, but using the sg_inq tool from sg3-tools package.

To answer your question:

If udevadm info shows ID_SERIAL but sg_inq tool does not, it means
that you have an udev rule creating the ID_SERIAL for you. In that
case, you should make changes to udev rules, to make sure they use
correct VPD pages for ID_SERIAL.

Also, take a look at your storage server, making sure that 0x80 and
0x83 pages are available (SBC-4 standards define *at least* VPD 0x80
as mandatory). Check my comment below...

> > $ sudo sg_inq -e /dev/sda
> > VPD INQUIRY, page code=0x00:
> >    Supported VPD pages:
> >      0x0 Supported VPD pages
> >      0x80 Unit serial number
> >      0x83 Device identification
> >
> > $ sudo sg_inq -e --page=0x80 /dev/sda
> > VPD INQUIRY: Unit serial number page
> >   Unit serial number: 4C532000040912113260
>
> # sg_inq -e /dev/sdc
> VPD INQUIRY, page code=0x00:
>    Supported VPD pages:
>      0x0        Supported VPD pages
>      0x80       Unit serial number
>      0x83       Device identification
>      0x86       Extended INQUIRY data
>      0xb0       Block limits (sbc2)
>      0xb2       Logical block provisioning (sbc3)
>
> # sg_inq -e --page=0x80 /dev/sdc
> VPD INQUIRY: Unit serial number page
>   Unit serial number:

Could you try 0x80, 0x83, 0x86 as well ? Nothing there ? If there is
SERIAL coming from your storage server, it is not behaving like
described by SCSI SBC-4 standards.. but you could create a wrapper to
be executed by udev (check bcache-tools package udev rules) that could
get something else from your storage server and define it as
ID_SERIAL.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Rafael David Tinoco-3
> Could you try 0x80, 0x83, 0x86 as well ? Nothing there ? If there is
> SERIAL coming from your storage server, it is not behaving like
> described by SCSI SBC-4 standards.. but you could create a wrapper to
> be executed by udev (check bcache-tools package udev rules) that could
> get something else from your storage server and define it as
> ID_SERIAL.

*if there is NO SERIAL coming*...

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Albert Chin
In reply to this post by Rafael David Tinoco-3
On Wed, Aug 26, 2020 at 12:59:46PM -0300, Rafael David Tinoco wrote:

> >
> > On Wed, Aug 26, 2020 at 09:53:09AM -0300, Rafael David Tinoco wrote:
> > > Are you able to inquiry VPD for the LUNs coming from the open solaris
> > > storage server ?
> >
> > Nope. Info below. So what happens if "udevadm info -q all
> > --path=/sys/block/sdc" shows ID_SERIAL but "sg_vpd --page=sn
> > /dev/sdc" does not?
>
> The ID_SERIAL is filled by the udev rules file. You have to check
> which rule is the one creating (or making it to skip the creation
> of) the ID_SERIAL. So, if udevadm has the ID_SERIAL, but it is not
> coming from the SCSI VPD page, it means that the serial was defined
> by some other script/wrapper - then inquiring SCSI VPD pages.
>
> From 60-persistent-storage.rules we have:
>
> scsi_id --export --whitelisted -d ...
>
> scsi_id comes from /lib/udev/scsi_id and it also gets information from
> VPD pages 0x80, 0x83.

# /lib/udev/scsi_id --whitelisted --device=/dev/sdc
3600144f0f4e106e711ff54b6b7820049

> If you install sg3-utils-udev package it will create a file called:
>
> /lib/udev/rules.d/55-scsi-sg3_id.rules
>
> that will try to use VPD 0x80 and 0x83 pages for the ID_SERIAL
> attribute, but using the sg_inq tool from sg3-tools package.
>
> To answer your question:
>
> If udevadm info shows ID_SERIAL but sg_inq tool does not, it means
> that you have an udev rule creating the ID_SERIAL for you. In that
> case, you should make changes to udev rules, to make sure they use
> correct VPD pages for ID_SERIAL.

Ok, let me do some digging.

> Also, take a look at your storage server, making sure that 0x80 and
> 0x83 pages are available (SBC-4 standards define *at least* VPD 0x80
> as mandatory). Check my comment below...
>
> > # sg_inq -e /dev/sdc
> > VPD INQUIRY, page code=0x00:
> >    Supported VPD pages:
> >      0x0        Supported VPD pages
> >      0x80       Unit serial number
> >      0x83       Device identification
> >      0x86       Extended INQUIRY data
> >      0xb0       Block limits (sbc2)
> >      0xb2       Logical block provisioning (sbc3)
> >
> > # sg_inq -e --page=0x80 /dev/sdc
> > VPD INQUIRY: Unit serial number page
> >   Unit serial number:
>
> Could you try 0x80, 0x83, 0x86 as well ? Nothing there ? If there is
> SERIAL coming from your storage server, it is not behaving like
> described by SCSI SBC-4 standards.. but you could create a wrapper
> to be executed by udev (check bcache-tools package udev rules) that
> could get something else from your storage server and define it as
> ID_SERIAL.

# sg_inq -e --page=0x83 /dev/sdc
VPD INQUIRY: Device Identification page
  Designation descriptor number 1, descriptor length: 20
    designator_type: NAA,  code_set: Binary
    associated with the Addressed logical unit
      NAA 6, IEEE Company_id: 0x144f
      Vendor Specific Identifier: 0xf4e106e7
      Vendor Specific Identifier Extension: 0x11ff54b6b7820049
      [0x600144f0f4e106e711ff54b6b7820049]
  Designation descriptor number 2, descriptor length: 71
    transport: Internet SCSI (iSCSI)
    designator_type: vendor specific [0x0],  code_set: ASCII
    associated with the Target port
      vendor specific: iqn.2010-09.org.openindiana:02:4a7b9f0f-4777-631e-e19a-fb0b94963439
  Designation descriptor number 3, descriptor length: 8
    designator_type: Target port group,  code_set: Binary
    associated with the Target port
      Target port group: 0x0
  Designation descriptor number 4, descriptor length: 8
    designator_type: Relative target port,  code_set: Binary
    associated with the Target port
      Relative target port: 0x2

# sg_inq -e --page=0x86 /dev/sdc
VPD INQUIRY: extended INQUIRY data page
  ACTIVATE_MICROCODE=0 SPT=0 GRD_CHK=0 APP_CHK=0 REF_CHK=0
  UASK_SUP=0 GROUP_SUP=0 PRIOR_SUP=0 HEADSUP=0 ORDSUP=0 SIMPSUP=1
  WU_SUP=0 [CRD_SUP=0] NV_SUP=0 V_SUP=0
  NO_PI_CHK=0 P_I_I_SUP=0 LUICLR=0
  LU_COLL_TYPE=0 R_SUP=0 RTD_SUP=0 HSSRELEF=0 [CBCS=0]
  Multi I_T nexus microcode download=0
  Extended self-test completion minutes=0
  POA_SUP=0 HRA_SUP=0 VSA_SUP=0 DMS_VALID=0
  Maximum supported sense data length=0
  IBS=0 IAS=0 SAC=0 NRD1=0 NRD0=0
  Maximum inquiry change logs=0
  Maximum mode page change logs=0
  DM_MD_4=0 DM_MD_5=0 DM_MD_6=0 DM_MD_7=0
  DM_MD_D=0 DM_MD_E=0 DM_MD_F=0

--
albert chin ([hidden email])

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Rafael David Tinoco-3
So, you see... your ID_SERIAL is coming from:

      Vendor Specific Identifier Extension: 0x11ff54b6b7820049

from VPD page 0x83

> # /lib/udev/scsi_id --whitelisted --device=/dev/sdc
> 3600144f0f4e106e711ff54b6b7820049

> > > # sg_inq -e /dev/sdc
> > > VPD INQUIRY, page code=0x00:
> > >    Supported VPD pages:
> > >      0x0        Supported VPD pages
> > >      0x80       Unit serial number
> > >      0x83       Device identification
> > >      0x86       Extended INQUIRY data
> > >      0xb0       Block limits (sbc2)
> > >      0xb2       Logical block provisioning (sbc3)
> > >
> > > # sg_inq -e --page=0x80 /dev/sdc
> > > VPD INQUIRY: Unit serial number page
> > >   Unit serial number:
> >
> > Could you try 0x80, 0x83, 0x86 as well ? Nothing there ? If there is
> > SERIAL coming from your storage server, it is not behaving like
> > described by SCSI SBC-4 standards.. but you could create a wrapper
> > to be executed by udev (check bcache-tools package udev rules) that
> > could get something else from your storage server and define it as
> > ID_SERIAL.
>
> # sg_inq -e --page=0x83 /dev/sdc
> VPD INQUIRY: Device Identification page
>   Designation descriptor number 1, descriptor length: 20
>     designator_type: NAA,  code_set: Binary
>     associated with the Addressed logical unit
>       NAA 6, IEEE Company_id: 0x144f
>       Vendor Specific Identifier: 0xf4e106e7
>       Vendor Specific Identifier Extension: 0x11ff54b6b7820049
>       [0x600144f0f4e106e711ff54b6b7820049]
>   Designation descriptor number 2, descriptor length: 71
>     transport: Internet SCSI (iSCSI)
>     designator_type: vendor specific [0x0],  code_set: ASCII
>     associated with the Target port
>       vendor specific: iqn.2010-09.org.openindiana:02:4a7b9f0f-4777-631e-e19a-fb0b94963439
>   Designation descriptor number 3, descriptor length: 8
>     designator_type: Target port group,  code_set: Binary
>     associated with the Target port
>       Target port group: 0x0
>   Designation descriptor number 4, descriptor length: 8
>     designator_type: Relative target port,  code_set: Binary
>     associated with the Target port
>       Relative target port: 0x2

Try installing sg3-utils and check if rules from 55-scsi-sg3_id
satisfy your need. I'm aware that the rules file takes both VPDs into
consideration for the ID_SERIAL.  Only thing left to try, if that does
not work, is to open a bug against systemd-udev:

$ dpkg -S /lib/udev/rules.d/60-persistent-storage.rules
udev: /lib/udev/rules.d/60-persistent-storage.rules

then let me know the bug #. I can't guarantee a fix but I'll make sure
to look into it for the next development cycle (as for this one we are
close to freeze date). Meanwhile you will be able to get a rules entry
that works for your case as a workaround.

Cheers o/

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems getting WWID recognized

Albert Chin
On Wed, Aug 26, 2020 at 02:11:25PM -0300, Rafael David Tinoco wrote:
> So, you see... your ID_SERIAL is coming from:
>
>       Vendor Specific Identifier Extension: 0x11ff54b6b7820049
>
> from VPD page 0x83

Coming back to this after a hiatus. I was reading through the email
exchange we had and while the Solaris iSCSI server might not be
responding correctly to VPD page 0x80, as long as ID_SERIAL in udev is
populated and uid_attribute is set to ID_SERIAL in multipath.conf, why
shouldn't "multipath -v4 -ll" output the correct device serial id
rather than:
  # multipath -v4 -ll 2>&1 | egrep 'sd.: serial'
  Aug 24 16:00:01 | sda: serial = 00d4e61f3aa6f0ca26002b133720844a
  Aug 24 16:00:01 | sdc: serial =
  Aug 24 16:00:01 | sdd: serial =
  Aug 24 16:00:01 | sdm: serial =
  Aug 24 16:00:01 | sdn: serial =
  Aug 24 16:00:01 | sdo: serial =

According to multipath.conf(5):
  uid_attribute    The udev attribute providing a unique path identifier
                   (WWID).  If  uid_attribute is set to the empty string,
                   WWID determination is  done  using  the  sysfs method
                   rather then using udev (not recommended in production;
                   see WWID generation below).

                   The default is: ID_SERIAL, for SCSI devices

                   The default is: ID_UID, for DASD devices

                   The default is: ID_WWN, for NVMe devices

  property         Regular  expression  for an udev property. All devices
                   that  have  matching  udev  properties  will be   ex‐
                   cluded/included.  The handling of the property keyword
                   is special, because devices must  have  at least  one
                   whitelisted  udev  property; otherwise they're treated
                   as blacklisted, and  the  message "blacklisted,  udev
                   property missing" is displayed in the logs.

And we have the following in multipath.conf:
  defaults {
    path_selector "round-robin 0"
    user_friendly_names no
    path_grouping_policy multibus
    rr_min_io_rq 1
    rr_weight priorities
    features "1 queue_if_no_path"
    uid_attribute "ID_SERIAL"
    verbosity 6
  }

  blacklist_exceptions {
    property "ID_SERIAL"
    wwid  ...
    ...
  }

It would seem like the udev ID_SERIAL property is irrelevant to
multipath. Indeed, looking at just sda:
  # sg_inq -e --page=0x80 /dev/sda
  VPD INQUIRY: Unit serial number page
    Unit serial number: 00d4e61f3aa6f0ca26002b133720844a

  # sg_vpd --page=sn /dev/sda
  Unit serial number VPD page:
    Unit serial number: 00d4e61f3aa6f0ca26002b133720844a

  # udevadm info --query=all --path /sys/block/sda | egrep ID_SERIAL      
  E: ID_SERIAL=3644a842037132b0026caf0a63a1fe6d4
  E: ID_SERIAL_SHORT=644a842037132b0026caf0a63a1fe6d4

  # multipath -v4 -ll 2>&1 | egrep 'sda: serial'
  Aug 24 16:00:01 | sda: serial = 00d4e61f3aa6f0ca26002b133720844a

If multipath identifies the sda serial as
00d4e61f3aa6f0ca26002b133720844a, this could only have come from the
sq_inq/sg_vpd inquiry, making udev useless and the modification of any
udev rule to help futile.

> > # /lib/udev/scsi_id --whitelisted --device=/dev/sdc
> > 3600144f0f4e106e711ff54b6b7820049
>
> > > > # sg_inq -e /dev/sdc
> > > > VPD INQUIRY, page code=0x00:
> > > >    Supported VPD pages:
> > > >      0x0        Supported VPD pages
> > > >      0x80       Unit serial number
> > > >      0x83       Device identification
> > > >      0x86       Extended INQUIRY data
> > > >      0xb0       Block limits (sbc2)
> > > >      0xb2       Logical block provisioning (sbc3)
> > > >
> > > > # sg_inq -e --page=0x80 /dev/sdc
> > > > VPD INQUIRY: Unit serial number page
> > > >   Unit serial number:
> > >
> > > Could you try 0x80, 0x83, 0x86 as well ? Nothing there ? If there is
> > > SERIAL coming from your storage server, it is not behaving like
> > > described by SCSI SBC-4 standards.. but you could create a wrapper
> > > to be executed by udev (check bcache-tools package udev rules) that
> > > could get something else from your storage server and define it as
> > > ID_SERIAL.
> >
> > # sg_inq -e --page=0x83 /dev/sdc
> > VPD INQUIRY: Device Identification page
> >   Designation descriptor number 1, descriptor length: 20
> >     designator_type: NAA,  code_set: Binary
> >     associated with the Addressed logical unit
> >       NAA 6, IEEE Company_id: 0x144f
> >       Vendor Specific Identifier: 0xf4e106e7
> >       Vendor Specific Identifier Extension: 0x11ff54b6b7820049
> >       [0x600144f0f4e106e711ff54b6b7820049]
> >   Designation descriptor number 2, descriptor length: 71
> >     transport: Internet SCSI (iSCSI)
> >     designator_type: vendor specific [0x0],  code_set: ASCII
> >     associated with the Target port
> >       vendor specific: iqn.2010-09.org.openindiana:02:4a7b9f0f-4777-631e-e19a-fb0b94963439
> >   Designation descriptor number 3, descriptor length: 8
> >     designator_type: Target port group,  code_set: Binary
> >     associated with the Target port
> >       Target port group: 0x0
> >   Designation descriptor number 4, descriptor length: 8
> >     designator_type: Relative target port,  code_set: Binary
> >     associated with the Target port
> >       Relative target port: 0x2
>
> Try installing sg3-utils and check if rules from 55-scsi-sg3_id
> satisfy your need. I'm aware that the rules file takes both VPDs into
> consideration for the ID_SERIAL.  Only thing left to try, if that does
> not work, is to open a bug against systemd-udev:
>
> $ dpkg -S /lib/udev/rules.d/60-persistent-storage.rules
> udev: /lib/udev/rules.d/60-persistent-storage.rules
>
> then let me know the bug #. I can't guarantee a fix but I'll make sure
> to look into it for the next development cycle (as for this one we are
> close to freeze date). Meanwhile you will be able to get a rules entry
> that works for your case as a workaround.
>
> Cheers o/
>
> --
> ubuntu-users mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

--
albert chin ([hidden email])

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users