topic raid5 p420io controller: logical disks have same unit serial number in ProLiant Servers (ML,DL,SL)

raid5 p420io controller: logical disks have same unit serial number

phil524 — Tue, 09 Jun 2015 08:44:21 GMT

Hello,

I have a proliant ML350p gen8 with raid contoller p420i.

4 physical disks in raid array that are seen as 3 logical disks. These are seen as scsi disk sda, sdb and sdc

With Linux (opensuse 13.2) it seems that each logical disk send the same unit serial number for the 3 disks which gives problem with udev (for more details see https://bugzilla.suse.com/show_bug.cgi?id=926053)

Is this a known problem with this raid controller? The firmware version on my system in 4.68

Regards

Philippe

Re: raid5 p420io controller: logical disks have same unit serial number

Torsten. — Tue, 09 Jun 2015 13:33:01 GMT

The current firmware is 6.34, check the fixes section at the download pages.

Re: raid5 p420io controller: logical disks have same unit serial number

phil524 — Wed, 10 Jun 2015 21:40:51 GMT

Hello,

I have updated the firmware to version 6.34 but the problem remains.

The 3 logical disks have the same scsi serial id..

Regards

Philippe

Re: raid5 p420io controller: logical disks have same unit serial number

Jimmy Vance — Thu, 11 Jun 2015 18:38:31 GMT

@phil524 wrote:
Hello,

I have a proliant ML350p gen8 with raid contoller p420i.
4 physical disks in raid array that are seen as 3 logical disks. These are seen as scsi disk sda, sdb and sdc

With Linux (opensuse 13.2) it seems that each logical disk send the same unit serial number for the 3 disks which gives problem with udev (for more details see https://bugzilla.suse.com/show_bug.cgi?id=926053)

Is this a known problem with this raid controller? The firmware version on my system in 4.68

Regards
Philippe

I don't think the ID_SCSI_SERIAL being the same is your issue. I just checked several systems I have in production and that value is the same on all the LUNS in a server

These values are all different

ID_SERIAL_RAW=

ID_SERIAL=

ID_SERIAL_SHORT=

ID_WWN=

ID_WWN_VENDOR_EXTENSION=

ID_WWN_WITH_EXTENSION=

Re: raid5 p420io controller: logical disks have same unit serial number

phil524 — Thu, 11 Jun 2015 22:34:04 GMT

Hello,

The answer from opensuse support is

It is a wrong value in codepage 0x80.

/lib/udev/rules.d/58-scsi-sg3_symlink.rules

is using SCSI_IDENT_SERIAL, which takes the value of 'Unit serial number' from codepage 0x80.

The value of 'Unit serial number' must be uniqe for a disk.
I your case, it is not.
I'd recommend to report this as a firmware bug to HP.

on my system the Unit serial number returned is the same for the three logial disk.

the command

udevadm info /dev/sdx
gives for disks sda, sdb, sdc the same value for

SCSI_IDENT_SERIAL=0014380280B60D0 and this is the problem

Regards
Philippe

Re: raid5 p420io controller: logical disks have same unit serial number

Jimmy Vance — Fri, 12 Jun 2015 13:50:07 GMT

I loaded SLES12 and OpenSUSE 13.2 on a system with a P420. I have four drvies configured RAID 5 with 4 LUNs. The SCSI_IDENT_SERIAL is the same, The system boots and function as expected. I have several other servers with Smart Array running in production the ID_SCSI_SERIAL is the same on them too. (these other systems are running older versions of RHEL and SLES so udevadm doesn't return any results with the below command but the scsi_id command returns the same id_scsi_serial values)

I'm not seeing any errors in journalctl with OpenSUSE and nothing in dmesg or messages on SLE12

SLE12test:~ # for i in a b c d; do udevadm info /dev/sd$i | grep SCSI_IDENT_SERIAL;done
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH

SLE12test:~ # for i in a b c d;do /lib/udev/scsi_id --export --whitelisted -d /dev/sd$i | grep ID_SCSI_SERIAL;done
ID_SCSI_SERIAL=PBKTU0ARH2O0YH
ID_SCSI_SERIAL=PBKTU0ARH2O0YH
ID_SCSI_SERIAL=PBKTU0ARH2O0YH
ID_SCSI_SERIAL=PBKTU0ARH2O0YH

SLE12test:~ # for i in a b c d; do udevadm info /dev/sd$i | grep SCSI_IDENT_LUN_NAA;done
E: SCSI_IDENT_LUN_NAA=600508b1001cb47fe7beefe5213c2409
E: SCSI_IDENT_LUN_NAA=600508b1001cba32fcd49dae746c2122
E: SCSI_IDENT_LUN_NAA=600508b1001c3d1ec954e173cfa10096
E: SCSI_IDENT_LUN_NAA=600508b1001c1f7e117fa35d23525336

SLE12test:~ # for i in a b c d;do /lib/udev/scsi_id --export --whitelisted -d /dev/sd$i | grep ID_SERIAL_SHORT;done
ID_SERIAL_SHORT=600508b1001cb47fe7beefe5213c2409
ID_SERIAL_SHORT=600508b1001cba32fcd49dae746c2122
ID_SERIAL_SHORT=600508b1001c3d1ec954e173cfa10096
ID_SERIAL_SHORT=600508b1001c1f7e117fa35d23525336

openSUSE13.2:~ # for i in a b c d;do udevadm info /dev/sda|grep SCSI_IDENT_SERIAL;done
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH
E: SCSI_IDENT_SERIAL=PBKTU0ARH2O0YH

openSUSE13.2:~ # for i in a b c d;do udevadm info /dev/sda|grep SCSI_IDENT_LUN_NAA;done
E: SCSI_IDENT_LUN_NAA=600508b1001cb47fe7beefe5213c2409
E: SCSI_IDENT_LUN_NAA=600508b1001cb47fe7beefe5213c2409
E: SCSI_IDENT_LUN_NAA=600508b1001cb47fe7beefe5213c2409
E: SCSI_IDENT_LUN_NAA=600508b1001cb47fe7beefe5213c2409

openSUSE13.2:~ # for i in a b c d;do /lib/udev/scsi_id --export --whitelisted -d /dev/sd$i | grep ID_SCSI_SERIAL;done
ID_SCSI_SERIAL=PBKTU0ARH2O0YH
ID_SCSI_SERIAL=PBKTU0ARH2O0YH
ID_SCSI_SERIAL=PBKTU0ARH2O0YH
ID_SCSI_SERIAL=PBKTU0ARH2O0YH

openSUSE13.2:~ # for i in a b c d;do /lib/udev/scsi_id --export --whitelisted -d /dev/sd$i | grep ID_SERIAL_SHORT;done
ID_SERIAL_SHORT=600508b1001cb47fe7beefe5213c2409
ID_SERIAL_SHORT=600508b1001cba32fcd49dae746c2122
ID_SERIAL_SHORT=600508b1001c3d1ec954e173cfa10096
ID_SERIAL_SHORT=600508b1001c1f7e117fa35d23525336

openSUSE13.2:~ # lsblk -f
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda
├─sda1 swap         8ee621e5-dc4f-4e35-83df-4a72a42fd6a9 [SWAP]
├─sda2 btrfs        5aacd3ad-b2f1-420d-b06a-95e50e75d0db /
└─sda3 xfs          9d2103c9-4c9b-47a9-b028-06760425e1c9 /home
sdb
└─sdb1 xfs          ad59c2a3-5a65-46bc-bda6-c9f5170c8d64 /data1
sdc
└─sdc1 xfs          d3125c53-7884-4849-969f-cd759af2f7d5 /data2
sdd
└─sdd1 xfs          9125794e-a130-45f3-bfb5-3d748a0286a9 /data3
linux-p2by:~ #

Re: raid5 p420io controller: logical disks have same unit serial number

Jimmy Vance — Fri, 12 Jun 2015 13:59:23 GMT

One thing I did just go back and check was how grub and etc/fstab are dealing with the disks

On the test system I'm using now OpenSUSE 13.2 is using UUID. The RHEL system I looked at is also using UUID, but the SLES 11 system I checked is using disk/by-id

I didn't change the persistent naming method on any of the systems and used what the installer set by default

Re: raid5 p420io controller: logical disks have same unit serial number

phil524 — Sat, 13 Jun 2015 07:13:45 GMT

Hello,

thanks for your feedback.

I have updated to the last firmware version (6.34)

This doesn't solve the error message in systemctl but I'm on opensuse 13.2 tumbleweed with the last kernel (4.0.4-3-xen). These error messages are coming in journalctl each 5 minutes but there are not other problems: the opensuse system runs correctly and none applications gives error or warnings about this

Only jouralctl is full of these errors (warnings?) and it is difficult to check other errors/warnings.

If I run your commands I have the same results as you. Some output shows same result for each disk and other shows a different result for each disks

The problem seems to be the SCSI_IDENT_SERIAL

In the /lib/udev/rules.d/58-scsi-sg3_symlink.rules there is this code for the generation of the disk/by-id:

ENV{SCSI_IDENT_SERIAL}=="?*", ENV{DEVTYPE}=="disk", SYMLINK+="disk/by-id/scsi-S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}"

and this gives the same result for the 3 disks. :-(

This is something new compared to opensuse13.2 standard. It came in tumbleweed on February/March 2015

Now I cannot decide if this is a firmware problem (as said by the opensuse support) or if it is a software error in tumbleweed.

As suggested by the opensuse support (workaround) I have set the rules in 58-scsi-sg3_symlink.rules as comment, after reboot the errors are not more comming and the system runs without problem

I'll live with this workaround and see if something pops up.

Now tumbleweed is the way to the next opensuse versionand I think that this problem should pops up with the next version on HP proliant

Regards

Philippe