Frank1940

+1

But, those who help out those who don't read them, do read them. It is always helpful to have a reminder of obscure things that cause problems.

You should probably consider adding this information in the release notes on every new version (and all of its rc releases) for the next eight stable releases! That way, 99% of the users will have updated at least once during this sequence! (And I have not doubt there will be a post from someone five years down the road who finally decided to upgrade...)

No, you are encouraged to upgrade your version of unRAID. I am assuming that you are talking about the preclear plugin. That is a hit and miss proposition. I strongly suspect that preclear plugin interacts in some manner with a few other plugins (or, maybe even, Dockers). (At this point with an apparent lack of support for the preclear plugin, no other plugin developer is going to address any problem of interaction from one side of the problem!) If you are not using one of these plugins, everything may work fine, you are one of the lucky ones, and you are home free. If you have any problems after the OS upgrade, your first action should be to uninstall preclear and reboot.

Two things. First, if you have installed any type of popup or adblocker that you 'whitelist' your unRAID server. Second, what browser are you using? Is it the latest version? If possible, try another browser. (There was some issues a while back with this problem and they were browser related.)

I have just successfully precleared a disk using the patched plugin using unRAID version 6.5.0 Stable. See here for the patched version: https://lime-technology.com/forums/topic/54648-preclear-plugin/?page=72&tab=comments#comment-632655 Now for some words of caution!!!! First the original preclear plugin has caused problems for some users. This patched version does NOT address those issues. If you have any unexplained problems after installing it, uninstall it first to verify that might (or might not) be causing your problem. No one is going to be able (or willing) to help you if you have an issue with the this plugin!!! Because of these problems, the Fix Common Problems plugin will complain about its installation. Only you can decide whether to ignore this warning,. But you do so at your own risk. This patched version comes from a source which has not been vetted in any manner. Use it at your own risk. You can lessen this risk by reading the succeeding posts after the one linked above. You will observe that the one users determined that the only change made was the one which allowed the plugin to work. He also listed the md5 sum for the file that he checked. You should verify that you are getting the exact same file as the one checked. (If you don't understand what I am talking about, you would be best served by not installing it!)

I just tested this script using unRAID version 6.5.0 and it completed without error. I collected the report on this preclear operation using grep and it looked identical to those reports which I had previously generated by the same command. This script was version 1.15 and I modified it per Joe L.'s instructions to work with version 6.2.X and later. See here for details: https://lime-technology.com/forums/topic/12391-re-preclear_disksh-a-new-utility-to-burn-in-and-pre-clear-disks-for-quick-add/?page=53#comment-460592

You download the latest preclear shell script (version 1.15) and apply this patch. The patched version still works on the 6.5.0-rc releases. https://lime-technology.com/forums/topic/12391-re-preclear_disksh-a-new-utility-to-burn-in-and-pre-clear-disks-for-quick-add/?page=53#comment-460592

I don't use 'sleep' on either one of my servers. I have simply been following this recent discussion on failure to sleep on Sunday overnight and I have noticed this weekly occurrence of the cache drive being spunup (apparently to make the weekly Docker update check ) in the status report and jumped to an observation that the failure to sleep might be related to that event. (BTW, I always 'stop' Krusader after use as it will keep my cache drive spinning as long as it is running.)

I have a very simple setup. Mostly A NAS box with typical plugins and one Docker application-- Krusader. One thing that I have observed, that when I daily status report is sent (at 12:20AM on the Monday Report which I got this morning), is that the cache drive (on both of my servers) are active. On no other night does this condition occur! I also have the Plugin Update Notification and Docker Update Fortification setup to run once a week. By about 6:00AM, the cache drive has spun been spun down. This has been happening for several months now. I have long assumed that the check for Docker Application updates was the cause of this spinup and ignored it. I am wondering if what this check with its cache drive spinup and the failure to sleep on Sunday overnight are related?

Anyone who wants to create your own unique banners, I will give you a few hints. I use Adobe Photoshop Elements and work in the 'Expert' mode. I create a number of layers with the background layer being the lowest layer so that everything can be placed on top of it. By adding one element per layer it becomes easy to built up exactly what you want. (You can also make each layer completely opaque or partially transparent thus allowing a blending of the elements of two or more different layers as your artistic talents dictate!) There are a number of other programs including GIMP that can work with layers (and the Adobe .PDS files for that matter). I would suggest Googling for one that you could use. Above is one of my latest creations and I have attached the Photoshop .PSD file for it so you can see how it was built up. You have never done anything like this, download it and play around with it to see how it was assembled! It is really not that difficult. Leprechaun-Gold-mod_forRose.psd

Be sure that you have not tied the sata cables together to make it 'neat' on the inside of the case. You should only do this if the cables are shielded and 99.9% of SATA cable made today are not! I am not sure if SAS cables are shielded or not. The problem is crosstalk between the cables. (This is a problem with any server because all of cables will have information on them during many parity operations.) Next thing to double check is that all of the cables are firmly seated on their connectors (again, tying the cables together can contribute to a problem here.) If you are using metal locking cables, check that they have friction when you pull on the drive end. For reason, see here (And WD may not be the only manufacturer to have done this...): https://support.wdc.com/knowledgebase/answer.aspx?ID=10477

Please, read before you do anything about your current hardware. CRC errors only indicate a problem if they are increasing now! Read this post: If you acknowledge the error, you should not get another warning UNLESS you have a new error. As @johnnie.black says even an occasional one is not a problem. In fact, you should never lose data because of a CRC error. Once the error is detected, the data will simply be resent until it received correctly. (I still have not quite figured out why they decided to highlight what is a minor problem in virtually all cases.)

Am I correct in assuming that one should enter ssh bash in the field for the Processes to kill before Array is Stopped: parameter? EDIT: So per your advice, like this ssh,bash

The only thing that scares me about this series of statements is that the preclear script is basically unsupported also. It has already requires a patch to the last supported release and any user who wants to use it has to do his own patching! (There are a number of folks who could make the patched version available but after what happened the last time when a modified script was released, I don't see that happening.) Luckily in the last change that broke the script, the kernel change was one that was documented with the solution to fixing any problems caused by the change. It may not so simple the next time. Everyone should realize that we may only be a kernel change or two away from it being broke again.

All of this is true from what I remember. Using the script is not that difficult if you follow the detailed instructions that JoeL. provided. One has be be meticulous and play attention to the details. It could be run from either the console or using a Telnet (SSH today) session. One had to install screen on the server in case the remote session was interrupted. (Interrupting the session would terminate the script.) What the plugin did was to allow folks with no command line experience (I would say that 70% of the unRAID users today fall into that category and and another 20% are very rusty in its use---myself included) to prelear and stress test a disk to get rid of any marginal or early failure disks before they are mounted in to the array. Folks kinda like how easy it was to use and that ease of use made a part of the 'ritual' to the adding a new drive to the array. There are those who say this may not be necessary, but as one who can remember when Computer builders/assemblers always burned their system for 72 hours before shipment, I want that little extra bit of insurance...

When that day arrives that the plugin does not work in my simple NAS setup, I guess I will go back to using the old modified preclear script that Joe.L wrote those many long years ago. Plus, I could use a bit of refresher ins-and-outs of the Linux Command Line beyond a few simple directory and file management commands...

https://lime-technology.com/forums/topic/54648-preclear-plugin/?page=72&tab=comments#comment-632655 I just finished preclearing a disk using the above version of the preclear plugin on unRAID version 6.5.0-rc3. I would guess (at this point) that it will work on all versions of 6.5.0 as this upgrade series appears to be mostly about the microcode fixes required for the spectre and meltdown concerns.

Here is a Leprechaun on a field of Gold. OK, Interesting Problem. If I insert the file (Above), it will be downsized to 32KB. If I upload (Below) the file, it will be its original size of 94KB.

And one for Saint Patrick's Day: Download the one below:

Here is another variation for the lighter themes: Download the one below:

I had this and what I did was to turn on the Scan user shares: Parameter. I did exclude many of my shares that I don't usually browse to conserve a bit of memory. I I am going to do a lot of browsing (or file work), you can also spin up all of the data drives before your begin.

It is under Settings >>> Disk settings. Look for the Tunable (poll_attributes): attribute.

I don't quite see what you are doing but I can tell the mv requires a complete Linux path down to the files that it is going to move. Here is a link to the manual for that command: http://man7.org/linux/man-pages/man1/mv.1.html Your command as present proposed will only move files from a top level directory on disk16 named 't' (which would by definition in unRAID also be a user share). By a complete path I mean some like this: /mnt/disk16/Music/t/* It has been years since I have used mv but from reading the description, it will probably only move files and not directories, so it will probably move only the files in the directory but not any sub-directories or their contents. IF you are not familiar with the Linux command line, you should either get a good reference book or avoid using it except when you can cut and paste command examples from experts (with some very minor editing by you). Linux generally assumes that you know what you are doing and does it with any questioning/warning.

Which is exactly the reason that many of us turned it off back in the days when MS first introduced this 'feature' in MS-DOS 6.22 in 1994. Plus, crashes with Windows for Workgroups happened at least once a day if not oftener. UPS were a very expensive luxury item for most of us for a problem that was a minor issue compared to the instability of MS-DOS software. I think one important factor to consider is that this memory is reserved at bootup and it is apparently contiguous. This is not a problem for most uses of Linux as, if the OS requires a block of memory larger than is currently available, it just 'rolls' some idle process(es) out to its disk cache. The problem with unRAID is that it does not have a dedicated disk cache to do this and it can go ballistic in its failure to be able to provide the requested memory! That was the one of the reasons why the current recommendation in the GUI Help for these settings are quite small values.