I have been running Unraid trouble free for over a year, but now it's suddenly acting up.

After i upgraded my parity disc to a bigger one, as i have done many times before, problems began.

Everytime i boot my unraid server it starts to parity-sync, as if it was booting the first time with a new parity disc.

If i let it complete the parity sync, power down, and then start again it starts all over again...

Anyone got an idea what might be wrong?

 

That usually means that the flash drive is not being updated at shut down.  I would look for problems with the flash drive.  If you like, post a syslog and we may have more ideas.

Sure, i just created a syslog and attached it. I don't have a complete parity sync during that log though, don't know if thats necessary?

Syslog looks good (except for one issue below), shows no problems with the flash drive.  It was found, setup correctly, write protect is off, and it was used to start the networking and the array.  Normally, when a major configuration change is made, the super.dat file in the config folder of the flash drive is updated.  You should be able to verify that.  At the completion of the parity build, just check the config folder and make sure the timestamp is updated to the current time for super.dat.  As you said, this syslog does not include the finish of the build.  It will be interesting to see if errors are reported then, for failure to update the flash.

 

You do have another problem!  You have been bitten by the Gigabyte HPA issue.  You have added a new drive, your only terabyte drive, as the new parity drive, but you connected it to the first SATA port of your Gigabyte motherboard, and since there are no other HPA's on any drive, a new HPA was created on this parity drive.  (I assume the old drive was connected here, and also had an HPA.)  Your system will work fine for now, but you won't be able to add a terabyte data drive without problems, because the next terabyte drive will be LARGER than this parity drive.  Check the UnRAID Topical Index, HPA section for more information.  A number of others have had the same problem, and you will have their sympathy, and perhaps their advice.

Ok wasn't aware of that HPA issue at all, fairly coincidental that my parity drive ended up being on the first sata port really... But thanks a lot for mentioning it, saves me a headache later on. Ill try to do a full parity check and report back.

 

Thanks for your time so far

Ok wasn't aware of that HPA issue at all, fairly coincidental that my parity drive ended up being on the first sata port really... But thanks a lot for mentioning it, saves me a headache later on. Ill try to do a full parity check and report back.

 

Thanks for your time so far

Very high odds are that the BIOS on that motherboard grabbed the space on the parity disk before parity was initially calculated.  As far as unRAID knows, your parity disk is just a few meg smaller than it really is.

 

Unfortunately, the next disk you go to put in your server as a data drive will not have been artificially made smaller with an "host protected area" and you will not be able to use it as a data disk because it will be slightly larger than your parity disk.

 

It gets real ugly from there.    Do not wait until you have a disk failure before you address this.   A nasty note to Gigabyte might not hurt... (it won't help you, but they might change their BIOS to allow the option to be disabled)

 

The

hdparm -N /dev/sd?

command can be used to see the current HPA settings on a disk.  It can also be used to set an HPA on a disk, or delete one, but so far, nobody has been able to use that to reset the HPA.

 

See this thread: http://lime-technology.com/forum/index.php?topic=4194.msg37010#msg37010

Joe L.

Okay back again. Did a full parity sync, and it did update the super.dat file.

Instead of shutting down the tower right away i tried restarting it, and it didn't trigger a resync.

Powered it down fully, and this time it didn't start syncing either?!?

Pretty strange after having synced it 4 times without luck earlier, can't really be the restart instead of power down can it?

 

As far as i can see from the log file it did a full successful sync (attached the log if it's of any use)

 

Once again i thank you guys for helping me out, now im off to sort out that HPA problem.

 

 

How are you "powering down?"

 

Are you first stopping the array?  and then pressing the power-down button on the web-interface, If not, that is your issue. 

No i stopped the array through the webinterface by pressing stop first...

 

Edit. Hmm could it have been a semi bad connection to the USB stick causing it, or would that have been reflected in the logs? I have my usb stick attacked to a usb extension cable that might not be best of health anymore. I moved my case just before i initiated this last parity sync, so don't if that pulled the cable back in place or something like that?

 

Hmm could it have been a semi bad connection to the USB stick causing it, or would that have been reflected in the logs? I have my usb stick attacked to a usb extension cable that might not be best of health anymore.

 

That is a possibility, and it would clearly be in the syslog.  Check the end of the syslog after you suspect a possible disconnect because of cable or other reason.  Because USB is one of the truly hot-swappable technologies, you should see messages associated with USB disconnects and reconnects, but the unRAID flash drive may no longer be identified correctly as the 'unRAID flash drive'.  That would definitely result in what appears to be an improper shutdown, because it won't be able to properly update the flash drive.

 

Both syslogs look fine, no evidence at all of any problems with the flash drive, at least during the periods covered by these syslogs.  Also, if you have a monitor attached when you shut it down or reboot it, you should probably see (but very quickly) messages concerning a failure to write to the flash drive.

 

There is one 'event' during this newer syslog.  The network goes down for almost 11 minutes between 8:20pm and 8:31pm.  It does not look like a sporadic problem, more like a deliberate cable disconnect or router turned off for the 11 minutes.  If you can account for that, then there is no problem.

Slight thread hijack, I have in the past by mistake pulled the flash drive from my unraid server when it was plugged in the front panel, is there a set of instructions on howto restore the USB key so as to avoid the issue mentioned above of a parity sync being generated after a reboot? Is it just a case of remounting the USB key?

I have in the past by mistake pulled the flash drive from my unraid server when it was plugged in the front panel, is there a set of instructions on howto restore the USB key so as to avoid the issue mentioned above of a parity sync being generated after a reboot? Is it just a case of remounting the USB key?

 

It depends on whether you get the same device ID (eg. sde) after reinsertion of the flash.  I could be wrong, but I don't think you do, and the config paths refer directly to the old device ID.  So you can expect a parity check on the next boot, which is not that bad of a thing, and can easily be aborted.  The reason he was repeating a parity sync/build is because he could not update the array status on the flash with a "parity sync is complete" status, so it kept rebuilding, thinking it had not been done yet.  From now on, the situation for him (as well as for the rest of us) is a parity *check* running, not a parity *build*.

 

Although there is no problem aborting a parity check, if it has not been done recently, then it might be a good thing to let it finish.  Otherwise, I recommend letting it complete 2 or 3 percent at least, before canceling it, just to cover the 'housekeeping' and file system areas of the drive.

Yea the network disconnect was just me tripping over the cable i had dragged across the room .

 

But everything seems to be working now, again thanks for the help.