Video Screencast Help
Search Video Help Close Back
to help

Linux OS - sub patch level granularity requirement

Created: 04 Oct 2012 | Updated: 28 Jan 2013 | 1 comment
jimmybhathena's picture
jimmybhathena Symantec Employee Accredited Certified
0 Agree
0 Disagree
0 0 Votes
Login to vote
Status: In Review

Currently the patch matrix on our SORT portal has provided valuable help:

https://sort.symantec.com/productmatrix

 

However, for Linux for instance, it is not down to individual sub-level of the OS release, for instance it only shows RHEL5 and RHEL6 or SLES9 and SLES10 but not RHEL5.8 or RHEL6.2, etc.

For instance it could really be useful since the Storage Foundation versions support for RHEL6.2 and RHEL 6.3 is in SFHA 5.1SP1PR3RP3, one has to actually read the release notes, etc.

Also, it would really be good if we could publish which OS kernel version has broken the KABI so that customers can easily know that if a KABI is broken, then the supportability on older versions may be questionable.

 

Idea Filed Under:
, , , , , , , , , ,

Comments 1 Comment • Jump to latest comment

dveeden's picture
dveeden
Linux OS - sub patch level granularity requirement - Comment:08 Oct 2012 : Link

One of the incidents fixed by SFHA 5.1SP1RP3 show that this could be important.

 

* INCIDENT NO:2863673 TRACKING ID:2783293

SYMPTOM: After upgrade to RHEL5.8(2.6.18-308), all paths get disabled when deport/import
operations are invoked on shared dgs with SCSI-3 mode.

DESCRIPTION: Linux 2.6.18-308 adds some enhancement in the scsi mid layer, where
RESERVATION_CONFLICT will be converted to DID_NEXUS_FAILURE error, which is a
newly introduced error type not recognized by DMP code. It causes DMP to convert
the error to transport failure by default and mark the paths disabled
accordingly.

RESOLUTION: Add the recognition code of the DID_NEXUS_FAILURE error in DMP.

 

0
Login to vote