VTRAK E5800f will not auto-mount on fibre after firmware update (MacOS 10.13.6)

  • 1.1K Views
  • Last Post 31 May 2019
Wallace Karraker posted this 31 May 2019

I have two E5800's that were working well with their original firmware, but failed many of our security audits for vulnerabilities. I installed the latest firmware release (SR4(11.07.0000.01)) which fixed a few of vulnerabilities but now the volumes will not auto-mount after a computer reboot. The only thing that changed was the firmware on each controller.

For now all I can do is shut down the RAIDs at the same time I bring down the computer, many times they will not mount after several attempts. While normally this isn't an issue we had a situation where our parent company forced a software update that involved a system reboot. Madness ensued.

I've tried two different fibre channel cards and a new ATTO ThunderLink FC 2162, all with the same results. Has anyone else experienced this issue?

Hardware:

   - Mac Pro 2013 64GB RAM (High Sierra 10.13.6)

   - ATTO ThunderLink FC 2162

   - Promise E5800f w/ dual controllers (145TB formatted)

   - New SFPs and 1M OM4 fiber cables

 

Order By: Standard | Latest | Votes
PROMISE Technology Inc. posted this 31 May 2019

Hi Wallace,

A firmware update does not modify any configuration settings. Does diskutil show the LUNs? If diskutil shows the LUNs, then there may be issues with the filesystem and perhaps running the check in diskutil would help.

If diskutil does not show the LUNs, verify that LUNmapping is disabled (if direct connected) or configured correctly if LUNs are mapped. Changing your HBAs or TB adapters will change your initiator WWPNs and if LUNmapping is enabled the client machine won't be able to see the LUNs. 

Wallace Karraker posted this 31 May 2019

The Disk Utility app does not show the directly connected LUNs when they fail to mount, neither does the ATTO configuration software. I've tried using the same ATTO Celerity PCI 8GB fibre cards, SFPs and cables that were in use with the previous firmware, I tried new SFPs and cables only as a last resort when I was trying to get the LUNs to mount. With the previous firmware the LUNs auto-mounted everytime, this problem started immediately after the firmware updates.

This is what I see immediately after a server reboot, the SFPs have active lights but do not appear to be communicating.

 

After I reboot the enclosures the SFPs begin to communicate and the LUNs mount. After the enclosures are rebooted the system works correctly until the server is restarted again.

 

I had a similar thought that the file system may have corrupted a driver. Last night I wiped the server hard drive and installed a fresh copy of macOS High Sierra (10.13.6), new Celerity drivers, used the original SFPs and fibre channel cards and it had no effect, the LUNs will only mount after a software managed reboot via WebPAM.

Wallace Karraker posted this 31 May 2019

I've confirmed LUN Masking checkbox is not enabled on both enclosures.

PROMISE Technology Inc. posted this 31 May 2019

Hi Wallace,

I am not aware of any bugs in the latest firmware, but perhaps an experiment would help clarify things. Could you try downreving the firmware one step (to 11.06.0000.00) and see if that fixes the problem?

Wallace Karraker posted this 31 May 2019

Unfortunately this is on our production system with 65 users on it. We were hoping the latest firmware had fixed some of the vulnerabilites that our Nessus scan was reporting. I'll have to schedule another evening once they catch up on their work. I'll get back to you once I have a chance to try it.

Search
Categories
Close