I just stopped my array, rebooted the server, and it came back telling me that all my disks were missing or the wrong disk. My cache drive was assigned as disk 1, parity was missing, disk 1 was assigned to disk 2 slot.

 

I tried to reboot again (which fixed an issue like this before I think), but the broken configuration remained.

 

Luckily the main page told me the ID of the drive it was expecting in each slot, so I manually went and re-assigned them, and all seems good again.

 

I'm using 5.0 beta 4, before the big changes (and bugs) relating to slots came into effect?

 

As a test, I stopped the array again and rebooted again. Same thing. This time disk1 is assigned as the cache drive, disk 2 is assigned as parity, disk 1 is missing, disk 2 is missing.

 

I've attached the syslog from the first and second reboots where the configuration was lost.

 

This is making me nervous. Should I revert to 4.7?

syslog1.txt

syslog2.txt

I just stopped my array, rebooted the server, and it came back telling me that all my disks were missing or the wrong disk. My cache drive was assigned as disk 1, parity was missing, disk 1 was assigned to disk 2 slot.

 

I tried to reboot again (which fixed an issue like this before I think), but the broken configuration remained.

 

Luckily the main page told me the ID of the drive it was expecting in each slot, so I manually went and re-assigned them, and all seems good again.

 

I'm using 5.0 beta 4, before the big changes (and bugs) relating to slots came into effect?

 

As a test, I stopped the array again and rebooted again. Same thing. This time disk1 is assigned as the cache drive, disk 2 is assigned as parity, disk 1 is missing, disk 2 is missing.

 

I've attached the syslog from the first and second reboots where the configuration was lost.

 

This is making me nervous. Should I revert to 4.7?

 

What makes you think 5.0 beta 4 is more stable than 5.0 beta 6a?

 

The beta6a will not start on its own.  It will wait for you to click on the "Start" button.

It will show you if it thinks the drive is formatted, or not, before you press the start button.  If you think the drive is formatted, and it says it is not, then DO NOT press the "Start" button.  Instead, grab some statistics from the drive using two commands lime-tech supplied.  There will be no harm to your data, and in fact, unless you press the "Format" button, there will be no harm to your data although unRAID might overwrite the MBR and set the default partitioning to where your disk looks like it is not yet formatted. This can be reversed in a few seconds with one of two  utilities.

 

Once you have successfully started your array under 5.0 beta 6a, you'll be fine.

 

so far, there have been three types of MBR that unRAID has thought it needed to overwrite.  One is a disk with an HPA (host-protected area) commonly added by some Gigabyte motherboards.  If you have an HPA, especially if you removed it in an earlier version of unRAID, it is suspected it will be considered as non-standard. 

 

The second is an MBR that was installed with a non-standard linux loader LILO.  It wrote its signature to the disk MBR.    If you have no idea what I'm talking about, then you do not have a non-standard linux loader set up in that way. 

 

The third MBR that has been overwritten has been a cache drive that was set up by an advanced user with multiple partitions.  If you have no idea what I'm talking about, then you do not have a cache drive set up in that way. 

 

Prior to starting 5.0 beta 6a you'll see the MBR type unRAID thinks you have on each disk.  If they all say MBR-unaligned, or MBR-4k-aligned then you are fine and you can press "Start"  If ANY disks say "unknown" then post what you see and also the results of the following two commands for each "unknown" disk:

cat /sys/block/sdX/size

dd status=noxfer count=1 if=/dev/sdX | od -Ad -t x1

(where sdX = the device of the disks showing MBR "unknown")

 

Rather than revert to 4.7, I'd give 5.0 beta 6a a try first seeing on how you are so inclined to use beta version on your production data.  (Just don't press "Format", even if you see the button on a disk you know has data when you first boot in that version.  As long as you do not, you can both help in confirming the issue that needs to be accommodated in 5.0 beta 7,

 

Joe L.

I agree with Joe. If you want to use a beta, use beta 6a. Beta 4 had a bug specifically with the structure of the configuration files. It caused a problem if you tried to go over aboy 15 disks.

 

But at first read of your post I thought that your USB filesystem may be corrupted impeding unRaid from writing the corrected disk configuration back to the stick for use on the next boot.  I'd recommend powering down and installing the stick back in your Windows machine and running chkdsk on it to see if there is corruption.

I'm using 5 Beta 5b without issue at the moment. Just before slots came into play.

I agree with Joe. If you want to use a beta, use beta 6a. Beta 4 had a bug specifically with the structure of the configuration files. It caused a problem if you tried to go over aboy 15 disks.

 

But at first read of your post I thought that your USB filesystem may be corrupted impeding unRaid from writing the corrected disk configuration back to the stick for use on the next boot.  I'd recommend powering down and installing the stick back in your Windows machine and running chkdsk on it to see if there is corruption.

 

I don't think it is the USB filesystem. When I checked the disk configuration, it still had my previous configuration saved (but the disks were reported as missing, or wrong). When I updated the disks in each slot I checked disks.cfg and it was being updated. Sometimes my four disks were reported as sda-sdd, and after a reboot they might be sdb-sde. Even if they were the same (sda-sdd), the actual disk for sdb the first time might have moved to sdc after a reboot.

 

What's strange is that I did reboot the server a few times (weeks ago) with no such problem.

 

I could re-assign all disks and start the array OK, but the problem would re-occur after reboot. So what I did was unassign all disks, upgraded to beta 6a and rebooted. Re-assigned the disks. The MBR was MBR-4k aligned for all disks. I rebooted, but the configuration was not remembered. I reassigned the disks again and started the array. It seems to be working fine, but I have to wait for a parity check to finish (parity was fine before).

 

Will find out tonight after the parity check has finished whether or not I can safely stop the array and reboot without losing configuration. Doesn't beta 6b use the actual disk ID when assigning disks to slots, instead of the sata port etc? So hopefully it should be OK. Not sure why it didn't remember the configuration before though, when I assigned disks but didn't start the array and then rebooted.

 

FYI, the parity rebuild has finished. I stopped the array and took note of the device assigned to each disk (sdb-sde) and rebooted. After the reboot my disks were still assigned correctly, even though the device names had changed again (sda-sdd).

 

I'm glad that unRAID is now using the actual ID when assigning disks. But is it normal for the operating system to consistently assign different device names to the same disks like this? I was under the impression that such a thing might happen normally only when adding or removing devices, or using a different sata port on the controller, etc?

 

FYI, the parity rebuild has finished. I stopped the array and took note of the device assigned to each disk (sdb-sde) and rebooted. After the reboot my disks were still assigned correctly, even though the device names had changed again (sda-sdd).

 

I'm glad that unRAID is now using the actual ID when assigning disks. But is it normal for the operating system to consistently assign different device names to the same disks like this? I was under the impression that such a thing might happen normally only when adding or removing devices, or using a different sata port on the controller, etc?

 

The devices are assigned their names as they are initialized by their hardware and make themselves known to the OS.  Identical disks that take nearly the exact same time to spin up will frequently finish their initialization in different order, and have their device names transposed.  Fortunately, unRAID does not care.

 

 

The devices are assigned their names as they are initialized by their hardware and make themselves known to the OS.  Identical disks that take nearly the exact same time to spin up will frequently finish their initialization in different order, and have their device names transposed.   Fortunately, unRAID does not care.

Thanks for that explanation. Makes sense.