unRAID Server Release 5.0-beta12a Available


limetech

Recommended Posts

Not sure to post this under b12 or b12a, but since 12a only focused on a NIC driver update, believe it should be fine under this thread.

 

After running for a week with my existing hardware setup after upgrading to b12, I performed a Parity Check, got no errors, then upgraded the parity drive from a 2TB to a 3TB.  I noticed that unRAID 5 went straight to building parity without performing any "pre-clear" tasks.

That is correct behavior for upgrading the Parity disk.

 

I had forgotten to run the manual pre_clear script but version 4 would always perform it's own "pre clear" processing if the pre_clear script wasn't performed.

Nope, only clears a data drive being added to an existing array.

 

Anyhow, I let it build parity on the new drive, then when completed immediately performed a Parity Check (correction enabled).  Got 406 errors.

That's not good.

 

Its in the process of performing a second Parity Check, but I had just thought about the fact that I was able to still access my server during the actual parity build as well as parity check and I'm not sure I was able to do this under version 4 but now I'm wondering if accessing the shares while parity build/check was in progress should not have been allowed.

That should definitely work and not cause any parity issues, but I will labor to try and reproduce this tomorrow on Labor Day.  Don't happen to still have the syslog do you?

 

During this second Parity Check I'm definitely not going to access the shares whatsoever (I hadn't stopped the array before commencing the second Parity Check) and see if any errors result.

Try both ways please, and if you see sync errors please capture the system log.

Link to comment
  • Replies 383
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Syslog PLEASE!!!!

 

I knew I should have mentioned but I forgot...

 

The syslog showed absolutely nothing in regards to the Parity Check or any errors period (other than authentication errors); not even to indicate that a parity check was initiated.

 

Attached in case you find something else...

 

EDIT:  Rereading the syslog again, it seems that unRAID "recycled" the syslog and started recording again "Sep 4 04:40:02."  I initiated the Parity Check on Sep 3, sometime in the morning.  I then found the second parity check entry made at "Sep 4 18:54:59", so it does indeed record a parity check initiated.

syslog-2011-09-04.txt.zip

Link to comment
You know Tom - I think it might be appropriate to come up with some archival scheme - that on beta's syslogs are saved to the flash drive unless manually disabled.

 

Just a thought.  We seem to run into an occasional "oh I don't have my syslog anymore" problem...

 

Was actually going to suggest that. There would be a few issues regarding size.. eg, if there are problems there is the potential for truly massive syslogs.

 

How about a system where the logger will keep the last two boots worth of syslogs on the flash drive and tarballs them after say, 10Mb has been reached? Splitting the syslog based on Boot number and time stamp. It should be done in real time, so to capture any issues that may stop the server from being accessed via telnet etc.

 

This should only be a requirement for betas however, as production systems don't want constant writes on the flash drive.

Link to comment

You know Tom - I think it might be appropriate to come up with some archival scheme - that on beta's syslogs are saved to the flash drive unless manually disabled.

 

Just a thought.  We seem to run into an occasional "oh I don't have my syslog anymore" problem...

 

Was actually going to suggest that. There would be a few issues regarding size.. eg, if there are problems there is the potential for truly massive syslogs.

 

Even a massive syslog will become pretty small when compressed.  Tarballs are nice, but a good .zip, .gz, etc. should eliminate storage space concerns on a decently-sized flash drive.  And I may be mistaken, but isn't this already done when you power down the machine?  I have the last 10 syslogs on my flash drive in the /flash/logs folder, with the most recent one being .zip ed up automatically for convenient posting.

 

I'm on an older beta, though.  Was that feature removed?  I don't think I have any extension enabled that does that for me.

Link to comment

After running for a week with my existing hardware setup after upgrading to b12, I performed a Parity Check, got no errors, then upgraded the parity drive from a 2TB to a 3TB.  I noticed that unRAID 5 went straight to building parity without performing any "pre-clear" tasks.

That is correct behavior for upgrading the Parity disk.

 

I had forgotten to run the manual pre_clear script but version 4 would always perform it's own "pre clear" processing if the pre_clear script wasn't performed.

Nope, only clears a data drive being added to an existing array.

 

Ah, as you can see, I've never replaced a parity drive before!

 

 

Anyhow, I let it build parity on the new drive, then when completed immediately performed a Parity Check (correction enabled).  Got 406 errors.

That's not good.

 

Its in the process of performing a second Parity Check, but I had just thought about the fact that I was able to still access my server during the actual parity build as well as parity check and I'm not sure I was able to do this under version 4 but now I'm wondering if accessing the shares while parity build/check was in progress should not have been allowed.

That should definitely work and not cause any parity issues, but I will labor to try and reproduce this tomorrow on Labor Day.  Don't happen to still have the syslog do you?

 

As I mentioned in another reply, the syslog appears to have "recycled" and dumped everything prior to Sep 4 04:40:02.  I had begun the Parity Check the previous morning and had not restarted the server in any which way since installing the 3TB drive.

 

 

During this second Parity Check I'm definitely not going to access the shares whatsoever (I hadn't stopped the array before commencing the second Parity Check) and see if any errors result.

Try both ways please, and if you see sync errors please capture the system log.

 

So far at 64% and no errors.  And this is without accessing the shares in any which way.

 

If you wanted me to try "both ways," I think the only way to do that is start fresh again by installing another, new 3TB drive (which I have a couple new ones on hand, BTW).  Hmm, that'll be like another 48 hours of testing (plus add on at least another 24 hours to that if I again get parity errors under the same conditions as before), yikes!  And I have still yet to upgrade my first data disk to 3TB...


EDIT: 84% complete and no errors... but all data drives are spun down ("flashing green").  Doesn't it have to reference the data drives to calculate parity and check it against Parity Drive?  All data drives were still spun up at the 64% mark.


FINAL EDIT:  Completed second Parity Check with zero errors.  All data drives had remained spun down from my last edit.  Speed averaged sub-40MB/s until near the end when it started hitting ~64MB/s.

 

For me, I will now ensure array access is prohibited during Parity Builds but will continue access during Parity Checks until I encounter parity errors again after a Parity Check and will post those issues.

 

I am now proceeding with replacing my first data drive to a 3TB drive.  Will not access array during this process.

Link to comment

I just upgraded from 4.7 to 5.0 b12a, and my array isn't aligned. I don't have any MBR errors or problems in my log. My parity and disk1 both show as "Wrong", but disk2 is working fine. What should i do? I'm on the basic version.

 

If you read this entire thread, one common theme that will stick out is...

 

post your syslog (!)

Link to comment

Your Flash device is corrupted and you should remove it from the server, backup the contents of 'config' directory, then reformat and re-install.  Then copy your 'config' backup to the flash.  This is probably not the cause of the SAS errors though.

 

The parity check starts at 19:11:17, but the first SAS error is reported 20 min later at 19:31:40.  During this time is the webGui responsive?

 

I see you have 5 drives plugged in.  Please simplify further, maybe a Parity drive and a single Data drive.  If this gets further than 20 min then probably ok, cancel, add another data drive or two, and repeat.  Trying to isolate issue to see if it's a particular hard drive/port.

 

Tom, I think I've found the issue.

 

1) Reformatted the Flash disk, restored the config dir and pro key

2) Tested with 1 parity, 1 data drive and a cache drive .. no problems, cancelled and added 1 extra data drive

3) At one point I started to hear the newly added drive having problems r/w (sounded like it wasn't able to write its data).

   The WebGUI immediately went unresponsive. Removed the drive from slot3 (didn't check the syslog, but it says enough)

4) Rebooted the system as it got stuck. Added a new data drive in Slot3 again. It's performing a "Parity-Sync in progress" for more than 90 mins now. 159 mins left. The WebGUI is still responsive and all looks fine.

 

 

Link to comment

Hi,

 

I am relatively new to unraid, but thought it maybe helpful to the development team to have a confirmation that 5B12a is working correctly/no issues in my mix Mac/Windows network.

 

Things that are working:

 

-AFP to both Lion and Snow Leopard machines (Two Lion, and 1 Snow Leopard). One Lion has multiple user accounts each with their own user auth + user share associated, no issues.

-SMB to Windows 7 Pro (Two Win7 Pro). One Win7 acts as server and accessed Unraid extensively, no issues in the past 48 hours

-User Auth for both AFP and SMB. I have a few guests daily and wanted to lock all the user shares down (different user auth per user share, no issues). I do not use Disk Exports

-Time Machine from Lion. It also leverages user auth to protect share access from anyone else. Limited Space to 400GB

-Network driver reported by ethtool is ATL1E / 1.0.0.7-NAPI

-Ran Parity check, no errors, approx 80 MB/s rate.

 

Upgrade path:

-Was running 4B7 for approx 8 months without issues. Very simple Setup - no cache, no user auth, 4 User Shares, just under 3.2 TB of data, all SMB

-Upgraded to 5B12a via release notes (I ran the new permissions utility)

-Added multiple user auth accounts, locked all shares to either private (AFP) or secure (SMB). No hiding

-Added more User Shares

-Changed access from all machines to leveraged user auth

-Attempted access with different/wrong auth, was denied access (seems to be working).

 

Thanks for the great release, and hope the confirmation helps!

Link to comment

Beta12a won't boot... "Loading bzroot" begins to load...bunch of periods (probably 12-13 rows of em), and it just hangs for as long as I let it sit there... re-downloaded and re-copied 12A to USB Stick with no change.

 

Attempted upgrading from Beta 11 which had been running with no issue.

 

Reverting back to 11 allows normal boot...Syslog for Beta11 Boot attached.

 

You did notice :

 

ata4.00: exception Emask 0x10 SAct 0x3ff SErr 0x1180000 action 0x6 frozen

Sep  5 22:32:22 Media kernel: ata4.00: edma_err_cause=020400a0 pp_flags=00000003, EDMA self-disable, SError=01180000

Sep  5 22:32:22 Media kernel: ata4: SError: { 10B8B Dispar TrStaTrns }

Sep  5 22:32:22 Media kernel: ata4.00: failed command: READ FPDMA QUEUED

Link to comment

I just upgraded from 4.7 to 5.0 b12a, and my array isn't aligned. I don't have any MBR errors or problems in my log. My parity and disk1 both show as "Wrong", but disk2 is working fine. What should i do? I'm on the basic version.

 

If you read this entire thread, one common theme that will stick out is...

 

post your syslog (!)

 

Sorry! I went back to 4.7 last night.

After some reading last night, i found i have the wrong partition system for both my EARS and EADS drives which was why they were showing as wrong while the Hitachi showed as fine.

I have checked my parity, and now i need to get a copy of preclear_disk.sh ver 1.6, but i cant find a link anywhere. Has anybody here got a link?

Also, do i use -A for my EARS drive and a EADS drive? Or do i do something different? Suggestions would be appreciated!

Link to comment

I have checked my parity, and now i need to get a copy of preclear_disk.sh ver 1.6, but i cant find a link anywhere. Has anybody here got a link?

Also, do i use -A for my EARS drive and a EADS drive? Or do i do something different? Suggestions would be appreciated!

v 1.13 is latest ver of preclear_disk.sh

Link is at bottom of first post here: http://lime-technology.com/forum/index.php?topic=2817.msg23246#msg23246 - first google result for "preclear_disk.sh"

 

Link to comment

Beta12a won't boot... "Loading bzroot" begins to load...bunch of periods (probably 12-13 rows of em), and it just hangs for as long as I let it sit there... re-downloaded and re-copied 12A to USB Stick with no change.

 

Attempted upgrading from Beta 11 which had been running with no issue.

 

Reverting back to 11 allows normal boot...Syslog for Beta11 Boot attached.

 

You did notice :

 

ata4.00: exception Emask 0x10 SAct 0x3ff SErr 0x1180000 action 0x6 frozen

Sep  5 22:32:22 Media kernel: ata4.00: edma_err_cause=020400a0 pp_flags=00000003, EDMA self-disable, SError=01180000

Sep  5 22:32:22 Media kernel: ata4: SError: { 10B8B Dispar TrStaTrns }

Sep  5 22:32:22 Media kernel: ata4.00: failed command: READ FPDMA QUEUED

 

Nope...nor do I have a clue what that means.

Link to comment
And I may be mistaken, but isn't this already done when you power down the machine?  I have the last 10 syslogs on my flash drive in the /flash/logs folder, with the most recent one being .zip ed up automatically for convenient posting.
I believe that the behavior you are describing is a result of installing the powerdown package in unMenu and is not a native part of unraid.
Link to comment

I have checked my parity, and now i need to get a copy of preclear_disk.sh ver 1.6, but i cant find a link anywhere. Has anybody here got a link?

Also, do i use -A for my EARS drive and a EADS drive? Or do i do something different? Suggestions would be appreciated!

v 1.13 is latest ver of preclear_disk.sh

Link is at bottom of first post here: http://lime-technology.com/forum/index.php?topic=2817.msg23246#msg23246 - first google result for "preclear_disk.sh"

 

 

"If you are running unRAID 5.0beta4 onward, you must use at least version 1.6 of preclear_disk.sh for all features to work properly." from that thread. I already have a copy of 1.13, why does that say 1.6? Will 1.13 be ok for running unraid 5.0b12a?

 

Link to comment

Beta12a won't boot... "Loading bzroot" begins to load...bunch of periods (probably 12-13 rows of em), and it just hangs for as long as I let it sit there... re-downloaded and re-copied 12A to USB Stick with no change.

 

Attempted upgrading from Beta 11 which had been running with no issue.

 

Reverting back to 11 allows normal boot...Syslog for Beta11 Boot attached.

 

You did notice :

 

ata4.00: exception Emask 0x10 SAct 0x3ff SErr 0x1180000 action 0x6 frozen

Sep  5 22:32:22 Media kernel: ata4.00: edma_err_cause=020400a0 pp_flags=00000003, EDMA self-disable, SError=01180000

Sep  5 22:32:22 Media kernel: ata4: SError: { 10B8B Dispar TrStaTrns }

Sep  5 22:32:22 Media kernel: ata4.00: failed command: READ FPDMA QUEUED

 

Nope...nor do I have a clue what that means.

 

Drive or interface issues with ata4 (see your own syslog which drive this is). This needs to be fixed before trying betas (or any other activity for that matter). TrStaTrns is not known to me. Please check your cabling to this drive.

 

This issue should be moved to another thread than this b12a discussion

Link to comment

I have checked my parity, and now i need to get a copy of preclear_disk.sh ver 1.6, but i cant find a link anywhere. Has anybody here got a link?

Also, do i use -A for my EARS drive and a EADS drive? Or do i do something different? Suggestions would be appreciated!

v 1.13 is latest ver of preclear_disk.sh

Link is at bottom of first post here: http://lime-technology.com/forum/index.php?topic=2817.msg23246#msg23246 - first google result for "preclear_disk.sh"

"If you are running unRAID 5.0beta4 onward, you must use at least version 1.6 of preclear_disk.sh for all features to work properly." from that thread. I already have a copy of 1.13, why does that say 1.6? Will 1.13 be ok for running unraid 5.0b12a?

v 1.13 is a later version than v1.6.

I think you are misreading "v 1.13" as "v 1.1.3", but they are not the same: "13" is a higher number than "6".

On the same site take a look at the release dates and their corresponding version numbers

 

 

Link to comment

Hi @all,

 

I had a crash today with 5b12a.

The server was not reachable and I couldn't get an output over DVI.

I had to reset the Server.

 

The logs are all written to the RAM (or not) so I can't give you an log file.

 

lspci:

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

 

lsmod:

r8168                170415  0

 

I use unRAID since beta5 or so. Never had a Problem with it.

Maybe it was a coincidence.

 

Regards, spidi

Link to comment

Also in this version I keep getting the BLK_EH_NOT_HANDLED.

 

Sep  4 09:38:25 Goliath kernel: sas: command 0xee53e300, task 0xf74963c0, timed out: BLK_EH_NOT_HANDLED

Sep  4 09:38:25 Goliath kernel: sas: Enter sas_scsi_recover_host

Sep  4 09:38:25 Goliath kernel: sas: trying to find task 0xf74963c0

Sep  4 09:38:25 Goliath kernel: sas: sas_scsi_find_task: aborting task 0xf74963c0

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 1818:<7>mv_abort_task() mvi=f70e0000 task=f74963c0 slot=f70f15d8 slot_idx=x0

Sep  4 09:38:25 Goliath kernel: sas: sas_scsi_find_task: querying task 0xf74963c0

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 1747:mvs_query_task:rc= 5

Sep  4 09:38:25 Goliath kernel: sas: sas_scsi_find_task: task 0xf74963c0 failed to abort

Sep  4 09:38:25 Goliath kernel: sas: task 0xf74963c0 is not at LU: I_T recover

Sep  4 09:38:25 Goliath kernel: sas: I_T nexus reset for dev 0500000000000000

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 5 ctrl sts=0x89800.

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 5 irq sts = 0x1001

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2226:phy5 Unplug Notice

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 5 ctrl sts=0x199800.

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 5 irq sts = 0x1081

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 5 ctrl sts=0x199800.

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 5 irq sts = 0x10000

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2253:notify plug in on phy[5]

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 1338:port 5 attach dev info is 0

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 1340:port 5 attach sas addr is 5

Sep  4 09:38:25 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 379:phy 5 byte dmaded.

Sep  4 09:38:25 Goliath kernel: sas: sas_form_port: phy5 belongs to port1 already(1)!

Sep  4 09:38:28 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 1701:mvs_I_T_nexus_reset for device[1]:rc= 0

Sep  4 09:38:28 Goliath kernel: sas: I_T 0500000000000000 recovered

Sep  4 09:38:28 Goliath kernel: sas: sas_ata_task_done: SAS error 8d

Sep  4 09:38:28 Goliath kernel: ata5: sas eh calling libata port error handler

Sep  4 09:38:28 Goliath kernel: ata6: sas eh calling libata port error handler

Sep  4 09:38:28 Goliath kernel: sas: sas_ata_task_done: SAS error 2

Sep  4 09:38:28 Goliath kernel: ata6: failed to read log page 10h (errno=-5)

Sep  4 09:38:28 Goliath kernel: ata6.00: exception Emask 0x1 SAct 0x1 SErr 0x0 action 0x6 t0

Sep  4 09:38:28 Goliath kernel: ata6.00: failed command: READ FPDMA QUEUED

Sep  4 09:38:28 Goliath kernel: ata6.00: cmd 60/00:00:10:d0:50/02:00:0f:00:00/40 tag 0 ncq 262144 in

Sep  4 09:38:28 Goliath kernel:          res 01/04:04:10:ce:50/00:00:0f:00:00/40 Emask 0x3 (HSM violation)

Sep  4 09:38:28 Goliath kernel: ata6.00: status: { ERR }

Sep  4 09:38:28 Goliath kernel: ata6.00: error: { ABRT }

Sep  4 09:38:28 Goliath kernel: ata6: hard resetting link

Sep  4 09:38:28 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2198:port 5 ctrl sts=0x89800.

Sep  4 09:38:28 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2200:Port 5 irq sts = 0x1001001

Sep  4 09:38:28 Goliath kernel: drivers/scsi/mvsas/mv_sas.c 2226:phy5 Unplug Notice

 

etc

 

The length of the drop-down box for assign drives on the Main page is still 20 in my case. Should be 26?

The main page reports beta12a aswell... not sure why I don't see drop-down boxes for 26 drives.. ;-)

 

I only replaced the bzimage and bzroot files, removed the super.dat file (renamed it to super.bak).

After a reboot I reorganized the drives back to their original order. That worked without any problems. Started the parity check again... emhttp stopped responding within 30 mins.  All again due to BLK_EH_NOT_HANDLED.

 

I've got a big system which is ready to go, but failing on this error. Is there a version that works without these issues? I really need to get this started asap. Thanks!

 

 

 

 

I'm getting the exact same error on beta 10, on the same port (port 5).  Fails the same way, last error in the syslog is  BLK_EH_NOT_HANDLED and then emhttp and unmenu stop working.  I can still telnet to the box in this state.  Nothing other than a reboot fixes emhttp and unmenu.

 

I have tried swapping out EVERYTHING - different motherboard, CPU, drives, cables, took them out of the Supermicro 5-in-3 and plugged them directly into the MV8 (I could basically build a parallel unraid server).  Tried it with two different MV8s.  I only have 5 data drives, a cache drive and parity drive on the system.  When I get home I can post a saved syslog from this if needed, but I've seen it so many times now I can confidently assert that it's the exact same error.  Same MB/CPU/Memory/MV8 combo as the Goliath system (though not a Norco case, it's a Azza Helios 910).  It has a Corsair 750 Watt power supply that should have more than enough juice to run 7 drives (http://www.newegg.com/Product/Product.aspx?Item=N82E16817139010).

 

-Scott

Link to comment

I have checked my parity, and now i need to get a copy of preclear_disk.sh ver 1.6, but i cant find a link anywhere. Has anybody here got a link?

Also, do i use -A for my EARS drive and a EADS drive? Or do i do something different? Suggestions would be appreciated!

v 1.13 is latest ver of preclear_disk.sh

Link is at bottom of first post here: http://lime-technology.com/forum/index.php?topic=2817.msg23246#msg23246 - first google result for "preclear_disk.sh"

"If you are running unRAID 5.0beta4 onward, you must use at least version 1.6 of preclear_disk.sh for all features to work properly." from that thread. I already have a copy of 1.13, why does that say 1.6? Will 1.13 be ok for running unraid 5.0b12a?

v 1.13 is a later version than v1.6.

I think you are misreading "v 1.13" as "v 1.1.3", but they are not the same: "13" is a higher number than "6".

On the same site take a look at the release dates and their corresponding version numbers

 

 

 

God damn it you're right. *dies of embarrassment* Ok, what command/flag do i use for this script on EARS and EADS drives? -A for both?

Link to comment

Just had the chance to test beta12a on my machine today.

 

It loads the correct driver for my card (r8168) and it works really good with that (around 45-50MB/s stable).

I attached my syslog (at least i tried, i will try to add it later on), only thing that wonders me is that my NIC first gets recognized as 8111B and after that as 8111D, but i cant tell if that makes any difference.

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.