Lev

I'm out of things to suggest to try in UnRAID. Does it the drive still work and partition OK in Windows? Last option I'd try in Windows is using whatever app Crucial has to wipe the drive and make sure it's got the latest firmware update. Good luck to you.

Show me the output of this command. The -n means it will take no action, it'll just output a list of partitions. wipefs -n /dev/<device>

This command may clear it, be extra sure you point it at the right device. sgdisk -Z /dev/<device>

Yes, you're right @ClintE, I have two servers, the 6.11 server exhibits the problem. The older 6.10 server does not. I upgraded the older 6.10 server to to the current 6.11.5, changed nothing else, now it also exhibit the problem. This is a good clue @dlandon, it's something with how UnRAID changed between 6.10 and 6.11 that's causing the conflict with UD.

@dlandon I can confirm their is some strange behavior with the Friefox browser with UD as @ClintE is reporting. I've been experiencing it for months? and been putting up with it, because I wasn't sure which plug-in was causing it, but finally had some time to look into it more. First I booted into UnRAID safe mode. Problem did not occur. Then I started uninstalling plug-ins one by one... When I uninstall UD, starting the array behaves normally. It's only when UD is installed that this problem occurs. This problem does not occur in safe mode. I tested with MS Edge and cannot reproduce. I don't have Chrome installed to test with. Here's what it looks like... UD is installed, using Firefox, I start the array... once the array is started and the page refreshes, Firefox prompts me with this. Diagnostics attached. I must click 'cancel' or else I'm in for a world of hurt, because the GUI will no longer work and I have to ssh to umount everything and reboot. tower2-diagnostics-20230115-1742.zip

I had the same experience after updating the UD plugin to the latest version just now. All my UD drives had been moved to history. Thanks for the quick fix you provided, it resolved the situation easily.

Works! 😃 Thank you @dlandon

@dlandon TL:DR Two problematic inconsistencies I've found with the naming convention for disk/by-id/scsi-* Either one or a mix of both maybe the root cause, please check. Supporting research is underneath in how I concluded this. If the _ underscore is being used as a delimiter in UD functions, it does not have strong consistency with SATA and with SCSI there is no consistency in its use in the naming convention for disk/by-id My guess is UD is unaware that the plugin once installed is altering the naming convention of disk/by-id/ specifically for SCSI devices, replacing the expected 'ID_SERIAL' with 'ID_SCSI_SERIAL' as this key is only encountered and present with SCSI disks, not ATA. See UDEVADM output below. UnRAID detection in the drop down list is consistent in naming convention 'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!) in both situations, plugin installed or NOT installed, my guess is the UnRAID detection function may have a conditional IF 'ID_BUS' = 'scsi' then use 'ID_SCSI_SERIAL' instead of 'ID_SERIAL' that aligns with how the plugin also uses 'ID_SCSI_SERIAL'for only SCSI disks. Supporting Research It was not easy to map the two different ID's for the disk that were generated with the plugin installed and with it removed to make this simple table. Why? lsscsi and all it's various command options will not output it, it's UDEVADM and some logic code. Here's what's interesting, and why I'm sharing this... notice the naming convention naming convention is not the same between the SATA drives and the SAS/SCSI drives. In multiple ways. Pay close attention to the underscores between the keys, I think they are the delimiter and this maybe where some function is expecting one or two delimiters to be present to return the expected values. This inconsistency in naming convention looks like something that could cause some problems like what we are seeing. SATA disk disk/by-id/ata-WDC_WD140EDGZ-11B2DA2_3HG65VTN Naming convention: 'ID_BUS'(not Unique)-'ID_SERIAL'(Unique!) root@tower2:~# udevadm info --query=all --name=/dev/sdg P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:52/1:0:52:0/block/sdg N: sdg S: disk/by-id/ata-WDC_WD140EDGZ-11B2DA2_3HG65VTN S: disk/by-id/wwn-0x5000cca29dc2d03d S: disk/by-path/pci-0000:01:00.0-scsi-0:0:52:0 E: DEVLINKS=/dev/disk/by-id/ata-WDC_WD140EDGZ-11B2DA2_3HG65VTN /dev/disk/by-id/wwn-0x5000cca29dc2d03d /dev/disk/by-path/pci-0000:01:00.0-scsi-0:0:52:0 E: DEVNAME=/dev/sdg E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:52/1:0:52:0/block/sdg E: DEVTYPE=disk E: ID_ATA=1 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_FEATURE_SET_APM=1 E: ID_ATA_FEATURE_SET_APM_ENABLED=0 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_PUIS=1 E: ID_ATA_FEATURE_SET_PUIS_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=65538 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=66774 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_ROTATION_RATE_RPM=7200 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_BUS=ata E: ID_MODEL=WDC_WD140EDGZ-11B2DA2 E: ID_MODEL_ENC=WDC\x20WD140EDGZ-11B2DA2\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=b7673fa9-3326-4df7-a432-ef769fc82c7e E: ID_PATH=pci-0000:01:00.0-scsi-0:0:52:0 E: ID_PATH_TAG=pci-0000_01_00_0-scsi-0_0_52_0 E: ID_REVISION=85.00A85 E: ID_SERIAL=WDC_WD140EDGZ-11B2DA2_3HG65VTN E: ID_SERIAL_SHORT=3HG65VTN E: ID_TYPE=disk E: ID_WWN=0x5000cca29dc2d03d E: ID_WWN_WITH_EXTENSION=0x5000cca29dc2d03d E: MAJOR=8 E: MINOR=96 E: SUBSYSTEM=block E: USEC_INITIALIZED=33560058 SAS/SCSI disk (Plugin NOT installed) Full Identifier: ST12000NM002G_ZLW0QFJV0000C0438211_35000c500ca3d8cbf Naming convention: 'ID_BUS'(not Unique)-'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!)'_'ID_SERIAL'(Unique!) disk/by-id/scsi-35000c500ca3d8cbf (there's not a single _ delimiter) Naming convention: 'ID_BUS'(not Unique)-'ID_SERIAL'(Unique! SAS/SCSI disk (Plugin INSTALLED) Full Identifier: ST12000NM002G_ZLW0QFJV0000C0438211_35000c500ca3d8cbf Naming convention: 'ID_BUS'(not Unique)-'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!)_'ID_SERIAL'(Unique!) disk/by-id/scsi-ST12000NM002G_ZLW0QFJV0000C0438211 (there's one _ delimiter) 'ID_BUS'(not Unique)-'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!) A few things jump out at me... disk/by-id/ naming convention is changed by the plugin to use 'ID_SCSI_SERIAL' instead of 'ID_SERIAL' On a SCSI disk, 'ID_SCSI_SERIAL' is strictly the SCSI serial number integer data type, 'ID_SERIAL' is a data type which appears to a data conversion of the hexidecmal WWN of the disk. See UDEVADM output below for SCSI SAS and then scroll back up to compare against ATA. It's a mess. Comparing the two UDEVADM outputs you'll notice the ATA device where 'ID_SERIAL' returns a long string data type, with _ underscores as delimiters for 2 other data keys, 'ID_MODEL'_'ID_SERIAL_SHORT' Also 'ID_MODEL' WDC contains a _ delimiter with value returned to complicate things further. Ugh. root@tower2:~# udevadm info --query=all --name=/dev/sdk P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:62/1:0:62:0/block/sdk N: sdk S: disk/by-id/scsi-35000c500ca3d8cbf S: disk/by-id/wwn-0x5000c500ca3d8cbf S: disk/by-path/pci-0000:01:00.0-scsi-0:0:62:0 E: DEVLINKS=/dev/disk/by-id/scsi-35000c500ca3d8cbf /dev/disk/by-id/wwn-0x5000c500ca3d8cbf /dev/disk/by-path/pci-0000:01:00.0-scsi-0:0:62:0 E: DEVNAME=/dev/sdk E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:62/1:0:62:0/block/sdk E: DEVTYPE=disk E: ID_BUS=scsi E: ID_MODEL=ST12000NM002G E: ID_MODEL_ENC=ST12000NM002G\x20\x20\x20 E: ID_PATH=pci-0000:01:00.0-scsi-0:0:62:0 E: ID_PATH_TAG=pci-0000_01_00_0-scsi-0_0_62_0 E: ID_REVISION=E003 E: ID_SCSI=1 E: ID_SCSI_SERIAL=ZLW0QFJV0000C0438211 E: ID_SERIAL=35000c500ca3d8cbf E: ID_SERIAL_SHORT=5000c500ca3d8cbf E: ID_TYPE=disk E: ID_VENDOR=SEAGATE E: ID_VENDOR_ENC=SEAGATE\x20 E: ID_WWN=0x5000c500ca3d8cbf E: ID_WWN_WITH_EXTENSION=0x5000c500ca3d8cbf E: MAJOR=8 E: MINOR=160 E: SUBSYSTEM=block E: USEC_INITIALIZED=33453336 UnRAID detection in the drop down list is consistent in naming convention 'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!) in both situations, see screenshot below, does not matter if plugin installed or NOT installed, it appears as UnRAID has the condition IF 'ID_BUS' = 'scsi' then use 'ID_SCSI_SERIAL' instead of 'ID_SERIAL' is my guess for its detection function.

yes. I just ran again, same output confirmed. ls /dev/disk/by-id

Here's the output of NOT Installed (left) and Installed (right) and the lines that are different. There are two things going on in this, I'll start with the most straight forward. Lines 15-18 on the left are lines 23-26 on the right, but out of order. These are four unassigned Seagate SAS disks using JBOD pass-through on a LSI 3108 RAID controller. Below is a table I created showing just these four drives in aligned order to make it less confusing. Best to focus on any of these four drives, but I'll explain what other more complicated thing going on is, because it may give you a clue, or it may just confuse you. In that case just ignore what I'm about to say. Lines 19-26 on the left are lines 15-22 on the right, but out of order. These are four logical RAID disks on the same LSI 3108 RAID Controller. All four of these disks are 'Assigned' successfully to UnRAID on the left (plugin Not Installed) but on the right are 'UnAssigned' (plug Installed) because it no longer matches what value UnRAID has stored to flag the disk as 'Assigned'. However as you can see UnRAID is able to detect all the SAS and RAID drives as they are visible in the drop down selection list and makes no difference whether the plug-in is installed or not. screenshot below with dynamix.scsi.device plugin NOT installed. Notice UnRAID assignments and detection is working. UD detection is working. screenshot below with dynamix.scsi.device plugin INSTALLED... Notice UnRAID no longer sees assigned SAS & RAID disks, however detection of those disks is working. UD detection is NOT working.

Not fixed. Same behavior I observed previously. Soon as I installed dynamix.scsi.device plugin the SAS drives that were showing in UD are no longer detected UD. Attached are two diagnostics. One with the dynamix.scsi.device plugin installed, one without it. Hopefully the difference will stand out. tower2-diagnostics-20220104-1236-dynamix.scsi.device REMOVED.zip tower2-diagnostics-20220104-1215-dynamix.scsi.device INSTALLED.zip

will happily test in the coming days 😃 happy others confirmed this issue after I spent so many hours trying to isolate.

I used UnRAID to format the Seagate 12TB SAS disks. but I found what other plug-in is causing the issue of the SAS drives not being detected. So it had nothing to do with how the drive was formatted. The plug-in that is causing the issue for the SAS drives with UD is 'Dynamix SCSI Devices'. I've run this plug-in along with UD for years and never had a issue with SATA drives. But this is my first time with SAS drives, and clearly it's causing some type of confusion. I remove the Dynamix SCSI device plug-in, reboot, and UD detects the SAS drives just fine. If I install the Dynamix SCSI Devices plug-in, the SAS drives in UD immediately disappear from UD. I've reproduced this on two UnRAID servers now with the SAS drives. Dynamix SCSI Devices and the reasons I first used it years ago, may no longer be needed with today's 6.10.x version of UnRAID. So I'm going to move forward and no longer use that plug-in and see what happens.

@dlandon all has been resolved. I formatted and recreated the UnRAID USB drive, installed only UD plug-in. All SAS drives are detected as expected. No clue what could of be conflicting in the previous install. I'll slowly add back the other plug-ins and check. Thanks again for all your help.

Another test. I removed the Areca and disabled the MegaRAID 3108 on the motherboard jumpers. I installed a LSI 2008 HBA card and connected to a backplane. The LSI 3008 HBA is still connected to its backplane. UD cannot detect the Seagate ST12000NM002G drives on either controller. UnRAID can see them. Definitely something about these hard drives metadata is different than UD is expecting.

Thanks for the info, this will help as I look deeper at the functions. I have new information to share, its not what I was expecting... I was never sure how all this would work out with the 3108 IR mode controller that's embedded in my motherboard. So last week I ordered a 3008 IT mode controller, which is the most widely recommended HBA LSI chipset for SAS3 on UnRAID. It arrived yesterday and I installed it. Firmware has been updated to latest release. I damn near fell out of my chair when UD exhibited the same behavior in regards to the SAS drives we've been talking about. Up until now, I had been assuming, and perhaps you have too, that the behavior I'm seeing with UD not detecting the six SAS disks was due to using a unsupported 3108 controller in JBOD pass through mode that must be messing with the how the disks are being reported. Now I can recreate the same behavior on a HBA. This is not what I was expecting. My plan was to install the HBA, see UD behaves as expected, detects the SAS drives correctly and then I'd move on from the 3108 and use the 3008 HBA. All I really wanted to was to get confidence in that 3108 controller. I got that, and want to thank you for your help over the last few days. Now I'd describe this differently...What do you think about this issue now being reproducible on a HBA controller? No RAID controllers involved. Worth your time to dive in and investigate? If so I'm happy to help provide more logs and run tests for you. I have no data on these drives, and this server is not in operation yet.

Right, I'm following. When I look at the include/lib.php code, I don't see why it's not working on it's initial detection of unassigned disks. The serial numbers are unique that the controller is providing. However the 3108 is returning two /by-id/ when invoking 'udevadm' , the other controllers do not do this. It's passing through an additional /by-id/wwn- identifier for the drive in addition to the expected /by-id/scsi- . Is it possible that lib.php is expecting only one /by-id/ to be returned when one of the functions for disk detection invokes the 'udevadm' command and it returns two? Because everything so far that I've seen be detected only has the one /by-id/scsi-* value returned in 'udevadm' Areca: disk/by-id/scsi-ST12000NM002G_XV9J0000C0398824 3108: disk/by-id/scsi-ST12000NM002G_ZLW0XV9J0000C0398824 disk/by-id/wwn-0x5000c500ca42d697 Raw output log files attached.

@dlandon Success! LOL... but with a twist! Had a breakthrough this evening in narrowing down why this is behaving as it is. Come with me on this journey 😀 I took a single drive, ZLW0XV9J, its physical serial number on the outside label, picture below that is used to make the following example easier to explain. UnRAID can detect it when it's attached to the Areca or MegaRAID 3108 controller. UD cannot detect it, after reboot, when attached to the MegaRAID 3108 controller UD can detect it, after reboot, when attached to the Areca. <the twist is coming!> UD can detect it, when hot-swapped after reboot, from the Areca to the MegaRAID 3108 controller! I can mount it, everything works as expected when the drive is connected to the 3108 after it's been hot-swapped from the Areca. There's a difference in UD's drive detection code, starting in include/lib.php, between lines 1863 to 1902 is where *I THINK* explains UDs behavior. I hope I don't embarrass myself 🤦‍♂️ but few dare to read the code, but I do! I say this because the drive attributes returned from udevadm are different depending which controller the drive is attached too, as you'll see. That initial creation of the array of unassigned devices seems to be the point of deviation. Attached are the following details. ZLW0XV9J.jpg - This is a picture I took of the physical drive label for helpful reference point. SAS disk - Areca.PNG - This is ZLW0XV9J correctly identified in UD when attached to the Areca controller. SAS disk - 3108hotswappedFromAreca.PNG - This is ZLW0XV9J correctly identified in UD after its been hot-swapped from the Areca controller to the 3108 controller. 3108 drives.PNG - Screenshot from system devices showing that the drive is attached to the 3108 after the hot-swap. UDseesHotSwappedsasDrive.png - This is the money shot... ZLW0XV9J is visible in UD and UnRaid after it was hot-swapped from the Areca, but it's other 5 siblings (ST1200NM002G) are not visible in UD. udevadm outputs files - I ran command "udevadm info --query=all --name=/dev/sdab" after each change to document how each controller was reporting the information. 3 .txt. files are attached with how that the output of whats being reported changes.

Yes.... you're on to something here! lsscsi doesn't show serial numbers... I'm running the command udevadm now and finding some interesting differences in terms of how serial number are being reported between the SATA, SAS and RAID drives with the 3108 controller. udevadm is showing that the SAS and the RAID volumes have their serial number named as 'ID_SCSI_SERIAL' and the contents of the 'ID_SERIAL' align with what you said. I'm curious to check again on the Areca controller it's putting the serial number in 'ID_SERIAL', if so then that may explain it... I'll test and follow up. SATA drive E: ID_SERIAL=WDC_WD140EDGZ-11B2DA2_2CHHA9LP E: ID_SERIAL_SHORT=2CHHA9LP SAS drive E: ID_SCSI_SERIAL=ZLW0XV610000C0348ZZZ E: ID_SERIAL=35000c500ca42e0ab <-- this is not the serial number E: ID_SERIAL_SHORT=5000c500ca42e0ab

@dlandon I was curious if I switched back to the Areca controller, would anything in the lsscsi command stand out as a difference? Answer is no, unfortunately, I didn't find anything. But I took some screenshots so you can see how UD with the Areca controller behaves as expected, and same as UnRAID in this test scenario. Remember all the of the drive locations will have changed since I moved the cables from the 3108 to the Areca, so just look for the six ST12000NM002G in the lists. Also, this is to be expected but just in case you wonder why the 3 RAID volumes are not in the list. Instead the has the 6 HGST physical drives that were part of the RAID volumes that were created on the 3108. All normal behavior here.

Screenshot attached. Unassigned - Cache Drive.png Following your thinking, I thought I'd do a 'New Config' and get a screenshot of what appears in UD when there is no array defined. Screenshot Unassigned - New Config attached. This helped find a new clue... there are six more drives went undetected by UD that I did not previously notice which had been assigned in UnRAID. Drives: sdd, sde, sdf, sdg, sdh, sdi This is visible in the screenshot. So what's different about these 6 other drives? These six are SAS drives, that are passed thru the 3108 as JBOD drives.... same as the SATA drives also are passed thru the 3108 as JBOD drives. SAS vs SATA is the major difference in disk type. See attached 'lsscsi -g.png' for a picture to help illustrate. Summary of UD behavior by Controller type: MegaRAID LSI 3108 UD only detect SATA drives, passed thru as JBOD with this controller. Not detecting SAS or RAID volumes. UnRAID detects all three types of drives as unassigned. Areca 1883 UD detects all three types as unassigned. UnRAID detects all three types as unassigned. I'm back to wondering... what is the difference between UD's unassigned disk function in code, vs how UnRAID's function works in code to identify eligible disks the operating system has? For example, I noticed in the 'lsscsi -g.png' the VENDOR attribute is generic as 'ATA' for SATA, but for others it's not generic... SAS its 'SEAGATE' and for RAID its AVAGO.

Hi @dlandon I'm using a MegaRAID 3108 adapter that I haven't used previously and it's behaving a bit different than my Areca RAID adapter in UD. I'm trying to understand why... mostly just because I want to have confidence in using the 3108 going forward. First what is working... UnRAID detects and I can assign to array.the 3108 three RAID logical volume drives: sdt, sdu, sdv When unassigned, the three logical drives don't appear in the UD list. Any thoughts what it is about how these logical drives are defined that prevent UD from listing them?

Not sure what explains this being fixed, but good new is good news... first time in many versions I'm able to run the UnRAID GUI. I tested both legacy and EFI boot modes and both now work. Awesome, I very much missed this feature! 😃 Everytime I boot into the GUI, after login, Firefox has a message pop-up asking to be the default browser, and select a color theme. If there is a way to make these selections persist, so not prompted after each reboot, that would be make the user experience that much more elegant.

Perfect, I was wondering where this went, thanks for the explainer. I got it figured out. Early first impression after 2 minutes of use... I like it! Positive enhancements, thank you @dlandon !

Makes sense. Nevermind my suggestion.