History of ASR-5405Z Configuration Notes

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?

Let's dig into this. The blank sg_map entry for /dev/sg2 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.

OK The starting point here is that I'd picked up an 8Tb SAS disk drive as the price was good not spotting that it was not SATA. As it turns out it has probably done me a favour as fixing the problem has provided another 4 disk connections on the media server, and since there is still an empty slot in the hot swap cage I can now fill up the machine. When the disk first arrived I simply plugged it in and it powered up fine, but I could not see it, at least not with the tools I was initially using. It was not until I tried to plug it into the USB SATA box to try that path that I found the connectors are actually different. Then I picked up on the mistake. A couple of suggestions were made on a suitable extra controller, but all were long lead time from China, and I get impatient ;) but digging around, the ASR-5405Z popped up in the refurbished area on eBay at only £14 delivered. At that price it was a little of a no-brainer, and a quick check confirmed that it should work on Tumbleweed. Which actually it does. The first problem was while some of the SCSI management tools were showing that there was an extra disk, the card was obviously in a mode where it was still trying to establish it's setup, and the message I was getting from rescan-scsi-bus.sh was actually flagging that. What I should have concentrated on initially was the management tool arcconf which is not available from openSUSE repos, so Claude pointing me to Microchip was a useful poke. arcconf_v3_07_23980.zip includes a .rpm package which loaded without a problem ... well after I overrid the earlier arcconf_B26540.zip install of version 4. The discussion with Claude I think confirms that V4 version was hanging because it was awaiting for the controller to be ready, while V3 simply said initially that the controller did not exist. A later retry obtained the good news that there was a controller to play with, and the arcconf tools are essential to connect the drives to the controller and create the links to /dev/sdX.

Let's walk through getting your SAS disk properly mounted.

1. Confirm the disk is visible and identify it

Confirming the controller is seen

Also run:

Installing arcconf

The -x flag shows the device type — type 0 is a disk, type 13 is an enclosure, etc. The blank against /dev/sg2 is likely one of those non-disk types.

2. Check what the kernel actually sees

Download v3 from Microchip — v4 hangs waiting for controller, v3 responds immediately:

The Adaptec ASR-5405Z uses the aacraid driver on Linux, so you should see it referenced. Look for lines attaching sdX devices.

3. Identify your SAS disk's block device

You're looking for an unpartitioned or unformatted disk — it'll show as a raw device like /dev/sdb or /dev/sdc with no children.

4. Partition the disk (if needed)

If it's a fresh/bare disk with no partition table:

Check controller and disk status

Replace sdX with your actual device. If it already has partitions, skip to step 5.

Look for disk showing as Ready before proceeding.

5. Format the partition

Create JBOD to expose disk as block device

Or xfs if you prefer:

Where `0 0` is channel and device ID from getconfig output.

6. Mount it

Verify block device created

Verify:

7. Make it persistent (fstab)

Get the UUID:

Then add to /etc/fstab:

Key question before going further

Run lsblk and sg_map -x and paste the output — that'll confirm exactly which /dev/sdX 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.

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

Ah, now I see the problem clearly. /dev/sg2 has no corresponding block device (/dev/sdX) — 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.

Diagnose first

Look for a Host: scsi0 entry with Channel: 01 Id: 00 — that's your missing disk. Also:

This will tell you exactly what's on the other end — confirm it's actually a disk (Device_type=0).

Force the block device to materialise

The sg device exists but the block device wasn't created. Try forcing it:

Then immediately check:

If that doesn't work, target it more precisely using the channel/id/lun from sg_map -x — your /dev/sg2 shows 0 1 0 0 meaning host 0, channel 1, id 0, lun 0:

Partition and format

If still nothing — aacraid rescan

The aacraid driver has its own rescan mechanism separate from the SCSI layer:

Mount and add to fstab

Adding subsequent disks

Then check lsblk again.

Nuclear option — modprobe cycle

If the above all fail, the driver may need a full reload to properly register the block device:

The sg_inq /dev/sg2 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?

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 ;)

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.

Check/start the management daemon

arcconf relies on a background service:

Try starting whichever exists:

Then retry arcconf list.

If no daemon exists, try the direct hardware access flag

Some versions support bypassing the daemon:

Alternative — use sg3_utils directly instead

Since arcconf is being awkward, we can interrogate the controller and disk state directly. You already have sg3_utils working:

Same process — wait for Ready status in `arcconf getconfig 1 PD` before creating JBOD! 😄

sg_turs sends a Test Unit Ready command — the response will tell us exactly why the controller is reporting PQual=1. It'll return one of:

Extra Notes

XFS vs ext4 note — worth a line explaining why XFS for large media files and the 400GB saving on 8TB from no reserved blocks. The PQual=1 explanation — one line noting that "LU temporarily unavailable" is normal while the controller initialises, just wait it out rather than panicking.

That sense key response is really what we need — it'll tell us whether this is a controller configuration issue or something else entirely.

Developed with Claude AI assistance - Anthropic - April 2026