eshelon

It's my primary card so I was going to see if stubbing it helped, but I can't get the device details even if I do lspci -nn as this is what I see: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779] 01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6450 / 7450/8450/8490 OEM / R5 230/235/235 X OEM] [1002:a... If you double click on the device in device manager, does it provide more info on the error? Also, can you try rebooting the host and on first boot of the VM guest see if this issue persists? I'm curious if the issue only comes up after you reboot the VM.

thats cos itimpi is prob running it the pro way , as in via command line script and NOT via plugin, unless you can be 100% sure that plugin is ver 6.x webui compatible then i would stick with running it via go script, that's what im going to do in any case. Yes - I am running cache_dirs via my go script. Gotcha. I'm sure this will be fixed soon. I can't imagine this is all that difficult of an issue. Probably just a bit of hunting that will need to occur to find it. The one thing I will caution others with is that installing cache_dirs using my method will work from an install standpoint, but as soon as you turn the service on, even with the ulimit line commented out from the plg, it will crash the webGUI and the only solution is a reboot. Just an FYI. It appears that Dynamix is currently having problems with beta 4 so I have also removed that and reverted to the standard GUI.

Tried both and they appear OK. Looking at my version of cache-dirs. I have the line # ulimit -v 5000 to comment out the ulimit command. I cannot remember where I saw that suggestion. Ok, i did this as well in the .plg and when running "installplg" I get the following: root@newtower:/boot/plugins# installplg /boot/plugins cache_dirs-1.6.7-4jr.plg plugin: installing: /boot/plugins Warning: simplexml_load_file(): /boot/plugins:1: parser error : Document is empty in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): ^ in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): /boot/plugins:1: parser error : Start tag expected, '<' not found in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): ^ in /usr/local/emhttp/plugins/plgMan/plugin on line 126 plugin: warning: no name attribute, installing anyway Warning: simplexml_load_file(): /boot/plugins:1: parser error : Document is empty in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): ^ in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): /boot/plugins:1: parser error : Start tag expected, '<' not found in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): in /usr/local/emhttp/plugins/plgMan/plugin on line 126 Warning: simplexml_load_file(): ^ in /usr/local/emhttp/plugins/plgMan/plugin on line 126 plugin: xml parse error root@newtower:/boot/plugins# I'm assuming that this is PHP / XML parsing issues that we've seen/discussed, but it's odd that you're not having the same issue... UPDATE: Install worked correctly... Here's what I did. After modifying the .plg, I first attempted to install by running the installplg command. However, after that failed to work, I used the extension page in the webGUI and manually entered the path to the modified .plg I had stored in /boot/plugins folder and voila, cache dirs installed successfully. Next step is to test to see if it runs correctly. Just turned it on and CPU is spiking again...

Tried both and they appear OK. Looking at my version of cache-dirs. I have the line # ulimit -v 5000 to comment out the ulimit command. I cannot remember where I saw that suggestion. You may have just solved our little problem. I will test here shortly. Sent from my Nexus 5 using Tapatalk

It seems to be working fine for me under v6 beta 3 and beta 4 Booting into Xen mode or non Xen mode? Sent from my Nexus 5 using Tapatalk

There is no 64bit conversion necessary for cache_dirs - it doesn't include any binaries and is, therefore, named as 'noarch'. However, there is, clearly, some incompatibility with unRAID 6 which I've not yet got to the bottom of. dlandon is pointing a finger at $_GET and $_POST, but making a simple change in this area doesn't fix the problem. More investigation needed! I hope that Tom has updated all of the drivers included in the distribution - I'm not adding any drivers. Oh, and I've worked around two of my problems, with minidlna and LogitechMediaServer, by installing those in an ArchLinux VM. I probably spoke to soon on the 64bit comment for cache dirs, but thought that maybe it needed some other slackware dependencies maybe and that those may have not yet been updated to point to their 64 bit equivalents. Either way I've had no success with getting cache dirs to work yet on 6.0 beta 3 or 4. The search for a fix continues. On the drivers, I'm not really sure what Tom has ported from 5 to 6 so I would ask. Sent from my Nexus 5 using Tapatalk Cache dirs is a Bash script and shouldn't have any 64 bit dependencies. I've been able to run it from a command line in a telnet session or at the console, but not from the go script or a plugin. There is one thing that needs to be removed from the cache_dirs script, but I can't remember what it is. Something to do with limiting memory use. All I know for sure is how much I miss cache dirs. Your forget how something so simple can have such a dramatic impact on usability and performance. I'll probably mess around with this more today... Sent from my Nexus 5 using Tapatalk

There is no 64bit conversion necessary for cache_dirs - it doesn't include any binaries and is, therefore, named as 'noarch'. However, there is, clearly, some incompatibility with unRAID 6 which I've not yet got to the bottom of. dlandon is pointing a finger at $_GET and $_POST, but making a simple change in this area doesn't fix the problem. More investigation needed! I hope that Tom has updated all of the drivers included in the distribution - I'm not adding any drivers. Oh, and I've worked around two of my problems, with minidlna and LogitechMediaServer, by installing those in an ArchLinux VM. I probably spoke to soon on the 64bit comment for cache dirs, but thought that maybe it needed some other slackware dependencies maybe and that those may have not yet been updated to point to their 64 bit equivalents. Either way I've had no success with getting cache dirs to work yet on 6.0 beta 3 or 4. The search for a fix continues. On the drivers, I'm not really sure what Tom has ported from 5 to 6 so I would ask. Sent from my Nexus 5 using Tapatalk

Any chance this will get fully supported for unraid 6.0-beta4?

You need to check the plugins you installed cache dirs and many others have not yet been converted to 64 bit and can have a negative impact to your system. Overbyrn has a set of 64 bit ones out already but unless specifically indicated as supporting 64 bit unRAID, plugins from unRAID 5 will not work on unraid 6. This also likely holds true for your drivers for your hardware. Need to be updated to 64 bit. Sent from my Nexus 7 using Tapatalk

that did it! Thanks for pointing the obvious I missed =) No problem. Glad it was a quick/easy fix. Odd, so it started, I started up a VM, noticed my passthrough settings were wrong. I destroy the VM, my screen goes blank, and then it drops off the network. On a reboot, it's again hanging on QEMU starting.... I'm perplexed. Any chance you can share your logs?

+1 Feature Request - The option for Automatically Created (the way it works now) or Manually Created Only user shares Would rather not have to start directory names with a "." to have unRaid ignore them. Why not put those directories on a disk that is excluded from user shares? I keep the contents of each disk categorized by function. Its not a big deal either way, but the sysadmin in me would like to have the choice. Out of curiousity, if you go into the webGUI and go under shares and select the directories you don't want "shared", what happens if you turn SMB/NFS to "No"? Do you just not want to see it in the webGUI? Just trying to understand...

Just in case anyone is curious, this is very helpful for those using a media server such as Plex in IronicBadgers ArchVM appliance. Thanks to the update in beta 4 where Tom patched the NFS security exports, a more simplistic method of accessing media served by Dom0 user shares from within the arch VM itself. For example, I have Plex Media Server running on IronicBadger's Arch VM Appliance (v4 image base). My ArchVM is a DomU. My Dom0 host serves /mnt/user/Media as an NFS share (configurable under the webGUI under user shares; public setting). Thanks to AutoFS running in the Arch VM, all NFS shares that are available on the network are automatically mapped/mounted to the /net folder on the Arch VM. So from within Plex Media Server (connecting via the webGUI) you can add media and just browse back to the root of the VM, then net, and voila, your NFS exports are there!! Happy media serving ;D

Badger and everyone else, My friends and I have been watching this thread closely since first posted and I recently made an investment into some new hardware and would like to test out this setup with 64-bit unraid. A little background... I've been in the tech industry for about 15 years and the last 10 have been working for virtualization solutions providers (think Citrix, VMWare, Microsoft, NetApp, EMC, etc). My friends are both also in tech (one's a web developer and the other a PC hardware engineer). The three of us are blocking out 2 full days of time towards this project (not just 8-5 ;-) starting on Thursday, January 30th. We'll be trying to wrap up by Saturday, February 1st. Our goal is to try and get 64-bit unraid running as described in this article. Here's the hardware we're using for this project: Intel Core i7-4770 Haswell 3.5GHz LGA 1150 84W ASRock Fatal1ty Z87 Professional LGA 1150 Intel Z8 2 x 4GB DDR3 1600MHz Corsair RAM 750Watt Power Supply 2 x Seagate Desktop HDD.15 ST4000DM000 4TB 64MB Cache - OEM Where we lack the expertise between the 3 of us is the initial setup. We're familiar with unRAID as we all have been using it along with several plugins (OpenVPN [thanks peter], BT Sync, Crashplan, and then the other usual suspects). Getting Arch/64-bit/unraid/xen/kvm/etc all configed, that's where we're a little hazy. We have access to Xen engineers and even some decent storage engineers through my job, but to be fair, they probably aren't going to be very helpful with anything outside of XenServer for what we're trying to accomplish. We will document our testing and share results with all. No reason not to. If we can get XenServer 6.2 installed and working as also described, further tests will include a lab with additional virtualization technologies (think virtual desktops/applications, etc). This will require a memory upgrade and I'm committed to 32-64GB of RAM for this. We also plan to implement a cache drive (SSD) for additional performance. There are many additional potential labs and use cases as well. Beyond this particular "server" that we will be building, we have a number of various client devices to test with for various purposes including, but not limited to: 2 x Ouya Consoles (Rooted w/ XBMC, SPMC, Plex, etc.) 2 x Apple TV 2's (Jailbroken w/ XBMC today) 1 x LG TV with Plex Native Streaming Capability (no set box needed for media server usage, it's built into the TV) 1 x iPad 3 1 x iPad Mini (last generation) 1 x Dell Venue Pro 8 Tablet 2 x Nexus 5 Smartphones 1 x Kindle Fire HD Tablet 1 x Desktop PC (Gigabyte Geforce 780 GPU) 1 x Additional unRAID server (running 5.0.4...considered the "production" system) This isn't a list of shared equipment or stuff on loan from others. This is all in hand right now. We're ready to start building and testing like crazy! The reason for the limited window of time is how difficult it is for the 3 of us to all get our schedules aligned where we can all take time off simultaneously. This was a rare window of opportunity for us and we were hoping to use it to build some servers, play some games, and have some fun. If any of you guys/gals are going to be around/available, I'd love to exchange IM information with yah ahead of time if you'd like to lend your support! We have no expectation other than to give it our best and see what we can do and share with others. Sorry for the long post...just really excited to try and get this working. Thanks!!