My machine comes up with all red disks and states too many missing disks. Reverting to 4.3.1 fixes the problem.

My machine comes up with all red disks and states too many missing disks. Reverting to 4.3.1 fixes the problem.

Different versions of Linux scan the hardware in different orders...  Odds are you just need to do the following:

 

1.  Go to the main management page for the unRAID server.  Make a note of the disk drive/serial numbers and the respective slots you have them assigned. (or do a print-screen from your browser)

 

2.  replace the bzroot and bzimage files with the latest release versions, just like you did when you found the drives "missing" and reboot.  Odds are high the drives  will be missing once more.  Do not panic... they are still there.

 

3. Go to the "devices" page on the management interface.  Assign the drives back to their original assignments, using the listing made in step 1.

 

4. Go back to the main management page, you should be able to use the "Start" button to start your array.

 

If you still are unable to start the array, capture a copy of the syslog as described here http://lime-technology.com/wiki/index.php?title=Troubleshooting for our analysis, and revert back to 4.3.1.

 

Joe L.

To make it easier to switch back and forth between versions, use Joe's changes to the boot menu (in syslinux.cfg), an example of which is here.  (A side benefit of his method is that it helps lengthen the life of the USB flash drive, by cutting down on extra writes to the flash memory.)

 

Definitely would like to see that 4.3.2 syslog...

Thanks for the speedy reply guys. Unfortunately, that didn't fix it. The drives on the "devices" page were all in the proper order. I unassigned them and assigned them back to no avail.

 

The main page shows all the drives in the proper order but with red icons on all of them. They're presented with two names. I assume what I'm seeing is what it's supposed to be followed by what is being read at startup in italics. For example here is the text for my parity drive...

 

ata-WDC_WD7500AAKS-00RBA0_WD-WCAPT0450424

ata-WDC_WD7500AAKS-0_WD-WCAPT0450424

 

 

 

 

Mine did the same thing. I unassigned & reassigned the drives & still had the red balls. I just checked the check box, below start the array. I then started the array, that reassigned the drives & all is good. All is green & data is safe.

 

Whatever you do don't click on the restore button. Just start the array. At least on mine that worked well.

 

Phil

The main page shows all the drives in the proper order but with red icons on all of them. They're presented with two names. I assume what I'm seeing is what it's supposed to be followed by what is being read at startup in italics. For example here is the text for my parity drive...

 

ata-WDC_WD7500AAKS-00RBA0_WD-WCAPT0450424

ata-WDC_WD7500AAKS-0_WD-WCAPT0450424

You've got it exactly right... the two values for each drive represent the old expected value, and the new.  And they ARE different in your example, similar, but different.

 

Can you attach a 4.3.1 syslog so we can do a stare-and-compare.   (I'm assuming you reverted to it)

 

Probably best to wait for Tom to see this thread, and hopefully, the two syslogs will give him the clues he needs for version 4.3.3.  

 

If it makes you feel any better, my upgrade went without a hitch.  I'm currently running 4.3.2.

 

Joe L.

If it makes you feel any better, my upgrade went without a hitch.  I'm currently running 4.3.2.

 

Mine too went without any problems at all.

ata-WDC_WD7500AAKS-00RBA0_WD-WCAPT0450424

ata-WDC_WD7500AAKS-0_WD-WCAPT0450424

 

It looks like the extended drive model number is reporting differently or truncating ("0" versus "00RBA0").  Are all your drives the same type of Western Digitals?  Are all your drives showing this behavior, or are some reporting correctly?  What are the makes and models of ones reporting correctly?

While it doesn't make me feel any better, I am glad you guys aren't having any problems. I'm able to revert back to the previous version so the initial panic is long since past.

 

Are all your drives the same type of Western Digitals?  Are all your drives showing this behavior, or are some reporting correctly?  What are the makes and models of ones reporting correctly?

 

All drives are the same model and all drives are red.

 

 

 

 

 

So far, it just seems to be Western-digital drives.  (I don't have any, guess they never were on sale when I was purchasing)

 

So far, reports are you can use the "Start" button to start the array, as long as all the drives are in their correct slots. (Most critical is parity drive is in the right assigned slot)

 

It appears as if the model names are truncated differently on the WD drives now vs. the 4.3.1 version.  Model/serial# is how unRaid tracks the assigned disks...

It is just protecting you from what it thinks are different disks.

 

DO NOT USE THE RESTORE BUTTON..., just the "Start" button.

 

Joe L.

I can't get the start button... I've checked all my assignments and they are correct, but the start button is greyed out and says "Too many wrong or missing disks".  I tried checking the "I'm sure I want to do this" but the only option it gives me is "restore."

 

I have 4 WD (out of 7 total).

 

I had two check boxes. One under - start array & one under - restore. I checked the one under start array. I have 13 WD drives that were effected.

 

Phil

I can't get the start button... I've checked all my assignments and they are correct, but the start button is greyed out and says "Too many wrong or missing disks".  I tried checking the "I'm sure I want to do this" but the only option it gives me is "restore."

 

Exact same here - no "Start" button and no "I want to do this" under Start (except I have 2 drives (parity and disk1) out of 4 that are WD).

See attached pic.

 

 

Tom will likely post a fix, but if you can't wait, I'd suggest booting with your prior unRaid version, and run a parity check. If there are any problems on the disks in the array, this will give a chance to detect/correct them. Once you are confident your disks are okay, boot with 4.3.2 and use the restore button. YOU WILL LOSE PARITY PROTECTION THE INSTANT YOU PRESS THE BUTTON, but since you just did a full parity check, your risk is pretty low. After you start the array, parity will be rebuilt. 

I believe the reason I had the check box under the start button was because my parity drive was a Seagate. It showed up with a green ball next to it. Since it knew my parity drive was ok it allowed me to just start the array.

Tom will likely post a fix, but if you can't wait, I'd suggest booting with your prior unRaid version, and run a parity check. If there are any problems on the disks in the array, this will give a chance to detect/correct them. Once you are confident your disks are okay, boot with 4.3.2 and use the restore button. YOU WILL LOSE PARITY PROTECTION THE INSTANT YOU PRESS THE BUTTON, but since you just did a full parity check, your risk is pretty low. After you start the array, parity will be rebuilt. 

If the shorter drive model number was stored in the earlier versions of unRAID, and the longer (complete) drive model number is now stored, there may not be an easy fix other than what you described.... unless Tom makes the drive comparison a bit smarter.

 

I do agree, if you don't want to wait for a recommendation from Tom, this is one of the few times where use of the "restore" button might be the way to get everything sane again.  Whatever you do, MAKE SURE the PARITY DRIVE is assigned to the PARITY slot in the array before you press "restore" otherwise, you will write trash to the data drive accidentally assigned in the parity slot.

SUMMARY

 

(this is based on best information currently available)

 

1.  If you have Western Digital (WD) drive in the array but NOT in the parity slot, make sure that the drives are in the right slots, and start the array.  unRAID may make you click a checkbox to enable the start button, but if your drives are in the right slots (ESPECIALLY PARITY), this is safe and will result in a saving your configuration, including the slightly different drive names, successfully.  No parity check / build will be required, although doing a parity check afterwards would not be a bad idea.

 

2.  If you have a WD in the PARITY slot, you will likely have problems having 4.3.2 recognize your array as valid.  The only known solution for these folks, besides waiting on a fix for Tom was described in this post ...

 

Tom will likely post a fix, but if you can't wait, I'd suggest booting with your prior unRaid version, and run a parity check. If there are any problems on the disks in the array, this will give a chance to detect/correct them. Once you are confident your disks are okay, boot with 4.3.2 and use the restore button. YOU WILL LOSE PARITY PROTECTION THE INSTANT YOU PRESS THE BUTTON, but since you just did a full parity check, your risk is pretty low. After you start the array, parity will be rebuilt.

 

As Joe L. mentioned, make doubly shure your parity drive is assigned to the parity slot, and not some data drive.  Starting the array with a data disk in the parity slot is a disaster!

 

This will take HOURS (first to run the parity check under the prior unRAID version, and then to rebuild parity).  Sorry, but at least you know.  Skipping the initial parity check is not advised, as it subjects you to greater risk that you'll have some disk problem when running the parity rebuild.  But this is a personal decision.

 

There is really no reason not to wait until either there is a fix or we know for sure there isn't going to be one. The enhancements in the new version are not compelling enough for me to use the RESTORE button just yet.

I thought of another possible way to get the disk model names back in sync.

 

DO THIS ONLY IF YOU ARE SURE YOU HAVE NO DISK "READ" ERRORS, NO DEFECTIVE DRIVES, AND HAVE RUN "smartctl" on the disks to ensure they are healthy.

This procedure is functionally equivalent to pressing the "Restore" button.  A better procedure is listed further on in this thread by Tom.  It involves a special command typed at the system console or a telnet prompt.  Use it instead.

 

Go to the devices page and UN-Assign the parity drive.

 

Go back to the main page, at this point, make sure every other drive is in their correct slot in the array.   They may be "red" because the disk model does not agree, but make sure they are all in their correct slots.  (The serial numbers should match up)  If any show as "unformatted" STOP and do not continue as all the data drives should have a file-system already.

 

Now,assuming none of the drives show as "unformatted" check the checkbox below "restore" and start the array.   Note: since you do not have a parity drive assigned, no parity calculation will occur.  The array should start, and all but the parity drive should show green.     Now, we just need to get the parity drive model/serial sync'ed up.

 

Stop the array once more, go to the devices page, re-assign the parity drive to the parity slot,  

Back on the Main page, press the "Restore" button. The array should start a full parity calculation with its "new" parity drive.  When done, all will be in synch.

 

As already said, a prior full parity check on the prior release will ensure that all the hardware is working without error.  Your call if you want to skip that step.

 

Edit: added warnings... this is equivalent to pressing the "restore" button.  If errors exist, you could lose data.  You will lose parity protection while the parity drive is being rebuilt.  A better procedure is listed further on in this thread by Tom.  It involves a special command typed at the system console or a telnet prompt.  Use it instead.

 

Joe L.

There is really no reason not to wait until either there is a fix or we know for sure there isn't going to be one. The enhancements in the new version are not compelling enough for me to use the RESTORE button just yet.

Very Very True... and smart too.

 

Joe L.

So for mine here, assuming I'm not overly worried about parity, I can just go ahead and click "Restore", and I won't lose any data?

 

http://www.wedontlikeu.com/images/unraid/unraid.JPG

 

Edit: Heh, caught the screenshot at a bad time; the ones with the different names are flashing red, the others are not.

So for mine here, assuming I'm not overly worried about parity, I can just go ahead and click "Restore", and I won't lose any data?

 

http://www.wedontlikeu.com/images/unraid/unraid.JPG

 

Edit: Heh, caught the screenshot at a bad time; the ones with the different names are flashing red, the others are not.

As long as the parity drive is in the parity slot you will not lose data. (and I can see from the screen shot it is)  Pressing "restore" will immediately start the process of re-computing parity.

 

(Just when I've convinced folks the only time the "restore" button is needed is when removing a drive, something like this comes along and gives you a different reason to use it).

 

Joe L.

This problem is a result of the "model" field being 20 40 characters in the ATA specification, and 16 characters in the SCSI specification.

 

For those of you experiencing this problem, please capture the output of this command:

 

 v /dev/disk/by-id

 

And post along with your system log.  This will help me decide the best course of action to fix it.  Thanks!

 

BTW you can also just click the Restore button and then click Start.   This will start a parity sync, but all data will remain intact.

 

Edit: struck out "20" above - "model" field in ATA spec allows for 40 chars.  Note that SCSI also permits a longer field when using VPD Page 0x83 (which libata does use).

As requested, here's my syslog and command output files from my 4.3.2 Pro system where I have no "Start" button and no "I want to do this" under Start.  I have 4 drives total and 2 drives (parity and disk1) are WD.

 

Bruce...

This problem is a result of the "model" field being 20 characters in the ATA specification, and 16 characters in the SCSI specification.

The code in md.c is comparing as many as 40 characters of the model, not 20.  The offending disks have a 22 character model number (including the "ata-" preface), but were truncated at 20 characters in the past.   You have room on the superblock for 40 for model, 20 for serial.  (I verified using "od" on an old superblock I happened to have saved.)

 

You might be able to get away with something like this following code block.... truncating the model numbers at 20 chars.  If the first 20 characters of the model are the same, AND the serial numbers are the same, odds are good it is still the same drive.

 

What is interesting is that the struct for the superblock has always had the model number as an array of 40 characters, even in the older release.   Might the recent linux release upgrade one of the last beta's have chaged the way the device id's are formed by udev?  (truncating them at 20 chars previously)

Edit: I did not realize the "ata-" preface was being stripped, so, the code below would have to truncate at 16 chars, not 20.

 

Joe L.

 

Excerpt from md.c

[pre]

/* check if disk info & size matches recorded info & size */

static int same_disk_info( mdp_disk_t *disk, mdk_rdev_t *rdev)

{

        char str1[41];

        char str2[41];

 

        set_str( str1, disk->model, 40);

        set_str( str2, rdev->model, 40);

        str1[16] = '\0';  /* truncate the model number tmp string at 16 20 characters for the comparison */ 

        str2[16] = '\0';  /* truncate the model number tmp string at 16 20 characters for the comparison */

       if (strcmp( str1, str2) != 0)

                return 0;

 

        set_str( str1, disk->serial_no, 20);

        set_str( str2, rdev->serial_no, 20);

        if (strcmp( str1, str2) != 0)

                return 0;

 

        if (disk->size != rdev->size)

                return 0;

 

        return 1;

}

[/pre]