8 hours ago, Viperkc said:

Hi great plugin!  I am running 6.7.2 and get this error when installing the plugin:

 

Warning: SQLite3::query(): Unable to prepare statement: 1, no such table: settings_group in /usr/local/emhttp/plugins/disklocation/pages/system.php on line 1062

Fatal error: Uncaught Error: Call to a member function fetchArray() on boolean in /usr/local/emhttp/plugins/disklocation/pages/system.php:1064
Stack trace:
#0 {main}
thrown in /usr/local/emhttp/plugins/disklocation/pages/system.php on line 1064

 

Thanks
 

Try to delete it and reinstall it, if it still fails you have to delete the database manually and try again. Be sure to wait until the installation is done and reports it has done so successfully. 

 

rm /boot/config/plugins/disklocation/disklocation.sqlite

 

If you did an upgrade and want to keep settings, a backup file of v3 should be in the same folder. Just unpack it and write it over the existing database.

That worked perfectly.

 

Thank you

 

 

On 7/3/2019 at 9:01 PM, shaunmccloud said:

I decided to do three groups.  However, for some reason my cache disk is always set as unassigned for its color.  I think its because for some reason it wasn't getting the sdc identifier in the plugin.  A quick hack, I mean test in the SQLite database fixed it.

I tried this now and got the same problem, looks like something is partly ignoring the unraid flags, I'll look into it soon

@shaunmccloud It likely happened because your cache drive is an nvme drive and that unraid uses nvme0n1 device node name for identification. This would be left blank in this plugin as it saved only the device node, and not the scsi generic device node. It will now store scsigen dev node as dev node if it is empty.

In other words, should be fixed during next update.

Update 2019.07.06

• Commit #90 - IMPROVEMENT: Adding a console window for "Force Scan" button, making it easier to see what's going on in the background.
• Commit #89 - BUG: Cache drive get unassigned color if it is an nvme drive. Use SCSI generic device node name instead if device node name is null.

Update 2019.07.06b

• Commit #92 - MINOR ISSUE: defined a variable as array(), caused a count() warning message.

On 7/5/2019 at 5:23 AM, olehj said:

@shaunmccloud It likely happened because your cache drive is an nvme drive and that unraid uses nvme0n1 device node name for identification. This would be left blank in this plugin as it saved only the device node, and not the scsi generic device node. It will now store scsigen dev node as dev node if it is empty.

In other words, should be fixed during next update.

I wish I ghad a NVMe cache drive.  Its a Silicon Power 512GB SSD SATA drive.  I plan on adding 3 more to the cache array in the future.

 

https://amzn.to/2xB5kkJ

 

Its also showing as unassigned again, if you want I can get you my SQLLite database and any other information you need to debug it.

Edited July 6, 20197 yr by shaunmccloud

2 hours ago, shaunmccloud said:

I wish I ghad a NVMe cache drive.  Its a Silicon Power 512GB SSD SATA drive.  I plan on adding 3 more to the cache array in the future.

 

https://amzn.to/2xB5kkJ

 

Its also showing as unassigned again, if you want I can get you my SQLLite database and any other information you need to debug it.

what's the output of "lsscsi -u -g" ?

Quote

lsscsi -u -g
[0:0:0:0]    disk    none                              /dev/sdb   /dev/sg1
[1:0:0:0]    disk    none                              /dev/sda   /dev/sg0
[1:0:0:1]    enclosu 5000cca267c7c85b                  -          /dev/sg2
[4:0:0:0]    disk    ATA     SPCC Solid State Disk   _ /dev/sdc   /dev/sg3
[5:0:0:0]    disk    50014ee2bb6519d6                  /dev/sdd   /dev/sg4
[10:0:0:0]   disk    5000c5009601c9bf                  /dev/sde   /dev/sg5
[10:0:1:0]   disk    5000cca273e20246                  /dev/sdf   /dev/sg6
[10:0:2:0]   disk    5000cca267c7c85b                  /dev/sdg   /dev/sg7
[10:0:3:0]   disk    5000cca249d01cf9                  /dev/sdh   /dev/sg8
[10:0:4:0]   disk    5000cca22ec6c8c7                  /dev/sdi   /dev/sg9
[10:0:5:0]   disk    5000039ff4c65f0b                  /dev/sdj   /dev/sg10
[10:0:6:0]   disk    50014ee6032e79d4                  /dev/sdk   /dev/sg11
[10:0:7:0]   disk    5000c5007965cfa0                  /dev/sdl   /dev/sg12
[10:0:8:0]   enclosu none                              -          /dev/sg13

 

Edited July 6, 20197 yr by shaunmccloud

56 minutes ago, shaunmccloud said:

 

[4:0:0:0]    disk    ATA     SPCC Solid State Disk   _ /dev/sdc   /dev/sg3

 

There's the problem, for some odd reason, this "disk" does not get a LUN like the others, and falls back to "ATA SPCC Solid State Disk _" for whatever reason. I'm sorry I can't help you further here. I dunno why it hasn't received any LUN's though.

Has it been inserted with the server on, like hot swap? I dunno if that might be a problem or the SATA SSD controller itself. If a reboot doesn't help, then I dunno how to fix this. I never had that issue with any of the disks I had

6 minutes ago, olehj said:

[4:0:0:0]    disk    ATA     SPCC Solid State Disk   _ /dev/sdc   /dev/sg3

 

There's the problem, for some odd reason, this "disk" does not get a LUN like the others, and falls back to "ATA SPCC Solid State Disk _" for whatever reason. I'm sorry I can't help you further here. I dunno why it hasn't received any LUN's though.

Has it been inserted with the server on, like hot swap? I dunno if that might be a problem or the SATA SSD controller itself. If a reboot doesn't help, then I dunno how to fix this. I never had that issue with any of the disks I had

Probably the SSD controller. It's plugged directly into a SATA Port on the motherboard. And idea why I can change the color of it in the plug-in?  That's all I really care about. 

1 hour ago, shaunmccloud said:

Probably the SSD controller. It's plugged directly into a SATA Port on the motherboard. And idea why I can change the color of it in the plug-in?  That's all I really care about. 

Because of the output above, I assume it can't detect the disk to assign the color to. It will fail hitting the device nodes as the output is outside the specifications of what the plugin can handle at the moment.

I might ditch the entire LUN in the future as I mainly don't use that anymore if I remember correctly.

Edited July 7, 20197 yr by olehj

Update 2019.07.07

• Commit #94 - MINOR ISSUE: Some disks fail because of missing LUN. Skipping LUN during device validation, add LUN from SMART instead.

@shaunmccloud I am just way too nice 🥴

 

Do a "Force Scan All" to get all disks updated, the installer/updater only care about spinning disks (non-standby)! New devices may appear (like USB drives and SATA/RAID controllers) as they might provide SMART information... do whatever you want with them or just ignore them. Devices without SMART "serial number" and "model name" will be skipped, and they play a vital role in the database system - this will not be changed.

That works much better, thank you.

I changed the color of the data disks to a darker green (makes it easier to read the white text).  However, it only changed the data disks colors as shown.  The other 2 in slots 11 and 14 are still the default green.

 

Edited July 9, 20197 yr by JasonK

4 hours ago, JasonK said:

I changed the color of the data disks to a darker green (makes it easier to read the white text).  However, it only changed the data disks colors as shown.  The other 2 in slots 11 and 14 are still the default green.

 

Did you make sure that:

- You changed the "Data" color under the "Configuration" tab and not the "Custom color" under "Tray Allocations"
- Does not try to use the same color for "Custom color" as for those pre-defined under "Configuration"?

Custom colors works as an override and can not be the same as "Parity" "Cache" "Data" "Empty" or "Unassigned" pre-defined colors. Try to change 11 and 14 to f.eks. #FF0000 to see if it saves and uses those values, to reset to colors, you can use the predefined colors and it will automatically ignore it and use the pre-defined instead.

Update 2019.07.10

• Commit #98 - IMPROVEMENT: Added color list for color selection under the "Configuration" tab.

7 hours ago, olehj said:

Did you make sure that:

- You changed the "Data" color under the "Configuration" tab and not the "Custom color" under "Tray Allocations"
- Does not try to use the same color for "Custom color" as for those pre-defined under "Configuration"?

Custom colors works as an override and can not be the same as "Parity" "Cache" "Data" "Empty" or "Unassigned" pre-defined colors. Try to change 11 and 14 to f.eks. #FF0000 to see if it saves and uses those values, to reset to colors, you can use the predefined colors and it will automatically ignore it and use the pre-defined instead.

I changed the colors in the configuration tab

12 hours ago, JasonK said:

I changed the colors in the configuration tab

The drives you assign has to be recognized as "Data" drives by Unraid and connected to the device node. There's nothing which can interfere with the main colors, sure you haven't stored some custom colors for disk 11 and 14?

Do you use a different card for these drives, than the other drives - like raid card or something. Maybe lsscsi doesn't pick up the device nodes and then won't find the function it is assigned for. For Unraid/main colors, it uses only device node and not the scsi generic device node. I have no documentation about what Unraid stores if it does not get the device node name.

4 hours ago, olehj said:

The drives you assign has to be recognized as "Data" drives by Unraid and connected to the device node. There's nothing which can interfere with the main colors, sure you haven't stored some custom colors for disk 11 and 14?

Do you use a different card for these drives, than the other drives - like raid card or something. Maybe lsscsi doesn't pick up the device nodes and then won't find the function it is assigned for. For Unraid/main colors, it uses only device node and not the scsi generic device node. I have no documentation about what Unraid stores if it does not get the device node name.

Nope - the data drives are all connected to the same sata/sas breakout cables connected to the motherboard.  The cache drives are connected to SATA header connections directly on the motherboard.

 

Here's the SCSI list from settings:

 

SCSI Devices

[0:0:0:0]disk SanDisk Cruzer Fit 1.00 /dev/sda 15.7GB

[1:0:0:0]disk ATA SAMSUNG SSD PM85 7D0Q /dev/sdd 256GB

[2:0:0:0]disk ATA SAMSUNG HD204UI 0001 /dev/sdj 2.00TB

[3:0:0:0]disk ATA Crucial_CT256MX1 MU01 /dev/sdk 256GB

[7:0:0:0]disk ATA ST4000DM000-1F21 CC54 /dev/sdb 4.00TB

[7:0:1:0]disk ATA TOSHIBA MD04ACA5 FP1A /dev/sdc 5.00TB

[7:0:2:0]disk ATA ST3000DM001-1E61 SC48 /dev/sde 3.00TB

[7:0:3:0]disk ATA ST3000DM001-9YN1 CC4B /dev/sdf 3.00TB

[7:0:4:0]disk ATA WDC WD40EZRX-00S 0A80 /dev/sdg 4.00TB

[7:0:5:0]disk ATA ST4000DM000-1F21 CC54 /dev/sdh 4.00TB

[7:0:6:0]disk ATA ST4000DM000-1F21 CC54 /dev/sdi 4.00TB

Edited July 10, 20197 yr by JasonK

32 minutes ago, JasonK said:

Nope - the data drives are all connected to the same sata/sas breakout cables connected to the motherboard.  The cache drives are connected to SATA header connections directly on the motherboard.

 

Then I suggest deleting the database and redo it, if that doesn't help, then I don't know what causes this. It should simply not be possible unless custom colors has been saved.

4 hours ago, olehj said:

Then I suggest deleting the database and redo it, if that doesn't help, then I don't know what causes this. It should simply not be possible unless custom colors has been saved.

How would I best do that?  I've had it rescan the drives.  As you see in the image above, the app shows the 2 bright green drives as data drives.

1 minute ago, JasonK said:

How would I best do that?  I've had it rescan the drives.  As you see in the image above, the app shows the 2 bright green drives as data drives.

Under "System Files" you can delete the database - you have to set up everything again, but it might help.

44 minutes ago, olehj said:

Under "System Files" you can delete the database - you have to set up everything again, but it might help.

Deleting the database and reconfiguring from scratch seems to have fixed the issue

 

Thanks

Good to hear!