JustinChase

The biggest request I see, beyond the 'how do I get started' questions is; an updated program version. I know dockers main purpose is to be fully reproducible on any machine, so everyone has the same version; but since we are mainly using docker as a plugin replacement, I think it's reasonable to assume most people would prefer to have the ability to always run the newest version, without having to bother the author to update the docker to the newest version. Perhaps the 'base image' that is agreed should address this issue, to avoid the issue. Just thinking out loud

Is X really the right drive designation? Do you really have over 20 drives in this machine?

I removed the dockerMan plugin, per recommendation from LimeTech, since it's now 'built into' unRAID/Dynamix. I had to re-add the template repository to get my icons back, which seems to have worked. however, the format of the information for the Docker plugin/part is a bit 'off'. The Created and Status/Log fields are wrapping, but they used to be on one line each. Not a big deal, but they looked better before. Changing the zoom of the page doesn't help, the whole 'table' shrinks or expands, and the columns remain the same percentage of the table, so they all stay wrapped. My computer is giving me a hard time, and not allowing me to make screenshots right now, but if you need/want to see what I mean, I'll try to get something. Also, I remember seeing a second template repository once before, but can't find that info now. Is the original gfardim repository still the suggested one; or is there another/better one I should use?

That seems to have worked, thanks! Both temps show 117; not sure if that's right. I'd expect them to be at least a little different. ** I refreshed a few times, and now they are different. Any way to know which is which? There are no labels.

Thanks for the help. I created a /boot/config/sensors.conf file and added only the lines quoted above. I then added "modprobe coretemp" (without quotes) to my go file. I have not rebooted, but I did run modprobe coretemp in putty, but still no temps. I'll reboot soon, just wanted to confirm I did it right before rebooting. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & echo 192.168.20.150 media >>/etc/hosts /usr/local/sbin/vfio-bind 0000:01:00.0 0000:01:00.1 0000:07:00.0 /boot/config/plugins/snap/snap.sh -m snapdisk modprobe coretemp

Check out the Wiki for information on setting up CPU and board temperature sensing here: http://lime-technology.com/wiki/index.php/Setting_up_CPU_and_board_temperature_sensing You'll want to save your sensors.conf file to your flash drive here: /boot/config/sensors.conf Gary Hmmm... root@media:~# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. so I did... root@media:~# sensors-detect # sensors-detect revision 6170 (2013-05-20 21:25:22 +0200) # System: # SMBIOS implementations newer than version 2.7 are not # SMBIOS implementations newer than version 2.7 are not [# SMBIOS implementations newer than version 2.7 are not] This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): yes Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Intel digital thermal sensor... Success! (driver `coretemp') Intel AMB FB-DIMM thermal sensor... No VIA C7 thermal sensor... No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): yes Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes Found unknown chip with ID 0xc803 (logical device B has address 0x290, could be sensors) Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Some systems (mainly servers) implement IPMI, a set of common interfaces through which system health data may be retrieved, amongst other things. We first try to get the information from SMBIOS. If we don't find it there, we have to read from arbitrary I/O ports to probe for such interfaces. This is normally safe. Do you want to scan for IPMI interfaces? (YES/no): yes Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): yes Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM79' at 0x290... No Probing for `Winbond W83781D' at 0x290... No Probing for `Winbond W83782D' at 0x290... No Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): yes Found unknown SMBus adapter 8086:8ca2 at 0000:00:1f.3. Sorry, no supported PCI bus adapters found. Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `coretemp': * Chip `Intel digital thermal sensor' (confidence: 9) Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): yes Copy prog/init/lm_sensors.init to /etc/init.d/lm_sensors for initialization at boot time. You should now start the lm_sensors service to load the required kernel modules. then, I still get... root@media:~# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. This is on an ASRock Z97 Extreme6 motherboard. I see temps and fans speeds in BIOS, just not in putty/console.

when you reboot the unraid server, after the bios boots, the screen/monitor connected to the server shows the boot options of unraid for several seconds. one of the choices is memtest. use your keyboard to navigate to memtest, then hit enter, it will start the memtest.

It means the drive tested each of the 8 sectors, when written zeroes to, and decided they were fine so put them back online. It doesn't mean those 8 are perfect, although they could be, but for now the drive believes each of them can be trusted. The drive appears to be fine now, but not perfect. The best advice we give users when this happens is to Preclear it one or two more times, and see if anything changes. If no further changes, then the drive should be good. All other numbers look OK. After a couple of false starts, here are the results. They look good to me, but would just like confirmation before putting this drive back into the array as a data drive... ========================================================================1.15 == invoked as: ./preclear_disk.sh -c 2 /dev/sdm == ST4000DM000-1F2168 W300LGJ3 == Disk /dev/sdm has been successfully precleared == with a starting sector of 1 == Ran 2 cycles == == Using :Read block size = 1000448 Bytes == Last Cycle's Pre Read Time : 11:35:45 (95 MB/s) == Last Cycle's Zeroing time : 8:13:31 (135 MB/s) == Last Cycle's Post Read Time : 20:41:48 (53 MB/s) == Last Cycle's Total Time : 28:56:19 == == Total Elapsed Time 69:44:26 == == Disk Start Temperature: 22C == == Current Disk Temperature: 30C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdm /tmp/smart_finish_sdm ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 High_Fly_Writes = 78 82 0 ok 22 Airflow_Temperature_Cel = 70 78 45 near_thresh 30 Temperature_Celsius = 30 22 0 ok 30 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 2. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 2. 0 sectors were pending re-allocation after post-read in cycle 1 of 2. 0 sectors were pending re-allocation after zero of disk in cycle 2 of 2. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 40 sectors had been re-allocated before the start of the preclear. 40 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ============================================================================

hmmm... okay, too bad. I'm 48 hours into the 2 cycles without the pre-read, so that's 2 more wasted days so much for saving time. I guess I'll cancel and start over again. thanks for the info

Okay, that makes sense. I'll preclear it 2 more times, then see what I come up with. Should I do the full preclear, or can/should I use the -W option to save a bit of time? That preclear took about 50 hours. I can live with it taking 100 hours, but if I can cut that down a bit, that might be better.

so, this is my old Parity drive. it started acting up and I've replaced it with a new drive. I was hoping a preclear would 'fix' this drive, but I'm not sure how to interpret these results. Is this drive okay to put back into service in the array as a data drive? ** Changed attributes in files: /tmp/smart_start_sdf /tmp/smart_finish_sdf ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 115 117 6 ok 188984744 Power_On_Hours = 91 92 0 ok 7887 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 Reported_Uncorrect = 89 91 0 ok 11 High_Fly_Writes = 88 92 0 ok 12 Airflow_Temperature_Cel = 69 72 45 near_thresh 31 Temperature_Celsius = 31 28 0 ok 31 No SMART attributes are FAILING_NOW 8 sectors were pending re-allocation before the start of the preclear. 8 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, a change of -8 in the number of sectors pending re-allocation. 40 sectors had been re-allocated before the start of the preclear. 40 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change.

I figured as much, but it's good to get confirmation; thanks.

I just finished a preclear on a new drive. There are a couple of items showing "near threshold". Should I be concerned? ** Changed attributes in files: /tmp/smart_start_sdi /tmp/smart_finish_sdi ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 118 100 6 ok 179537912 Spin_Up_Time = 98 92 0 ok 0 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 High_Fly_Writes = 99 100 0 ok 1 Airflow_Temperature_Cel = 75 74 45 ok 25 Temperature_Celsius = 25 26 0 near_thresh 25 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change.

I noticed lots of empty folders while going thru this process myself. I used this to remove the empty directories; and it seemed to work fine... -type d -exec rmdir {} + 2>/dev/null I also tried this, which also seemed to work fine... find . -type d -empty -delete

thank you for this! it was very helpful to me in finding and merging/deleting my duplicates after a disk problem. It took me quite a while to open the different disks to move the files around, but after 3 or 4 runs of this utility, it says I've got them all now. nice! now I'm running Joe's script to see what I have that ma have different names. Fun stuff

I would start a Preclear but skip the Pre-read (use preclear_disk.sh -W) It took 48 hours to finish... ========================================================================1.15 == invoked as: ./preclear_disk.sh -A -W /dev/sdc == WDCWD20EARS-00MVWB0 WD-WCAZA2130725 == Disk /dev/sdc has been successfully precleared == with a starting sector of 64 == Ran 1 cycle == == Last Cycle's Zeroing time : 28:50:44 (19 MB/s) == Last Cycle's Total Time : 47:41:53 == == Total Elapsed Time 47:41:53 == == Disk Start Temperature: 35C == == Current Disk Temperature: 39C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdc /tmp/smart_finish_sdc ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 189 200 51 ok 21640 Reallocated_Sector_Ct = 142 184 140 near_thresh 1108 Seek_Error_Rate = 100 200 0 ok 0 Temperature_Celsius = 111 115 0 ok 39 Reallocated_Event_Count = 1 1 0 near_thresh 1108 Current_Pending_Sector = 3 1 0 near_thresh 64234 No SMART attributes are FAILING_NOW 65021 sectors were pending re-allocation before the start of the preclear. 64230 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 64234 sectors are pending re-allocation at the end of the preclear, a change of -787 in the number of sectors pending re-allocation. 317 sectors had been re-allocated before the start of the preclear. 1108 sectors are re-allocated at the end of the preclear, a change of 791 in the number of sectors re-allocated. ============================================================================ Looks like I've got myself a paperweight now, no?

I didn't see that until you mentioned it. It doesn't look like he edited his post, so I must be blind. I only found the -n option, which skips pre and post read it seems. Once it finishes, if it still looks like it might work, I'll run it again with the -W option, as one more test. thanks for pointing it out for me.

Thanks, I'll re-run the pre-clear (have to find the skip pre-read option again), and will post back if I have any more questions. No problem about your tone. Sometimes I'm 'the one that broke the camels' back', and I get the brunt of pent up frustration. I didn't take it personal. I do appreciate the help. Thanks again.

Edit: I apologize, I've just noticed elsewhere that you have included a syslog. [respectful chide mode on] It was hard to know how to respond. You have a drive that had been red-balled, and was now running extremely slowly, and yet it does not appear that you thought to check or include a SMART report and the syslog... [chide mode off] I understand your frustration, but since this is a fresh install, only being used to pre-clear, and the pre-clear was/is still running, I don't know of any way to get a syslog at this time. i suppose I could stop the pre-clear, and get a syslog, and considering how slowly it's moving, I don't suppose I really lose much by doing this. Currently, the pre-read is only 2% complete after 4 hours. If that's all the faster this drive is now able to function, it's useless to me, so I could just trash it. I posted in the hopes that the thorough information/history that I included might provide enough clues to be useful. I also mentioned in my follow up post that I may need to learn how to do a smart report, because I don't know how to do that right now. I cancelled the preclear. syslog and short smart test log attached. to my uneducated eye, it doesn't look good... Thanks for your help. syslog.txt smartshort.txt

initial signs are that this was not the problem. it started out at 27.7 MB/s, quickly dropped to 8.6, and now I'm waiting to see the next update. This seems to be the same as the last time I ran it. I wonder if this might do any better if I formatted it in windows, then tried pre-clearing it. I may need to see how to run a smart report on it, so see if it's 'okay' per SMART.

That's a good idea. It can't hurt, right

I'm trying to preclear a drive that had red-balled on my, but I suspect it was just due to a cabling issue. I've since replaced that drive with a larger one, and am now trying to preclear the drive that 'failed' to confirm I can add it back to the array. I've put a stock version of unraid 6beta9 on a newly formatted USB, and put it and the drive into a different computer for this process. I've booted and started the process, and it seems to have started fine, but the onscreen info is showing it to be going VERY slow. Current stats are Disk Pre-Read in progress: 0% complete ( 4,201,881,600 bytes of 2,000,398,934,016 read ) 3.7 MB/s Disk Temperature: 36C, Elapsed Time 1:02:50 by my calculations, it's only .2% done, and will take about 500 hours to finish just the pre-read. Obviously something is wrong (3.7MB/s is not good). So, is this an indication that the drive is just bad after all, or is there possibly something else at play here? Ideas on how to proceed?

it seems setting locale is another important think that needs to be done in dockers, see discussion here... http://lime-technology.com/forum/index.php?topic=34168.msg317791#msg317791 Also, do we need/want versioning for dockers? If needo needs/wants to add/update locale in his dockers, the versions I have installed/running now would benefit from updating, but how would one know that? Perhaps versioning can help with the docker plugin knowing we need updates, and prompt us to do so.

As a general principal, I would suggest to never permanently transcode files to a lower quality based on hardware/software you currently own. They both improve constantly, and someday, you won't need to have a lower quality file to do what you want. However, once transcoded, you can't get the higher quality file back without re-ripping or re-downloading the file. I would suggest instead you try to find a way to transcode on the fly to a device today, and keep the higher quality file for the future. Just my opinion.

Sounds great, I'm looking forward to seeing a working solution.