Load fibre drivers at startup
17 Nov 2021
We have seen several Big Sur Macs at different locations not mount their Xsan volume after a restart or power on. After some investigation, we have found that the fibre HBA driver is not loaded. This has happened with ATTO ThunderLink FC adapters, ATTO Celerity PCI cards, and Promise SANLink FC adapters, so it doesn’t appear to just be one bad driver.
The first indication of this issue is the message in System Information -> Fibre Channel, “This computer doesn’t contain any Fibre Channel devices. If you installed Fibre Channel adapters, make sure they are seated properly and that any devices, hubs, and switches are connected properly and powered on.” We know that there is a Fibre Channel adapter connected. Next we check the extension in System Information -> Extensions and see that it shows Loaded -> No.
To confirm the issue, we load the extension manually with
kmutil. The command is
sudo kmutil load -p /Library/Extension/ATTOThunderLinkFC16.kext, for example. Shortly after loading the extension, the volume mounted on our Desktop. So now we need to make it automatic.
The way to have something happen when the Mac boots up is a LaunchDaemon, which is defined by a plist file. There is a lot of good information about launchd already on the internet, so this will focus on running the above command. Adjust the file name and contents to match the driver you need to load. We create the file /Library/LaunchDaemons/org.rskgroup.loadATTO.plist and it contains:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Next we need to tell the Mac to load this LaunchDaemon. The newer syntax to use is
sudo launchctl bootstrap system /Library/LaunchDaemons/org.rskgroup.loadATTO.plist. This tells the Mac to read this file every time it boots up and the plist says to run the
kmutil command when this plist is loaded. So this means the driver will be loaded every time the Mac starts. In our experience there isn’t any problem running this if the driver is loaded by the system as expected.
So far we have seen this behavior on Big Sur systems (11.5 and 11.6) but haven’t run into it on the couple of Monterey systems we are testing.