dalben Posted January 23, 2014 Share Posted January 23, 2014 agree. even though it will mean I am stuck on a 5.x release until the plugins (or VM or docker) are available, I think its wise to keep 6.x releases purely 64bit. Quote Link to comment
zoggy Posted January 23, 2014 Share Posted January 23, 2014 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). people will be in for a rude awakening if they just expected things to 'work'. especially if the package dir locations arent changing.. can easily seeing this being a ongoing support problem. maybe add some logic to disable installing the plugin if its 32bit then? Quote Link to comment
jbartlett Posted January 23, 2014 Share Posted January 23, 2014 My only annoyance with this release so far is that the readme.txt file is in unix format so I had to close Notepad and open Wordpad. Quote Link to comment
PeterB Posted January 23, 2014 Share Posted January 23, 2014 I do not have the luxury of a test server, so will leave those who do test 6.0 first. However, I do not expect to wait too long before trying it. I agree, very strongly, with keeping 6.0 64-bit clean, even though it will cause some frustration at first. It would have been helpful if the extension for plugins had been changed for 6.0, (.plg64, perhaps). This would have made it easier to switch backwards and forwards between the two versions. Perhaps the best thing for me would be to install 6.0 on another SD card (loaded in my Kingston G2 reader). I have already fetched several 14.1 64bit packages in preparation. Top priority is to get apcupsd built in the new environment (we get at least two powercuts a day at the moment, so this really is urgent for me). I've already fetched the sources ready to build, but would be very happy if someone else beat me to it! My plan is to replicate my 5.0 config, with plugins, and get that running before working out how to push some of the services off into VMs. Next, I would have to get my email up - Dovecot and mpop plugins - again, I have the sources ready to go. After that, to keep the family happy, I will need to get my OpenELEC boxes going (dnsmasq and MySQL/MariaDB). After that, other things become a little less important (LogitechMediaServer, Couchpotato, Transmission etc). Quote Link to comment
grumpybutfun Posted January 23, 2014 Share Posted January 23, 2014 Below is an illustration to help clear up why the Plugins will not work / will crash your system Download a 32-Bit XBMC 10.0 package from the Ubuntu 8.04 repository and install it in 64-Bit Ubuntu 13.10. 1. Why in the hell would you even think of doing that? 2. Do you honestly think it will actually work? When Slackware 13.1 was released... That was the current version of XBMC and Ubuntu to put into perspective what we are talking about here. You / Me / We don't want to touch that with a ten foot pole. Create new plugins that download CURRENT 64-Bit Packages / Libraries that are INTENDED for Slackware 14.1 64-Bit so your Server will function CORRECTLY and be STABLE. Quote Link to comment
snowboardjoe Posted January 23, 2014 Share Posted January 23, 2014 This new 6.0 release is a major step forward and I don't want to see that momentum die. So, I'm also very much in favor of keeping 6.0 pure 64-bit right now. There is nothing to forcing people to move to 6.0 either. We've got 5.0, it's solid, you're still providing maintenance releases and it really has not been out that long. We have excellent solutions with 4.x and 5.x and there's no reason why people can't use those. We just need to be clear in the documentation for the masses on the critical differences. Quote Link to comment
jbartlett Posted January 23, 2014 Share Posted January 23, 2014 My VM finger is itchy. How do I scratch it? Quote Link to comment
grumpybutfun Posted January 23, 2014 Share Posted January 23, 2014 My VM finger is itchy. How do I scratch it? I'm with you. I'm positive the users who were busting my balls in several of the recent threads will have KVM / Xen Guide posted any minute now. I keep hitting refresh on my browser hoping to see one posted. Quote Link to comment
zoggy Posted January 23, 2014 Share Posted January 23, 2014 Below is an illustration to help clear up why the Plugins will not work / will crash your system Download a 32-Bit XBMC 10.0 package from the Ubuntu 8.04 repository and install it in 64-Bit Ubuntu 13.10. 1. Why in the hell would you even think of doing that? 2. Do you honestly think it will actually work? When Slackware 13.1 was released... That was the current version of XBMC and Ubuntu to put into perspective what we are talking about here. You / Me / We don't want to touch that with a ten foot pole. Create new plugins that download CURRENT 64-Bit Packages / Libraries that are INTENDED for Slackware 14.1 64-Bit so your Server will function CORRECTLY and be STABLE. so lets take your scenario.. firefox (even the latest) is 32bit software. a lot of people dont even know that... but sure enough it installs fine on win7 64bit. its one thing to be forced into a 64bit only ecosystem. and if thats what your wanting.. just realize that not all software is out there for 64bit (i do agree it should.. but some apps just arent developed anymore..) anyways my arguments is just to mention from a support standpoint.. if people can install packages the same way as before.. and if when upgrading your server you just do the normal routine.. a lot of people are going to get burned by it. which could stifle any interest and bring lots of negative feedback because they just dont 'known'. why not mandate a new folder for 64bit packages? (add 64prefix at the end)? or change the utility name? or add logic to prevent such things from getting loaded? side question, anyone tested out memtest on this new version... Tom, can we get the forums updated a bit to reflect a 6.x trunk now. Quote Link to comment
bobmagnuson Posted January 23, 2014 Share Posted January 23, 2014 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 - 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. Awesome job Tom! Quote Link to comment
limetech Posted January 23, 2014 Author Share Posted January 23, 2014 side question, anyone tested out memtest on this new version... No change to memtest since 5.x Tom, can we get the forums updated a bit to reflect a 6.x trunk now. Yes, forum will undergo a major re-org and also will be moved to a different host. Quote Link to comment
grumpybutfun Posted January 23, 2014 Share Posted January 23, 2014 so lets take your scenario.. firefox (even the latest) is 32bit software. a lot of people dont even know that... but sure enough it installs fine on win7 64bit. unRAID isn't running on Windows. its one thing to be forced into a 64bit only ecosystem. and if thats what your wanting.. just realize that not all software is out there for 64bit (i do agree it should.. but some apps just arent developed anymore..) anyways my arguments is just to mention from a support standpoint.. if people can install packages the same way as before.. and if when upgrading your server you just do the normal routine.. a lot of people are going to get burned by it. which could stifle any interest and bring lots of negative feedback because they just dont 'known'. 1. Convince the Plugin guys who are gracious enough to donate their time, energy and effort to develop / create / maintain Plugins for FREE and have THREE separate versions of their plugins (Slackware 13.1 32-Bit, Slackware 14.1 32-Bit and Slackware 14.1 64-Bit). 2. Convince Tom to turn on / install / maintain multilib support. why not mandate a new folder for 64bit packages? (add 64prefix at the end)? or change the utility name? or add logic to prevent such things from getting loaded? A lot of the plugins will not work and they will CRASH YOUR SERVER even with multilib support enabled. Trust me, I know what I am talking about and can duplicate Kernel Panics all day long with them. Therefore, new plugins have to be updated / created for unRAID 6.0 NO MATTER WHAT and there isn't a damn thing you, me, Tom or a Plugin Developer can do to get around that. Quote Link to comment
EGOvoruhk Posted January 23, 2014 Share Posted January 23, 2014 so lets take your scenario.. firefox (even the latest) is 32bit software. a lot of people dont even know that... but sure enough it installs fine on win7 64bit. Grumpy already "covered" it, but just in case you wanted to know more: http://en.wikipedia.org/wiki/WoW64 Quote Link to comment
Fx. Posted January 23, 2014 Share Posted January 23, 2014 nice comes with ssh baked in, small but appreciated Quote Link to comment
pyrater Posted January 23, 2014 Share Posted January 23, 2014 why is everyone freaking out, 1: you knew 64bit was coming 2: if you dont want to use 64bit DONT use 5.0.5 3. run VM's with a 32bit OS and install whatever 32 bit crap you want. I say Live and let live. Thanks TOM! Quote Link to comment
dirtysanchez Posted January 23, 2014 Share Posted January 23, 2014 I also would prefer to see 6.0 x64 kept as clean as possible. Since, like a few others here, I don't have a dev server, I will be sitting on the sidelines watching until there is a guide out there on how to run VM's on 6.0 (preferably by grumpy, as he writes awesome guides). I run a number of plugins and would prefer to offload them to a VM to keep unRAID itself as vanilla as possible. I'm also willing to bet that this will by far be the quickest way to migrate to 6.0 (if you are like me and can't move immediately due to plugins) as I'm sure running a VM on 6.0 will be solidified long before all the plugins I use are updated. Looking forward to unRAID progressing! Quote Link to comment
pyrater Posted January 23, 2014 Share Posted January 23, 2014 ^^ same as sanchez. Quote Link to comment
Markb Posted January 23, 2014 Share Posted January 23, 2014 Up and running on the test box (supermicro x8sax w/L5639), I had 4 new drives to put into the main box, but I will pre clear them and run them on the test box. Thanks Tom. Just abit of clarity, part of going to 6.0 was to add in the support for virtualization. As someone who does not run plugins but has a separate box for esxi and all my vm needs, if I do a little bit of light reading to enable/configure xen I can move my vm's to the unraid box and scrap the old unraid machine. Quote Link to comment
zoggy Posted January 23, 2014 Share Posted January 23, 2014 so lets take your scenario.. firefox (even the latest) is 32bit software. a lot of people dont even know that... but sure enough it installs fine on win7 64bit. unRAID isn't running on Windows. its one thing to be forced into a 64bit only ecosystem. and if thats what your wanting.. just realize that not all software is out there for 64bit (i do agree it should.. but some apps just arent developed anymore..) anyways my arguments is just to mention from a support standpoint.. if people can install packages the same way as before.. and if when upgrading your server you just do the normal routine.. a lot of people are going to get burned by it. which could stifle any interest and bring lots of negative feedback because they just dont 'known'. 1. Convince the Plugin guys who are gracious enough to donate their time, energy and effort to develop / create / maintain Plugins for FREE and have THREE separate versions of their plugins (Slackware 13.1 32-Bit, Slackware 14.1 32-Bit and Slackware 14.1 64-Bit). 2. Convince Tom to turn on / install / maintain multilib support. why not mandate a new folder for 64bit packages? (add 64prefix at the end)? or change the utility name? or add logic to prevent such things from getting loaded? A lot of the plugins will not work and they will CRASH YOUR SERVER even with multilib support enabled. Trust me, I know what I am talking about and can duplicate Kernel Panics all day long with them. Therefore, new plugins have to be updated / created for unRAID 6.0 NO MATTER WHAT and there isn't a damn thing you, me, Tom or a Plugin Developer can do to get around that. you missed the point. the argument was not how to handle 64bit. im well aware that unraid isnt running on windows. the point was the users expectations and what they would try to do. and as you point out, theres nothing stopping them from installing plugins that can cause issues. what i bring up is just the fact that there should be things changed to steer people into the right direction as plugin management is quite messy on unraid. ive provided many plugin updates.. i can only assume what horrors unmenu for example would cause if someone was to just upgrade to 6.x not knowing any better (because unmenu doesnt have any logic to stop the plugins users ask it to install -- nor the fact its updated to reflect any changes for 6.x obviously). anyways if you want to bicker some more come to the #unraid irc room on freenode. Quote Link to comment
speeding_ant Posted January 23, 2014 Share Posted January 23, 2014 Below is an illustration to help clear up why the Plugins will not work / will crash your system Download a 32-Bit XBMC 10.0 package from the Ubuntu 8.04 repository and install it in 64-Bit Ubuntu 13.10. 1. Why in the hell would you even think of doing that? 2. Do you honestly think it will actually work? When Slackware 13.1 was released... That was the current version of XBMC and Ubuntu to put into perspective what we are talking about here. You / Me / We don't want to touch that with a ten foot pole. Create new plugins that download CURRENT 64-Bit Packages / Libraries that are INTENDED for Slackware 14.1 64-Bit so your Server will function CORRECTLY and be STABLE. so lets take your scenario.. firefox (even the latest) is 32bit software. a lot of people dont even know that... but sure enough it installs fine on win7 64bit. its one thing to be forced into a 64bit only ecosystem. and if thats what your wanting.. just realize that not all software is out there for 64bit (i do agree it should.. but some apps just arent developed anymore..) anyways my arguments is just to mention from a support standpoint.. if people can install packages the same way as before.. and if when upgrading your server you just do the normal routine.. a lot of people are going to get burned by it. which could stifle any interest and bring lots of negative feedback because they just dont 'known'. why not mandate a new folder for 64bit packages? (add 64prefix at the end)? or change the utility name? or add logic to prevent such things from getting loaded? side question, anyone tested out memtest on this new version... Tom, can we get the forums updated a bit to reflect a 6.x trunk now. All major plugins can be easily migrated to 64-bit plugins, even easier than creating a 32-bit plugin for a dated version of Slackware. Plex is already 64-bit capable, shouldn't take long for them to create a new plugin (considering it contains all dependencies). I don't foresee many issues personally. The PLG plugin system means technically you just need to replace the packages. Post a 64-bit version, and once 6 is stable you deprecate the 32-bit plugins. Not hard really? Quote Link to comment
garycase Posted January 23, 2014 Share Posted January 23, 2014 One more vote for keeping the x64 version completely "clean" and 64-bit. Since it supports virtualization, there's a trivial way to run all the current plug-ins anyway ... create a VM, install a 32-bit Linux distro (or a 64-bit with 32-bit support); and just run your add-ons in that separate "clean" machine => that isolation has, of course, been one of the driving forces for virtualization anyway. Then they can all use the UnRAID NAS for their data ... and UnRAID will remain "pure" 64-bit So all that's needed is an easy-to-follow guide for setting up the virtualization support Quote Link to comment
SchoolBusDriver Posted January 23, 2014 Share Posted January 23, 2014 I'm sure running a VM on 6.0 will be solidified long before all the plugins I use are updated. Just so that people understand what is involved in updating a plugin... I just upgraded the sabnzb plugin in 5 minutes or less. Replace in the plugin where it would download the 32-Bit Slackware 13.1 packages with the correct 64-Bit Slackware packages. Cut and Paste mostly for the "simple" plugins like sabnzbd, sickbeard, couchpotato, etc. The Plugin guys can knock those out in no time. Things like Virtualbox, tvheadend, unmenu, etc. will require more "tweaking". Quote Link to comment
zoggy Posted January 23, 2014 Share Posted January 23, 2014 Below is an illustration to help clear up why the Plugins will not work / will crash your system Download a 32-Bit XBMC 10.0 package from the Ubuntu 8.04 repository and install it in 64-Bit Ubuntu 13.10. 1. Why in the hell would you even think of doing that? 2. Do you honestly think it will actually work? When Slackware 13.1 was released... That was the current version of XBMC and Ubuntu to put into perspective what we are talking about here. You / Me / We don't want to touch that with a ten foot pole. Create new plugins that download CURRENT 64-Bit Packages / Libraries that are INTENDED for Slackware 14.1 64-Bit so your Server will function CORRECTLY and be STABLE. so lets take your scenario.. firefox (even the latest) is 32bit software. a lot of people dont even know that... but sure enough it installs fine on win7 64bit. its one thing to be forced into a 64bit only ecosystem. and if thats what your wanting.. just realize that not all software is out there for 64bit (i do agree it should.. but some apps just arent developed anymore..) anyways my arguments is just to mention from a support standpoint.. if people can install packages the same way as before.. and if when upgrading your server you just do the normal routine.. a lot of people are going to get burned by it. which could stifle any interest and bring lots of negative feedback because they just dont 'known'. why not mandate a new folder for 64bit packages? (add 64prefix at the end)? or change the utility name? or add logic to prevent such things from getting loaded? side question, anyone tested out memtest on this new version... Tom, can we get the forums updated a bit to reflect a 6.x trunk now. All major plugins can be easily migrated to 64-bit plugins, even easier than creating a 32-bit plugin for a dated version of Slackware. Plex is already 64-bit capable, shouldn't take long for them to create a new plugin (considering it contains all dependencies). I don't foresee many issues personally. The PLG plugin system means technically you just need to replace the packages. Post a 64-bit version, and once 6 is stable you deprecate the 32-bit plugins. Not hard really? if everyone only used the new webgui to do things. being the gatekeeper it would be very easy to control. and yes most of the plugins just literately need a url change to reflect the new 14.1 lib/package file. for those that are testing: What does unraid do if you try to boot off with a cpu that doesnt have 64bit support? What does unraid do if you do have 64bit support, but have bios settings set to not enable those extensions? Quote Link to comment
BLKMGK Posted January 23, 2014 Share Posted January 23, 2014 I do think that moving to a plg64 extension for the new 64bit only plugins would make sense and that 64bit unRAID shouldn't support a deprecated 32bit plg format. I think this might be the best way to prevent ignorant users from shooting themselves in the foot installing 32bit code. Seems a simple change to make IMO.. Now for something controversial - any chance of using BTRFS on unRAID in the future? Having read the latest Ars article on it and ZFS I *think* running BTRFS on something "not RAID" is doable and we'd still reap the benefits of rollback from drive slack space, maybe even dedupe or crypto? Something I'd like to hear more educated thoughts than mine on but don't want to derail this 64bit discussion too badly ;-) Sent from my iPad using Tapatalk Quote Link to comment
Recommended Posts
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.