Jump to content

unRAID Server Release 6.0-beta1-x86_64 Available


limetech

Recommended Posts

Download

 

Please see

readme.txt

in the release zip file for installation/upgrade instructions.

 

Disclaimer: This is beta software.  While every effort has been made to ensure no data loss, use at your own risk!

 

This is 64-bit version of unRAID Server OS.  I expect a couple more betas and then straight to -rc, then straight to 'final'.

 

As of posting this, I have not yet pushed the updated webGui to github, but that is next on my list.  What I'm going to do is remove the current repo and upload a new one, i.e., a "do over"  ;)

 

Here are some highlights:

 

- linux kernel 3.10.24 - we'll be updating to 3.12 probably in next beta

 

- full virtualization kernel support, including libvirt.  Post here if I forgot something  :o

 

- updated slackware - yup this is still slack, but latest version 14.1.

 

- "new" webGui - love it or hate it, this is the basis for moving forward.  A word about the banner image: you will notice it's different.  The idea with the banner image is that eventually we'll add the code to let you upload your own banner images.  This way if you have multiple servers, maybe called "mountain", "ocean", and "forest", you could have appropriate banner images - this just ensures you're on the right server.  You can disable the banner image completely via the Settings/Display Preferences page.

 

- other: updated samba, php.  Added mailx (for future email notifications).  Added openssh.  The initial set of host keys will be generated upon first boot and stored on the flash in config/ssh directory.

 

- wanted to update netatalk to latest 3.1.x but ran out of time.  This will also probably be in next beta.

 

There a few known issues, chief of which is problem with dhcp and bonding driver.  Current workaround seems to work, but solution will wait for kernel update since starting with 3.11 they redesigned how bonding is done (no more ifenslave), so we'll give that a whirl later.

 

Also, I didn't include the necessary libraries to support 32-bit executables.  This may give some plugin authors grief, so we might add this later.

Link to comment
  • Replies 181
  • Created
  • Last Reply

Thanks Tom - will be testing this tonight.

 

Re: 32-bit executables...  There should be little need to do this. I can't think of many binaries that cannot be compiled to support 64-bit, so for the sake of complexity and future proofing, I think it's probably best to force plugin developers to support it. Once you add it in, it's much harder to remove it...  ;)

Link to comment

Thanks Tom - will be testing this tonight.

 

Re: 32-bit executables...  There should be little need to do this. I can't think of many binaries that cannot be compiled to support 64-bit, so for the sake of complexity and future proofing, I think it's probably best to force plugin developers to support it. Once you add it in, it's much harder to remove it...  ;)

That was my thought too but we'll see how much wailing and gnashing of teeth occurs  ;)

 

Link to comment

Thanks Tom - will be testing this tonight.

 

Re: 32-bit executables...  There should be little need to do this. I can't think of many binaries that cannot be compiled to support 64-bit, so for the sake of complexity and future proofing, I think it's probably best to force plugin developers to support it. Once you add it in, it's much harder to remove it...  ;)

 

I completely agree. My personal preference is that my unRAID 6.0 servers to be fully 64bit.

Link to comment

Thanks Tom - will be testing this tonight.

 

Re: 32-bit executables...  There should be little need to do this. I can't think of many binaries that cannot be compiled to support 64-bit, so for the sake of complexity and future proofing, I think it's probably best to force plugin developers to support it. Once you add it in, it's much harder to remove it...  ;)

That was my thought too but we'll see how much wailing and gnashing of teeth occurs  ;)

 

Let 'em gnash  ;D    lazy developers like gnashing    ;D

Link to comment

I assume we can load this up on my current server, have a play, and then downgrade back to the 5.04 prod release without any trouble ?  Or is there some conversion required that will make hopping back and forth trickier ?

 

It will depend on how much you have customized your setup. Most plugins will not work until they are updated. For example if you run SickBeard it will need to be updated to grab the Slack 14.1 64bit version of python. Or if you use Plex, Plex will need to release a 64bit version for unRAID 6.0. Same thing if you are installing any packages through unmenu.

 

If you are just using unRAID default without any plugins or packages the upgrade should be simple.

Link to comment

Is there a way to change the header on the WebGUI? I prefer solid white, like we have with the current 5.0.X webGUI.

 

I assume we can load this up on my current server, have a play, and then downgrade back to the 5.04 prod release without any trouble ?  Or is there some conversion required that will make hopping back and forth trickier ?

 

It will depend on how much you have customized your setup. Most plugins will not work until they are updated. For example if you run SickBeard it will need to be updated to grab the Slack 14.1 64bit version of python. Or if you use Plex, Plex will need to release a 64bit version for unRAID 6.0. Same thing if you are installing any packages through unmenu.

 

If you are just using unRAID default without any plugins or packages the upgrade should be simple.

 

Does this mean we're going to have to redo Sickbeard/Sabnzbd settings? Redoing Sickbeard would be a nightmare for me. Hopefully the plugins just need to get the 64bit version of python and it'll work...

 

What about cache dirs, preclear disks, etc?

Link to comment

I assume we can load this up on my current server, have a play, and then downgrade back to the 5.04 prod release without any trouble ?  Or is there some conversion required that will make hopping back and forth trickier ?

 

It will depend on how much you have customized your setup. Most plugins will not work until they are updated. For example if you run SickBeard it will need to be updated to grab the Slack 14.1 64bit version of python. Or if you use Plex, Plex will need to release a 64bit version for unRAID 6.0. Same thing if you are installing any packages through unmenu.

 

If you are just using unRAID default without any plugins or packages the upgrade should be simple.

 

Does this mean we're going to have to redo Sickbeard/Sabnzbd settings? Redoing Sickbeard would be a nightmare for me. Hopefully the plugins just need to get the 64bit version of python and it'll work...

 

What about cache dirs, the webgui based on simple features, preclear disks, etc addons?

 

No you will need to redo any settings. The underlying infrastructure need to be updated. For example Sickbeard is a python script. But the python it installs is the 32 bit version. So in theory the package maintainer will need to update the .plg to point to the new 64bit python and other dependencies. It will not affect your databases, settings, etc.

 

For tunables, cache_dir, preclear these scripts call OS level utilities that are included with the default unRAID and are safe to run without any updates.

Link to comment

I too may hold off just a little bit since I no longer have a test server I can dork with on the bleeding edge. That said, I am also very excited to see a 64bit only release! I will almost certainly use this as an opportunity to clean out all of my plugins and start from scratch. I really have got such a mess of stuff on there now that I wouldn't trust it to go 64bit lol

 

Actually, I do have some small servers I built for others that could be candidates, I'll have to see about updating one of them to this release.

Link to comment

For tunables, cache_dir, preclear these scripts call OS level utilities that are included with the default unRAID and are safe to run without any updates.

They may act differently however. Some scripts may assume things that are no longer true with 64 bit. Max performance from changing the memory allocated for specific items for example. Free memory is going to have to be evaluated a little differently now.
Link to comment

I assume we can load this up on my current server, have a play, and then downgrade back to the 5.04 prod release without any trouble ?  Or is there some conversion required that will make hopping back and forth trickier ?

 

It will depend on how much you have customized your setup. Most plugins will not work until they are updated. For example if you run SickBeard it will need to be updated to grab the Slack 14.1 64bit version of python. Or if you use Plex, Plex will need to release a 64bit version for unRAID 6.0. Same thing if you are installing any packages through unmenu.

 

If you are just using unRAID default without any plugins or packages the upgrade should be simple.

 

Does this mean we're going to have to redo Sickbeard/Sabnzbd settings? Redoing Sickbeard would be a nightmare for me. Hopefully the plugins just need to get the 64bit version of python and it'll work...

 

What about cache dirs, the webgui based on simple features, preclear disks, etc addons?

 

No you will need to redo any settings. The underlying infrastructure need to be updated. For example Sickbeard is a python script. But the python it installs is the 32 bit version. So in theory the package maintainer will need to update the .plg to point to the new 64bit python and other dependencies. It will not affect your databases, settings, etc.

 

For tunables, cache_dir, preclear these scripts call OS level utilities that are included with the default unRAID and are safe to run without any updates.

 

you get little to gain on going to 64bit with regards to sickbeard/sab, if you are running 64bit in sab we try to detect it and load the appropriate tools we provide (unrar/par/etc) -- but only for osx/win. when it comes to linux, we just use whatever is installed. its been a long battle on 64bit and python.. as a lot of installers actually just install a 32bit version to ensure compatibility... or just flat out lies to the env. Anyways, nothing is forcing you to upgrade to 64bit software as 32bit support is still included. now for those that want to make the argument that hey.. i have 4+gb of ram.. i want 'sab' to use it.. its not sab that needs it.. it would be par/unrar that would.. which are its own apps. so go upgrade those :P

 

*disclaimer* i'm under the impression that 32bit support is included with this build. if its not..then the x86_64 part really needs to be updated to reflect it.

 

Tom, is this built off slackware64 14.1 ?

Link to comment

Why not include lib-ia32/multi-lib in the package (is it? Slackware is ready for it) that way all the 32bit executables (python, etc) will mean the existing Plex/Sickbeard packages will run as is...

 

I strongly disagree.

 

With Slackware 14.1 64-Bit... I CAN cause kernel panics with mulilib support enabled when installing OLD 32-bit packages that the current plugins do.

 

Would rather have the plugin guys update their packages with updated versions of the 32-Bit versions that don't work on 5.0 or just make / update the plugins for 64-Bit?

 

Otherwise we will have 3 versions of plugins. Slackware 13.1 32-bit, Slackware 14.1 32-Bit and Slackware 14.1 64-Bit.

Link to comment

Why not include lib-ia32/multi-lib in the package (is it? Slackware is ready for it) that way all the 32bit executables (python, etc) will mean the existing Plex/Sickbeard packages will run as is...

 

I strongly disagree.

 

With Slackware 14.1 64-Bit... I CAN cause kernel panics with mulilib support enabled when installing OLD 32-bit packages that the current plugins.

 

Would rather have the plugin guys update their packages with updated versions of the 32-Bit versions that don't work on 5.0 or just make / update the plugins for 64-Bit?

 

 

I'm with grumpy on this one. If people want to stay on 32bit, stay on the 5.x versions.

Leave 6.x x64 clean as possible.

Link to comment

Why not include lib-ia32/multi-lib in the package (is it? Slackware is ready for it) that way all the 32bit executables (python, etc) will mean the existing Plex/Sickbeard packages will run as is...

 

I strongly disagree.

 

With Slackware 14.1 64-Bit... I CAN cause kernel panics with mulilib support enabled when installing OLD 32-bit packages that the current plugins.

 

Would rather have the plugin guys update their packages with updated versions of the 32-Bit versions that don't work on 5.0 or just make / update the plugins for 64-Bit?

 

 

I'm with grumpy on this one. If people want to stay on 32bit, stay on the 5.x versions.

Leave 6.x x64 clean as possible.

 

why not transition off of 64bit. 6.1 can be 64bit only? that way you can get a lot more people willing to test 6.x. as a lot of people wont even bother if its too much trouble. lower the barrier to entry...

Link to comment

why not transition off of 64bit. 6.1 can be 64bit only? that way you can get a lot more people willing to test 6.x. as a lot of people wont even bother if its too much trouble. lower the barrier to entry...

 

The plugins as they are today will CRASH your Server in unRAID 6.0 when the plugins install the various packages / binaries designed for a 4+ year old 32-Bit version of Slackware 13.1.

 

To do what you propose the Plugin Developers would have to create new plugins anyway. Might as well have them just make ONE package (64-Bit) instead of TWO (32-Bit and 64-Bit).

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...