unRAID Server Release 6.0-beta1-x86_64 Available

[PeterB]

Yes, all the drivers are "modules" and loaded on demand based on detected h/w, but in unRaid the root filesystem is in RAM, which means it takes up RAM, so even if module not loaded it still takes up space.  We're talking 10's of K's here per driver, so I'm probably being a bit anal about wanting to save space.  Some day I might get over that 

 

I'm with you on saving space.  The modules can't be loaded (insmod, or whatever) from another location, even if it's just by placing the desired drivers in a specific folder on the flash drive (like the plugins and extras folders)?

 

I agree that very common/standard drivers should be auto-loaded on demand, but if it were possible to 'force' less common drivers to load from flash, it would make things a lot more flexible.

[NAS]

Yes, all the drivers are "modules" and loaded on demand based on detected h/w, but in unRaid the root filesystem is in RAM, which means it takes up RAM, so even if module not loaded it still takes up space.  We're talking 10's of K's here per driver, so I'm probably being a bit anal about wanting to save space.  Some day I might get over that 

 

I'm with you on saving space.  The modules can't be loaded (insmod, or whatever) from another location, even if it's just by placing the desired drivers in a specific folder on the flash drive (like the plugins and extras folders)?

 

I agree that very common/standard drivers should be auto-loaded on demand, but if it were possible to 'force' less common drivers to load from flash, it would make things a lot more flexible.

 

For what it is worth I also agree. Space may be less important than in the past but every single thing that is added is sothing that can break and has to be supported ad nausium. Stick with the current approach of adding as real demand dictates and avoid any urges to add support for one users $2 network card purchased on ebay last century

[nicinabox]

I've started a wiki page, 64 bit Compatibility, tentatively designed to collect in one place all of the info related to what's ready for 64 bit and what's not.  Its usefulness will depend entirely on how well it is kept up-to-date.  Feel free to edit, expand, change the formatting, add new sections, etc.

 

To start it off, I've added 4 sections:

* General System for the basics, the UnRAID OS, WebGUI, and general virtualization stuff, with a special section for Known Issues

* Plugins, hoping that the plugin devs will keep this updated (already have Boiler and Plex and APCUPSD there!)

* Scripts, hoping that various existing scripts will be either updated or confirmed to work with v6, perhaps add notes about known limitations (already have Preclear there!)

* VM Images, an unofficial place to list them all as they become available

 

That was fast. I'll test boiler tomorrow for real. The code definitely works, but I suspect a dependency problem now that I think about it. I'll get the package api updated for 64bit too.

 

Tom: a big thank you for keeping these releases coming. I deeply appreciate your work; I know how thankless it can be.

[Ice_Black]

Is Parity drive any faster on 64 bit?

[sacretagent]

Not sure where to put this .... in this thread or make a new one in the virtualization board

 

but we are missing something to make libvirt work

 

root@Tower:/etc/rc.d# rc.libvirt restart

libvirt is not running...

root@Tower:/etc/rc.d# rc.libvirt start

Starting libvirtd...

p11-kit: couldn't load module: /usr/lib64/pkcs11/p11-kit-trust.so: libtasn1.so.6: cannot open shared object file: No such file or directory

root@Tower:/etc/rc.d# virsh -c qemu+tcp://192.168.1.10/system nodeinfo

p11-kit: couldn't load module: /usr/lib64/pkcs11/p11-kit-trust.so: libtasn1.so.6: cannot open shared object file: No such file or directory

CPU model:          x86_64

CPU(s):              2

CPU frequency:      2800 MHz

CPU socket(s):      1

Core(s) per socket:  2

Thread(s) per core:  1

NUMA cell(s):        1

Memory size:        3962900 KiB

 

 

not sure what it means ....not used to KVM  so doing everything with the help of google how to's

also how are we supposed to make changes to /etc/libvert/libvertd.conf stick ?

 

was hoping to get a test vm running .... but seems my google fu is coming up short

libtasn1 is missing from build, added for -beta2

 

Thanks Tom

 

anyway to get the

/etc/libvirt/qemu.conf

/etc/libvirt/libvirtd.conf

/etc/libvirt/lxc.conf

/etc/libvirt/libvirt.conf

hardlinked to a folder on boot

so we can make changes that stick ?

or you prefer us to work around that (Sed)?

 

[garycase]

Is Parity drive any faster on 64 bit?

 

No ... the speed of the drive is the limiting factor -- not the speed of the CPU.  Even modest CPU's are faster than the fastest modern drives.

 

 

[meoge]

Another noob question.  Is the ability to schedule parity checks a built in feature or do I need to add a package?  I can't find it under any settings so I'm guessing this is another thing I had running from an unmenu package.  I did install the APC shutdown package and it works like a charm.

[Dephcon]

Do we really need to support PATA on a 64bit only server OS?  I would be terrified of using an IDE drive purely based on it's age and replacing a 250-500GB IDE drive isn't going to break anyone's bank.  Eliminating PATA/IDE is eliminating one more thing that needs to be supported and simplifies troubleshooting.

[jowi]

So, is this something i could just try on my 5.0.4 machine? I dont really care about or have any use for virtualization (i dont really understand what the fuzz is about and why people are excited about it...?) and i have some plugins running (sabnzb, sickbeard, squeezeserver) that might, or might not work...? Is that it?

 

If this 64 bit version doesn't work for me, or doesn't add any value for my use, or if my plugins are incompatible, i can simply revert back to 5.0.4, right?

[itimpi]

 

If this 64 bit version doesn't work for me, or doesn't add any value for my use, or if my plugins are incompatible, i can simply revert back to 5.0.4, right?

I would expect the majority of plugins to be incompatible with a 64-bit environment as they would almost certainly have dependencies on 32-bit libraries.

[trurl]

So, is this something i could just try on my 5.0.4 machine? I dont really care about or have any use for virtualization (i dont really understand what the fuzz is about and why people are excited about it...?) and i have some plugins running (sabnzb, sickbeard, squeezeserver) that might, or might not work...? Is that it?

 

If this 64 bit version doesn't work for me, or doesn't add any value for my use, or if my plugins are incompatible, i can simply revert back to 5.0.4, right?

Unless you are interested in helping out with testing a beta 1 then you are probably better off staying on 5 for a while. 5.0.5 is the current stable release. You shouldn't expect any 32bit plugins to work. Some people have begun working on 64bit addons but it will probably be a while before you can easily duplicate all your current functionality.

 

 

[jowi]

So, on windows 64 its no problem to run 32bits binaries without rebuilding. But on linux this not possible? Things have to be rebuilt for 64 bits otherwise they don't even run?

[RobJ]

Do we really need to support PATA on a 64bit only server OS?  I would be terrified of using an IDE drive purely based on it's age and replacing a 250-500GB IDE drive isn't going to break anyone's bank.  Eliminating PATA/IDE is eliminating one more thing that needs to be supported and simplifies troubleshooting.

 

I realize many UnRAID users are well off, and have no trouble affording the latest drives, SAS cards, high performance CPU's and other hardware, supporting dozens of drives and advanced virtualization performance and capabilities, but I believe I speak for a number of users, the silent minority, that cannot afford all of that.  UnRAID is for us too, and its ability to make use of old hand-me-down systems and reuse retired hard drives makes it a fantastic value.  We only add a hard drive as it becomes available to us, whether on sale or given away by someone else with more money or upgrading to bigger and newer.

 

'Terrified' is a strong word.  May I remind you that while IDE is from the previous generation of drive interfaces, it is still a tried and true one, considerably more stable and mature than the current SAS interfaces and drivers are.  And these drives come from the age when 3 to 5 year warranties were common, try and get a 5 year warranty now!

 

Many old machines do support 64 bit, so while we may not have enough RAM to take full advantage of it, let us enjoy what we can.

[Fx.]

So, on windows 64 its no problem to run 32bits binaries without rebuilding. But on linux this not possible? Things have to be rebuilt for 64 bits otherwise they don't even run?

http://en.wikipedia.org/wiki/WoW64

for *nix it adds complexity that people would rather not support (multilib doesnt work very well usually and even worse on slackware)

its one more thing to support when the alternative is to update the software which tends to be a better answer anyway

 

edit: and windows only runs x32 binarys that dont touch drivers or hardware in any real way, nix tends to get a bit more direct especially appliance level nix

[RobJ]

So, on windows 64 its no problem to run 32bits binaries without rebuilding. But on linux this not possible? Things have to be rebuilt for 64 bits otherwise they don't even run?

 

Multilib support was discussed earlier in this thread and the clear consensus was that a 64 bit version should be kept completely pure, 64 bit only, recompiling as needed.

 

I think a lot of people at Microsoft would really get a laugh out of your statement of "on windows 64 its no problem to run 32bits binaries".  If they could have outlawed 32 bit before, they would have, at least by Vista, surely by Windows 7.  There is probably no way to count how much it has cost them to maintain 32 bit support, and make it 'look' as easy to do now.  You still have to use the Compatibility wizard for some apps, and probably a lot of money and effort has gone just into that tool.  Linux doesn't have that kind of money, or the interest/requirement in backward compatibility.

[ashaneil]

This maybe off-topic but if I wanted to test new builds / rc without messing up my main server (Goliath build), would this be possible on a HP 54L or would I have to build a new machine? Another option maybe that since I am running unRAID as a VM, maybe I can do the same for the new version.

 

 

Any comments / suggestions?

[Fx.]

that seems to run a turian 2 whcih seems to run x64 so.. yes

 

 

http://www.amd.com/us/Documents/48396B_Turion_N54L_vs_i5_520M_flyer.pdf

 

 

edit: but yeah if you already have virtualisation set up, just run up another vm, be the easiest way

[jowi]

I've been reading on v6 and vm's and plugins, am i correct in thinking that unraid 64 is now able to HOST vm's? So that e.g. unraid hosts a vm running linux, on which sabnzb and sickbeard etc are running? Or hosts vm's that run a 'plugin' each?

 

Or should you install and run some virtualization software on your machine, prior to running unraid, so unriad becomes one of many vm's?

[trurl]

I've been reading on v6 and vm's and plugins, am i correct in thinking that unraid 64 is now able to HOST vm's? So that e.g. unraid hosts a vm running linux, on which sabnzb and sickbeard etc are running? Or hosts vm's that run a 'plugin' each?

 

Or should you install and run some virtualization software on your machine, prior to running unraid, so unriad becomes one of many vm's?

This is the direction we are headed but it is still very early. Lots more work being done and to do.

[nicinabox]

I'm trying to upgrade my testing VM from 5.0.2 to 6.0-beta. I'm get this error on startup:

 

VFS: Insert root floppy and press ENTER

 

What am I doing wrong?

[Fx.]

re-ran "make_bootable" ?

[grumpybutfun]

So, on windows 64 its no problem to run 32bits binaries without rebuilding. But on linux this not possible? Things have to be rebuilt for 64 bits otherwise they don't even run?

 

It's works and works quite well.

 

The problem is...

 

1. unRAID / Slackware doesn't have a package manager.

 

2. unRAID uses a root ramfs.

 

3. Plugins as they are today download various packages / libraries (who knows which version you get) and many of those are 4+ years old.

 

You cannot download 32-Bit Packages / Libraries for XBMC 10.0 from Ubuntu 8.04 repo and install it in 64-Bit version of Ubuntu 13.10 and think / believe it will work (it won't). There were WAY to many changes to shared libraries, packages and the underlying OS / file structure for it too.

 

unRAID 5.0 is based on Slackware 13.1 (4+ Years old = Ubuntu 8.04) and all the various plugins install packages / libraries from 4+ years ago too.

 

Even if everyone wanted 32-Bit packages for unRAID 6.0 (which almost all of us don't)...

 

The plugin guys have redo them anyway so they can grab the Slackware 14.1 32-Bit packages / libraries. Might as well forget 32-Bit and have those guys focus 100% on 64-Bit only. Otherwise we now have 3 versions of each plugin. Slackware 13.1 (32-Bit), Slackware 14.1 (32-Bit) and Slackware 14.1 (64-Bit).

 

If I was a plugin guy (who creates / maintains them for FREE)... I wouldn't want to maintain 3 versions. Now you pay me, then we can start talking but I am not posting it on the unRAID forum though.

[nicinabox]

So, on windows 64 its no problem to run 32bits binaries without rebuilding. But on linux this not possible? Things have to be rebuilt for 64 bits otherwise they don't even run?

 

It's works and works quite well.

 

The problem is...

 

1. unRAID / Slackware doesn't have a package manager.

 

2. unRAID uses a root ramfs.

 

3. Plugins as they are today download various packages / libraries (who knows which version you get) and many of those are 4+ years old.

 

You cannot download 32-Bit Packages / Libraries for XBMC 10.0 from Ubuntu 8.04 repo and install it in 64-Bit version of Ubuntu 13.10 and think / believe it will work (it won't). There were WAY to many changes to shared libraries, packages and the underlying OS / file structure for it too.

 

unRAID 5.0 is based on Slackware 13.1 (4+ Years old = Ubuntu 8.04) and all the various plugins install packages / libraries from 4+ years ago too.

 

Even if everyone wanted 32-Bit packages for unRAID 6.0 (which almost all of us don't)...

 

The plugin guys have redo them anyway so they can grab the Slackware 14.1 32-Bit packages / libraries. Might as well forget 32-Bit and have those guys focus 100% on 64-Bit only. Otherwise we now have 3 versions of each plugin. Slackware 13.1 (32-Bit), Slackware 14.1 (32-Bit) and Slackware 14.1 (64-Bit).

 

If I was a plugin guy (who creates / maintains them for FREE)... I wouldn't want to maintain 3 versions. Now you pay me, then we can start talking but I am not posting it on the unRAID forum though.

 

See my comment here about how trolley can do this automatically. No one should have to maintain more than 1 version of their package.

 

Using boiler we can define dependencies by name and version, and let the system handle arch automatically.

[SchoolBusDriver]

Using boiler we can define dependencies by name and version, and let the system handle arch automatically.

 

I understand that. The plugin guys still have to rewrite their plugins to use it.

 

It would help if Lime Technologies puts their weight / support behind it too.

[jbartlett]

If this 64 bit version doesn't work for me, or doesn't add any value for my use, or if my plugins are incompatible, i can simply revert back to 5.0.4, right?

You can also install the 32 bit version which is 5.0.5.