Ayuda de vídeo de Screencast
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Linux OS - sub patch level granularity requirement

Created: 04 Oct 2012 • Updated: 28 Enero 2013 | 1 comentario
el cuadro de los jimmybhathena
1 Acepto
0 Discrepe
+1 1 Vote
Login to vote
Estado: En revisión

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.

Comentarios 1 CommentIr al último comentario

el cuadro de los dveeden

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