JorgeB

Non correcting parity check is a good test.

This is a RAID controller and not recommended for Unraid, but it might work if you initialize/export the disks, note that all disks are detected by the controller: Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:0:0: added RAID HP H240 controller SSDSmartPathCap- En- Exp=1 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:1:0: masked Direct-Access HITACHI HUS723020ALS641 PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:2:0: masked Direct-Access ATA WDC WD20EARX-008 PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:3:0: masked Direct-Access HITACHI HUS723020ALS641 PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:4:0: masked Direct-Access ATA WDC WD20EURX-63T PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:5:0: added Direct-Access ATA WDC WD20EURX-64H PHYS DRV SSDSmartPathCap- En- Exp=1 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:6:0: masked Direct-Access ATA WDC WD20EURX-63T PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:7:0: masked Direct-Access ATA ST8000VN0022-2EL PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:8:0: masked Direct-Access ATA WDC WD20EURX-64H PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:9:0: added Direct-Access ATA WDC WD30EURX-63T PHYS DRV SSDSmartPathCap- En- Exp=1 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:10:0: added Direct-Access ATA WDC WD30EURX-63T PHYS DRV SSDSmartPathCap- En- Exp=1 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:11:0: masked Direct-Access ATA CT500MX500SSD1 PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:12:0: masked Direct-Access ATA Samsung SSD 840 PHYS DRV SSDSmartPathCap- En- Exp=0 Aug 30 17:14:50 UnDragon kernel: hpsa 0000:0d:00.0: scsi 7:0:13:0: masked Enclosure HP Gen8 ServBP 12+2 enclosure SSDSmartPathCap- En- Exp=0 Looks like the ones that are being detected by Unraid are the ones with Exp=1 in then end, I never used any of these controllers, but maybe Exp means export, check controller BIOS for options.

Unfortunately there's nothing logged about the crash: Aug 30 07:31:37 Tower kernel: w83795 0-002f: Failed to set bank to 128, err -6 Aug 30 07:31:37 Tower kernel: w83795 0-002f: Failed to set bank to 128, err -6 Aug 30 07:31:37 Tower kernel: w83795 0-002f: Failed to set bank to 128, err -6 Aug 30 07:31:37 Tower kernel: w83795 0-002f: Failed to set bank to 128, err -6 Aug 30 07:31:37 Tower kernel: w83795 0-002f: Failed to set bank to 128, err -6 Aug 30 07:31:37 Tower kernel: w83795 0-002f: Failed to set bank to 128, err -6 Aug 30 07:46:37 Tower kernel: microcode: microcode updated early to revision 0x1f, date = 2018-05-08 Mostly the log spam mentioned by trurl, last entry is after the crash.

The extended SMART test failed on both disks with a read error, this is a disk problem, can't be controller/cable related.

Changed Status to Closed

Going to close this for now then.

It not a software problem, it's not being detected at a hardware level, like if there's no NIC there.

I don't know, I only use Mellanox, but before we can't see if there's a driver or not the NIC must be detected at the hardware level, and it's not.

If you mean the array is not auto-starting after boot it's because auto-start is disable, change to enable in Settings -> Disk Settings

NIC is not being detected by Linux/Unraid in the device list, this is not a software issue, try a different slot if available or check if it works in a different computer.

Then it's not parity protected.

Unfortunately there's nothing logged that points to what's causing the crashing, would suggest downgrading to the previous version you were running to confirm if crashing stops and it's not for example hardware related.

Do you mean the unassigned device? If yes please use the existing plugin support thread:

Is this an array drive?

This usually indicates a drive error, xfs_repair won't work if there are read errors, you can try cloning the disk with ddrescue then run xfs_repair on the clone.

Unless all your data is not important they should be replaced, don't forget that Unraid requires all other disks to be OK to rebuild a failed disk.

Unlikely that was the problem, unless there were also filesystem corruption besides the main problem, main problem is this: This is what Unraid uses to detect the filesystem when set to auto, since it can't detect it won't try to mount, blkid not showing correct output means something is wrong there, but you're not the first with this and as long as the filesystem is manually set it shouldn't cause any other issues, but you must remember that if in the future you do a new config you'll need to set this again.

Basically of you have to rule out any of these:

No NIC being detect, either it's disable in the BIOS or it's not working, check BIOS or use add-on NIC.

Can't see how that is possible, number of devices his checked before array start, it won't start with more devices than the license allows, likely some disk(s) had dropped offline, so they din't count.

Yes, Docker service should be disable, mover should also move them to the array for cache=yes, we'd need diags with mover logging enable to see the problem it it doesn't work.

You'll likely need to force it.

Boot Unraid, run two consecutive correcting parity checks and post new diags.

Yes.