Leaderboard

When I click the search box a drop-down defaulting to "All Content" appears to the left of the text field. Changing it to "This Topic" limits the search to ... this topic! The new desk build search is a bit weird. Seems like it gets converted to new+desk+build. Replace that text on the search page with new desk build and your unRAID Desk Build will be in the search results... Edit: More specifically, if I enter new desk build in the small top right search box, I get sent to: https://forums.lime-technology.com/search/?type=all&q=new+desk+build Entering new desk build in the big search box on that page sends me to: https://forums.lime-technology.com/search/?&q=new%20desk%20build I would expect different search boxes to behave the same way, so absolutely a bug.

Should be, but the balance shouldn't take that long.

I wouldn't worry about buying older hardware, especially if its enterprise quality. For example, I just got a great deal on a Dell R710, the machine was shipped in 2010 and went out of warranty in 2014, so its a sevenish year old server. I have no doubt I will be able to run it for the next five to six years without issue. These machines were built to last, and sure you may have to replace a few fans here and there, a power supply if it fails etc, but otherwise the stuff is solid. If you are wanting newer technology that consumes less power, puts out less heat and runs quieter, then that's another story, and you will pay a premium for it but there are some good deals to be had out there for dual quad/hex core servers with plenty of bays. Your rack depth issue is unique and it will limit what you can buy, but beyond that, don't be afraid of older tech, it works and lasts.

Yes, you need to use the console.

With the array stopped wipe out the Kingston: blkdiscard /dev/sdX Replace X with the correct letter. Re-add the Kingston to the pool, start array, balance will begin, don't stop array until it finishes, i.e., when there's no cache pool read/write activity.

Something went wrong with the pool, it's reporting a negative number on devices missing, don't think I ever saw that before: Mar 29 13:52:09 Tower emhttp: cacheNumDevices: 2 Mar 29 13:52:09 Tower emhttp: cacheTotDevices: 1 Mar 29 13:52:09 Tower emhttp: cacheNumMissing: -1 You can try disconnecting one of the SSDs at the time (it needs to be physically disconnect from the server) and see if it mounts with the other one alone, if not use these steps to try and recover your data:

Went to Micro Center and looked at their returned Items shelf and it was loaded with Corsair Power supplies and TP Link products, Did my homework on various power supplies and decided that the EVGA SuperNOVA 650 Watt P2 ATX 12V Power Supply fit my need perfectly. (plus it was on sale at the time for $89.00 USD) If it was not for the sale I probably would have picked up the Seasonic USA Platinum 660 Watts ATX Modular Power Supply, I am a very firm believer in that, high quality power supplies will prolong equipment life. I went low cost in a lot of my build but refused to do that with the power supply.

I left bonding all together and went 10gbe.... plug and play ftw.

I run IPv6 on mine with fixed addresses. Currently I use a kernel recompiled to include IPv6, then added '--ipv6 --fixed-cidr-v6='2a02:xxxx:xxxx:xxxx::/64' into the DOCKER_OPTS in /boot/config/docker.cfg I'm just an end-user, so I'm not sure how much integration they'll do to start off with adding this feature, but this may help when it comes. If you've not got IPv6 yet on the network, then you can probably get by with just adding '--ipv6' and it will assign link-local addresses to containers.

Do pretty much that, what is written in the notes you quoted: Please remove the full quote of that post and insert a link instead. Thanks!

Glad to help, I was happy to find one that already exists and worked out of the box!

Who knows when it might fall.

There's a couple of differences between the 6.1.9 and 6.3.2 lspci reports. 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) Subsystem: ASUSTeK Computer Inc. Device [1043:8436] Kernel driver in use: vfio-pci For the Azalia audio, 6.1.9 has the vfio-pci driver assigned, 6.3.2 does not, has nothing. I don't have VM experience yet, but I assume that's for audio passthrough, probably not working in your 6.3.2 VM. When you move to 6.3, you may need to rework your VM's. For 6.1.9: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (external gfx0 port B) [1002:5a14] (rev 02) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (external gfx0 port B) [1002:5a14] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD/ATI] RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (PCI express gpp port B) [1002:5a16] Kernel driver in use: pcieport 00:0a.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (external gfx1 port A) [1002:5a1d] For 6.3.2: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge [1002:5a14] (rev 02) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD890 PCI to PCI bridge (external gfx0 port B) [1002:5a14] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0) [1002:5a16] Kernel driver in use: pcieport 00:0a.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 5) [1002:5a1d] These changes may not look significant at first, but they represent changes in the main AMD motherboard support. In 6.1.9, the RD890 modules were for the RD800 series AMD chipsets. In 6.3.2, the same modules appear to have been enhanced to also provide support for the RD900 series, and renamed to be RD9X0. If they were modified to cover more chipsets, then there is a possibility that mistakes were made, and compatibility for your board was harmed. All you can do is check you have the latest BIOS for your board, and wait for a newer kernel with fixed support, *if* this is the cause of the problem (and it may not be). I would guess there are thousands of other users with your board, or similar enough, and complaining too (if this is the problem). What's odd is that you have a 990FX chipset, so you would think the RD9X0 would be better, but the RD890 did support the 990. One other difference, in 6.3.2 you used an MTU of 9000, in 6.1.9 you used an MTU of 1500. That could conceivably cause communication difficulties if not everything in the network path supports 9000.

Very cool! A lot of people will really benefit from this!! But, thought I would explain some potential usage pitfalls. This feature does not just take advantage of time other drives happen to be spun up, by its very nature time drives are spinning up will elongated, and in some cases, drives will be prevented from spinning down. Basically the spindown timer countdown on all drives will be reset after any write to the array. And until the array is quiet (no writes) long enough for drives to spindown, turbo write is going to stay on. If you spin up your array - within 5 minutes (with default settings above) turbo write mode will be enabled. You would not know how long you have to wait until turbo kicked in (1 second to 5 minutes). If a transfer were in progress and you said - hey, it'd be nice if turbo were on, you could spin up the array and in a few minutes it would engage. If you want instant, though, this would not give you instant. A shorter interval would help, but there may be negative implications to checking it very frequently. And if you manually spin down at least one disk (assuming disks allowed to be spun down is 0), turbo write mode is disabled within that same time interval. This would not be foolproof. If you spin down some disk(s), and then before the interval, a new array write occurs, the disk(s) would spin up again (since turbo write is still enabled) and the write is performed, and turbo write would not be turned off. As mentioned, having a docker image on an array disk would all but guarantee your array would never get out of turbo-write mode with this plug in, even if you are manually spinning down disks. You would not want to create a situation where your disks spinning up and down frequently for no useful purpose. After a parity check, fresh boot, or if there are frequent writes to the array, array drives may never spin down unless there is manual intervention. Using the feature to force turbo write off (probably late evening and after mover runs) would help. But using this plugin will result in more drives spinning more of the time (not just during faster writes). Those running power efficient arrays might find their electric bill inching north. A person might think a shorter spindown interval might be in order so that turbo write would get disabled "naturally" more of the time. Problem is, shorter spindown intervals will result in drives going through multiple thermal cycles (through your normal usage pattern), which has been identified as a bad thing (maybe the worst thing) for drive health. I have my spindown interval set to 5 hours which largely prevents multiple spinups per day. Balancing settings to allow drives to spin down to shut off turbo write vs setting to reduce frequent spinup/spindown cycles would be tricky. Since my experience is that normal writes are fast enough most of the time, and I'd prefer drives to stay spin down most of the time, I'd prefer to just have an icon on my desktop that turns turbo on for a time interval. That way, if I am waiting for a write to finish, I can quickly turn on turbo write and it will turn off automatically. User scripts with remote SSH execution could be used to set this up. But that is me - I think this plugin would be useful for many unRAID users, and hoping the info above might help get it configured optimally.

I checked this out yesterday. The template is actually set for container port of 9022. And take make matters worse, because of how the template is created, you cannot simply change the container port. You actually have to delete the port mapping and create another one.

You started 6.3.2 in safe mode which means that none of the plugins were installed. Unfortunately, there is a bug with the plugin system in safe mode where it will still parse the .cron files on the flash drive and add the entries to the cron lists. Since the plugin wasn't installed, the executable doesn't exist. Annoying, but nothing to worry about. (You do have the system stats plugin, so this error is to be expected in safe mode)

I haven't been following this, but there is this in your syslog which suggests you may still have some things installing that you shouldn't: Mar 26 17:53:59 BlackBoX logger: Installing /boot/extra packages Mar 26 17:53:59 BlackBoX logger: Installing system plugins [deprecated] Unfortunately, this old version of unRAID doesn't have as much in the diagnostics, in particular the system/folder.txt file, so I can't see if you actually have anything installing from these. Do you have the folders "extra" and "plugins" in the root of your flash drive? If so, do they have any files in them?

I took a look and like eschultz, did not find any real issues, system looks like it's working fine. The earlier diagnostics showed a small network issue, but it's not in the latest, and it wouldn't have caused your issues anyway. The syslog does end with the following, don't know what that's about. Mar 26 17:38:01 BlackBoX crond[1609]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null The system looks far better after your cleanup, don't know how you operated at all with so many really old 2012 and 2013 packages installed! For example, the earlier diagnostics showed that python 2.7.5 was installed, then later uninstalled completely, then 2.7.10 was installed, and used to compile and set up denyhosts, then 2.7.10 was completely uninstalled, and python 2.7.13 was installed! And you removed some old stuff from your go file. I would also remove the hosts and nameserver lines, don't think they are needed any more, and the hosts line was wrong, an IP with no host. I would also consider removing UnMenu, can't see what it's loading from /boot/packages, but have to assume it's very old! Probably unnecessary at best, may be causing conflicts. If you'd like to submit a 6.1.9 diagnostics, from a working system, we can compare and see if any differences appear that may be relevant.

A little teaser...

I quickly checked over your logs and nothing jumped out leading to the issues you're experiencing. You have a TON of plugins installed so I'd recommend booting with 'Safe Mode' next time you try a newer version of unRAID to see if one of those plugins might be the culprit.

Did you read and follow the first couple of posts in this thread?

Should anybody still need the ISO recommended in this old post (I would not recommend buying DELL SaS 6/ir cards in this day and age since they the hardware only supports 2TB drives max) but if you have them, why not use them with proper firmware. It seems the link is down, so it's now available in a 7zipfile here: https://mega.nz/#!UgAXBTRQ!_GH26z-lOIJWB0ol24ryAJ8pXUjrWhd5VE7iB_Q7LL8 And is also linked in this post. I contains firmware for LSI 1068E 3080/3081/3800/3801/3442/3041/3444/31601 for IR and IT mode. It also has the Dell SAS6/iR firmware for this card should you want to flash it back to a Dell card. Name: sas6iflashcd.7z Size: 1599173 bytes (1 MB) CRC64: 1E5447B82A6AE64D SHA256: 4D4BBE0ADF3FCE685D7F7F9F43160EDE0AC970AC38BFBF3C07650ADF184BF435 SHA1: 987EBD913E1CC7886429BCE01B7AD04EDA63BD1E Name: sas6iflashcd.iso Size: 15316992 bytes (14 MB) CRC64: A88C23086536667D SHA256: 31B23B2B2B3716BB1B261687CF376E619AEE491442D9E76AE2188482379E7E29 SHA1: EDA221F4DC933711222EA415FD72D7CA546CB7B8 sas6iflashcd.7z

I got my hands on an LGA775 board. The 1015 still gives me No MR Controllers found. the 5014 on the other hand, I was able to find it, and go a clean flash on it. Will post back the result. Edit: Yes, the 5014 is flashable; https://www.servethehome.com/flash-ibm-serveraid-m5014-lsi-92608i-firmware/

I was afraid you would say something like that... When you've got time I'm still looking for an answer to my original question. Yeah, I just got home from work. This will work with nginx. location /deluge { proxy_pass http://192.168.0.1:8112/; proxy_set_header X-Deluge-Base "/deluge/"; include /config/nginx/proxy.conf; } Obviously change 192.168.0.1 to your Unraid IP

It's not related to bridge mode. The AP doesn't know where the controller is unless you have your DHCP server specifically set up to issue the controller address as an option in the lease. Normally you would use the UniFi discovery tool to find the AP and tell it the IP of the controller, but the UniFi dockers don't have the discovery tool as it is a separate app. To get the AP to show up in the controller so it can be adopted and provisioned, do the following: Determine the IP the AP was leased SSH to that IP Login as ubnt / ubnt mca-cli set-inform http://address:port/inform (where address is IP of controller and port is the port you are using for inform, default is 8080) Once you run the set inform command it should show in the controller. As soon as you click adopt you need to run the set inform command a second time on the AP. EDIT: Syntax correction