PeterB

Okay, I think that I've almost got to the bottom of this issue: SYSTIN and CPUTIN names appear to be the result of some internal label changing - the original names being temp1 and temp2. Where SYSTIN and CPUTIN are being set, I don't know, but those names cannot be used in a label statement - you have to go back to the original temp1 and temp2. So, temp1 = SYSTIN and, I guess, is a sensible choice to display as Mobo temp. It appears to match the peripheral temperature reported via IPMI. temp2 = CPUTIN and is, obviously, some instance of CPU temperature. So, my sensors,conf is now: root@Tower:~# cat /etc/sensors.d/sensors.conf # lines starting with "#" are comments and ignored # sensor configuration chip "nct6776-*" label temp1 "MB Temp" label temp2 "CPU Temp" The only thing which puzzles me now is why your high and hyst values for temp2 vary significantly from mine. Different BIOS version, perhaps? Anyway, I'm reasonably happy that this appears to be a sane setting.

I'm having trouble getting temperature sensors working on my X9SCM-iiF mobo. I've been through the wiki: root@Tower:~# sensors acpitz-virtual-0 Adapter: Virtual device temp1: +27.8 C (crit = +106.0 C) temp2: +29.8 C (crit = +106.0 C) coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +46.0 C (high = +85.0 C, crit = +105.0 C) Core 0: +36.0 C (high = +85.0 C, crit = +105.0 C) Core 1: +38.0 C (high = +85.0 C, crit = +105.0 C) Core 2: +43.0 C (high = +85.0 C, crit = +105.0 C) Core 3: +47.0 C (high = +85.0 C, crit = +105.0 C) nct6776-isa-0a30 Adapter: ISA adapter Vcore: +0.68 V (min = +0.60 V, max = +1.49 V) in1: +1.86 V (min = +1.62 V, max = +1.99 V) AVCC: +3.39 V (min = +2.98 V, max = +3.63 V) +3.3V: +3.38 V (min = +2.98 V, max = +3.63 V) in4: +1.52 V (min = +1.35 V, max = +1.65 V) in5: +1.26 V (min = +1.13 V, max = +1.38 V) 3VSB: +3.33 V (min = +2.98 V, max = +3.63 V) Vbat: +3.17 V (min = +2.70 V, max = +3.63 V) fan1: 2606 RPM (min = 300 RPM) fan2: 1421 RPM (min = 300 RPM) fan3: 0 RPM (min = 300 RPM) ALARM fan4: 0 RPM (min = 300 RPM) ALARM fan5: 1336 RPM (min = 300 RPM) SYSTIN: +42.0 C (high = +75.0 C, hyst = +70.0 C) sensor = thermistor CPUTIN: +37.5 C (high = +95.0 C, hyst = +92.0 C) sensor = thermistor AUXTIN: +2.0 C sensor = thermistor PECI Agent 0: +0.0 C CPUTIN: +37.5 C (high = +80.0 C, hyst = +75.0 C) cpu0_vid: +0.000 V intrusion0: OK intrusion1: ALARM root@Tower:~# From this I identify SYSTIN and CPUTIN on the nct6776 as the labels for the values I want to display, so I create my sensors.conf thus: root@Tower:~# cat /boot/config/sensors.conf # lines starting with "#" are comments and ignored # sensor configuration chip "nct6776-isa-0a30" label SYSTIN "MB Temp" label CPUTIN "CPU Temp" root@Tower:~# Now, the driver is identified as: #----cut here---- # Chip drivers modprobe coretemp modprobe nct6775 /usr/bin/sensors -s #----cut here---- so I set up my go file thus: root@Tower:~# cat /boot/config/go #!/bin/bash # # Turn on the variable clock speed (power save) feature modprobe acpi-cpufreq # modprobe for each sensor modprobe coretemp modprobe nct6775 /usr/bin/sensors -s # Enable alternate AHCI controllers /boot/config/enable_ahci.sh #Mount docker device mkdir -p /mnt/docker mount /dev/disk/by-id/ata-ST3500418AS_5VME2D7A-part1 /mnt/docker # # Start the Management Utility /usr/local/sbin/emhttp & root@Tower:~# However, even after a reboot and reinstalling the plugin, I still se the temperatures displayed as '##' I do note the following in my syslog: Dec 3 22:00:06 Tower kernel: w83627ehf: Found NCT6776F chip at 0xa30 , and further down I see: Dec 3 22:00:08 Tower logger: Starting go script Dec 3 22:00:08 Tower kernel: nct6775: Found NCT6776D/F or compatible chip at 0x2e:0xa30 Dec 3 22:00:08 Tower kernel: nct6775: probe of nct6775.2608 failed with error -16 So, I have some doubts in my mind ... it seems that the nct6776 chip is recognised by a w83627ehf driver and loading the nct6775 driver produces an error -16.

What is the significance of installing in /boot/plugins? Does it affect the way that the plugin operates?

What do we do when, not if, there is a bug in the updated plug-in and we need to roll-back to a working version? This was my immediate thought when I read the suggestion. If, for some unseen circumstances, the updated plugin 'breaks' someone's system, they need a way to, quickly and easily, revert to the last known good working version.

So we need to turn cache_dirs into a (semi-)plugin, starting it on one of the emhttp events?

I am experiencing exactly the same. What appears in the ps -eaf list is : root 2679 1003 0 09:57 ? 00:00:00 /bin/bash /var/tmp/go root 2680 2679 0 09:57 ? 00:00:00 /usr/local/sbin/emhttp root 2681 2679 97 09:57 ? 01:17:28 /bin/bash -c /boot/packages/cache_dirs Note that there are no command parameters appended to the cache_dirs command, and the go process doesn't terminate. EDIT: I note that the go script is not run directly from the /boot drive, but from a copy in /var/tmp I'm not quite sure why, but the plain /boot/packages/cache_dirs -w -B -m 15 -M 30 -d 6 -i "Movies" -i "Music" -i "Series" -i "Videos" -i "xbmc" -i "Torrents" -i "ReadyTorrents" -i "Downloaded" -i "Photos" -i "Maildir" command is actually invoked as: /bin/bash -c /boot/packages/cache_dirs The -c option on the /bin/bash command says 'read commands from the following string (variable)'. The problem is that '/boot/packages/cache_dirs' isn't a string variable, so I'm not sure why the -c is getting added to the command line. Some experimentation is required - perhaps we can work around this in some way ... by including the /bin/bash in the line in the go script, or setting up the command in a variable. This needs to wait for a reboot ...

I was ... on V4 and V5 Now I'm on V6, I haven't spent time to get it working, but user shares are now taking a very long time on first access. So, shfs may be a memory-resident file system, but memory caching definitely makes a great difference .... oh, and I use nfs exclusively.

Don't hold your breath waiting for a ready-made package to do everything you want out of the box. It's relatively easy to use the ArchVM image produced by Ironicbadger, and add all the applications you could want. Pacman is very easy to use, and much simpler than having to create plugins for unRAID. I currently have LogitechMediaServer, minidlna, MySQL (MariaDB) and deluge running. I did build 64-bit unRAID plugins for mpop and Dovecot, to keep my email going, but I will soon move those over to VM. The only problem I currently have is getting minidlna and CouchPotato to co-exist on the same machine - if I cannot resolve that, I will simply create a separate VM.

Actually, I believe that Cache_Dirs still has a benefit for these users in that it pre-caches rather than waiting for your first access. My Movies collection is still small compared to many here. However, split across three drives, there is a delay of about 20 seconds on first access. For those who can keep their system up for months on end, this is a non-issue. However, if you experience multiple power outages a day, it is a significant aggravation.

In your two photos, the stock fan is blowing the air towards us, the replacement fan is blowing the air away from us.

I've been using trayless for more than two years without problem. I'm puzzled by the report of damaged drives because of inadvertent contact - not enough detail of how the contact occurred and I don't see how contact could damage the drives anyway (unless you were to drop one, from six feet, onto the other!).

This is the model I'm using in my HTPCs. It works perfectly well and is a standard ATX form factor, so should be a direct bolt-in for your case.

Yes - whereas the connector can be damaged by a short term high current (causing arcing), a wire is damaged by heat. A short term high current will not raise the temperature of the wire significantly. The ratings for a wire are given for a steady continuous current.

My Seasonic X650 came with eight molex connectors and it is possible to obtain additional wiring harnesses for modular PSUs.

Those are the iStarUSA units.

This is only sensible if using all green drives. The maximum current specification for a molex pin is 11A (for a new connector). As the components age, the electrical resistance (power loss and heat generation) will increase - a potential source of problems. Using a power splitter cable will only move the weak point in the system. Five non-green drives can exceed the 11A specification. Which drives would cause a continuous power consumption of 26,4W/drive (11*12/5)? For instance WD 3TB Greens are maxing out on spin up to 10,24W and 4,96W under constant load (source). I assume that short time spin up loading would not cause any problems even with an ageing connector. I'm definitely not an expert on this subject so these were real questions Yes, as I said, using a single power connector is probably safe if you only use 'green' drives. If you look at the specification for 'black', 15,000 rpm drives, you will see that spinup currents can exceed 2A. I would say that instantaneous high currents can can cause damage at the contacts and, over time, can result in unreliable operation. I have experience of molex connectors on single drives (some time ago, when drives were more power hungry) where the contacts go bad and the nylon housing melts. However, my original post was merely to point out that multiple power connectors are designed into drive cages for safety reasons on a technical basis, not simply to provide redundancy.

This is only sensible if using all green drives. The maximum current specification for a molex pin is 11A (for a new connector). As the components age, the electrical resistance (power loss and heat generation) will increase - a potential source of problems. Using a power splitter cable will only move the weak point in the system. Five non-green drives can exceed the 11A specification. The multiple power connectors are there for a reason, and it's not simply to do with redundancy. I run two separate power connectors from my single psu to each drive cage for my own peace of mind, even using all green drives.

I knew that there had to be a good reason. I'm not familiar with the DE version, but my original BPN-350 units work much better with the fans removed!

Errr... aren't those drive cages upside down?

Proximity to audio gear probably indicates that it's not loud!

I would suggest the Seasonic Platinum 1000 - not the cheapest but, arguably, the best!

Boston, Scan, Amazon (I'm sure there are others) all claim to have stock.

There seem to be a number of posts suggesting that the UEFI flasher has to be used on Supermicro X9SCM motherboards in order to flash the LSI controllers. I have just successfully updated my SAS2008 controller, installed in my X9SCM-iiF motherboard, using the Linux flasher under unRAID/Slackware, exactly as I posted up near the beginning of this thread. My motherboard, obviously, came with a V2 BIOS - however, I believe that the Linux flasher would work equally well with a V1 BIOS

If I remember correctly, that is because unMENU adds a -d ATA parameter to the smartctl command. The driver for the motherboard interface doesn't care if it's asked to behave as an ATA (parallel) drive, but the LSI driver objects. If the -d ATA parameter is removed from the command line, the driver for both interfaces will respond as required. Try typing this command at the command prompt: smartctl -a -d ata /dev/sdX (where X is the last letter of your drive identifier - a, b, c etc) You will find that you get a SMART report for drives on the motherboard interface, but you will get an error for drives on the M1015 interface.

Well, when you've installed unRAID on your system, we may be able to help you!