Ubuntu 16.10: lsscsi shows wrong wwn

[bugproxy]

== Comment: #0 - Ping Tian Han <email address hidden> - 2016-10-25 02:01:23 ==

---Problem Description---
The 'lsscsi -w' gives a wrong WWN:

% lsscsi -w | grep sda
[0:0:1:0] disk 0x6005076304ffc4410000000000000 /dev/sda
% ls -l /dev/disk/by-id/ | grep 'wwn.*sda'
lrwxrwxrwx 1 root root 9 Oct 24 21:20 wwn-0x6005076304ffc4410000000000000096 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 24 21:20 wwn-0x6005076304ffc4410000000000000096-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 24 21:20 wwn-0x6005076304ffc4410000000000000096-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 24 21:20 wwn-0x6005076304ffc4410000000000000096-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 24 21:20 wwn-0x6005076304ffc4410000000000000096-part4 -> ../../sda4

Contact Information = Ping Tian <email address hidden>

Machine Type = lpar
 ---Debugger---
A debugger was configured, however the system did not enter into the debugger

Userspace tool common name: lsscsi

Userspace rpm: 0.27-3

The userspace tool has the following bit modes: 64-bit

Userspace tool obtained from project website: na

*Additional Instructions for Ping Tian <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach ltrace and strace of userspace application.

== Comment: #1 - VIPIN K. PARASHAR <email address hidden> - 2016-10-25 05:50:58 ==
lsscsi -w output
==========
[0:0:5:0] disk 0x60050764008181941000000000000 /dev/sdad
[0:0:5:1] disk 0x60050764008181941000000000000 /dev/sdae
[0:0:5:2] disk 0x60050764008181941000000000000 /dev/sdaf
[0:0:5:3] disk 0x60050764008181941000000000000 /dev/sdag
[0:0:5:4] disk 0x60050764008181941000000000000 /dev/sdah

/dev/disk/by-id/ contents
===============
# ls -l /dev/disk/by-id/ | grep wwn | awk '{printf("%s %s %s\n", $9, $10, $11)}'
wwn-0x600507640081819410000000000001b1 -> ../../sdad
wwn-0x600507640081819410000000000001b2 -> ../../sdae
wwn-0x600507640081819410000000000001b3 -> ../../sdaf
wwn-0x600507640081819410000000000001b4 -> ../../sdag
wwn-0x600507640081819410000000000001b5 -> ../../sdah
#

Last 3 digits of wwn id is getting tripped in lssscsi output.
This is causing wwn to differ. Its a bug in lsscsi code.

== Comment: #2 - VIPIN K. PARASHAR <email address hidden> - 2016-10-25 05:56:59 ==
Pull request with the fix reading "Fix truncation of 128-bit wwn"
is already raised upstream at

https://github.com/hreinecke/lsscsi/pull/1

== Comment: #3 - VIPIN K. PARASHAR <email address hidden> - 2016-10-25 06:06:38 ==
lsscsi binary created with fix prints full WWN
without any truncation.

# ./lsscsi -V
version: 0.28 2014/09/30 [svn: r120]
#

# ./lsscsi -w
[0:0:5:0] disk IBM 2145 0000 0x600507640081819410000000000001b1 /dev/sdad
[0:0:5:1] disk IBM 2145 0000 0x600507640081819410000000000001b2 /dev/sdae
[0:0:5:2] disk IBM 2145 0000 0x600507640081819410000000000001b3 /dev/sdaf
[0:0:5:3] disk IBM 2145 0000 0x600507640081819410000000000001b4 /dev/sdag
[0:0:5:4] disk IBM 2145 0000 0x600507640081819410000000000001b5 /dev/sdah
#

# ls -l /dev/disk/by-id/wwn* | awk '{printf("%s %s %s\n", $9,$10,$11)}'
/dev/disk/by-id/wwn-0x600507640081819410000000000001b1 -> ../../sdad
/dev/disk/by-id/wwn-0x600507640081819410000000000001b2 -> ../../sdae
/dev/disk/by-id/wwn-0x600507640081819410000000000001b3 -> ../../sdaf
/dev/disk/by-id/wwn-0x600507640081819410000000000001b4 -> ../../sdag
/dev/disk/by-id/wwn-0x600507640081819410000000000001b5 -> ../../sdah
#

[Jon Grimm (jgrimm)]

Setting this for low priority for now.

[Jon Grimm (jgrimm)]

FWIW, the upstream mentioned in

>>Pull request with the fix reading "Fix truncation of 128-bit wwn"
>>is already raised upstream at
>>
>>https://github.com/hreinecke/lsscsi/pull/1

, is just a convenience mirror according to the upstream lssci webpage:

http://sg.danny.cz/scsi/lsscsi.html

" The lsscsi package is developed by the author using subversion. Subversion revisions, which are ascending integers, can be seen in the ChangeLog file and the version string (i.e. 'lsscsi -V') . Some users have asked for git access and a contributor has set up a git mirror on github:
https://github.com/hreinecke/lsscsi
Updates are sent to that mirror whenever a beta is placed on the main page, perhaps more often than that. Please report any problems to me."

, SO its really not clear whether your bug report or pull request would even be seen by the upstream maintainer.

Accordingly, you may want to report this bug directly through the maintainer's email (as per his directions to do so).

Additionally, this package is fully in sync with debian, so tracking in bug there would be useful to and can trickle down once debian enable fix.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-10-27 06:14 EDT-------
(In reply to comment #8)

> Accordingly, you may want to report this bug directly through the
> maintainer's email (as per his directions to do so).
>
> Additionally, this package is fully in sync with debian, so tracking in bug
> there would be useful to and can trickle down once debian enable fix.

IBM development has already informed lsscsi tool maintainer
Doug Gilbert @(<email address hidden>) via e-mail about this issue
and potential fix via e-mail and will work with him for acceptance.

We can retain this bug for tracking fix delivery in Ubuntu release
and verification.

[Manoj Iyer (manjo)]

Based on the fact that IBM is already working with upstream to fix this issue, I am removing taco screen team as the owner.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-02-07 12:04 EDT-------
(In reply to comment #10)
> Based on the fact that IBM is already working with upstream to fix this
> issue, I am removing taco screen team as the owner.

Unfortunately, we haven't heard back anything yet on this from
lsscsi tool maintainer Doug Gilbert @(<email address hidden>)
This bug is found with Ubuntu and we (IBM) don't use Debian for any
internal testing. In case upstream maintainer follows Debian bugs
for lsscsi utlity, will it be possible for Canonical to file a Debian bug
for this issue ?

or any suggestions here about getting this issue fixed into lsscsi utility ?

[Jon Grimm (jgrimm)]

>any suggestions here about getting this issue fixed into lsscsi utility

Ah, yeah, it can sometimes take a bit of persistence at getting a maintainer's attention. Still, its the right thing to do to continue to pursue that path as wanting to ensure there aren't side effects you have not thought of. I'd suggest you also try posting patches to the linux-scsi mailing list as the maintainer appears to be active in that forum.

However, it doesn't seem terrible for us to carry an Ubuntu patch for this at least temporarily with the assumption that you'll keep working to get upstreamed so we can drop such patch going forward.

 >> we (IBM) don't use Debian for any internal testing. In case upstream maintainer follows Debian bugs for lsscsi utlity

FWIW, its pretty easy to set up a LXD container or VM with docker and reproduce this bug, and then use the 'reportbug' utility. I'd do so, but I lack the hardware to validate your bug.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-03-15 02:35 EDT-------
(In reply to comment #12)
> >any suggestions here about getting this issue fixed into lsscsi utility
>
> Ah, yeah, it can sometimes take a bit of persistence at getting a
> maintainer's attention. Still, its the right thing to do to continue to
> pursue that path as wanting to ensure there aren't side effects you have not
> thought of. I'd suggest you also try posting patches to the linux-scsi
> mailing list as the maintainer appears to be active in that forum.
>
> However, it doesn't seem terrible for us to carry an Ubuntu patch for this
> at least temporarily with the assumption that you'll keep working to get
> upstreamed so we can drop such patch going forward.
>

Thanks!! that will help.
Meanwhile we will send out patch to linux-scsi mailing list as well
to catch maintainer attention.

[Christian Ehrhardt  (paelzer)]

While I agree to the patch, the effect is very much non-fatal.
Especially when I see that this was the case since like forever (all precise - zesty are the same).

I like the fix, but I'm not so sure it is worth an SRU not having a good real case for it.

For the sake of tracking, there was feedback and a v2 version is out there atm without comment.
=> https://<email address hidden>/msg59720.html

[Christian Ehrhardt  (paelzer)]

Also I wanted to report that I can test and verify the issue on s390x:

$ lsscsi --wwn | grep sde
[1:0:0:1073889316]disk 0x6005076306ffd6b60000000000002 /dev/sde
$ ll /dev/disk/by-id/* | grep 'wwn.*sde'
/dev/disk/by-id/wwn-0x6005076306ffd6b60000000000002402 -> ../../sde

"402" is the lost info.

One more reason which makes this even less important IMHO is that usually those disks are driven with multipathing and as soon as that is set up the wwn is linked to the device mapper object.
=> /dev/disk/by-id/wwn-0x6005076306ffd6b60000000000002402 -> ../../dm-0

After that "lsscsi" is no more seeing anything in regard to the wwn:
lsscsi --wwn | grep sde
[1:0:0:1073889316]disk /dev/sde

An extra bug - I don't think so, just the fact that the WWN is not represented by a single disk anymore. Even before multipath only one of many "disks" to the same WWN owns the wwn.
[1:0:0:1073889316]disk 0x6005076306ffd6b60000000000002 /dev/sde
[1:0:0:1073954852]disk /dev/sdf
[1:0:1:1073889316]disk /dev/sdg
[1:0:1:1073954852]disk /dev/sdh

Anyway all that might be a reason not to SRU it, but clearly it should be fixed still.
Once that is resolved it might be a good trigger to pull a newer version into Debian and Ubuntu.
While development is super slow there are at least a few fixes.
We should help to push a newer one to Debian soon in the aa-cycle so we can sync it into aa.
At that time we can look at the progress of this fix.

[Christian Ehrhardt  (paelzer)]

P.S. subscribing myself to help on verification if needed.

[Christian Ehrhardt  (paelzer)]

The issue is still not picked up upstream, I pinged on the Github issue.

Did you have success with your submission to the mailing list?
Could you link that mail thread here.

Further I think eventually we would want to fix that in Debian and sync to Ubuntu anyway - as we carry no delta on lsscsi. In addition to fixing to avoiding Ubuntu Delta where not needed (this isn't a Ubuntu specific fix, Debian would benefit just as much), it would give the issue a bit extra visibility.

Please mind that this is painfully similar to [1] which could mean your change might be rejected upstream - yet I haven't checked the exact fields affected in your commit and the former old post.

If you could read the linked bug and then decide to either chime in there or to report a new Debian bug that would be great. If you do so please mention here which bug we should let Launchpad track in that regard.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788700

[Vaibhav (vaibhav-l)]

Hi paelzer,

I have already responded to you on the corresponding Github issue (https://goo.gl/kxcRwY). Summarizing my response here for the convenience of others:

- Already tried multiple times to catch lsscsi maintainer Doug Gilbert <email address hidden> regarding this patch with no success.
- The github repository is just and mirror for a private svn repo hence only way to push patches is via email.
- I have already sent an updated patch to the linux-scsi mailing list at http://marc.info/?l=linux-scsi&m=148975219308242
- Helpfully redhat has verified the patch and accepted it as an out of tree patch.

The Debian bug report you mentioned looks different from what this patch tries to fix hence probably needs a new bug to be reported to Debian.

[Christian Ehrhardt  (paelzer)]

Thanks Vaibhav for your quick response!

Then even more so we want some more attention - would you be so kind and open a matching Debian report to pick up a change for this?
You could do all the explanation on the background and what (has not) happened.
I'll in the meantime convert your upstream patch to a proper debdiff for them to include.
Once you report back to me here what the new debian bug number is I can provide the debdiff there to ease the Debian maintainers work picking that change up.

[Vaibhav (vaibhav-l)]

Two updates:
* Have filed a bug with debian viz bug-report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867868

* The pull request https://github.com/hreinecke/lsscsi/pull/1 has just been merged.

[Christian Ehrhardt  (paelzer)]

Attached a preparation of your upstream fix to be forwarded to Debian, just need to replace the two occurrences of "TODO" with the Debian bug number you got.

Some maintainers prefer to pick from upstream themselve, some prefer a Debdiff you never know.
I think it can only help to provide.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lsscsi - 0.28-0.1

---------------
lsscsi (0.28-0.1) unstable; urgency=medium

  * Non-maintainer upload.
  * New upstream version. Closes: #875846.
  * debian/patches/lsscsi-Fix-truncation-of-128-bit-wwn.patch: fix lsscsi
    truncating 128-bit wwns (Closes: #867868) (LP: #1636467).

 -- Matthias Klose <email address hidden> Tue, 05 Dec 2017 08:22:04 +0100