50 minutes ago, FreeMan said:

Any indication of why UNRAID may have thought that the drive was not cleared?

 

Maybe since you ran preclear in the enclosure, so it was on a totally different controller, sometimes those USB SATA drive controllers remap the drive geometry somewhat.

 

2 minutes ago, jonathanm said:

 

Maybe since you ran preclear in the enclosure, so it was on a totally different controller, sometimes those USB SATA drive controllers remap the drive geometry somewhat.

 

Interesting thought. I do have a WD MyBook and another Seagate Expansion external drive that I've precleared in their enclosures then shucked, this is the first time this has happened. By no means am I implying you're wrong, just that it's never happened (to me) before. Of course, they may have changed something in the SATA->USB interface since my last purchase.

 

It's annoying and time consuming, but A) I'm happy to be able to run the preclear just to be sure it's not DOA (I just hit my first ever DOA with my last 2 drives purchased!), and B) there doesn't seem to be a darn thing I can do about it, so I'll just live with it.

 

I was hoping that if there was an issue that could be solved, it could be taken care of for the next person.

On 2/22/2020 at 4:22 PM, FreeMan said:

When I booted the server up, I stopped the array, added the drive, started the array and it's now 26 minutes and 4% into clearing the drive before adding it to the array.

 

I've attached the preclear report - everything there indicates to me that it completed successfully. Any indication of why UNRAID may have thought that the drive was not cleared

ive seen this myself first hand!, so in my case i precleared two identical drives, both in their enclosures (WD My Books), one of the drives i disconnected fairly swiftly after preclear and it was fine, no additional clearing required., the other i left for 24 hours before i had chance to disconnect it, its this second drive that then required clearing again by unraid.

i believe what is happening is something (dunno what) is writing to the newly cleared drive, and as soon as ANYTHING (be it 1 bit or 1TB of data) is written to the disk its instantly invalidated from being cleared, thus requiring clearing again by unraid.

 

so what i could try is to issue a command to put the drive into a read only state at the end of the preclear (needs testing but it should be back to normal operation on disconnect and reconnect), this should then hopefully prevent the drive from being invalidated by writes.

 

fyi - util is blockdev, link to man page:- https://linux.die.net/man/8/blockdev

 

Just finished preclearing a 6TB WD Blue Drive.  I checked to see if the disk had the proper preclear signature. This is the output of the check:

 

 

Edited March 2, 20206 yr by Frank1940

 

 

Looks to me like it has something to do with the old 2.2TB limit size limit...

 

 

And what is "test 6"?

1 hour ago, Frank1940 said:

 

 

Looks to me like it has something to do with the old 2.2TB limit size limit...

 

 

And what is "test 6"?

 

Which command you passed to preclear_binhex.sh?

1 minute ago, gfjardim said:

 

Which command you passed to preclear_binhex.sh?

preclear_binhex.sh  -c 1 -M 3 /dev/sdd

and this is the command I used to check it:

preclear_binhex.sh -t /dev/sdd

(Both of these were copied directly from the BASH command stack on the noVNC terminal screen.)

The Disk is still in the server and I could rerun it with the -f option if that would be of some value.

 

EDIT:  However, I do recall that I did check it after a run of two cycles and the test also failed at that point.  I didn't report it than because it was some time after that the finish of the preclear cycle that I did the check.  (I was trying to put hours on a new hard disk as it will be a cold standby replacement.)

Edited March 2, 20206 yr by Frank1940

5 minutes ago, Frank1940 said:

The Disk is still in the server and I could rerun it with the -f option if that would be of some value.

That's not needed. You could test it using the plugin so we can see if it replicates on the other script? You can run the "Verify MBR Only" opoeration.

I reinstalled the Preclear Plugin and run the "Verify MBR Only" and it failed the verification.  I am attaching the log file from this.

ROSE-preclear.disk-20200302-0937.zip

36 minutes ago, Frank1940 said:

I reinstalled the Preclear Plugin and run the "Verify MBR Only" and it failed the verification.  I am attaching the log file from this.

ROSE-preclear.disk-20200302-0937.zip 1.9 kB · 0 downloads

Apparently I found the bug. Please update your plugin to 2020.03.02 and test it again, please.

If we validate the solution, I'll commit the fix to binhex repository.

Edited March 2, 20206 yr by gfjardim

3 minutes ago, gfjardim said:

Apparently I found the bug. Please update your plugin to 2020.03.02 and test it again, please.

If we validate the solution, I'll commit the fix to binhex repository.

How do I do this?

5 minutes ago, Frank1940 said:

How do I do this?

Update the Preclear Plugin to version 2020.03.02 and test it again.

 

54 minutes ago, gfjardim said:

That's not needed. You could test it using the plugin so we can see if it replicates on the other script? You can run the "Verify MBR Only" operation.

 

3 minutes ago, gfjardim said:

Update the Preclear Plugin to version 2020.03.02 and test it again.

 

 

OK that was successful!

 

19 minutes ago, Frank1940 said:

OK that was successful!

 

Yep, that's it. I've committed the fix to binhex too, we should see an update soon.

5 minutes ago, gfjardim said:

Yep, that's it. I've committed the fix to binhex too, we should see an update soon.

Firstly, thanks a ton for this gfjardim!, i really appreciate you helping out, saw the PR and looks like a reasonable fix to me :-), can i just ask, is this fix also applicable to the plugin, as the underlying preclear script is the same/similar, right?.

12 minutes ago, binhex said:

Firstly, thanks a ton for this gfjardim!, i really appreciate you helping out, saw the PR and looks like a reasonable fix to me :-), can i just ask, is this fix also applicable to the plugin, as the underlying preclear script is the same/similar, right?.

This bug was introduced when you changed the start sector of disks larger than 2.2TiB to 64, and the verification routine remain expecting it to be 1. With the fix, now the correct partition size is set even if the disk is greater nan 2.2TiB and is precleared starting on sector 64.

Tell me, is that blockdev -setro op really preventing changes in the MBR?

 

PS: The verification step of the plugin obey the same logic of the original script, so it suffered the bug too.

Edited March 2, 20206 yr by gfjardim

Just now, gfjardim said:

Tell me, is that blockdev -setro op really preventing changes in the MBR?

It SHOULD prevent any user space writes to the disk, but it does depend on what is causing the invalidation of the signature as to how effective this really is, it was really the only thing that even look remotely like it might help, so for now its in, we shall see how effective it is in the future i guess.

i would still like to know what process is writing to the disk, its certainly a bit hit and miss as to whether it maintains the signature or not when added to the array.

Update Docker.  Now getting this:

 

It looks like it is working now.  The only question is the size of sdd1 and its ending sector.  It is not quite what I would be expecting to see...

 

5 minutes ago, Frank1940 said:

Update Docker.  Now getting this:

 

It looks like it is working now.  The only question is the size of sdd1 and its ending sector.  It is not quite what I would be expecting to see...

 

That's correct. It creates a GPT Protective partition so Unraid can recognize it. We must remember that when Unraid was first launched, we only had MBR partitioning scheme and disks were far from archiving more than a few gigabytes. This was the way that was found to implement a layer of compatibility in the transition to > 2.2TiB hard disks.

Hi all, I ran this plugin a week ago and cleared a HGST 6TB it ran fine and passed the preclear (took 32 hours). So then I quit the docker, stopped the array, and added the new disk and it cleared it anyways. Then I came here and found I guess there is a bug and it needs to be like read only at the end now, but also saw today that the plugin was updated so this has this bug resolved for future use?

 

Again thanks for the hard work to put this great plugin and docker together for us.

Hi,

 

I successfully precleared 4 drives, but when I tried to add them to the array, it still tried to clear it. I cancelled the preclear again and removed them from the array. When I run preclear_binhex.sh -t to check each one, it still says they are precleared. Just to check though, I installed the preclear plugin, and that says the drives are not cleared.

 

 

HEllo, I have an issue with the container, after installation, the Unraid UI is getting corrupted and displays

 

Warning: parse_ini_file(/boot/config/plugins/dynamix/dynamix.cfg): failed to open stream: Success in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 22

Warning: array_replace_recursive(): Expected parameter 2 to be an array, bool given in /usr/local/emhttp/plugins/dynamix/include/Wrappers.php on line 22

Warning: extract() expects parameter 1 to be array, null given in /usr/local/emhttp/plugins/dynamix/template.php on line 21

Unraid is still working but the ui is in text mode. I reinstalled the whole server, tried again to install the docker, same output ! what's am I missing ?

 

Thanks

3 minutes ago, chocorem said:

HEllo, I have an issue with the container, after installation, the Unraid UI is getting corrupted and displays

 

Unraid is still working but the ui is in text mode. I reinstalled the whole server, tried again to install the docker, same output ! what's am I missing ?

 

Thanks

Seems more like a Flash problem. 

 

Go to Tools-diagnostics and attach the complete Diagnostics zip file to your NEXT post. 

done, not sur about the flash, I installed with 2 different flash, and the problem arrived both time after the docker installation

 

loki-diagnostics-20200429-2110.zip

Edited April 29, 20206 yr by chocorem