FlamongOle

There's nothing I can do about it with this information at least. Open a pastebin (do not paste contents in here, only link), and copy&paste all the PHP errors. Include also the output of "lsscsi -u -g" and "ls -l /dev/bsg/"

Update 2019.02.04 - Commit #41 - BUG: Parity and cache did not save values into the database. - Commit #40 - IMPROVEMENT: Javascript and style sources now wrapped with autov()

Yup! That's because I forgot to actually add them to the save query, will be in the next release!

Update 2019.02.03 - Commit #38 - BUG: Array checked before count() - Commit #37 - BUG: Disk allocations in config and info tab sorted by ID and not tray when "empty = 0" - Commit #36 - FEATURE: Added color choice for parity and cache devices. - Updated the Help page a bit with some new information. Pre-release for you all (mainly because it's safer before I get more drunk) Have a nice weekend!

Thanks, this is now also fixed and will be included in the next release. It didn't check for empty or non-existing array

I think I figured out the problem, and it was a silly one. It happens if you assign all 24 drives with -no- empty drives because it uses another SQL query for that. It will be included in the next release in some few hours.

I have tried to modify my database back and forth a lot now, and I cannot make it fail for some reason. I tried the same configuration as you did and changed the dates and warranty, even the way "it shouldn't be done" - which should not cause any issues whatsoever. I have to ask if you do have the newest version installed? If you do, maybe you should try to delete the sqlite database manually and retry it from there. Be sure to not refresh any form data in the browser just after deleting it. Database is located at: /boot/config/plugins/disklocation/disklocation.sqlite EDIT: And more importantly: which browser are you using? It does require flex compatibility for sorting of the boxes as it is done client side. Newer Chrome-based browsers and Firefox is the only browsers which are tested for this plugin.

I guess that can be arranged in the near future, will also then add for cache drives. It will be released next update!

That look indeed strange, I know I did a bunch of rewrites earlier to get some stuff working yesterday. I will look into it and check what might cause the issue. It does however only use device model and serial number combined into a SHA string and are else sorted by the tray allocated number. Something is not right here. When it comes to the date warranty entry: "Unraid" will use dates written in Unraids own database if it exists, else from disklocations own datrabase. Unraid supports only "purchase date + X months of warranty". ISO date require full manual entry for those who want to lookup the factory date for warranty expire, and supports full date only. But that trigger has to be saved before you get the new row for warranty config.

Good to hear! Easy to forget some mandatory stuff when things are installed by other plugins

I updated the addon to install GIT by itself if it's missing, else it will upgrade it to the Slackware 14.2 package. Try the new package with normal update: 2019.02.02b

Oh! I see what's the problem here. Unraid does not have git installed by default, I see I have it manually installed via "NerdPack" - so for sure it should work if you install it from the NerdPack addon. That's probably a better approach than installing it via my plugin. I would prefer to have a direct access to git as it makes the job way more easy and faster to release.

Hmm, can you try to remove the plugin manually via Plugins -> Installed plugins and then install it again with the link below to check if that works: https://raw.githubusercontent.com/olehj/disklocation/master/disklocation-master.plg It works here, so I'm not sure what might have gone wrong. The database should stay intact while doing this. Must eventually wait for debugging until tomorrow when i sober up 😛 But try remove and reinstall, it does work here after removing cached files even etc.

New info posted on the frontpage (1st and 2nd post)

Update 2019.02.02 - Commit #33 - BUG: Settings not saved for fresh installs, fixed database query. - Changed installer to use git clone instead of a prebuilt archive. Current archive will be made for installation after reboots.

Or try to update now, I pushed .02 earlier

If you updated recently I can imagine why. Just hang on there, a new release is expected in some few hours. Try to update it then, next stable release is 2019.02.02, if you gor 2019.02.01[a-l] (a letter behind the date, then you just got bad luck)

You are absolutely right, and I know why! It happens only for newly created databases. To fix it before next update, do following in the terminal: # Download the new development file: wget https://raw.githubusercontent.com/olehj/disklocation/devel/disklocation/pages/system.php # And overwrite file with existing: mv system.php /usr/local/emhttp/plugins/disklocation/pages/system.php Refresh the plugin/browser and save! ..or wait for the next update release.

Update 2019.02.01 - Commit #31 - Improvement: Created a new SHA256 string of static device model name and serial number instead of using LUN. Should now remember devices regardless of controllers. Require a database upgrade (v2). - Commit #29 - BUG: Javascript: Added delay between kill and start/stop to the Locate button, should be more stable now. Thanks to TeeNoodle for debugging and testing.

Haha ye, I won't make a caseless layout Happy building tomorrow!

Thanks for the beer I will check if I can find a new Canadian craft beer (I assume you're from there based upon the currency)! Else I have just finished porting over from LUN to SHA256 string of model name and serial number, those should be valid for all drives and written on the device itself. So in the future it should be safe to swap controllers (motherboards etc) without loosing any information. Anyway, I expect to release the next update at 00:00 CET just in case I come up with some more or discover some sudden bugs 😛

Maybe it isn't that bad anyway.. it looks like this is specified by the hardware controller before the connected device. So rather a bad approach of defining hard drives at my end. I just saw some nice looking unique numbers and thought that would be a good idea, but I expect they might change if you change HW controller (like raid cards or motherboards). I better get down and changing this behavior to a MD5/SHA1 hashed number based upon family name, device model and serial number - I guess I never seen any drives (at least serious ones) without a serial number. Thanks for the info you provide, it helps me understand even more of how things might be setup.

That is actually a bit scary - typically everything will have a LUN in my mind. I do have it on my SSD drives and all other drives. For sure my script will fail if you add two of these drives as it is heavily depended on the LUN. You can check smartctl -i /dev/<path to device> if you get something else than a bunch of 0's. Look for: "LU WWN Device Id"

Ye, the SSDs can be a bit lacking when it comes to SMART information, and seems to work different with LEDs, temp works though. I have 2 identical SSDs so I need to check the serial number of the drive and hopefully have assigned the correct tray to it Be aware that this SMART locate might not work on a failed/failing drive, it is mainly meant as a guide for assigning the trays for later. But who knows, the board of the HD can break as well making the HD completely inaccessible - hopefully only one drive fail at the time

Sweet! Then it will be included in the next update