Help needed getting Gigabyte GA-81848P775-G going

[Suse User]

Having given up on the Asus A7N8X I bought a Gigabyte GA-81848P775-G.  It's really hard to find any of the supported boards here in the UK.

 

Spent the other afternoon fitting the new Mobo & CPU (Celeron 3.06) now USB starts to boot, gets as far as a "Detecting Hardware" line, something like /etc/rc.d/hotplug.something the the PC speaker emits a constant tone and the computer goes to a Linux login prompt.  This is really beginning to get me down.  I followed the CTRL+F1 SMART enable tip and believe I have the other settings correct, I've tried various combinations of enable Legacy USB/Keyboard etc. with no success.

 

In particular precise bios settings for this motherboard would be a big help.  I'm pretty sure I have them right though.

 

Additionally, I've tried removing all my Reiserfs partitioned Linux discs of Media and tried to start with just three unformatted 400gb Drives (in PM,PS & SM positions) and get the same result.

 

IMPORTANT - Now I'm worried that I'll lose all my music & films as the UnRaid did boot a little way.

Is ther any way to check whether having had a few unsucceful attempt at booting I will now lose all my data if I add my populated volumes?

 

I've been without my server for ages now and am close to giving up on unraid and going back to my Suse setup.

 

Tomm was looking into the A7N8X problem but hadn't managed to get back to me when I found the Gigabyte board online and went for it after reading someone had successfully used it for Unraid on these forums.

 

Does anyone have an idea what may be wrong?

 

Thanks,

 

Mark.

[Suse User]

I got it going!! 

 

Turned out that despite the fact I had 3 brand new identical 400gb drives one of them is showing as being 1056bytes smaller than the others.  What I was mistaking as a system board error was unraid warning me.

 

Trust me to have that one in the Parity position

 

Anyway, swapped those over and all seems ok, other than the fact this "smaller" HDD appears to be populated, full actually..Of 390,710,296 available only 51,764 Free.  Looking at the drive on the network it's got nothing on it.

 

Any tips on how to re-introduce it to the array as a NEW drive without affecting theo ther 11 Disks?  I've got another 4 hours or so before parity sync completes but I'm really relived that all the data on my existing Reiserfs partitions is presnt and correct!

 

Mark.

[Joe L.]

Be very careful and make absolutely certain you know which disk you are clearing before you do this... in fact, you might even unplug all those that have your other data first before clearing your new disk. (unplug when powered-down of course, not when power is applied ... you knew that, but just wanted to make sure)

 

Log in as "root" at the "login" prompt

 

now you need to determine the device name of the disk you want to clear...

Type:

 

cat /proc/mounts

 

The first column is the device name, the second the name used when sharing it on the network.

On my server the output of the above command looks like this:

[pre] cat /proc/mounts

rootfs / rootfs rw 0 0

/dev/root / ext2 rw,noatime,nodiratime 0 0

proc /proc proc rw 0 0

/dev/sda1 /boot vfat rw,sync 0 0

usbfs /proc/bus/usb usbfs rw 0 0

/dev/md3 /mnt/disk3 reiserfs rw,noatime,nodiratime 0 0

/dev/md2 /mnt/disk2 reiserfs rw,noatime,nodiratime 0 0

/dev/md1 /mnt/disk1 reiserfs rw,noatime,nodiratime 0 0

root@Tower:/boot/system/current#[/pre]

 

So if I want to clear disk2 on MY server, its device name is /dev/md2    (You may get a different device on your server depending on how the "go" script has been edited, so, make sure you check your own results before continuing to the next step.)

 

Next step is to clear the drive (now that we know which one it is)

 

Type the following  (assuming you are clearing /dev/md2.  If you are clearing a different drive, use its name instead)

 

dd if=/dev/zero  of=/dev/md2

 

That command will write zeros to the entire drive (and it will take quite a while for a large drive)  If you only want to erase the partitioning instead of erasing all the contents you can limit how many blocks you write by typing this instead:

 

dd if=/dev/zero of=/dev/md2 count=10

 

It will be much faster as it will only write the first 10 blocks with zeros. (512 byte blocks, total of 5120 bytes written)

 

Now, when you next restart unRaid it should see an unformatted disk and prompt you for how to proceed.  (I'm pretty sure it writes zeros to clear an entire  drive before initially adding it to the array, so might as well let it do it and only write a few blocks to the drive as I described above to wipe out the partition table instead of the clearing the whole drive)

 

You have been warned, giving the wrong device name as the output file of the "dd" command will zero out the wrong disk, and there is NO UNDO command.  This could be very bad the disk you accidentally named held all your movies or music.  Make sure you have the correct "device" name before you perform these steps.

 

If you are unsure of any of this ask for help before proceeding...

 

Joe L.

[Suse User]

That seems very clear & straight forward, do I stop the Unraid array first?

 

The offending drive is "Disk 1" and is on the Primary IDE Controller Slave (Primary Master being the Parity drive), so I guess that'll be /dev/mnt1?

 

This disks either side of it are the Parity drive and another blank HDD so should be ok.

 

Thank you for that,

 

Mark.

 

 

 

[Joe L.]

That seems very clear & straight forward, do I stop the Unraid array first?

 

The offending drive is "Disk 1" and is on the Primary IDE Controller Slave (Primary Master being the Parity drive), so I guess that'll be /dev/mnt1?

 

No...First... Don't guess..type the  command I listed above to see the mounted disks to be certain, you do NOT get to undo if you make a mistake.  Since you have disks with data you want to keep, this is not a time to "guess"

 

Second, you've got the device name wrong. The shared mount point is /dev/mnt1 (as you stated) but the device for the disk itself would most likely be /dev/md1

 

so... if that is true, then "dd if=/dev/zero of=/dev/md1 count=10" would probably do it for you.

 

Last, you should stop the array first.  (Not sure how it would react, but it would not be something it normally expects, that's for sure)

 

In any case, after running the "dd" command you can reboot the server. It should then show you an unformatted the disk then on the tools page "Reset Array Configuration" and it should rebuild parity for you.

 

Good luck...

[Joe L.]

Thinking about it a bit more, unRaid seeing a disk "missing" (unformatted actually might just get it to start re-building the disk exactly as it was before you zero'ed it out... (That is what raid does... right) so

 

Stop the array

Zero the drive

Power down

Unplug the zero'd drive

Power up

Use "Reset Array Configuration" on the "Tools" page to have it forget it ever had the disk currently unplugged.

Stop the array again

Power down

Plug back in the disk you zero'ed

Power back up and it should think the drive is new (It should have forgotten it had ever seen it before)

Format the drive you had zero'ed and start using it.

 

Joe L.

[Suse User]

This is very strange, I did the DD business on Disk1, booted with it powered off, restarted with it reconnected and all appeared fine

 

Only problem was that the array wouldn't start telling me that the Parity drive was once more not the largest drive.  If you look at the image above it appears to be the equal biggest partition.  Refreshing the screen didn't change the above figures so I tried a reboot and got:-

 

My Parity drive has now shrunk!  Disk2 & Disk9 are now the largest.  Disk2 shouldn't cause me a problem as it's empty, I'm guessing that if I do the same DD procedure on it then it'll also come back as the new slightly smaller size.  However Disk9 is fully populated.  I'm guessing that a reiserfs format under Suse gives a slightly larger available free space than under UnRaid.

 

I'm wondering whether I could manually mount Disk1,Disk2 and Disk9 whilst the array is down using:-

 

Mount /dev/mnt1 /mnt/disk1

Mount /dev/mnt2 /mnt/disk2

Mount /dev/mnt9 /mnt/disk9

 

then use a command line instruction to manually copy the data currently on Disk9 to Disk1 & Disk2 so I can do the DD procedure on disk9 too?

 

Any advice?

 

Thanks,

 

Mark.

[Joe L.]

Very interesting...

 

It seems as if your new ST3400832A drives are "discovering" bad blocks on their surfaces, marking them as unusable, and subsequently reporting the slightly smaller size.  Now I thought that some manufacturers map bad blocks to a pool of good ones so you don't lose space (you lose data, but not space)

 

Not sure what to tell you. 

 

Yes, there is a command to copy one disk to another.

 

Assuming the disks are mounted

cp -r /mnt/disk9 /mnt/disk2

 

This will copy all the files, directories, and subdirectories on disk9 to disk2.  (This will take a while if the disks are full)  Be very careful here since if you get the names backwards you be copying from disk2 to disk9 (Not as you intended at all)

 

To mount the disks if they are not mounted you can use the "mount" command, but you must use the "device" names, not the names you gave in your example.  (/dev/mnt1,/dev/mnt2, and /dev/mnt9 are NOT valid disk device names)

 

The device names are /dev/md0 through /dev/md15 on my server with /dev/md0 being my parity drive.  Odds are they are the same on yours, but since these are defined in your "go" script you will need to verify how you have them configured to be certain.

 

Joe L.

 

 

 

 

[Suse User]

I've also noticed that all my drives are now marked as "NEW", does this mean I'll lose data when parity is rebuilt?

 

Thanks,

 

Mark.

[Suse User]

SOmetimes the simplest solutions are staring you in the face but you can't see them.

 

Having removed Disk2 to another machine and completely deleted the partition, tried reiserfs formatting under Suse, "fdisk"'ed it back in the UnRaid box when that didn't work it hit me...

 

The despite the fact they are the same make & model HDD, bigger drive is empty, the parity is smaller.  And then it hit me....SWAP THEM OVER YOU IDIOT!  It's no different to if the Parity and the Empty volume had failed.

 

Done it and all data appears intact and parity in resynching.

 

I'm embarrased that I didn't think of this before, but I am new to UnRaid so that's my excuse

 

Thanks for the help Joe, I've learned some useful lesson to store up for the future.

 

Mark.

[Joe L.]

I've also noticed that all my drives are now marked as "NEW", does this mean I'll lose data when parity is rebuilt?

 

Thanks,

 

Mark.

No, they were all marked as "New" when you pressed the "Reset Array Configuration"  In this case, when all are marked as new, the unRaid software simply detects the disks (to learn their sizes and ID's) and then builds parity on all those present.  No data on the existing drives is deleted.

 

Glad you got things going now..

 

Once the parity rebuild is complete, the drives will be marked as "OK" (If I remember correctly)

 

Joe L.

[Suse User]

ARRRGGHHH!!!!!!!

 

OK, so I need some therapy now.  I've officially flipped!  Can't decide whether to cry or break something right now....

 

Swapped the drives over no problem.  Spend a couple of days sorting the drives out, juggling all my data around (which wasn't easy) but eventually everything is good to go!

 

So today I am done!  everything is where I want it, I'm ready to move the server to it's permenant new location.

 

Turn off (incl. shutdown command in Linux before powering off to be double safe), Move it, boot up and...

 

 

Apprarantly Parity isn't my biggest drive again!  Parity is the biggest drive!!  Can't you count?? stupid box!!!!

 

What can I do now please?  I've tried rebooting with no difference

 

I'd really appreciate some comment from UnRaid support here.

 

Thanks,

 

Mark.

[Suse User]

I need a couple of drives for some Desktop PCs, and using this as an opportunity/excuse to upgrade a couple of the smaller drives in my UnRaid array seems like a good idea to me.

 

I'm still running 2.060706 without subsequent incident, despite several power cuts recently (3 in 1 day!)

 

So....Do I risk buying a couple of 750Gb drives and risk going through all this "Shrinking Parity" again?  or would I be better off attempting a v3.0 upgrade first?

 

I have to say the idea of a failed V3 upgrade sends a cold shiver down my spine, though the new features would be nice.

 

Mark.

 

 

[limetech]

Upgrading to 3.0 is very low risk because you will be using a completely different Flash.  If you are careful to create a 'super.dat' file then you will be able to ensure that your new Flash will recognize your array without having to rebuild parity.