itimpi

In Maintenance mode the drives are not mounted - this only happens in Normal mode. There is a version of memtest86 you can select from the Unraid boot menu if you boot in legacy mode. if you use UEFI boot mode or have ECC RAM then you should download the latest version from memtest86.com.

If you ARE going to try and reproduce this issue can you first enable the Testing logging mode in the plugin so I have more information on what is happening under the covers. The message is from the plugin (not Unraid) and indicates that the plugin THOUGHT an unclean shutdown occurred and that Unraid is about to start an automatic check. However if Unraid does not agree it was an unclean shutdown then no check is started. Looking at the code that can explain why the message text was a little strange. I am working on handling such a scenario in a tidy manner.

If you want to use a trial then you must not copy the config/super.dat file across and then reassign the drives as they were. Other configuration fines CAN be copied

You could always temporarily use a trial licence

Probably means it has failed

Are you sure that you had an unclean shutdown as the plugin should never prevent Unraid starting a parity check so something else is going on. Simply doing the reboot after an upgrade should not cause an unclean shutdown unless the Unraid did not succeed in stopping the array cleanly. it looks as if the plugin was expecting an automatic check because of an unclean shutdown and is trying to inform you of this. However the message itself does not actually make sense as an automatic check does not appear to have started, so I need to look into that code to see why the plugin thought an unclean shutdown occurred in case it got that wrong It has never been tested against rc5 so that may have caused some unexpected. behaviour and a spurious message to be displayed. Now that I can get rc5 for myself I will look into this.

The difference is described in this section of the online documentation that can be accessed via the Manual link at the bottom of the GUI

Not sure where you would have seen this information. Pending Sectors can only be cleared by the system trying to rewrite the problem sector so that is either successfully written or reallocated to use one of the pool of spare sectors on the drive. Adding a parity drive would only try to read the pending sectors so would not clear them. what you might have seen was that if you already have a parity drive with its contents valid, then on a read failure caused by the pending sector then Unraid can use the corresponding sector on the parity drive in conjunction with the corresponding sector from all other drives to work out what should have been on the sector that failed to read and will try to rewrite it. If that succeeds then Unraid will simply continue, but if that rewrite of the sector fails Unraid will disable the drive and stop using it and start emulating its contents using the combination of all other drives plus the parity drive.

Parity is always updates in real time which is one of the reasons having parity drives slows down write performance. The scheduled parity check is basically a housekeeping task to confirm that parity DOES agree with the current data drives as if it ever gets out of sync for any reason it compromises any future failure of a drive. Scheduling it weekly seems excessive, monthly or quarterly are much more frequently used.

The pop up you would have got when you ticked the format box would have explicitly told you that was going to happen. Having said that I understand that in a panic people have been known to blindly click the OK option without carefully reading the warning message, so making it even harder to ignore makes sense.

The issue is that adding a card can change the id’s. You should be able to undo the current passed-through devices, add the 10g card, and then redo the pass-throughs with the id’s that they now have.

If you only have parity1 then you can do that as parity1 does not include the slot number in its calculations. However if you have parity2 then you have to rebuild parity as the parity2 calculation includes the slot number as one of its inputs so changing slot numbers invalidates parity2.

Just a warning those are unofficial (I.e. old) pages for those steps. The current ones can be accessed via the `Manual’ link at the bottom of the Unraid GUI that takes you to the official documentation. I do not think there is any significant difference but it is always better to use the latest versions.

Yes - but if we can make it even more proof against users taking the wrong action through not properly reading (or understanding) the pop up it would be a desirable change. I must be honest and I do not see a really good reason as to why an emulated drive ever needs to be formatted, but the difficulty is in how to stop it (or at least make it harder than it is).

This sounds like it might be a good idea. This would not be trivial to implement though, but I might see if I can work out a Pull Request that implements this in a way that it could be done as an alternative popup to the one that is currently given when you elect to format a drive? I wonder, however, if anyone can come up with a Use Case for when it WOULD make sense to allow formatting of an emulated drive? There is frequently a need to do this as it is not the disk that caused the drive to be disabled but the something else so not such a good idea. I also think this would be much harder to detect in a sensible manner.

Does seem like it could be Dolphin. You could try accessing a share set to Public (most of yours seem to be set to Private) so no authentication is required to see if that works

I think you have to copy/paste it into a new script entry within the User Scripts plugin.

You are likely to get better informed feedback if you post your Unraid system's diagnostics zip file so we can see how you have your shares setup at the Unraid level.

There is a link given as part of step 8 to the post where you can get the script.

I think you have two conflicting requirements here? If you have the GP’u isolated so that it can be passed through to a VM then it is not visible at the Unraid level and needs to be controlled from within the VM.

I think the version of memtest you can download from memtest86.com can handle ECC RAM.

Where do you have the vdisk(s) for the VM placed? For best performance you do not want this to be 0n the array.

This is NOT a good sign With a value like that there is a good chance that failure could be imminent, although if it remains constant you may in theory get away with continuing to use the disk. Also not a good sign. Overall I would suggest this disk is a RMA candidate.

To give me more information on exactly what is happening under the covers can you enable the Testing mode of logging in the plugin and then give me the syslog (or diagnostics which includes the syslog). You may also get a clue if you simply enable the Debug level of logging as that will show you the details of the plugin monitoring the temperatures. Sounds as if something may be going wrong with determining the correct resume conditions, but it is not obvious what that might be. Having said that I notice you have a large value for the temperature drop at which to resume - are you sure your disks cool down enough to reach that temperature as if not that it could explain why you do not get the check resumed. Regardless the testing mode of logging will let me see if that is the problem.

You should try disabling spindown on the drive and then rerun the extended SMART test. Failing that would normally be sufficient to be able to RMA a drive that is still in warranty.