Van Helsing

Maybe check your bios version against what the last version that was available for that motherboard. Possibly updating the motherboard bios to the latest version could solve the problem your having.

Uraid version 6.1.8 Disk: Hitachi 4 TB 7200 rpm Preclear Disk Beta version 0.3 [pre]############################################################################################# # # # unRAID Server Pre-Clear of disk /dev/sdi # # Cycle 1 of 1, partition start on sector 64. # # # # # # # # Step 1 of 5 - Pre-read verification: [9:34:09 @ 116 MB/s] SUCCESS # # Step 2 of 5 - Zeroing the disk: [8:20:13 @ 133 MB/s] SUCCESS # # Step 3 of 5 - Writing unRAID's Preclear signature: SUCCESS # # Step 4 of 5 - Verifying unRAID's Preclear signature: SUCCESS # # Step 5 of 5 - Post-Read verification: [10:41:20 @ 103 MB/s] SUCCESS # # # # # # # # # # # # # ############################################################################################# # Cycle elapsed time: 28:36:27 | Total elapsed time: 28:36:27 # #############################################################################################[/pre]

Also a couple of noob questions just to clarify a few minor points. 1. Does the parity disk have a file system and is there any need to change it, because none is listed? 2. In the final step when you stop the system and change the copied RFS disk to XFS and then format it, is the parity still intact or should another parity sync be done?

I don't know about whether there's a temporary file or what it's named (I've never had one), but it should have a current timestamp, as the last thing written. I'd use a file manager and view the destination folder(s), sort by date modified with newest on top, and look for the most recent file. UPDATE: After what happened above I started a new telnet session, reissued the rsync copy command exactly as before. After it completed I started a rsync checksum verification, which took as long to copy all the files, so yes lengthy with no apparent errors or recopied files. Did a disk to disk file and folder comparison with Ultracompare and it was an exact duplicate. Ran a parity sync with no errors. So even after the interrupted copy procedure, everything came out A-OK as far as I can tell and feel confident that this is a very secure procedure. As far as I can tell with my limited knowledge of Linux the -a (archive command) saves the interrupted file and then picks up where it left off when reissued. Thanks for all the help.

I started the rsync operation as in RobJ's tutorial from a windows telnet session. Went to bed and when I awoke to check the operation, found that windows had performed an update and rebooted, terminating the telnet session and as far as I can tell the copy operation as well because the new drive was not even close to having the same amount of data that the copied drive had. I really don't know anything about Linux, but from my research it seemed to indicate that rsync will continue to copy but depending on what version of Linux you have, the partial hidden file my or may not be deleted. Since I'm trying to make an exact copy for replacing the reiserfs disk with the xfs disk I'm concerned about what effect the partial file would have and if there is some way I can determine what the name of the file is and delete it if it indeed exists and wasn't already deleted. I've inputed the same exact rsync command and it seems to be picking up where it left off but I have no idea if the partial file was deleted.

Will rsync pickup where it left off if Windows restarted during screen session? What about the temporary file that was left behind will that be deleted?