Joe L.

Yes, and I fixed my original post. (and I've used "sed" for over 40 years)

Google no longer supports downloads of individual files from code.google.com. unmenu cannot be installed using those instructions. Joe L.

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 type (or copy from here and paste) the following: sed -i -e "s/print \$9 /print \$8 /" -e "s/sfdisk -R /blockdev --rereadpt /" preclear_disk.sh Your preclear disk script will be edited and should work with the two changes you mentioned. (actually, each occurs in two places, so there are a total of 4 lines changed) Joe L.

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.

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 judged to cause disk access or not. It judges that a disk has been accessed during scan if scan takes a long time or if any recent disk access was made (and no recent disk access was made before scanning). The purpose being to avoid the situations where cache_dirs will continuously search through my files keeping disks busy all the time. Before it was also rather difficult to tell if cache_dirs was 'trashing' my disks, now its quite clear from the log if logging is enabled (though the log is rather large at the moment). If disks are kept spinning for some consecutive scans, the depth is decreased, and future rescan is scheduled at higher depth. If the file '/var/log/cache_dirs_lost_cache.log' exists then it will write a log that is easily imported into spreadsheet (excel) so its easier to check whether it trashes disks with current settings. I also added the kill I mentioned and some other quite minor bug-fixes. If you need more let me know, and I might supply more detail over christmas. If you think it looks good and useful I might do a clean up run on the script. I havn't felt like spending more time on the script if nobody but me used it. Best Alex no, not moved on... Just have precious free time to be as heavily involved as I was a few years ago. (when I was not working.) My servers are both built with out-dated hardware. I cannot contribute in the same way I did in the past. (One is an original server sold by Limetech, with IDE based drives, the second newer, but incapable to handle virtualization) I do follow the threads... and respond occasionally... Joe L.

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 Bootable Hard Drive and it/they still failed. Maybe the Bios still changed it to the Cleared (not PreCleared) hard drive as it showed "no Bootable disc found". Still an interesting and "freaky" thing to witness. It worked fine until the PreClear "failed" then would not boot until it was reset. Dave Even though the pre-clear had failed (detected it had not filled the disk as expected), it could have written what looks to the BIOS as a valid master-boot-record to the hard-disk being cleared. In other words, as RobJ said, your bios was trying to "help" you by choosing one of your hard-disks to boot from that it thought had a valid master-boot-record, and since none contain actual code to boot from, nothing would boot until you set the bios back to boot from the correct usb-flash-drive.

you can see all the available options by typing preclear_disk.sh -? In any case, you can specify multiple cycles on the command line easily, just use "-c N" where N = the number of cycles desired. example: preclear_disk.sh -c 3 /dev/sdX

I think ANY problem with the preclear is an issue. The results of the preclear run should be stored on the flash drive in the preclear_reports folder. Hi Guys, From ~ 10 days ago, I wrote about my problem PreClearing a 5TB drive with a V6 key using a separate computer. The first drive got all the way through 2x but indicated that it could not Preclear the MBR, hence itimpi's comment. I've checked, no log reports at all. After rebooting and adding the PreClear Plugin & Script, I started over several times but at some point 20+ hours into Preclear the drive/system disconnect (lose communication with the drive) rendering Preclear useless. This has now happened to a new 2nd 5TB Drive (fresh out of the box). Anyone have a thought? Dave Yes, your drive is losing contact with the disk controller. You are lucky you are discovering the issue before you start loading your data to the drive. In many cases in the past, the issue was poor or intermittent SATA cabling to the drive, or an intermittent power splitter or power connection, or intermittent drive tray, or back-plane, or a power supply inadequate for the number of drives connected. Occasionally, it was traced to a flaky SATA controller port. What exact power supply are you using? How many disks are being powered from it? Do not get confused by the preclear report stating it could not clear the MBR. It must write a protective MBR to the drive, for older utilities that expect it to be there, even though the actual partition is located further up on the disk. Apparently, at the point where the MBR is being written the drive is already not communicating with the disk controller. (So no writes to the drive would work, regardless of what they were for) Joe L.

I would try running the short smart test before doing anything that would power cycle the disk. type smartctl -t short /dev/sdi then wait for the time it indicates and get a new smart report smartctl -A /dev/sdi followed by the same steps for the long test, waiting several hours or more as indicated when invoked before getting a subsequent smartctl -A report. (Don't forget to disable any spin-down timers, as spinning down the disk will terminate the long test.) smartctl -t long /dev/sdi waiting hours as needed, then smartctl -A /dev/sdi It might have currently stopped responding to read requests, but might start again if power cycled. The actual issue could be with the disk controller OR the disk itself. (That is not a good behavior, as if you cease being able to read a disk it is a very bad thing in any network-storage-device)

Actually, it said "0 bytes copied" so it could not read the disk when it was trying to. Might be fine in operation, but I expect you might want to keep an eye on it. Can you get a smart report on the drive right now? (does it respond at all to read requests?) What do you see when you run this command that attempts to read the disk's first 195 sectors: (it will print, at most, 30 lines of text) dd if=/dev/sdi count=195 | od -c -A d | sed 30q

based on the smart report, it is highly likely to be bad cabling to the drive, or cabling picking up noise from adjacent cables. (if you neatly tie-wrapped all the drive cables, you've caused the problem. Do NOT run the cables all parallel to each other or to power cables.) It might also possibly indicate a power supply at its limits, with the power supplied to the drive being noisy causing the checksum errors in communicating with the drive that are showing in the SMART report:

Then it indicates your disk is dropping off-line in some way and can no longer be accessed. (either a bad disk, or a power supply that cannot supply proper power to the disk, or a disk controller that is stopping to respond, or a loose cable or connector, or loose drive tray, or back-plane. ) Sorry to say, difficiult to isolate which it might be) Thanks Joe. I think that I am just going to RMA the drive even thought it passes all of the Seagate SeaTools tests. I am using a Norco 4224 case and I have tried preclearing the drive in multiple slots to eliminate the possibility of a bad cable, or PCI-E card with no luck. I was able to preclear an old 2 TB drive just fine so I am suspecting the drive. Better to RMA the drive now, then to have it stop responding when attempting to load it with your data (or fail when using it to recover another failed disk). Joe L.

Then it indicates your disk is dropping off-line in some way and can no longer be accessed. (either a bad disk, or a power supply that cannot supply proper power to the disk, or a disk controller that is stopping to respond, or a loose cable or connector, or loose drive tray, or back-plane. ) Sorry to say, difficiult to isolate which it might be)

exactly. Thee signature is partly based on the drive size. When seen as its full size on your main system, it would have the wrong preclear-signature, and the wrong partition-type.

PRetty sure it says the same thing regardless if it is pre-cleared, or not.... but skips the lengthy clearing step it would normally perform if once it starts on the process of adding the drive to the array. I did not see in your syslog any evidence of you actually adding the disk to the array. Did you press the button to actually add the disk, or just stop because it says it will clear the disk? Joe L. I stopped it because it just clears it again. I tried removing the Dynamix plugins and preclearing and then adding the drive, but have the same problem of it wanting to clear the drive again. No matter what I seem to do, it keeps saying wanting to clear the drive and never lets me get to the format drive. Are you sure you are using the latest version of preclear? Are you using unRAID v6? There was an issue with the preclear signature on v6 which has been fixed in the latest version of preclear I am 100% sure I am using the latest version. 1.15. If I do a preclear_disk.sh -v it outputs 1.15. I am on unRaid 5.0.6 SO I upgraded to unRaid 6 Beta 12 and tried preclear and then tried adding and getting the same exact problem. I am almost at capacity, what can I do? It is pretty obvious... Does the disk still test as "precleared" when you invoke: preclear_disk.sh -t /dev/sdX (where X = your drive letter) If that test says it is pre-cleared, it is... and you can add the disk to your array and let unRAID do as it wants, regardless of what the screen seems to say. If I'm right, it will skip the step of writing zeros to the entire drive and add it to your array. If I'm wrong, it will write zeros to the drive and then add it to your array. Either way, it ends up added to your array. Joe L.