madshi
Members
-
Joined
-
Last visited
-
Hey guys, currently running preclear on 2 disks. The log is getting flodded with messages like these: Feb 15 21:53:13 Tower preclear_disk_ZDH1NDE7[5373]: tput: unknown terminal "screen" I started the preclear via unassigned devices plugin. In the GUI everything appears fine, the unassigned devices section shows the preclear progress correctly, but the GUI just can't show my the syslog, anymore, due to "out of RAM". Not a big deal, but thought I'd report it.
-
P.S: After copying in both the 2.5 and 3.0 jar files for this addon to both addons folders I have now, it started to work. I'm not sure if it's the addons folder which I added to userdata, or if it's the path assignment to "/openhab/addons" I added to the docker.
-
I'm trying to install this one, which classifies as a "binding", as far as I can see, but needs to be manually copied to the "addons" folder: https://github.com/jannegpriv/openhab-addons/blob/8108-vwweconnect/bundles/org.openhab.binding.vwweconnect/README.md There's no "addons" folder in /appdata/openhab/userdata for me. I just now tried creating one and copying the jar file in there, as well. Then I restarted the docker but openhab still doesn't seem to find (or use) the jar file.
-
Hey there, thanks for this docker, it's working nicely! I've one problem, though: I'd like to install a custom addon, and the openhab "addons" folder does not seem to be available (?). I've tried adding a "/openhab/addons" -> "/mnt/user/appdata/openhab2/addons/" path setting to the docker, but it doesn't seem to be effective. Or at least openhab behaves as if the addon I copied there didn't exist. Any ideas?
-
dlandon: Thanks. It's not a dramatic problem, just a bit ugly, so I'll just wait it out. wgstarks: I'm not doing preclear often enough to make it worth running as a docker. Thanks for the suggestion, though.
-
I'm still having nervous behaviour with my running preclear actions. The preclear info comes and goes every 1-3 seconds. I just uninstalled and reinstalled the unassigned devices plugin, just to be safe I really have the latest. But the preclear refresh cycle still happens.
-
This happened with 6.3.5. I'm sorry, I'm not going to upgrade unRAID while my array is in unprotected state, so I can only report this issue with 6.3.5. I've had a power outage. After booting up, one disk was dead. I started the array, nevertheless. The missing disk is now being "emulated", which is nice. However, unRAID insisted on doing a full Parity check. Which makes no sense, whatsoever. I only have 1 Parity disk, and with one disk missing it means that a Parity check can't possible do any good. So unRAID shouldn't insist on doing a Parity check. Maybe unRAID should even disable the option to run a Parity check manually? Should be easy for you guys to check if this was already fixed in the latest unRAID build or not. It's not a dramatic problem, but it's more than an "Annoyance", because any disk accesses while the array is unprotected is "dangerous". So insisting on doing a useless full Parity check in this situation is a really bad idea, IMHO.
-
I can confirm the (double) fix to be effective - thank you very much!
-
While you're at it, the description reads: "This plugin is a parser for Joe L. excelent Preclear Disk Script". The "excellent" is missing an "l".
-
PHP 5.4.45 (cli) (built: Sep 19 2015 14:52:22) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies If this is really just in incompatability with unRaid 6.1.7 then I personally don't need a fix. I'm planning to upgrade to the latest unRaid as soon as my array rebuild is completed. Just wanted to run preclear to test the new harddisk before starting the rebuild.
-
@gfjardim, see attachment. TOWER-preclear.disk-20170630-1638.zip Maybe the latest plugin version doesn't like the old 6.1.7 unRaid version I'm still running?
-
I'm currently running unRaid 6.1.7 with the latest preclear plugin version. I have the following problem: The preclear.disc.log is constantly growing. At some point it's so large that \var\log is full. This seems like a bug? Is there any way to change preclear configuration so that the log doesn't exceed a certain file size?
-
Love this plugin, it's wonderful. Today I almost got a heart attack, though. I had preclear expected to be finished today, and it was, but the result was written in alarmingly red color, making me think for a split second that something dramatically bad had happened. But actually everything was perfectly alright. My suggestion would be to use a green font for successful preclear. And maybe a red font if something went wrong. In the end I don't care much about the color, but a red font for a successful operation is not a good choice, IMHO. Obviously this is an extremely minor complaint.