History of ASR-5405Z Configuration Notes
<p><span style="background-color:#ECF0F1">19:51 > Llama 4 has been making a pigs ear of help on this problem, so I've ditched it and switched to here ;) Text based server running tumbleweed. I am trying to see if the Adaptec ASR-5405Z 512MB SAS controller I have just fitted is being seen and I have established that it is and rescan-scsi-bus.sh can see all the /dev/sdX devices, but sg_map has a blank entry against /dev/sg2 and so I need help to hook it up so I can mount the SAS disk to the file system?</span></p>
<p>Let's dig into this. The blank <code>sg_map</code> entry for <code>/dev/sg2</code> is actually normal/expected behaviour — it just means that device is a non-disk type (like an enclosure services device or expander), so don't worry about that.</p>
<p>Let's walk through getting your SAS disk properly mounted.</p>
<h2>1. Confirm the disk is visible and identify it</h2>
<pre>
<code>lsblk -o NAME,SIZE,TYPE,TRAN,MODEL,SERIAL
</code></pre>
<p>Also run:</p>
<pre>
<code>sg_map -x
</code></pre>
<p>The <code>-x</code> flag shows the device type — type <code>0</code> is a disk, type <code>13</code> is an enclosure, etc. The blank against <code>/dev/sg2</code> is likely one of those non-disk types.</p>
<hr />
<h2>2. Check what the kernel actually sees</h2>
<pre>
<code>dmesg | grep -E &#39;sd[a-z]|scsi|aacraid&#39; | tail -30
</code></pre>
<p>The Adaptec ASR-5405Z uses the <strong>aacraid</strong> driver on Linux, so you should see it referenced. Look for lines attaching sdX devices.</p>
<hr />
<h2>3. Identify your SAS disk's block device</h2>
<pre>
<code>lsblk
fdisk -l
</code></pre>
<p>You're looking for an unpartitioned or unformatted disk — it'll show as a raw device like <code>/dev/sdb</code> or <code>/dev/sdc</code> with no children.</p>
<hr />
<h2>4. Partition the disk (if needed)</h2>
<p>If it's a fresh/bare disk with no partition table:</p>
<pre>
<code>parted /dev/sdX mklabel gpt
parted /dev/sdX mkpart primary ext4 0% 100%
</code></pre>
<p>Replace <code>sdX</code> with your actual device. If it already has partitions, skip to step 5.</p>
<hr />
<h2>5. Format the partition</h2>
<pre>
<code>mkfs.ext4 /dev/sdX1
</code></pre>
<p>Or <code>xfs</code> if you prefer:</p>
<pre>
<code>mkfs.xfs /dev/sdX1
</code></pre>
<hr />
<h2>6. Mount it</h2>
<pre>
<code>mkdir -p /mnt/sasdisk
mount /dev/sdX1 /mnt/sasdisk
</code></pre>
<p>Verify:</p>
<pre>
<code>df -h /mnt/sasdisk
</code></pre>
<hr />
<h2>7. Make it persistent (fstab)</h2>
<p>Get the UUID:</p>
<pre>
<code>blkid /dev/sdX1
</code></pre>
<p>Then add to <code>/etc/fstab</code>:</p>
<pre>
<code>UUID=your-uuid-here /mnt/sasdisk ext4 defaults 0 2
</code></pre>
<hr />
<h2>Key question before going further</h2>
<p>Run <code>lsblk</code> and <code>sg_map -x</code> and paste the output — that'll confirm exactly which <code>/dev/sdX</code> is your new SAS disk and whether it needs partitioning or already has data on it. That'll make sure we don't touch the wrong device.</p>
<p><span style="background-color:#ECF0F1">20:03 > lsblk only lists the disks that have entries in sg_map and -X gives srv9:/media2 # sg_map -x /dev/sg0 2 0 0 0 0 /dev/sda /dev/sg1 2 0 1 0 5 /dev/sr0 /dev/sg2 0 1 0 0 0 /dev/sg3 3 0 0 0 0 /dev/sdb /dev/sg4 5 0 0 0 0 /dev/sdc /dev/sg5 6 0 0 0 0 /dev/sdd Step 2 shows the 4 other disk and the DVD drive mounting, but srv9:/media2 # dmesg | grep -E 'aacraid' | tail -30 [ 2.018564] [ T418] Adaptec aacraid driver 1.2.1[50983]-custom [ 2.046734] [ T9] aacraid 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 2.048446] [ T9] aacraid: Comm Interface enabled [ 2.272724] [ T9] aacraid 0000:02:00.0: 64 Bit DAC enabled [ 2.307024] [ T9] scsi host0: aacraid Step 3 fails because /dev/sg2 is not seen as a block device, it's THAT which I need to fix as none of the rest will do anything until there is a /dev/sde entry in sg_map</span></p>
<p>Ah, now I see the problem clearly. <code>/dev/sg2</code> has <strong>no corresponding block device</strong> (<code>/dev/sdX</code>) — the SCSI generic device exists but the kernel never created a block device for it. This is a known aacraid quirk where the controller sees the disk but the block layer doesn't get properly notified.</p>
<h2>Diagnose first</h2>
<pre>
<code>cat /proc/scsi/scsi
</code></pre>
<p>Look for a <code>Host: scsi0</code> entry with <code>Channel: 01 Id: 00</code> — that's your missing disk. Also:</p>
<pre>
<code>sg_inq /dev/sg2
</code></pre>
<p>This will tell you exactly what's on the other end — confirm it's actually a disk (Device_type=0).</p>
<hr />
<h2>Force the block device to materialise</h2>
<p>The sg device exists but the block device wasn't created. Try forcing it:</p>
<pre>
<code>echo &quot;- - -&quot; &gt; /sys/class/scsi_host/host0/scan
</code></pre>
<p>Then immediately check:</p>
<pre>
<code>lsblk
dmesg | tail -20
</code></pre>
<p>If that doesn't work, target it more precisely using the channel/id/lun from <code>sg_map -x</code> — your <code>/dev/sg2</code> shows <code>0 1 0 0</code> meaning <strong>host 0, channel 1, id 0, lun 0</strong>:</p>
<pre>
<code>echo &quot;1 0 0&quot; &gt; /sys/class/scsi_host/host0/scan
</code></pre>
<hr />
<h2>If still nothing — aacraid rescan</h2>
<p>The aacraid driver has its own rescan mechanism separate from the SCSI layer:</p>
<pre>
<code># Check if the driver exposes a rescan interface
ls /sys/bus/pci/drivers/aacraid/
</code></pre>
<pre>
<code># Force PCI device rescan
echo 1 &gt; /sys/bus/pci/devices/0000:02:00.0/rescan
</code></pre>
<p>Then check <code>lsblk</code> again.</p>
<hr />
<h2>Nuclear option — modprobe cycle</h2>
<p>If the above all fail, the driver may need a full reload to properly register the block device:</p>
<pre>
<code>modprobe -r aacraid &amp;&amp; modprobe aacraid
dmesg | tail -30
lsblk
</code></pre>
<hr />
<p>The <code>sg_inq /dev/sg2</code> output is the most useful next step — it'll confirm whether this is genuinely a disk that the block layer has missed, or something else (e.g. a virtual device or BBU presented by the controller). What does it show?</p>
<p><span style="background-color:#ECF0F1">20:10 > Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: LENOVO-X Model: ST8000NM0075 Rev: LC77 Type: Direct-Access ANSI SCSI revision: 06 and srv9:/media2 # sg_inq /dev/sg2 standard INQUIRY: [PQ indicates LU temporarily unavailable] PQual=1 PDT=0 RMB=0 LU_CONG=0 hot_pluggable=0 version=0x06 [SPC-4] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=1 [BQue=0] EncServ=0 MultiP=1 (VS=0) [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 [Linked=0] [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=96 (0x60) Peripheral device type: disk Vendor identification: LENOVO-X Product identification: ST8000NM0075 Product revision level: LC77 Unit serial number: ZA19KPP00000R817QGA2 and I am now at the nuclear option which needed a power reset last time to regain control ;)</span></p>
<p>That hanging behaviour is a known issue with newer arcconf versions on some systems — it tries to connect to a management daemon that either isn't running or isn't compatible. Let's fix that.</p>
<h2>Check/start the management daemon</h2>
<p>arcconf relies on a background service:</p>
<pre>
<code>systemctl status arcconf
systemctl status StorMan
</code></pre>
<p>Try starting whichever exists:</p>
<pre>
<code>systemctl start arcconf
# or
systemctl start StorMan
</code></pre>
<p>Then retry <code>arcconf list</code>.</p>
<hr />
<h2>If no daemon exists, try the direct hardware access flag</h2>
<p>Some versions support bypassing the daemon:</p>
<pre>
<code>arcconf getconfig 1 --nologs
</code></pre>
<hr />
<h2>Alternative — use sg3_utils directly instead</h2>
<p>Since arcconf is being awkward, we can interrogate the controller and disk state directly. You already have sg3_utils working:</p>
<pre>
<code>sg_readcap /dev/sg2
</code></pre>
<pre>
<code>sg_turs /dev/sg2
</code></pre>
<p><code>sg_turs</code> sends a <strong>Test Unit Ready</strong> command — the response will tell us exactly why the controller is reporting <code>PQual=1</code>. It'll return one of:</p>
<ul>
<li>A sense key like <strong>NOT READY</strong> with an additional code that pinpoints the cause (e.g. logical unit not configured, becoming ready, format in progress)</li>
</ul>
<p>That sense key response is really what we need — it'll tell us whether this is a controller configuration issue or something else entirely.</p>
<p>Let's dig into this. The blank <code>sg_map</code> entry for <code>/dev/sg2</code> is actually normal/expected behaviour — it just means that device is a non-disk type (like an enclosure services device or expander), so don't worry about that.</p>
<p>Let's walk through getting your SAS disk properly mounted.</p>
<h2>1. Confirm the disk is visible and identify it</h2>
<pre>
<code>lsblk -o NAME,SIZE,TYPE,TRAN,MODEL,SERIAL
</code></pre>
<p>Also run:</p>
<pre>
<code>sg_map -x
</code></pre>
<p>The <code>-x</code> flag shows the device type — type <code>0</code> is a disk, type <code>13</code> is an enclosure, etc. The blank against <code>/dev/sg2</code> is likely one of those non-disk types.</p>
<hr />
<h2>2. Check what the kernel actually sees</h2>
<pre>
<code>dmesg | grep -E &#39;sd[a-z]|scsi|aacraid&#39; | tail -30
</code></pre>
<p>The Adaptec ASR-5405Z uses the <strong>aacraid</strong> driver on Linux, so you should see it referenced. Look for lines attaching sdX devices.</p>
<hr />
<h2>3. Identify your SAS disk's block device</h2>
<pre>
<code>lsblk
fdisk -l
</code></pre>
<p>You're looking for an unpartitioned or unformatted disk — it'll show as a raw device like <code>/dev/sdb</code> or <code>/dev/sdc</code> with no children.</p>
<hr />
<h2>4. Partition the disk (if needed)</h2>
<p>If it's a fresh/bare disk with no partition table:</p>
<pre>
<code>parted /dev/sdX mklabel gpt
parted /dev/sdX mkpart primary ext4 0% 100%
</code></pre>
<p>Replace <code>sdX</code> with your actual device. If it already has partitions, skip to step 5.</p>
<hr />
<h2>5. Format the partition</h2>
<pre>
<code>mkfs.ext4 /dev/sdX1
</code></pre>
<p>Or <code>xfs</code> if you prefer:</p>
<pre>
<code>mkfs.xfs /dev/sdX1
</code></pre>
<hr />
<h2>6. Mount it</h2>
<pre>
<code>mkdir -p /mnt/sasdisk
mount /dev/sdX1 /mnt/sasdisk
</code></pre>
<p>Verify:</p>
<pre>
<code>df -h /mnt/sasdisk
</code></pre>
<hr />
<h2>7. Make it persistent (fstab)</h2>
<p>Get the UUID:</p>
<pre>
<code>blkid /dev/sdX1
</code></pre>
<p>Then add to <code>/etc/fstab</code>:</p>
<pre>
<code>UUID=your-uuid-here /mnt/sasdisk ext4 defaults 0 2
</code></pre>
<hr />
<h2>Key question before going further</h2>
<p>Run <code>lsblk</code> and <code>sg_map -x</code> and paste the output — that'll confirm exactly which <code>/dev/sdX</code> is your new SAS disk and whether it needs partitioning or already has data on it. That'll make sure we don't touch the wrong device.</p>
<p><span style="background-color:#ECF0F1">20:03 > lsblk only lists the disks that have entries in sg_map and -X gives srv9:/media2 # sg_map -x /dev/sg0 2 0 0 0 0 /dev/sda /dev/sg1 2 0 1 0 5 /dev/sr0 /dev/sg2 0 1 0 0 0 /dev/sg3 3 0 0 0 0 /dev/sdb /dev/sg4 5 0 0 0 0 /dev/sdc /dev/sg5 6 0 0 0 0 /dev/sdd Step 2 shows the 4 other disk and the DVD drive mounting, but srv9:/media2 # dmesg | grep -E 'aacraid' | tail -30 [ 2.018564] [ T418] Adaptec aacraid driver 1.2.1[50983]-custom [ 2.046734] [ T9] aacraid 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 2.048446] [ T9] aacraid: Comm Interface enabled [ 2.272724] [ T9] aacraid 0000:02:00.0: 64 Bit DAC enabled [ 2.307024] [ T9] scsi host0: aacraid Step 3 fails because /dev/sg2 is not seen as a block device, it's THAT which I need to fix as none of the rest will do anything until there is a /dev/sde entry in sg_map</span></p>
<p>Ah, now I see the problem clearly. <code>/dev/sg2</code> has <strong>no corresponding block device</strong> (<code>/dev/sdX</code>) — the SCSI generic device exists but the kernel never created a block device for it. This is a known aacraid quirk where the controller sees the disk but the block layer doesn't get properly notified.</p>
<h2>Diagnose first</h2>
<pre>
<code>cat /proc/scsi/scsi
</code></pre>
<p>Look for a <code>Host: scsi0</code> entry with <code>Channel: 01 Id: 00</code> — that's your missing disk. Also:</p>
<pre>
<code>sg_inq /dev/sg2
</code></pre>
<p>This will tell you exactly what's on the other end — confirm it's actually a disk (Device_type=0).</p>
<hr />
<h2>Force the block device to materialise</h2>
<p>The sg device exists but the block device wasn't created. Try forcing it:</p>
<pre>
<code>echo &quot;- - -&quot; &gt; /sys/class/scsi_host/host0/scan
</code></pre>
<p>Then immediately check:</p>
<pre>
<code>lsblk
dmesg | tail -20
</code></pre>
<p>If that doesn't work, target it more precisely using the channel/id/lun from <code>sg_map -x</code> — your <code>/dev/sg2</code> shows <code>0 1 0 0</code> meaning <strong>host 0, channel 1, id 0, lun 0</strong>:</p>
<pre>
<code>echo &quot;1 0 0&quot; &gt; /sys/class/scsi_host/host0/scan
</code></pre>
<hr />
<h2>If still nothing — aacraid rescan</h2>
<p>The aacraid driver has its own rescan mechanism separate from the SCSI layer:</p>
<pre>
<code># Check if the driver exposes a rescan interface
ls /sys/bus/pci/drivers/aacraid/
</code></pre>
<pre>
<code># Force PCI device rescan
echo 1 &gt; /sys/bus/pci/devices/0000:02:00.0/rescan
</code></pre>
<p>Then check <code>lsblk</code> again.</p>
<hr />
<h2>Nuclear option — modprobe cycle</h2>
<p>If the above all fail, the driver may need a full reload to properly register the block device:</p>
<pre>
<code>modprobe -r aacraid &amp;&amp; modprobe aacraid
dmesg | tail -30
lsblk
</code></pre>
<hr />
<p>The <code>sg_inq /dev/sg2</code> output is the most useful next step — it'll confirm whether this is genuinely a disk that the block layer has missed, or something else (e.g. a virtual device or BBU presented by the controller). What does it show?</p>
<p><span style="background-color:#ECF0F1">20:10 > Host: scsi0 Channel: 01 Id: 00 Lun: 00 Vendor: LENOVO-X Model: ST8000NM0075 Rev: LC77 Type: Direct-Access ANSI SCSI revision: 06 and srv9:/media2 # sg_inq /dev/sg2 standard INQUIRY: [PQ indicates LU temporarily unavailable] PQual=1 PDT=0 RMB=0 LU_CONG=0 hot_pluggable=0 version=0x06 [SPC-4] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=1 [BQue=0] EncServ=0 MultiP=1 (VS=0) [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 [Linked=0] [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=96 (0x60) Peripheral device type: disk Vendor identification: LENOVO-X Product identification: ST8000NM0075 Product revision level: LC77 Unit serial number: ZA19KPP00000R817QGA2 and I am now at the nuclear option which needed a power reset last time to regain control ;)</span></p>
<p>That hanging behaviour is a known issue with newer arcconf versions on some systems — it tries to connect to a management daemon that either isn't running or isn't compatible. Let's fix that.</p>
<h2>Check/start the management daemon</h2>
<p>arcconf relies on a background service:</p>
<pre>
<code>systemctl status arcconf
systemctl status StorMan
</code></pre>
<p>Try starting whichever exists:</p>
<pre>
<code>systemctl start arcconf
# or
systemctl start StorMan
</code></pre>
<p>Then retry <code>arcconf list</code>.</p>
<hr />
<h2>If no daemon exists, try the direct hardware access flag</h2>
<p>Some versions support bypassing the daemon:</p>
<pre>
<code>arcconf getconfig 1 --nologs
</code></pre>
<hr />
<h2>Alternative — use sg3_utils directly instead</h2>
<p>Since arcconf is being awkward, we can interrogate the controller and disk state directly. You already have sg3_utils working:</p>
<pre>
<code>sg_readcap /dev/sg2
</code></pre>
<pre>
<code>sg_turs /dev/sg2
</code></pre>
<p><code>sg_turs</code> sends a <strong>Test Unit Ready</strong> command — the response will tell us exactly why the controller is reporting <code>PQual=1</code>. It'll return one of:</p>
<ul>
<li>A sense key like <strong>NOT READY</strong> with an additional code that pinpoints the cause (e.g. logical unit not configured, becoming ready, format in progress)</li>
</ul>
<p>That sense key response is really what we need — it'll tell us whether this is a controller configuration issue or something else entirely.</p>