BrianAz

+1 on having to pull the stick, move syslinux over manually and run make_bootable. After that though, it's the perfect setup as all my config carried over without issue. This script makes upgrading pretty easy. Thanks!

I've moved the drive to a bay plugged directly to the motherboard (rather than the SAS2LP-MV8). So far so good. Cycle 2 of 3 and no problems at all thus far. It's even emailing me every step of the way like it should. I also found a couple other threads of people reporting difficulty pre-clearing on the SuperMicro card(s). One guy said it resolved when he plugged direct to the motherboard. It's looking like that's the key here. I wonder why it doesn't have any issues during normal use or parity checks but preclear causes problems. I guess maybe preclear is stressing the card harder than a parity check/build does? Edit: Just finished the 2nd of 3 preclear cycles with my original command. Seems to be working just fine plugged into the motherboard. My system even did its monthly parity check last night and everything's still going strong. Seems like preclear and SAS2LP-MV8 just don't mix

No good ideas here. Just to eliminate a possibility, can you try re-running with adjusted email options, as the -M 4 option runs some code not used by anything else. Try -M 3 and lower, and perhaps with no email at all. Are you receiving the emails correctly, both with and without the -c option? Most likely, Joe L will have to help you, when he has time. Thanks for your response. I do receive the emails until a certain point and then they just stop coming. It had been more than a few hours between emails during a preclear, so I telneted in to investigate and noticed things were a bit slow and the load avg was ~ 50. Then of course I try the gui, but it's dead as well. I think if I caught it earlier, I could probably shutdown cleanly via the gui. I'll have to look into monitoring the load somehow. Shutting down hard like that and the ensuing parity check sucks . My parity check just finished, so I'll start the following preclear command tonight and check on it in the am. I took your suggestion of simplifying the command and also removed the -b -w -r options as well since I'm doing just this one disk. I'll report back in a day or two unless it exhibits problems sooner. My experience has been that it became unresponsive before the first cycle was complete (towards the end though...) so if we move on to the second cycle, that'd be an improvement. root@Tower:/boot# preclear_disk.sh -l ====================================1.13 Disks not assigned to the unRAID array (potential candidates for clearing) ======================================== /dev/sdn = ata-Hitachi_HDS722020ALA330_JK1101B8GN2BBZ root@Tower:/boot# preclear_disk.sh -A -c 3 /dev/sdn Pre-Clear unRAID Disk /dev/sdn ################################################################## 1.13 Model Family: Hitachi Deskstar 7K2000 Device Model: Hitachi HDS722020ALA330 Serial Number: JK1101B8GN2BBZ Firmware Version: JKAOA3EA User Capacity: 2,000,398,934,016 bytes Disk /dev/sdn: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdn1 64 3907029167 1953514552 0 Empty Partition 1 does not end on cylinder boundary. ######################################################################## invoked as ./preclear_disk.sh -A -c 3 /dev/sdn ######################################################################## (-A option elected, partition will start on sector 64) Are you absolutely sure you want to clear this drive? (Answer Yes to continue. Capital 'Y', lower case 'es'): Yes Edit: So far so good. Nearly complete with cycle 2. Since the minimal command seems to work for me, I'll leave this until I need to do another preclear and add the -M option back slowly... starting with the lower levels as suggested. Thanks! Edit #2: About 75% through the third of 3 cycles, the video I happened to be watching began to skip. I telneted into UnRaid and saw the load had spiked to 4-5 range. The GUI came up, but a bit slowly. I was able to stop the array properly and re-started it after the load dropped down to ~ 1.8/2.0 (5-10 min) I started the array again (with the preclear still running) and everything was fine from there out (watched another 1-2 hrs of videos after re-starting the array). Once the preclear completed the load declined to it's normal ~.04/.05 range. Does preclear require a stronger CPU for some reason? Should I expect to be able to run preclear without issue on my hardware? My machine is an ASRock z77 Extreme4-M with a Celeron G1610, 4GB ddr3 memory. The majority of my drives (including the one I have been preclearing) are in drive cages connected to 2x Supermicro SAS2LP-MV8 controllers. I do also have a few slots in the cages plugged directly into the motherboard SATA ports. No idea if it would make a difference if I used one of those. Thanks

Background: A few months ago, I moved my UnRaid system from an older GIGABYTE GA-EP45-UD3R motherboard w/ a Q6600 processor w/ 4GB ram to an ASRock z77 Extreme4-M w/ Intel Celeron G1610 and 4GB ram to allow me to expand beyond the 16 drive limit I had at the time. 8 drives were using the SATA ports on the Gigabyte motherboard and the other 8 were on a AOC-SAS2LP-MV8 card. On the ASRock, I'm using 2x AOC-SAS2LP-MV8 cards (1 half-full currently) plus 3 motherboard SATA II ports for 15 drives (14 plus the 1 I'm preclearing. I have 3 more awaiting preclear). UnRaid itself works perfectly. I have no issues with multiple reads/writes going on at the same time (often streaming full Bluray rips). Parity checks happen on a monthly schedule and are running around 10 hours currently. I'm not running anything additional except UnMenu for a couple things (like the parity check). In the past (Gigabyte board, onboard + SAS2LP card ports used), I was able to run preclears without any issue at all. I could run a single drive multiple times using -c and I could also create additional screens and do 2, maybe 3 drives at once. I've been running UnRaid ver 5.0-rc16c without any changes at all since it was running on the Gigabyte board. I just moved the stick to the new board. Problem: With the new board setup, it seems I am only able to run a preclear without the "-c" option or my load avg rises to like 50, the web GUI becomes unresponsive, "Clean Shutdown" commandline script doesn't work (though to be fair, I haven't tried it under normal circumstances yet either) and I end up having to power the server down hard by holding the power button. When it boots, I do the 10 hour parity check and everything is good.... until I decide to try preclear again with -c . Here is the preclear command I'm using: root@Tower:/boot# preclear_disk.sh -r 65536 -w 65536 -b 2000 -A -M 4 -c 3 /dev/sdk For some reason, this seems to cause the load to skyrocket after a while. When it happened last time, I was 12 hours in and 75% through Zeroing the disk on cycle 1 of 3. I make sure the parity check is NOT running while doing a preclear. However when I use the following command to only clear the disk once, it has never failed (except when the disk itself actually fails). root@Tower:/boot# preclear_disk.sh -r 65536 -w 65536 -b 2000 -A -M 4 /dev/sdk I ran this command once 2 days ago, the preclear worked great, unraid remained fully responsive. Then yesterday I added the "-c 3" as mentioned above and after 12 hours, the load (5 min avg?) was 49.89 and all I could do is telnet in. This has happened with 3 different drives thus far, so I don't think it's the drive, port/card or drive cage at fault. So my questions are two fold: Does anyone know why I'm having these issues off the top of their head? I don't think my CPU is as solid as before with the Q6600 but in my mind, I don't use my server for anything other than UnRaid, so I shouldn't need it. Also, The CPU usage seems fine when the problem is happening. What logs would be helpful in troubleshooting this? How should I save them once I telnet in? I'm guessing I copy relevant logs to a folder on /boot, restart, run parity check and then go grab them from /boot? Thanks!