Everything posted by FlamongOle
-
[PLUGIN] Disk Location
Update 2019.03.10 Commit #63 - BUG: Removed harddrives did not show up in the Information list but got invisible instead. Commit #62 - MINOR ISSUE: Fix broken harddrive information. Parsing of lsscsi is redone.
-
[PLUGIN] Disk Location
I guess I have a solution now using some regexp and less modifications in general. As LUN is mainly not in use anymore, I just compress the Vendor ID into a "selfmade" LUN. Else it will rather check for the contents. Also fixed a bug I discovered, old removed drives will now be shown until removed manually under "Information" - will release this asap
-
[PLUGIN] Disk Location
I looked at it a bit, but I think I might try a different approach based upon your data. However I feel it is strange you get a fallback value of Vendor ID instead of "none" as I get for some drives not including LUN. Just for the sake, what Unraid version are you using?
-
[PLUGIN] Disk Location
That is a bit of a bummer. I thought LUN always would be found. I might try to parse and compare and do some more checks and make a fallback myself.
-
[PLUGIN] Disk Location
That does not look like the output of "lsscsi -u -g", or at least not the first output. The LUN should not be visible with "lsscsi", and the ATA+Model Name should not be visible with "lsscsi -u -g" Also it appears to add an underscore after some spaces after the Model Name. It does split on a \s+ flag, meaning single and multiple spaces/tabs will be split correctly if the output of lsscsi is. I must say it is interesting if this is your output with the "-u -g" flags. The device model and serial number your drive shows is good for creating a hash. I still question the serial number a bit, if you have multiple of this SPCC disk check if you have any matching serial numbers as well. In short; if the output is truly what you show above from the exact command "lsscsi -u -g", then I might think this can be a bug from the lsscsi program. I don't see why it should have a different output unless the drive itself messes up with the parsing of lsscsi. Sorry if I can't help you enough here right now, but keep me posted if you find something useful.
-
[PLUGIN] Disk Location
Some SSD's might not include enough information to make a unique checksum. It must include "model" and "serial number" - this is as far as I've seen always included, if it's not; it will fail. It might also cause the layout to be messed up like you show it. Another reason might be that you assigned devices to the tray slots before storing the actual layout. Please check the drives if they give at minimum model+serial number, serial number has to be unique. I know for a fact that some less known brands might just put in a lot of zeroes instead of an actual number and hence won't work with this script. It won't be able to assign them either in any way.
-
[PLUGIN] Disk Location
Update 2019.03.09 Commit #60 - MINOR ISSUE: Warranty info is repeated for empty or non configured devices. Fixed by defining a variable as null.
-
[PLUGIN] Disk Location
Update 2019.03.08 Commit #58 - BUG: Invalid argument supplied for foreach(). Check if it is an array before searching in it, else default to false. @Nightowl805 You can test this now and check if that resolves the error message. I might need to dig in a bit deeper into this if it's not resolved.
-
[PLUGIN] Disk Location
It's impossible for anyone to know where your drives are located as the configurations out there varies a lot, so you must assign them manually the first time. So no automagic is happening there. For the error it looks like it might detect a false blank or something odd in the SMART rotational data. I'll fix this later.
-
[PLUGIN] Disk Location
To make it more precise about this syntax error; this means the updated harddisk data like SMART status, hours, load cycle count etc. is not updated when refreshing/loading the page. It will destroy some of the benefits of this plugin, so I highly recommend to update Unraid to 6.6+ But I'll leave that up to you of course, but the plugin will not work as intended.
-
[PLUGIN] Disk Location
USB drives are not supported, it has to be accessible via SAS/SATA controller. It is a very bad practice to follow the device node in general as it might shift node, it might be added in the future for the configuration - but I see no real use for it when it is accessible at the front page which is the main page for the overview. I also want to keep the configuration page/list as small as possible. The wish item is a task for design v2.0, this will not happen anytime soon though. Meanwhile you have to play with tray overrides, like 1*6 tray, and 10 for total trays for override. At least you can then separate them a bit.
-
[PLUGIN] Disk Location
The installer script is now updated. No other additional changes has been made, so an update won't bring anything new. New requirements are Unraid 6.6.0 and above, front page is updated. If you have earlier versions, the development package needs to be installed instead. This will -not- fix the SQLite syntax error issues, but it will be possible to install the script. Check the first page for more info on howto swap between stable and development branch.
-
[PLUGIN] Disk Location
I looked into the unraid changelogs; The version which supports "UPSERT" came in SQLite version 3.24.0. This version got included in Unraid 6.6.0. I guess then I have to conclude that this plugin is compatible with Unraid 6.6+, I weren't aware of this as I normally don't deal with SQLite but MySQL/MariaDB.
-
[PLUGIN] Disk Location
I would highly suggest and recommend to get a new connector instead (or fix it if possible, maybe just slightly bad connection with the pins - swapping the cable might help as well). I do not intend to fix something which is really not broken, and adding comments for empty trays might mess up the database and it will require a stupid amount of coding to just get that. Sorry I can't help you with this, at least not with this design.
-
[PLUGIN] Disk Location
Empty trays does not contain any data at all, it is simply one number that defines the empty tray slot and nothing can be added to it. That's why you can't add or view the comments.
-
[PLUGIN] Disk Location
@radfx & @GeekMajic What you can try to check if the SMART data actually get read, is to set a higher delay for "SMART execution delay" The plugin setting is a delay to be sure it has closed enough SMART instances before running new ones. It is mainly a nasty hack to be sure PHP has closed the run before opening too many new ones simultaneously which smartmontools does not like. A busy system might need a higher value, try 500 and 1000 just for the fun of diagnostics. It will/might take longer time to load the page with higher values. You can also try to run time smartctl -X /dev/sgX in the terminal to check how long time it takes to execute a SMART read. NB! The time it takes to read, has no influence over the setting for the plugin itself other than real time. If this does not help, either SMART is reporting false data or the drive gives weird values.
-
[PLUGIN] Disk Location
Update 2019.02.18b Commit #53 - MINOR ISSUE: Found the actual line, checks for disksize value before calculating human readable size. This should hopefully fix the warning message you got earlier
-
[PLUGIN] Disk Location
Which version of the plugin do you have? This issue should have been fixed some time ago. Yet the SSD is displayed when it find no rotation and it should also check for another input regarding solid state, it might not be 100% but then I can't do so much about it yet until smartmontools gets their info a bit better.
-
[PLUGIN] Disk Location
line 95 makes way more sense than line 9. You do not need to worry about that, it is only a converter for the harddisk size to convert from pure bytes to eg. TB. It faults when it does not receive anything. I'll fix this later.
-
[PLUGIN] Disk Location
Update 2019.02.18 Commit #53 - MINOR ISSUE: Replaced single quote to double quote for the definitions. Could cause some warnings to appear - maybe.
-
[PLUGIN] Disk Location
I might have fixed the warning message, but I'm not 100% certain about it. Next release will maybe help. It looks like the SMART data can't be read from the last SSD drive you have, as you can also see from the unraid page. Run smartctl manually on the drive and compare it with the other one. Are they connected on the same board? Maybe it might be some hardware controller issues, sometimes (rather often) a motherboard have multiple types of chipset/sata controllers on board. I might look into a mini version, but it has to be cached and running in the background in that case. As it will read smartdata to have any actual purpose, it might take time to do so and also interrupt the system drive by drive until it is finished. I dunno if that would be a good solution. I'll add it at github for possible future tasks, but don't count on it (at least for a while).
-
[PLUGIN] Disk Location
Yes, it is intended to work like this as people might change entire configuration and do more than one step at a time. Reorganizing of drives, adding or removing and then also swapping controller or motherboard would be hard to keep track on. That's why it is chosen to just use harddisk+slot.
-
[PLUGIN] Disk Location
Update 2019.02.14 Commit #51 - FEATURE: Added warranty left and comment options to be visible in the devices tab. These options has to checked and be saved in the configuration. For existing users, both comment and warranty must be activated and saved manually. For new users the warranty left is on by default.
-
[PLUGIN] Disk Location
Did it work without issues?
-
[PLUGIN] Disk Location
1: Yup, and believe me I wanted to avoid this as much as possible - and luckily won't be any problem in 6.7+ The first official stable version of this plugin will be near Unraid 6.7 stable launch, and then it will be required to use 6.7+. My main focus is to keep it working with the current stable release, and I like the current version number so no rush. 😈 2: I believe the plugin install script would reinstall them as the plugin itself? The packages and the plugin is stored at /boot, so those should "survive" (reinstall) a(t) reboot?!