JustinChase

I followed these steps also, and got these drivers... coretemp nct6775 I already had coretemp working, but wanted to see if nct6775 would give me fan speed info, so I put that in the available drivers box, hit detect, then hit load drivers, and now I have more stuff available in my dropdown boxes; see attached. I don't really know which one goes with which, but it feels like progress.

Ah, yes, that did it. Attached is the dropdown after 'resetting'... I'm assuming the top one is the MB, and will just pick one of the cores as the CPU temp. One of these days, I'll try to figure out which driver will give me fan speeds also. thanks again!

This. There is nothing in the dropdown. There is nothing in the fanspeed status bar (as expected). None of this is a big deal to me, I'm just reporting my findings, to hopefully help with development.

I also only get coretemp. How would I know what driver I should have for my motherboard?

I didn't even notice the detect button changed to save. i tried hitting apply and load, but they obviously didn't work. hitting save did work I have 4 cores, all showing in the list, and something else at the top of the list. I can't remember what it said, since after saving it to the processor temp, it changed what it had showed before. Anyway, I'm not sure which one is my MB and which one is my CPU (or why the 4 cores seem to vary by as much as 3 degrees.) I also don't have any fan speed info, even though the motherboard does provide the info. Not a big deal, just providing feedback. Thanks again.

I just updated, and now I don't have any temps, and none of the dropdowns allow me to select them. I can find the driver okay, but now can't select anything.

it's probably getting stopped when your disk spins down. Try extending the spindown time a bit longer, and try again. *Don't forget to change it back once finished. This post made me remember to change mine back from 5 hours, which was long enough for the extended test on my system.

I see the fan indicator now, but it's showing ## instead of a reading. I had to install/update the driver for my temps a couple months ago, when this was first released, and I don't remember the details of how I did this. Do I need to undo what I did back then, since the plugin is now supposed to take care of this for me? If so how? Also, how do I get it to find/report the rpm info now? thanks again for all you do for us

Very likely, but it can/should be resolved apart from the preclearing. If you want to find/resolve that problem first, that would be fine also. i was just trying to help provide a way to do the preclearing

That tells me the windows machine can/will see your raw drive; perfect. Now, put the USB with stock unRAID into that machine, reboot the computer, and hit F8 (or DEL, or ESC or F12 or whatever that BIOS requires to get to the boot options). Once you see your boot options, select the USB stick, and it will boot into unRAID. Then preclear the drive. once finished, do a clean shutdown from unRAID, remove the drive and the USB stick, and when you turn that machine back on, it will book back into windows, as if you'd never done anything with it. Put the newly precleared drive back into your real server, and unRAID will recognize it's already precleared. if the unRAID server doesn't recognize the drive, that's an entirely different problem, but at least you'll know the drive is ready to add, once the server recognizes it.

I would probably put it in a computer that can directly access it (not virtualized), then boot stock unRAID from a thumb drive, and preclear it/them on that system. Once finished, put them into the server, and it will see they are already precleared, and you should be good.

To be clear, I'm not suggesting we should have/offer dockers that run the 'bleeding edge'. I'm referring to offering the current, stable version. Occasionally most/all programs go from one stable version to another, and until the docker creator updates their docker to the new, stable version, the program will continue to run the older version. The issue is the same whether or not we're talking about the bleeding edge, or moving stable version; at some point in time a user wants to use a newer version than they have currently, and are then at the mercy of someone else to provide that for them. I only brought this up as something to consider when discussing a 'standard' system for unRAID dockers. It seems this is a consideration that needs to be incorporated into any new base system.

The only 'problem' with this is that the user is (still) reliant on the docker creator to update the docker, and some people don't have the patience to wait for this to happen. Also, as we've seen with plugins, authors come and go, as life happens, so one day an author is likely going to disappear, and their docker won't get updated unless/until someone else jumps on it. It's a difficult thing to manage, for sure. Also - there is nothing that forces us to avoid "abusing the docker purpose" if our purpose is different. Docker is just a tool. Using that tool in a manner that is different to it's intended use does not invalidate the effectiveness of the tool. Using a free wooden paint stirrer as a shim is still a totally valid use of that tool.

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.