unRAID Server Release 6.0-beta4-x86_64 Available


Recommended Posts

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.

 

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!

 

This also likely holds true for your drivers for your hardware. Need to be updated to 64 bit.

 

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.

Link to comment
  • Replies 263
  • Created
  • Last Reply

Top Posters In This Topic

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.

It seems to be working fine for me under v6 beta 3 and beta 4

Link to comment

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.

 

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!

 

This also likely holds true for your drivers for your hardware. Need to be updated to 64 bit.

 

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

 

 

Link to comment

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.

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

 

 

Link to comment

Booting into Xen mode or non Xen mode?

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

 

 

Link to comment

Booting into Xen mode or non Xen mode?

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.

 

probably from here:-

http://lime-technology.com/forum/index.php?topic=4500.msg285576#msg285576

 

not exactly sure what the fallout might be from doing this though, possibly higher risk of OOM?, im guessing Joe L would be able to answer that

Link to comment

Booting into Xen mode or non Xen mode?

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.

I think that on a 64-bit system the memory constraints are very different.  As such systems can use more than 4GB effectively the chance of OOM should be mich lower. 

 

probably from here:-

http://lime-technology.com/forum/index.php?topic=4500.msg285576#msg285576

 

not exactly sure what the fallout might be from doing this though, possibly higher risk of OOM?, im guessing Joe L would be able to answer that

Link to comment

Booting into Xen mode or non Xen mode?

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...

Link to comment

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...

 

thats cos itimpi is prob running it the pro way ;D, 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.

Link to comment

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...

 

thats cos itimpi is prob running it the pro way ;D, 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. 

 

It appears that Dynamix is currently having problems with beta 4 so I have also removed that and reverted to the standard GUI.

Link to comment

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...

 

thats cos itimpi is prob running it the pro way ;D, 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.

Link to comment

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...

 

thats cos itimpi is prob running it the pro way ;D, 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.

 

After installing the plg unRaid needs to be restarted right?  It's been a while =)

Yes - I am running cache_dirs via my go script. 

 

It appears that Dynamix is currently having problems with beta 4 so I have also removed that and reverted to the standard GUI.

Link to comment

I'm experiencing a problem with the emhttp interface.  I am using the standard 'one line' go file.  I've not got any plugins installing.  I'm running plain unRAID - no Xen.

 

I'm seeing this:

Warning: syntax error, unexpected $end, expecting ']' in /var/local/emhttp/sec.ini on line 71 in /usr/local/emhttp/plugins/webGui/template.php on line 36 Warning: syntax error, unexpected $end, expecting ']' in /var/local/emhttp/shares.ini on line 93 in /usr/local/emhttp/plugins/webGui/template.php on line 40 Warning: syntax error, unexpected $end, expecting ']' in /var/local/emhttp/sec_afp.ini on line 79 in /usr/local/emhttp/plugins/webGui/template.php on line 41 Warning: syntax error, unexpected $end, expecting ']' in /var/local/emhttp/sec_nfs.ini on line 53 in /usr/local/emhttp/plugins/webGui/template.php on line 42 

at the top of the 'Tower/Main' page.

 

The error text pushes the page banner frame down such that the tabs are not accessible.  I have cleared the browser cache (several times), but that makes no difference.

 

Other than this, the system appears to be running okay, through several reboots.

 

Incidentally, is there a good reason why Asia/Manila has never been included as timezone data?

 

 

Edit:

Okay, I think that I can see the reason for this!  All of those files are system-generated, listing all the user shares.  Every line which errors refers to one of my top level directories (which I never wanted as a user share - I realise that this is a fundamental, philosophical, discussion, but I really would be much happier if the system didn't automatically turn every top-level directory into a user share!) - that directory is "Pete's N97".  I guess that the php code is complaining about the apostrophe.  There is obviously a significant change here (use of php?) because 4.x and 5.x never had a problem with this directory.

 

Edit 2:

Yes, renaming the directory, and rebooting, has got rid of the problem.

 

Ok, got to the bottom of this.  The problem is with the single-quote in the share name, "Pete's N97".  unRaid 6 is using php 5.4 whereas unRaid 5 used php 5.2.  The way php deals with single quotes in it's "parse_ini_file()" function was changed in 5.3.  Refer to first comment here: https://bugs.php.net/bug.php?id=47703

 

The fix to get rid of the error message will require a new release 6.0-beta5.  The workaround is to not use share names with single quotes in them.

Link to comment

Its great that you're hoping to get Xen 4.4 in beta5, but what about XenGT? It looks like some pretty great tech as we can reuse the iGPU for many different VM with  very little performance hit!!

 

https://github.com/01org/XenGT-Preview-xen

 

Im sure the patch for Xen 4.4 will be released soon, if anything, just thought it would be great to hjave this for us who dont want to get radeons just to have more than 1 GPU passthru

Link to comment

I was checking the upgrade instructions in the changelog but it appears to only have directions from beta 1/2 and I'm running beta 3. Is there any difference or should I just follow the beta 1/2 directions? Also I've had a lot of freezes on beta 3 and I wanted to know if there was any way to have the log stored in a file for 24 hours (i know it'll get quite large), but it appears to be crashing overnight and when I get up in the morning it's frozen (can't telnet/putty into the server).

Link to comment

A couple of observations.

  • I had a bluray drive plugged into my test box and 6.0b4 wouldn't load in plain or Xen.
     
  • I have only added a cache drive to my array of the test box so far to have a play with VM's but cannot start the array as no other disks added.

 

Care to elaborate?  Maybe a syslog?

Link to comment

A couple of observations.

  • I had a bluray drive plugged into my test box and 6.0b4 wouldn't load in plain or Xen.
     
  • I have only added a cache drive to my array of the test box so far to have a play with VM's but cannot start the array as no other disks added.

 

Care to elaborate?  Maybe a syslog?

 

I'll plug the Bluray DVD drive back in to try to get some more detail but it stalled while loading, same place for both standard and Xen.

 

If I go to Extensions - Xen domains it states "array must be started to view domains" but in Main - I have no option to start the array because only a cache drive is added.

Link to comment

A couple of observations.

  • I had a bluray drive plugged into my test box and 6.0b4 wouldn't load in plain or Xen.
     
  • I have only added a cache drive to my array of the test box so far to have a play with VM's but cannot start the array as no other disks added.

 

Care to elaborate?  Maybe a syslog?

 

I'll plug the Bluray DVD drive back in to try to get some more detail but it stalled while loading, same place for both standard and Xen.

 

If I go to Extensions - Xen domains it states "array must be started to view domains" but in Main - I have no option to start the array because only a cache drive is added.

 

Image added of screen shot.

BD_stall.jpg.1db1d3abadc652d9aad4ffa443248eac.jpg

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.