Joe L.

Members
  • Content Count

    19009
  • Joined

  • Last visited

  • Days Won

    1

Joe L. last won the day on March 5 2017

Joe L. had the most liked content!

Community Reputation

13 Good

3 Followers

About Joe L.

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, and I fixed my original post. (and I've used "sed" for over 40 years)
  2. unfortunately, google no longer operates code.google.com, therefore, the release list file cannot be accessed from them any longer. A zip file of the entire unmenu source tree can be found at this link: https://code.google.com/archive/p/unraid-unmenu/source/default/source you can download the zip file, un-zip it, and have access to all the awk,shell files, and package definition config files within it. Joe L.
  3. Google no longer supports downloads of individual files from code.google.com. unmenu cannot be installed using those instructions. Joe L.
  4. I only (very) recently put 6.2 beta on my server. I did not have any issue pre-clearing the second parity disk I have just added to my array. The fix will need to wait until I add/replace one of the existing disks with a larger one. (Otherwise, I have no way to test the process. ) Whatever the fix might be, it must be backwards compatible with the older releases of unRAID. In the interim, you can type this command to "patch" the preclear_disk.sh command First change directory to the directory holding the preclear_disk.sh command. For most, it will be cd /boot then ty
  5. I agree that there is value in stress testing the drive and checking to make sure nothing is failing after the first few writes. That said, maybe this signals that a new plugin needs to be made that removes the clearing portion of the plugin and instead focuses entirely on stress testing. Leave the clearing entirely to the OS since that's not an issue anymore. This should allow more cycles of stress testing without having to have that long post read cycle (that verifies the dive is zeroed) meaning you can do more cycles faster... I think. I think you are missing a part of
  6. Actually, the preclear script logs its reports on the flash drive in /boot/preclear_reports You might look there. If the report is not there, then it finished the clearing step, but not the post-read phase to see if it was successfully zeroed. Joe L.
  7. Ha! I think you need glasses if that's all the change you see But I totally get the need for a better description than the change-log. I don't have the time right now to go into details and I don't remember everything I did but this is what I wrote earlier: I have added adaptive depth level, to prevent cache_dirs from thrashing disks when they are otherwise occupied and cache is evicted. I found the cache was often evicted with the number of files I had when system become occupied with other things. I added the ability to adjust depth automatically based on whether scans are judg
  8. Or, the SATA cables are picking up noise from adjacent cables. (adjacent power OR SATA cables) This often occurs when a user attempts to make their server look neat by bundling all the SATA cables together. When doing so, it is putting into place a situation where induced noise is very likely. Therefore, cut the tie-wraps bundling cables together. Yes, it looks less neat, but... you'll see far fewer noise induced CRC errors. Joe L.
  9. Thanks for the info, I had never seen this. I am trying it now, although I think it is not the perfect choice for my case, since errors, appear in different places of the HDDs. If the errors are in different places each time, it is more likely to be a memory problem, disk controller problem, or a power supply problem. Very first thing to check is to run a memory test, preferably overnight (or at least several full passes). As often as not, a bad memory strip is the issue. Joe L.
  10. You are welcome. If you think about it, much of the newer (now native) features were originally implemented in unMENU, and unMENU was originally created to explore alternative and improved user-interfaces to unRAID. It has done exactly what it was created for. I am happy that it still offers substantial value after all these years. No, unMENU does not offer "docker" or "virtual server" features... but it certainly holds its own with almost everything else. (unRAID itself does not yet allow you to choose a vertical vs. horizontal menu bar... they still have some catching up to do)
  11. First, no software (including Preclear) writes to the BIOS. This is actually a common problem with many motherboards. Whenever you change the installed drives list for the system, the BIOS may decide to "help" you, and reorder the boot order so that the most likely hard drive will be booted, which is usually NOT the USB drive you had configured! You did the right thing by going into the BIOS and correcting the boot order, making sure the right drive is booted, not what the BIOS *thinks* is the right drive. Thanks Rob - I agree in a sense, but I actually selected a "seen" USB Bo
  12. Which is why I will NOT be upgrading to 6.1 unless this is made compatible or the features from this that I use are put into the unRAID GUI. We have the basic chicken vs. egg issue here. I do not typically upgrade my server to the latest version until it is out for a few days. Therefore, I have no way to test or make changes to unMENU. From what I've read, the /root/mdcmd shell command no longer exists. unMENU uses it to get the status of the array. /root/mdcmd was just a interface to /proc/mdcmd. You could try putting it back into place and see if everything starts w
  13. Which is why I will NOT be upgrading to 6.1 unless this is made compatible or the features from this that I use are put into the unRAID GUI. We have the basic chicken vs. egg issue here. I do not typically upgrade my server to the latest version until it is out for a few days. Therefore, I have no way to test or make changes to unMENU. From what I've read, the /root/mdcmd shell command no longer exists. unMENU uses it to get the status of the array. /root/mdcmd was just a interface to /proc/mdcmd. You could try putting it back into place and see if everything starts w
  14. Which is why I will NOT be upgrading to 6.1 unless this is made compatible or the features from this that I use are put into the unRAID GUI. We have the basic chicken vs. egg issue here. I do not typically upgrade my server to the latest version until it is out for a few days. Therefore, I have no way to test or make changes to unMENU. From what I've read, the /root/mdcmd shell command no longer exists. unMENU uses it to get the status of the array. /root/mdcmd was just a interface to /proc/mdcmd. You could try putting it back into place and see if everything starts w
  15. Since lime-tech is in release-candidate-2 of 6.1, I'd not expect new features, but instead just tiny bug-fixes so they can get to 6.1 final. (I can't speak for lime-tech, as I'm a customer, just like you, so it is always possible they would throw in something at the last moment... but I would look to a community plugin rather than something in 6.1 natively) Joe L.