unRAID 6.6.7 reporting "wrong" disk?


Recommended Posts

Added new share folder to my unRAID server yesterday, shared via SMB and nsf, and everything worked as it should ran it all night with no issues. 

Powered the server down with no issues. 

 

Turned it on this morning and now it reports one of the disks as a "wrong" disk, have never seen this problem before? 

 

Have had a faulty disk in the past but as far as I remember this was not how unRAID acted and reported the issue back then.... 

 

Anyone else tried this and what to do? 

 

PS. Am at work and on my phone writing, I can upload whatever is needed to diagnose the problem, as soon as I am home later today 

:)

 

Cheers Dennis 

tower-diagnostics-20190321-1108.zip

Edited by Denner
Uploaded tower-diagnostics zip file created by the unRAID server...
Link to comment
21 minutes ago, johnnie.black said:

More than one disk has HPA enable, it's likely your board, more info here:

 

Will change from IDE to SATA/AHCI in bios but it has never been an issue for me .....

 

So you are thinking that my board is defect ?

Link to comment
3 minutes ago, Denner said:

So you are thinking that my board is defect ?

It's not a defect, it's a "feature", it's all explained in the link above.

 

Originally the disk was using the max (normal) size, then after rebooting the board created an HPA making the disks smaller, and that's why Unraid is complaining the disk is wrong.

Link to comment

Ahh okay, sorry I didn't understand you correctly, i have not used my unRAID system for many years, so I am kind of getting "back into it" so to speak :)

 

So if I understand correctly, this should be fixable and what to do is explained in the link about HPA you posted? 

 

I am just wondering why this happened all of a sudden, because the unraid has been running for about a month now and I have made no changes to the settings or anything else, except for adding a new shared folder to it last night 🤔

Link to comment
11 minutes ago, Denner said:

So if I understand correctly, this should be fixable and what to do is explained in the link about HPA you posted? 

Yes.

 

12 minutes ago, Denner said:

I am just wondering why this happened all of a sudden, because the unraid has been running for about a month now and I have made no changes to the settings or anything else, except for adding a new shared folder to it last night 🤔

A boot order change can be enough, though since you're running Unraid without parity you can also easily fix it with a new config, but I would recommend disabling so that it doesn't happen again, especially if there are plans to add a parity disk in the future.

 

 

  • Like 1
Link to comment
31 minutes ago, johnnie.black said:

Yes.

 

A boot order change can be enough, though since you're running Unraid without parity you can also easily fix it with a new config, but I would recommend disabling so that it doesn't happen again, especially if there are plans to add a parity disk in the future.

 

 

Thanks again man, I really appreciate your support and that you are taking your time to answer my "noob" questions 🙏

 

The reason for me not running a parity disk at the moment is that I am in the process of migrating all my data from from 4 different servers and a spare pc to the unraid server.

And l am still waiting for my parity drive to arrive, a 10tb Seagate drive, that is being exchanged because it was defective on delivery and the exchange process is apparently dragging out 🙄

Hope that what I wrote makes sense? 

 

Cheers Dennis 

Link to comment
5 hours ago, johnnie.black said:

More than one disk has HPA enable, it's likely your board, more info here:

 

Okay have been at it for a lot of hours, and I am getting nowhere, I have been looking trough the syslog.txt file and it does not look like dirk 5, that I am having issues with is affected py HPA, but I could have missed it ?

 

If and when I am going to fix HPA using the "hdparm -N p1953525168 /dev/sde" command, where do I do that from, is it via SSH or can it be done via the web interface that I normally use to control my unRAID server ?

 

Last but not least, it looks like HPA can not be disabled on my  GA-MA74GM-S2H in the bios, so I will be replacing the board, but would love to have the server up an running with all data intact before doing so, keeping my fingers crossed that you are able to guide me :)

*EDIT* found out it can be done via the web interface ">_terminal" option but it is warning me against doing so, am I missing something or should I not do the "hdparm -N p1953525168 /dev/sde" to fix the issue ?

Annotation 2019-03-21 172001.jpg

Edited by Denner
Link to comment
6 minutes ago, Denner said:

it does not look like dirk 5, that I am having issues with is affected py HPA, but I could have missed it ?

This is disk5:

Mar 21 11:00:29 Tower kernel: ata2.00: HPA detected: current 15628044911, native 15628053168
Mar 21 11:00:29 Tower kernel: ata2.00: ATA-10: ST8000DM004-2CX188,             WCT03KKZ, 0001, max UDMA/133

Disk4 also has one:

Mar 21 11:00:29 Tower kernel: ata2.01: HPA detected: current 15628051055, native 15628053168
Mar 21 11:00:29 Tower kernel: ata2.01: ATA-10: ST8000DM004-2CX188,             WCT0Q2PF, 0001, max UDMA/133

And so does the cache disk:

Mar 21 11:00:30 Tower kernel: ata3.00: HPA detected: current 1953523055, native 1953525168
Mar 21 11:00:30 Tower kernel: ata3.00: ATA-8: SAMSUNG HE103SJ, S2JBJ90B104158, 1AJ10001, max UDMA/133

And that's all :)

 

Edited by johnnie.black
Link to comment
Just now, johnnie.black said:

This is disk5:


Mar 21 11:00:29 Tower kernel: ata2.00: HPA detected: current 15628044911, native 15628053168
Mar 21 11:00:29 Tower kernel: ata2.00: ATA-10: ST8000DM004-2CX188,             WCT03KKZ, 0001, max UDMA/133

Disk4 also has one:


Mar 21 11:00:29 Tower kernel: ata2.01: HPA detected: current 15628051055, native 15628053168
Mar 21 11:00:29 Tower kernel: ata2.01: ATA-10: ST8000DM004-2CX188,             WCT0Q2PF, 0001, max UDMA/133

And do does the cache disk:


Mar 21 11:00:30 Tower kernel: ata3.00: HPA detected: current 1953523055, native 1953525168
Mar 21 11:00:30 Tower kernel: ata3.00: ATA-8: SAMSUNG HE103SJ, S2JBJ90B104158, 1AJ10001, max UDMA/133

And that's all :)

 

Ok thanks :)

 

Found out it can be done via the web interface ">_terminal" option but it is warning me against doing so, am I missing something or should I not do the "hdparm -N p1953525168 /dev/sde" to fix the issue ?

Annotation 2019-03-21 172001.jpg

Link to comment
1 hour ago, johnnie.black said:

The warning appears if you're using a smaller sector size instead of full size, for all purposes creating a HPA, so you're doing it on the wrong disk or using the wrong value.

My bad used the wrong value, did not know that it needed to be changed from what was used in the HPA thread you linked to, sorry about that, so if I am correct the value I should use for disk 5 is: 15628053168 so the command should look like this "hdparm -N p15628053168 /dev/sde" ?

 

1 hour ago, johnnie.black said:

Note that if you disable HPA on disk4 now, Unraid will complain it's wrong, since it was added with HPA enable.

How do I go about excluding disk4, and the rest of the disks for that matter, so that the HPA fix is only applied to disk5 and not all the disks ?

 

I am so sorry for all the questions but I am really trying to learn and figure this out so that I can do it on my own if it happens again and help others if need be :)

Link to comment
14 minutes ago, Denner said:

hdparm -N p15628053168 /dev/sde

Yes, if disk5 is sde, it was sdb in the screenshot you posted above, though it can change after a reboot, mostly if SATA connections are swapped around, I suspect you're getting sde from the link, in doubt and if you rebooted since post new diags, assuming it's still sdb it would be:

hdparm -N p15628053168 /dev/sdb

 

18 minutes ago, Denner said:

How do I go about excluding disk4, and the rest of the disks for that matter, so that the HPA fix is only applied to disk5 and not all the disks ?

Command is only applied to the disk specified, using the correct identifier, as shown after the serial number in the GUI, sdb, sdc, sdd, etc.

Link to comment
4 minutes ago, johnnie.black said:

Yes, if disk5 is sde, it was sdb in the screenshot you posted above, though it can change after a reboot, mostly if SATA connections are swapped around, I suspect you're getting sde from the link, in doubt and if you rebooted since post new diags, assuming it's still sdb it would be:


hdparm -N p15628053168 /dev/sdb

 

Command is only applied to the disk specified, using the correct identifier, as shown after the serial number in the GUI, sdb, sdc, sdd, etc.

Just did a screen-grab, and attached it, and it looks like the disk5 is named "sdf" and in that case the command should look like this "hdparm -N p15628053168 /dev/sdf" to fix disk5 HPA issue am I correct ?

 

 

Annotation 2019-03-21 193759.jpg

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.