December 27, 200718 yr When I reboot through the console I am forced into a parity sync every time? Is this normal?
December 27, 200718 yr I believe so. One of the steps of the stop array process from the web interface is to set a flag that the array was shutdown properly and parity is valid. Otherwise, this flag says CHECK ME!!
December 27, 200718 yr If you login via telnet you will find a script in the /root folder named "stop" If you execute it by typing stop it will stop samba, unmount the disks, and stop the unRaid array. You can then power down. Upon startup, it should not do a parity check since it was shut down cleanly. Joe L.
December 27, 200718 yr Author Thanks Joe... thats good to know. Im kinda shocked that using the reboot feature from the command area of the web console doesnt take the server down cleanly. I would have thought the reboot command would do the stop and then issue the shutdown. ah well .. another 500 minutes and I'm good to go!
December 27, 200718 yr Thanks Joe... thats good to know. Im kinda shocked that using the reboot feature from the command area of the web console doesnt take the server down cleanly. I would have thought the reboot command would do the stop and then issue the shutdown. ah well .. another 500 minutes and I'm good to go! I'm a bit confused. When you said that you did a reboot from the console I assumed you were not talking about the web-interface, but the Linux command line. From the command line, either from the system console, or the telnet login, a "reboot" command will do as you described, reboot the server, but not shut down cleanly so a parity check will result upon restart. From the web-interface, you can only get to the reboot buton when the array is stopped. Assuming parity calculations have been completed and your array is up and running correctly otherwise, then upon reboot, another parity calc will not occur when you use it. Joe L.
December 27, 200718 yr Author From the web-interface, you can only get to the reboot buton when the array is stopped. Assuming parity calculations have been completed and your array is up and running correctly otherwise, then upon reboot, another parity calc will not occur when you use it. When I go to the web-interface and select 'stop' and then 'reboot' .. on startup it starts a parity check? (all the drives are green and the parity is in sync) So I am not going crazy it should not be doing this? What would cause it?
December 27, 200718 yr From the web-interface, you can only get to the reboot buton when the array is stopped. Assuming parity calculations have been completed and your array is up and running correctly otherwise, then upon reboot, another parity calc will not occur when you use it. When I go to the web-interface and select 'stop' and then 'reboot' .. on startup it starts a parity check? (all the drives are green and the parity is in sync) So I am not going crazy it should not be doing this? What would cause it? I don't know. You would need to post your syslog for anyone to take a guess as to what is going on. Have you ever let the parity check complete? Is your flash drive "writable" (I'm not referring to the user-share permissions, but a physical switch on it to disable writing) If the unRaid server is unable to write the status to the flash drive, it would not be able to mark the parity as having completed.
December 27, 200718 yr Author I am getting a ton of these errors in syslog Dec 27 09:45:58 tower kernel: [48775.280578] scsi 0:0:0:0: rejecting I/O to dead device Dec 27 09:45:58 tower kernel: [48775.280583] FAT: Directory bread(block 527) failed The flash is writable (I edited the go file yesterday)
December 27, 200718 yr I am getting a ton of these errors in syslog Dec 27 09:45:58 tower kernel: [48775.280578] scsi 0:0:0:0: rejecting I/O to dead device Dec 27 09:45:58 tower kernel: [48775.280583] FAT: Directory bread(block 527) failed The flash is writable (I edited the go file yesterday) Bad flash.
December 27, 200718 yr Author It looks like the flash is bad ... I put it in my PC and I can only access it once in a while .. and slow when I do. What options do I have?
December 27, 200718 yr or full flash? Perhaps, but normally the only time the Flash is written is to update the array config data (super.dat) file. It's also written when you create User Shares. Is the Flash full? Also possible the FAT file system is corrupted.
December 27, 200718 yr Author Ok, I am going to backup the flash drive and reformat it and copy the files back on and see if that fixes things.
December 27, 200718 yr Author After I formatted, used syslinux and copied the files back on the flash drive I get a boot error... "invalid or damaged bootable partition" and I get the same error when I try a diff flash drive? Help!?
December 27, 200718 yr After I formatted, used syslinux and copied the files back on the flash drive I get a boot error... "invalid or damaged bootable partition" and I get the same error when I try a diff flash drive? Help!? perhaps try a different usb port. Make sure the BIOS is still set to boot from the flash drive. Make sure you set the volume label to UNRAID
January 2, 200917 yr Was this resolved? I think I am seeing a similar problem. If the flash is bad, that would explain a few other hickups I have seen. "Jan 1 15:09:07 Tower kernel: md: could not write superblock from /boot/config/super.dat Jan 1 15:09:07 Tower kernel: md: recovery thread sync completion status: 0 Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1984) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1985) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1986) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1987) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1988) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1989) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1990) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1991) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1984) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1985) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1986) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1987) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1988) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1989) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1990) failed Jan 1 21:27:18 Tower kernel: FAT: Directory bread(block 1991) failed "
January 3, 200917 yr You might have a corrupt FAT file-system on the flash drive. Or, it might be failing... One thing for sure, if the super.dat file cannot be written, you will be doing a new parity check upon reboot. Joe L.
Archived
This topic is now archived and is closed to further replies.