I upgraded from 4.3.2 to 4.4.2 and now my array will not start. My parity drive seems fine and my two data drives are green but when I attempt to start they just say "mounting". Any help would be greatly appreciated. Also, "restore" is an option at the main console.

I upgraded from 4.3.2 to 4.4.2 and now my array will not start. My parity drive seems fine and my two data drives are green but when I attempt to start they just say "mounting". Any help would be greatly appreciated. Also, "restore" is an option at the main console.

DO NOT PRESS the button labeled "Restore"  It does NOT restore data... It resets your initial configuration, before you calculated parity, so in effect it throws away any parity data, and uses only the existing working assigned drives to define your array... it throws away your old configuration in the superblock, and generates a new superblock.  Normally, this is only needed if you are removing a drive from the array and do not intend to replace it with another.

 

Other than that, a syslog would let us know what is happening.  Also, 4.4.2 is about 5 versions old... You might just try 4.5beta6.  It is very stable... and it might just work since it has a newer Linux kernel and drivers.

 

Joe L.

4.5 did't help. Is the syslog on my usb key? When I upgrade to new version I am only replacing bzroot and bzimage. Is that correct?

4.5 did't help. Is the syslog on my usb key? When I upgrade to new version I am only replacing bzroot and bzimage. Is that correct?

No, the syslog is not on your USB key.

 

If you can get to the management console on 4.5beta6, you can get to the syslog from the browser by typing

http://tower/log/syslog

Then you can save the page to your PC as syslog.txt and upload it here.

 

On older versions, before 4.5beta6 , you need to log in via telnet, or on the system console, and copy the syslog to your flash drive first, and then you can get to it from your PC.

 

Instructions in the wiki here: http://lime-technology.com/wiki/index.php/Troubleshooting

 

Joe L.

OK. I think this is it.

I posted my syslog. Thanks again for your your help. Just further help me understand the unraid software, why couldn't I hit restore and start over. All three of my drives appear healthy and i would only be unprotected during the parity build? I understand that if i restore while i have a drive missing that I would abandon parity for that drive, but i have healty drives (i think).

OK. I think this is it.

It appears as if you have a series of disk drive errors on /dev/hdb with bad CRC.  (checksums)  It is a ST380012A

It tries slower and slower methods to get to it, eventually getting to PIO mode (very slow access)

Jun 18 15:07:14 Tower kernel: ide0: reset: success
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: error=0x84 <3>{ DriveStatusError BadCRC }
Jun 18 15:07:14 Tower kernel: ide: failed opcode was: unknown
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: error=0x84 <3>{ DriveStatusError BadCRC }
Jun 18 15:07:14 Tower kernel: ide: failed opcode was: unknown
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: error=0x84 <3>{ DriveStatusError BadCRC }
Jun 18 15:07:14 Tower kernel: ide: failed opcode was: unknown
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Jun 18 15:07:14 Tower kernel: hdb: dma_intr: error=0x84 <3>{ DriveStatusError BadCRC }
Jun 18 15:07:14 Tower kernel: ide: failed opcode was: unknown
Jun 18 15:07:14 Tower kernel: hdb: no DMA mode selected
Jun 18 15:07:14 Tower kernel: ide0: reset: success

This could be an indication of a poor quality cable to the drive, or some other hardware issue.  It is not likely to be related to the change in version of unRAID, but perhaps it is now detected, where before it was not.  I would first try a new cable to /dev/hdb  Make sure it is NOT a round cable and is a 80 conductor cable.. (usually one blue, one grey and one black connector)

 

While you are looking at your server, make certain that the memory voltage, timing, and speed are properly set in your BIOS.  A lot of MB set it automatically, and a lot get it WRONG.  Incorrectly set up memory can cause all kinds of weird problems.

 

If that does not get rid of the errors....

Can you revert to your old working version (by putting back the original two bzroot and bzimage files) and see if the syslog shows a clean startup?   (You can just re-name the current files to bzroot45 and bzimage45 temporally)

 

Yes, you can just press restore, and re-compute parity on ALL your drives. if they were all healthy..

but one is NOT healthy... so I'd not do that just yet.   

Joe L.

 

 

 

 

I cant believe I had you spend all that time and brain power to troubleshoot a bad cable. It was just that. You are the man and I want to apologize to the community for wasting your time.

It's amazing how many times that bad cables have been determined to be the cause of unRAID trouble.  It looks to me as if it may be approaching the top of the list for possible suspects whenever there is a problem with an unRAID array, especially if it already looks like a drive problem.  It's clearly time to revise the hard drive sections of the Troubleshooting wiki page, as well as some of the hard drive FAQ entries, at least to warn users not to assume too quickly that a drive is bad when they see errors or a Red ball; and to never decide anything until someone has seen the syslog and SMART report.