Bug 1328771

Summary: sd: ID_SERIAL and ID_SERIAL_SHORT should use ID_SCSI_SERIAL if avaiable
Product: Red Hat Enterprise Linux 7 Reporter: yduan
Component: systemdAssignee: systemd-maint
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: hutter2, knoel, systemd-maint-list, udev-maint-list, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:41:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description yduan 2016-04-20 09:17:20 UTC 
Description of problem:
  Can not display serial number correctly when with wwn.

Version-Release number of selected component (if applicable):
Host:
  kernel: 3.10.0-382.el7.x86_64
  qemu-kvm-rhev: qemu-kvm-rhev-2.5.0-4.el7.x86_64
  Reproducible with qemu-kvm-rhev-2.3.0-31.el7_2.12.x86_64
Guest:
  kernel: 3.10.0-382.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Start a VM by using following command:
  ...
 -device virtio-scsi-pci,id=scsi_pci_bus0 \
 -drive file=/dev/sdb,format=qcow2,id=drive_sysdisk,if=none,cache=none,aio=native,werror=stop,rerror=stop \
 -device scsi-hd,drive=drive_sysdisk,bus=scsi_pci_bus0.0,id=device_sysdisk,bootindex=0 \
 -device virtio-scsi-pci,id=scsi_pci_bus1 \
 -drive file=/home/scsi_test1/datadisk1.qcow2,format=qcow2,id=drive_datadisk1,if=none,cache=none,werror=stop,rerror=stop \
 -device scsi-hd,drive=drive_datadisk1,bus=scsi_pci_bus1.0,id=device_datadisk1,wwn=0x345,serial=DATA_DISK_1 \
  ...
2.Check serial number in guest:
  lsblk --output NAME,SERIAL,WWN

Actual results:
# lsblk --output NAME,SERIAL,WWN
NAME                        SERIAL           WWN
sda                         drive_sysdisk    
├─sda1                                       
└─sda2                                       
  ├─rhel_dhcp--11--192-root                  
  └─rhel_dhcp--11--192-swap                  
sdb                         0000000000000345 0x0000000000000345

Expected results:
# lsblk --output NAME,SERIAL,WWN
NAME                        SERIAL           WWN
sda                         drive_sysdisk    
├─sda1                                       
└─sda2                                       
  ├─rhel_dhcp--11--192-root                  
  └─rhel_dhcp--11--192-swap                  
sdb                         DATA_DISK_1 0x0000000000000345

Additional info:
Comment 2 Fam Zheng 2016-06-27 08:32:06 UTC 
Reassigning to udev.

lsblk calls libudev for disk information. The cause is in udev, ID_WWN overrides ID_SERIAL if present, even ID_SCSI_SERIAL is there:

# udevadm info -q all -n sdb
P: /devices/pci0000:00/0000:00:04.0/virtio1/host2/target2:0:1/2:0:1:0/block/sdb
N: sdb
S: disk/by-id/scsi-300000000000abcde
S: disk/by-id/wwn-0x00000000000abcde
S: disk/by-path/pci-0000:00:04.0-scsi-0:0:1:0
E: DEVLINKS=/dev/disk/by-id/scsi-300000000000abcde /dev/disk/by-id/wwn-0x00000000000abcde /dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:1:0
E: DEVNAME=/dev/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:04.0/virtio1/host2/target2:0:1/2:0:1:0/block/sdb
E: DEVTYPE=disk
E: ID_BUS=scsi
E: ID_MODEL=QEMU_HARDDISK
E: ID_MODEL_ENC=QEMU\x20HARDDISK\x20\x20\x20
E: ID_PATH=pci-0000:00:04.0-scsi-0:0:1:0
E: ID_PATH_TAG=pci-0000_00_04_0-scsi-0_0_1_0
E: ID_REVISION=2.5+
E: ID_SCSI=1
E: ID_SCSI_SERIAL=sd0
E: ID_SERIAL=300000000000abcde
E: ID_SERIAL_SHORT=00000000000abcde
E: ID_TYPE=disk
E: ID_VENDOR=QEMU
E: ID_VENDOR_ENC=QEMU\x20\x20\x20\x20
E: ID_WWN=0x00000000000abcde
E: ID_WWN_WITH_EXTENSION=0x00000000000abcde
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=49056
Comment 3 Tony Hutter 2017-05-23 00:24:11 UTC 
Any updates on this?  We're hitting this issue when calling lsblk from our ZFS scripts:
https://github.com/zfsonlinux/zfs/issues/6153
Comment 6 RHEL Program Management 2020-12-15 07:41:07 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.