I just upgraded (following the upgrade instructions exactly as documented in the "4.2 final" announcement) from 4.0 to 4.2 final.  I copied the appropriate files over to the flash, overwriting the older ones, and rebooted the server.  When the server came back up, I logged in to the box, only to find that most of the drives had a red icon, and it said my parity disk was not the largest disk in the array?!?!

 

Fortunately I backed up the old files on the flash and promptly copied them back over to the flash drive and rebooted once more, which put things back to where they were and I was up and running again.

 

As one can imagine, this was a bit of a shock to do the upgrade and find things in that state.  I did not delete or overwrite any files on the flash pertaining to the configuration of the server.

 

Can anyone explain why this happened?  Why would unraid think my drives are in different positions?  And why would it think my parity drive is some other drive that has actual data on it?

 

I would really like to upgrade to 4.2 now that it is "final", so any assistance with this issue would be greatly appreciated.

The different (newer) version of Linux is simply detecting your disk hardware in a different order than the older version of Linux.  This is not a problem, but simply how it is designed.  It has nothing to do with unRaid, but instead the underlying Linux operating system.

 

As disks are detected, the drive letters are assigned.    Since the drives are detected in a different order, the drive letters are affiliated with different drives then before, and as you described, the parity and data drives are in the wrong logical slots so the unRaid array will not start.

 

This time, prior to shutting down, write down the current disk  drive model/serial numbers and their associated logical slots in your array.  You can see this on the drive assignment page.

 

When you put the 4.2 upgrade files in place again and re-start the array it will complain once more since as you described, it has the drive assignments wrong. 

 

All you should have to do is go to the drive assignment page and un-assign the drives and then re-assign them to their correct logical slots.  Use your written notes on model/serial number to put the same drives back on their original slots.

 

Then, go to the main page, it should let you then start the array.

 

Whatever you do, do not check any "checkbox" to reformat any drives... none should need reformatting.

 

Joe L.

I just upgraded (following the upgrade instructions exactly as documented in the "4.2 final" announcement) from 4.0 to 4.2 final.  I copied the appropriate files over to the flash, overwriting the older ones, and rebooted the server.  When the server came back up, I logged in to the box, only to find that most of the drives had a red icon, and it said my parity disk was not the largest disk in the array?!?!

 

Fortunately I backed up the old files on the flash and promptly copied them back over to the flash drive and rebooted once more, which put things back to where they were and I was up and running again.

 

As one can imagine, this was a bit of a shock to do the upgrade and find things in that state.  I did not delete or overwrite any files on the flash pertaining to the configuration of the server.

 

Can anyone explain why this happened?  Why would unraid think my drives are in different positions?  And why would it think my parity drive is some other drive that has actual data on it?

 

I would really like to upgrade to 4.2 now that it is "final", so any assistance with this issue would be greatly appreciated.

 

Is this the complete set of files that you copied from the new release?

    bzimage

    bzroot

    syslinux.cfg

    menu.c32

    memtest

 

Yes, those are the 5 files I copied from the 4.2 final release.

 

Did this drive re-ordering issue happen when upgrading to previous 4.2 beta releases?  I get really nervous when it comes to making configuration changes on this box for fear of accidentally clicking the wrong option and losing data.

 

Is there any way the upgrade files can be tweaked so things stay as they are now and I don't have to go in and re-do the drive assignments?

Is there any way the upgrade files can be tweaked so things stay as they are now and I don't have to go in and re-do the drive assignments?

No.  An unRAID release is a slimmed down Linux Slackware-based distro, that installs a new Linux system each time it boots, then loads the unRAID modules.  It is the Linux system that identifies and configures the hardware, then unRAID loads and maps the drive devices to the disk numbers.

 

The re-ordering of the drives is a side-effect of the upgrading of the Linux kernel included with each upgrade of unRAID.  It does not happen often, and does NOT endanger your data.  It just means that occasionally you may have to re-assign 1 or more drives.  Even if you assign them differently (except for the parity drive), no data is lost.

 

There have been several times (but rare) that a newer release detected hardware differently or wrongly on a particular user's hardware, and then the user would report it, and revert to the previous release, until a fixed version was issued.  No data was lost.

 

I wonder if Tom could convert his drive table to store the drive serial number and disk number pairs only, and not the current disk number with drive device info, making it almost completely independent of the hardware.

 

Yes, those are the 5 files I copied from the 4.2 final release.

 

Did this drive re-ordering issue happen when upgrading to previous 4.2 beta releases?  I get really nervous when it comes to making configuration changes on this box for fear of accidentally clicking the wrong option and losing data.

 

Is there any way the upgrade files can be tweaked so things stay as they are now and I don't have to go in and re-do the drive assignments?

 

Please post your h/w config: Motherboard, Disk controllers (if any).

 

For a given static h/w config, the disk port assignments should remain the same across all unRAID versions starting with 4.0 - at least we have never seen a case where they didn't.  But we only have a handful of motherboards we test against - all Intel based.  So I suppose it could happen.

For a given static h/w config, the disk port assignments should remain the same across all unRAID versions starting with 4.0 - at least we have never seen a case where they didn't.  But we only have a handful of motherboards we test against - all Intel based.  So I suppose it could happen.

There were a few of us with changes with the release of 4.1.  I only had a minor issue, but at least a couple of others were a little more significant, but in no way insurmountable.  Here's 1 thread, and it points to another, and I believe I've seen at least 1 more:  http://lime-technology.com/forum/index.php?topic=921.

 

Thanks everyone for the explanation of what happened.  I feel comfortable doing the upgrade and corresponding drive re-assignments now, based on your feedback.

 

Tom, just a suggestion - since it seems like this is not the first time this issue has come up, I think it would be helpful for other users if you augmented your upgrade instructions on the  announcement page to include what to do if someone upgrades and encounters a situation where their drives are detected in a different order after rebooting.

 

Also as you requested, here is my hardware config:

Motherboard:  Gigabyte GA-945GZM-S2

SATA controller:  2x Promise SATAII150/SATA300 TX4 (all drives are connected to these controllers)

1GB RAM

hard drives:  2x WD 320GB, 1x WD 500GB, 2x Seagate 500GB

 

 

 

SATA controller:  2x Promise SATAII150/SATA300 TX4 (all drives are connected to these controllers)

 

 

Do you mean that you have:

 

1 SATAII150 TX4

and

1 SATA400 TX4

 

or something else?

I have 2 Promise SATA300 TX4 controllers.  I have 5 hard drives total, 4 of which are connected to the first card, and the 5th is connected to the second card.  No hard drives are connected to the SATA ports on the motherboard.