needo Posted January 23, 2014 Share Posted January 23, 2014 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 You are correct. My point was that the current plugins install the 32bit binaries and libraries of python and therefore would not work on unRAID 6 until these plugins are updated with their 64bit counterparts. Quote Link to comment
Finka Posted January 23, 2014 Share Posted January 23, 2014 - linux kernel ... we'll be updating to 3.12 probably in next beta Why? 3.10 is the latest LTS, while 3.12 will be EOL pretty soon, just like we dead ended with the 3.9 EOL in unRAID v.5. Unless there is some veery good reason to move to 3.12, I would much rather we stick to the LTS kernels. Quote Link to comment
PeterB Posted January 23, 2014 Share Posted January 23, 2014 ... because unmenu doesnt have any logic to stop the plugins users ask it to install Since when has unmenu had anything to do with plugins? It has no knowledge of any plugins, whether the user is installing them or not. -- nor the fact its updated to reflect any changes for 6.x obviously). I thought Joe said that there was no architecture-dependence in unmenu itself - but, until it's updated, it will still be offering i486 packages. In fact, once an unmenu package is set to autoinstall, unmenu is not involved in the process at all. Quote Link to comment
speeding_ant Posted January 23, 2014 Share Posted January 23, 2014 - linux kernel ... we'll be updating to 3.12 probably in next beta Why? 3.10 is the latest LTS, while 3.12 will be EOL pretty soon, just like we dead ended with the 3.9 EOL in unRAID v.5. Unless there is some veery good reason to move to 3.12, I would much rather we stick to the LTS kernels. Probably something to do with the DHCP on bonded interfaces bug Tom posted Quote Link to comment
SchoolBusDriver Posted January 23, 2014 Share Posted January 23, 2014 Why? 3.10 is the latest LTS, while 3.12 will be EOL pretty soon, just like we dead ended with the 3.9 EOL in unRAID v.5. Unless there is some veery good reason to move to 3.12, I would much rather we stick to the LTS kernels. Here are the reasons why I would go with 3.12 Series until the next LTS Kernel is out: 1. KVM (which is updated via Linux Kernel) needs the updates in Linux Kernel 3.12 that many here will want. 2. Passthrough AMD 5xxx, 6xxx, 7xxx Video Cards using Radeon drivers, VDPAU (Video Hardware Acceleration) and have HD Audio. Otherwise we have to use AMD's Proprietary Drivers and install a "special" version of XBMC with XVBA to get Hardware Video Acceleration and no HD Audio. 3. Passthrough nVidia GeForce 7, 8, 4xx, 5xx, 6xx Video Cards. No can do without Linux Kernel 3.12 Series. Quote Link to comment
dirtysanchez Posted January 23, 2014 Share Posted January 23, 2014 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. I figured as much. I wasn't talking about how long it would take to update them, but more along the lines of the plugin developers getting it done. Some of them aren't around much these days. Quote Link to comment
zoggy Posted January 23, 2014 Share Posted January 23, 2014 ... because unmenu doesnt have any logic to stop the plugins users ask it to install Since when has unmenu had anything to do with plugins? It has no knowledge of any plugins, whether the user is installing them or not. -- nor the fact its updated to reflect any changes for 6.x obviously). I thought Joe said that there was no architecture-dependence in unmenu itself - but, until it's updated, it will still be offering i486 packages. In fact, once an unmenu package is set to autoinstall, unmenu is not involved in the process at all. many people rely on unmenu to install packages/plugins. and you further elaborate my point that the 'damage is done' by the fact that the same old plugin folder is used.. thus items put in there from unmenu would cause problems if not addressed. the same thing can be said for boxcar or anything that is doing it. the fact remains that there are several 3rd party solutions that would allow users to make the mistake. im just trying to point this out so we get traction on the best way to handle this gracefully / prevent it. i'm sure the users will just come looking to the forums the first crash.. so maybe Darwinism will just work the problem out? Quote Link to comment
WeeboTech Posted January 23, 2014 Share Posted January 23, 2014 I liked the idea someone suggested of having an x64 and an i386 extra folder. extrax64 extrai386 or something like that. Quote Link to comment
BRiT Posted January 23, 2014 Share Posted January 23, 2014 As perhaps one of the earlier users to ever dabble with 64bit unRAID and having been running my own multilib versions of it to run 64bit and 32bit since 2010, here's my take on the situation. For the love of all things, keep unRAID 6.0 64bit only. Do not even delve into the world that is multi-lib. Quote Link to comment
bonienl Posted January 23, 2014 Share Posted January 23, 2014 Make take on the plugin story ... introduce a new extension ".plg64" This would prevent the system to load any 'old' plugins and avoid conflicts, while it also becomes clearer for users in selecting either the 32-bit or 64-bit version of the plugin, and finally for developers it is easier to maintain 'two' versions - as long as it lasts. Quote Link to comment
jbartlett Posted January 23, 2014 Share Posted January 23, 2014 /proc/mdcmd is reporting that there's 11 drives attached and in the protected array on my backup server but there's only 10 - I don't have a parity drive configured or installed currently. sbName=/boot/config/super.dat sbVersion=2.2.0 sbCreated=1389921131 sbUpdated=1390460925 sbEvents=47 sbState=0 sbNumDisks=11 sbSynced=0 sbSyncErrs=0 mdVersion=2.2.0 mdState=STARTED mdNumProtected=11 mdNumDisabled=1 mdDisabledDisk=0 mdNumInvalid=1 mdInvalidDisk=0 mdNumMissing=0 mdMissingDisk=0 mdNumNew=0 mdResync=0 mdResyncCorr=0 mdResyncPos=0 mdResyncDt=0 mdResyncDb=0 diskNumber.0=0 diskName.0= diskSize.0=0 diskState.0=4 diskId.0= rdevNumber.0=0 rdevStatus.0=DISK_DSBL_NP rdevName.0= rdevSize.0=0 rdevId.0= rdevNumErrors.0=0 rdevLastIO.0=0 rdevSpinupGroup.0=0 diskNumber.1=1 diskName.1=md1 diskSize.1=1953514552 diskState.1=7 diskId.1=WDC_WD2002FAEX-007BA0_WD-WMAY01934977 rdevNumber.1=1 rdevStatus.1=DISK_OK rdevName.1=sdj rdevSize.1=1953514552 rdevId.1=WDC_WD2002FAEX-007BA0_WD-WMAY01934977 rdevNumErrors.1=0 rdevLastIO.1=0 rdevSpinupGroup.1=0 diskNumber.2=2 diskName.2=md2 diskSize.2=1465138552 diskState.2=7 diskId.2=WDC_WD15EARS-00MVWB0_WD-WMAZA3205240 rdevNumber.2=2 rdevStatus.2=DISK_OK rdevName.2=sdb rdevSize.2=1465138552 rdevId.2=WDC_WD15EARS-00MVWB0_WD-WMAZA3205240 rdevNumErrors.2=0 rdevLastIO.2=0 rdevSpinupGroup.2=0 diskNumber.3=3 diskName.3=md3 diskSize.3=1465138552 diskState.3=7 diskId.3=WDC_WD15EARS-00MVWB0_WD-WMAZA3203761 rdevNumber.3=3 rdevStatus.3=DISK_OK rdevName.3=sdd rdevSize.3=1465138552 rdevId.3=WDC_WD15EARS-00MVWB0_WD-WMAZA3203761 rdevNumErrors.3=0 rdevLastIO.3=0 rdevSpinupGroup.3=0 diskNumber.4=4 diskName.4=md4 diskSize.4=1465138552 diskState.4=7 diskId.4=WDC_WD15EARS-00MVWB0_WD-WMAZA3393982 rdevNumber.4=4 rdevStatus.4=DISK_OK rdevName.4=sdf rdevSize.4=1465138552 rdevId.4=WDC_WD15EARS-00MVWB0_WD-WMAZA3393982 rdevNumErrors.4=0 rdevLastIO.4=0 rdevSpinupGroup.4=0 diskNumber.5=5 diskName.5=md5 diskSize.5=1465138552 diskState.5=7 diskId.5=WDC_WD15EARS-00MVWB0_WD-WMAZA3413329 rdevNumber.5=5 rdevStatus.5=DISK_OK rdevName.5=sdg rdevSize.5=1465138552 rdevId.5=WDC_WD15EARS-00MVWB0_WD-WMAZA3413329 rdevNumErrors.5=0 rdevLastIO.5=0 rdevSpinupGroup.5=0 diskNumber.6=6 diskName.6=md6 diskSize.6=1465138552 diskState.6=7 diskId.6=WDC_WD15EARS-00MVWB0_WD-WMAZA3396022 rdevNumber.6=6 rdevStatus.6=DISK_OK rdevName.6=sdh rdevSize.6=1465138552 rdevId.6=WDC_WD15EARS-00MVWB0_WD-WMAZA3396022 rdevNumErrors.6=0 rdevLastIO.6=0 rdevSpinupGroup.6=0 diskNumber.7=7 diskName.7=md7 diskSize.7=1465138552 diskState.7=7 diskId.7=WDC_WD15EARS-00MVWB0_WD-WMAZA3318333 rdevNumber.7=7 rdevStatus.7=DISK_OK rdevName.7=sdi rdevSize.7=1465138552 rdevId.7=WDC_WD15EARS-00MVWB0_WD-WMAZA3318333 rdevNumErrors.7=0 rdevLastIO.7=0 rdevSpinupGroup.7=0 diskNumber.8=8 diskName.8=md8 diskSize.8=976762552 diskState.8=7 diskId.8=ST31000333AS_5TE0E0NZ rdevNumber.8=8 rdevStatus.8=DISK_OK rdevName.8=sdc rdevSize.8=976762552 rdevId.8=ST31000333AS_5TE0E0NZ rdevNumErrors.8=0 rdevLastIO.8=0 rdevSpinupGroup.8=0 diskNumber.9=9 diskName.9=md9 diskSize.9=976762552 diskState.9=7 diskId.9=ST31000333AS_9TE1BTC3 rdevNumber.9=9 rdevStatus.9=DISK_OK rdevName.9=sde rdevSize.9=976762552 rdevId.9=ST31000333AS_9TE1BTC3 rdevNumErrors.9=0 rdevLastIO.9=0 rdevSpinupGroup.9=0 diskNumber.10=10 diskName.10=md10 diskSize.10=976762552 diskState.10=7 diskId.10=ST31000528AS_9VP03ESG rdevNumber.10=10 rdevStatus.10=DISK_OK rdevName.10=sdk rdevSize.10=976762552 rdevId.10=ST31000528AS_9VP03ESG rdevNumErrors.10=0 rdevLastIO.10=0 rdevSpinupGroup.10=0 diskNumber.11=11 diskName.11= diskSize.11=0 diskState.11=0 diskId.11= rdevNumber.11=11 rdevStatus.11=DISK_NP rdevName.11= rdevSize.11=0 rdevId.11= rdevNumErrors.11=0 rdevLastIO.11=0 rdevSpinupGroup.11=0 diskNumber.12=12 diskName.12= diskSize.12=0 diskState.12=0 diskId.12= rdevNumber.12=12 rdevStatus.12=DISK_NP rdevName.12= rdevSize.12=0 rdevId.12= rdevNumErrors.12=0 rdevLastIO.12=0 rdevSpinupGroup.12=0 diskNumber.13=13 diskName.13= diskSize.13=0 diskState.13=0 diskId.13= rdevNumber.13=13 rdevStatus.13=DISK_NP rdevName.13= rdevSize.13=0 rdevId.13= rdevNumErrors.13=0 rdevLastIO.13=0 rdevSpinupGroup.13=0 diskNumber.14=14 diskName.14= diskSize.14=0 diskState.14=0 diskId.14= rdevNumber.14=14 rdevStatus.14=DISK_NP rdevName.14= rdevSize.14=0 rdevId.14= rdevNumErrors.14=0 rdevLastIO.14=0 rdevSpinupGroup.14=0 diskNumber.15=15 diskName.15= diskSize.15=0 diskState.15=0 diskId.15= rdevNumber.15=15 rdevStatus.15=DISK_NP rdevName.15= rdevSize.15=0 rdevId.15= rdevNumErrors.15=0 rdevLastIO.15=0 rdevSpinupGroup.15=0 diskNumber.16=16 diskName.16= diskSize.16=0 diskState.16=0 diskId.16= rdevNumber.16=16 rdevStatus.16=DISK_NP rdevName.16= rdevSize.16=0 rdevId.16= rdevNumErrors.16=0 rdevLastIO.16=0 rdevSpinupGroup.16=0 diskNumber.17=17 diskName.17= diskSize.17=0 diskState.17=0 diskId.17= rdevNumber.17=17 rdevStatus.17=DISK_NP rdevName.17= rdevSize.17=0 rdevId.17= rdevNumErrors.17=0 rdevLastIO.17=0 rdevSpinupGroup.17=0 diskNumber.18=18 diskName.18= diskSize.18=0 diskState.18=0 diskId.18= rdevNumber.18=18 rdevStatus.18=DISK_NP rdevName.18= rdevSize.18=0 rdevId.18= rdevNumErrors.18=0 rdevLastIO.18=0 rdevSpinupGroup.18=0 diskNumber.19=19 diskName.19= diskSize.19=0 diskState.19=0 diskId.19= rdevNumber.19=19 rdevStatus.19=DISK_NP rdevName.19= rdevSize.19=0 rdevId.19= rdevNumErrors.19=0 rdevLastIO.19=0 rdevSpinupGroup.19=0 diskNumber.20=20 diskName.20= diskSize.20=0 diskState.20=0 diskId.20= rdevNumber.20=20 rdevStatus.20=DISK_NP rdevName.20= rdevSize.20=0 rdevId.20= rdevNumErrors.20=0 rdevLastIO.20=0 rdevSpinupGroup.20=0 diskNumber.21=21 diskName.21= diskSize.21=0 diskState.21=0 diskId.21= rdevNumber.21=21 rdevStatus.21=DISK_NP rdevName.21= rdevSize.21=0 rdevId.21= rdevNumErrors.21=0 rdevLastIO.21=0 rdevSpinupGroup.21=0 diskNumber.22=22 diskName.22= diskSize.22=0 diskState.22=0 diskId.22= rdevNumber.22=22 rdevStatus.22=DISK_NP rdevName.22= rdevSize.22=0 rdevId.22= rdevNumErrors.22=0 rdevLastIO.22=0 rdevSpinupGroup.22=0 diskNumber.23=23 diskName.23= diskSize.23=0 diskState.23=0 diskId.23= rdevNumber.23=23 rdevStatus.23=DISK_NP rdevName.23= rdevSize.23=0 rdevId.23= rdevNumErrors.23=0 rdevLastIO.23=0 rdevSpinupGroup.23=0 Quote Link to comment
TheWombat Posted January 23, 2014 Share Posted January 23, 2014 Agree on 64 bit only even if it means I have to wait for plex and apc Quote Link to comment
dalben Posted January 23, 2014 Share Posted January 23, 2014 As perhaps one of the earlier users to ever dabble with 64bit unRAID and having been running my own multilib versions of it to run 64bit and 32bit since 2010, here's my take on the situation. For the love of all things, keep unRAID 6.0 64bit only. Do not even delve into the world that is multi-lib. Can't argue with experience. Quote Link to comment
pras1011 Posted January 23, 2014 Share Posted January 23, 2014 Can people please stop typing crap and actually talk about the testing outcomes of the 6.0!!! Sent from my GT-I9505 using Tapatalk Quote Link to comment
tallnerd1985 Posted January 23, 2014 Share Posted January 23, 2014 Can we get 64-bit section on the forums or a OS 6.x section? Quote Link to comment
PeterB Posted January 23, 2014 Share Posted January 23, 2014 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. That works fine where there are maintained Slackware packages. As far as I'm aware, no packages are maintained for apcupsd, dovecot, mpop etc. The binaries for these have to be rebuilt for the 64-bit environment. I already have the sources for these, and I know that it is possible to cross-compile/link, but I'd rather wait to build on the target environment in order to minimise the risk of incompatibilities. If I have time later, I may start having a go at these by booting a one disk unRAID 6 on other hardware. Quote Link to comment
Harpz Posted January 23, 2014 Share Posted January 23, 2014 Lol 6.0 came out last night before i went to bed, i get up this morning and go to look at the thread to see if there were any major issues with the release and i have to troll though 5 pages of crap about plugins, screw plugins hows the unraid 6.0 base function. Take it to the user customization forum guys not this thread, i couldn't give a shit about if plugin x or y works i want to know if there are any show stopping bugs in the new release. Just my 2 pence. Quote Link to comment
garycase Posted January 23, 2014 Share Posted January 23, 2014 Working perfectly on an old test system I have. Copied 50TB of data to & from; did a parity check; streamed a movie while doing the parity check; etc. This on an ancient Prescott P4 (earlier P4's don't support 64 bit). System has 2 250GB drives at the moment -- both SATA. I attempted to add a 3rd 250GB IDE drive, but the system won't see it. Will "bang" it for a couple days; then try this on a newer system with half a dozen drives and more SATA ports. Edit: Turns out the IDE port was disabled in the BIOS on the old Dell I used for this. Enabled it and it works fine -- system now has 2 SATA drives and an IDE drive working perfectly. Quote Link to comment
bonienl Posted January 23, 2014 Share Posted January 23, 2014 It does not support anymore IDE interfaces (hdX). My cache drive happens to be on IDE and disappeared. Quote Link to comment
nars Posted January 23, 2014 Share Posted January 23, 2014 I liked the idea someone suggested of having an x64 and an i386 extra folder. extrax64 extrai386 or something like that. You mean one usable for 5.x and one for 6.x, right? +1, but to make it simple I would just keep 'extra' as-is for 32bit and use maybe just a simple 'extra64' for 64bit... Also keeping them separate would allow easy setup multiboot 5.x/6.x on same flash, useful for testing at least Make take on the plugin story ... introduce a new extension ".plg64" This would prevent the system to load any 'old' plugins and avoid conflicts, while it also becomes clearer for users in selecting either the 32-bit or 64-bit version of the plugin, and finally for developers it is easier to maintain 'two' versions - as long as it lasts. Couldn't it be easier to maintain one single .plg file (with proper simple script checks added for unraid version, to install the right packages for it, etc) and just add some xml tag on the plg file specifying compatible unraid versions (if no tag present take it as 5.x compatible only), and when trying to install an incompatible plugin just ignore it...? that would still prevent installing incompatible plg's and make it possible a single .plg file to be maintained, compatible with multiple unraid versions (even thinking on future... yet newer unraid will hopefully eventually come again, based on an yet newer slackware or other distro, etc that would require yet different packages again even if also x64...) I mean something like firefox plugins minver/maxver compatibility check or similar... Anyway I do also surely agree with some way of .plg separation, even if just file extension based. Quote Link to comment
garycase Posted January 23, 2014 Share Posted January 23, 2014 It does not support anymore IDE interfaces (hdX). Just found that out when I tried to add the 3rd drive I've been "banging" it with (a) just one 250GB SATA (wrote a bunch of data to it; then read it all back); then (b) added a SATA parity drive and did a parity sync followed by a check ... streaming a movie during the check; then I wrote my note above when I shut down to add a 3rd drive to the IDE port ... and just now tried to add that drive to the system -- and it doesn't see it !! I've edited my note to remove the reference to the 3rd drive Edit: See my earlier note -- the IDE drive works just fine Quote Link to comment
limetech Posted January 23, 2014 Author Share Posted January 23, 2014 It does not support anymore IDE interfaces (hdX). My cache drive happens to be on IDE and disappeared. I'll look into that... Quote Link to comment
dave_m Posted January 23, 2014 Share Posted January 23, 2014 On the shares page, the free space is including the cache drive, if that share has files on the cache drive. So in my case, several shares appear to have 2TB more free than they really do. Quote Link to comment
limetech Posted January 23, 2014 Author Share Posted January 23, 2014 On the shares page, the free space is including the cache drive, if that share has files on the cache drive. So in my case, several shares appear to have 2TB more free than they really do. Right that's kind of a longstanding issue (feature?). Quote Link to comment
ironicbadger Posted January 23, 2014 Share Posted January 23, 2014 Tom, great work. Really glad to see this in the wild and will load this up when I get home from Uni (totally not reading this in a lecture). Once I've had a good play I'll endeavour to get some guides out for VMs, but really until kernel 3.12 is included it might not be worth the effort for anything over and above a 'plugin VM'. Fork thread for plugin v6 specific discussion http://lime-technology.com/forum/index.php?board=6.0 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.