vmcore.2> ::stack
vx_root+0xc4(a004a3979e0, 2a1052e1170, 1, a005cd43280, ffbffb34, a004a3979e0)
fsop_root+0x10(a004a3979e0, 2a1052e1170, 40, a003d170280, 7af87954, 20888938)
traverse+0x6c(2a1052e1250, 2a1052e12b8, 0, a003c27ec80, 2a1052e1170, 0)
lookuppnvp+0x48c(2a1052e1548, 0, 21, 0, 2a1052e1748, a0010377a40)
lookuppnatcred+0x110(2a1052e1548, 0, 21, 0, 2a1052e1748, a0010377a40)
lookupnameatcred+0x44(a0f68, 0, 21, 0, 2a1052e1748, 0)
lookupnameat+0x20(a0f68, 0, 21, 0, a003cb22278, 0)
vn_openat+0x2fc(2, 0, 2001, 0, 0, 0)
copen+0x490(ffffffffffd19553, a0f68, 2001, 104, 0, 20)
uopen+0x18(ffffffffffd19553, a0f68, 2001, 104, 0, 600000)
syscall_trap32+0x23c(ffd19553, a0f68, 0, 104, a0f68, 0)
From crash and code walk it seems that we got panic while accessing the vnode of root directory because it is NULL.
Solaris Bugs : 32478784 & 32588146 - vxfs and mvfs from veritas/IBM fail post SRU30 and ice lake integration
Veritas recommends to keep the SRU version Lower than 30.
Oracle is ready to do changes in their next SRU, so that panic will not hit and all ISV binaries that previously worked will work again.
As per Oracle, fix will available in next SRU (either in SRU32 or SRU33).
Please check the Veritas qualification site on SORT website before upgrading to SRU 32 or SRU 33.