garycase Posted June 12, 2013 Share Posted June 12, 2013 Just buy a Plus license and you'll be at a "sensible level" ... and when final is out you'll be able to use up to 8 disks in whatever assignments you want I've already got a Plus key I need either the possibly new mystery one or a pro key but I really don't want to fork out $59 this month. Remember that the $59 allows TWO key upgrades ... so it also means you can get a 2nd Pro key for the price of a Plus key [since you'll already have an "extra" upgrade ]. Quote Link to comment
Dephcon Posted June 12, 2013 Share Posted June 12, 2013 FYI, the banner link to rc14 goes to the rc13 page. Quote Link to comment
johnodon Posted June 12, 2013 Share Posted June 12, 2013 Updated to RC14 (using the unlimited RAM option). Stopped array and rebooted 3 or 4 times...no hangs/crashes. Running a parity check now. Total size: 2 TB Current position: 53.52 GB (3%) Estimated speed: 102.18 MB/sec Estimated finish: 318 minutes Sync errors corrected: 0 I won't know if OpenELEC plays nicely with the NFS shares until I get home later but I don't expect any issues. John Just fired up OpenELEC. NFS shares working as expected. John Quote Link to comment
eek Posted June 12, 2013 Share Posted June 12, 2013 For reference the machine is a virtual machine (using esxi) with 1gb of ram allocated to it. Right its definitely a bug (and Thanks Tom for the emails). The system is a esxi virtual machine with 1gb of ram passing through an M1015 card for all the drives using the new syslinux.cfg if I choose the top option (unraid no memory limit) RC14 loads fine. If however I use the default unraid 4gb limit option RC14 dies with the attached screenshot. This has occurred 3 times now so something is not 100% right. [/img] Quote Link to comment
Dephcon Posted June 12, 2013 Share Posted June 12, 2013 Is it possible to introduce some logic where it checks how much memory the system has and boots normally if its 4GB or less and limits to 4GB if it's more than 4GB? Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 Is it possible to introduce some logic where it checks how much memory the system has and boots normally if its 4GB or less and limits to 4GB if it's more than 4GB? I think that's what the 4GB parameter does. But in any event, you can simply move the "default" line to one of the other options and it won't be invoked. Quote Link to comment
eek Posted June 12, 2013 Share Posted June 12, 2013 Is it possible to introduce some logic where it checks how much memory the system has and boots normally if its 4GB or less and limits to 4GB if it's more than 4GB? I think that's what the 4GB parameter does. But in any event, you can simply move the "default" line to one of the other options and it won't be invoked. This is all fine if the 4gb parameter works the way you claim it does but in my system it doesn't. Now it may be that my setup is really non standard (unraid runs as a virtual machine with 1gb of ram while the machine as a whole has 16gb mostly allocated to the other vms) but its a bug. It may be unique to me, it may be unique to just those of us running unraid on an esxi machine but it is an issue that we need to identify because if the first attempt to run unraid generates a kernel panic people aren't going to try again. Quote Link to comment
limetech Posted June 12, 2013 Author Share Posted June 12, 2013 Is it possible to introduce some logic where it checks how much memory the system has and boots normally if its 4GB or less and limits to 4GB if it's more than 4GB? I think that's what the 4GB parameter does. But in any event, you can simply move the "default" line to one of the other options and it won't be invoked. Damn, right, no good deed goes unpunished. This is why I don't like "workarounds". I'll look into a non-PAE kernel to achieve this. Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 Is it possible to introduce some logic where it checks how much memory the system has and boots normally if its 4GB or less and limits to 4GB if it's more than 4GB? I think that's what the 4GB parameter does. But in any event, you can simply move the "default" line to one of the other options and it won't be invoked. This is all fine if the 4gb parameter works the way you claim it does but in my system it doesn't. Now it may be that my setup is really non standard (unraid runs as a virtual machine with 1gb of ram while the machine as a whole has 16gb mostly allocated to the other vms) but its a bug. It may be unique to me, it may be unique to just those of us running unraid on an esxi machine but it is an issue that we need to identify because if the first attempt to run unraid generates a kernel panic people aren't going to try again. Just remove these 4 lines from the new syslinux.cfg BEFORE you try to boot. label unRAID OS (4G RAM limit) menu default kernel bzimage append initrd=bzroot mem=4095M and add the "menu default" to the first option. Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 ... but of course it's better if it's resolved so that's not necessary Quote Link to comment
limetech Posted June 12, 2013 Author Share Posted June 12, 2013 A problem with a non-PAE kernel is that you only get 3GB of RAM, not 4GB. This is because the top 1GB of address space is used for memory-mapped devices. Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 A problem with a non-PAE kernel is that you only get 3GB of RAM, not 4GB. This is because the top 1GB of address space is used for memory-mapped devices. I'd stay with the PAE kernel ==> you have enough issues to deal with already without trying to have multiple kernel options. It would be very simple to simply include two versions of syslinux.cfg with the download -- perhaps syslinux.cfg and syslinux.4gb -- with a note to rename the "4gb" version and copy it to the flash drive if you have > 4GB of RAM and have the slow write problem. This would eliminate the need to have console access to select the 4GB limit and would also make it automatic on reboot for those with the issue, while working normally for everyone else. Quote Link to comment
Joe L. Posted June 12, 2013 Share Posted June 12, 2013 A problem with a non-PAE kernel is that you only get 3GB of RAM, not 4GB. This is because the top 1GB of address space is used for memory-mapped devices. I'd just leave the "mem=" line off the default. (but put instructions on how to make it the default), or add a script that can perform the edit to syslinux.cfg once booted. Joe L. Quote Link to comment
johnodon Posted June 12, 2013 Share Posted June 12, 2013 So far it seems like this kernel has caused the least amount of grief. My vote is to stay with it. John Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 So far it seems like this kernel has caused the least amount of grief. My vote is to stay with it. John Agree. I'd just include two versions of syslinux.cfg (as I noted above) and leave well enough alone Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 I'd stay with the PAE kernel ==> you have enough issues to deal with already without trying to have multiple kernel options. Hopefully, there won't be multiple kernel options. But those issues he has to deal with seem to come from PAE. And fooling around with boot options is just piling more mess on top of a mess. I don't think there needs to be any real "fooling around with boot options" ==> if I understand the key problem, it's just a matter of whether or not you need the 4GB constraint. MOST people do not ... but those that have a motherboard that results in slow writes with > 4GB of RAM do. Seems simple enough for those folks to (a) rename one file, and (b) copy it to the flash drive. Everyone else would just use the default syslinux.cfg. Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 Still easily resolved with the the alternative syslinux.cfg versions => just change the directions to always use the 4GB version if you have > 4GB of RAM. Quote Link to comment
garycase Posted June 12, 2013 Share Posted June 12, 2013 No need to know it -- just use the 4GB switch if you have > 4GB ... period. Knowledgeable folks who want to experiment a bit without it can do so; but for everyone else, it limits the RAM to 4GB and avoids any of the issues caused by more RAM. Certainly seems better than trying to deal with multiple kernels. Quote Link to comment
Frank1940 Posted June 12, 2013 Share Posted June 12, 2013 Still easily resolved with the the alternative syslinux.cfg versions => just change the directions to always use the 4GB version if you have > 4GB of RAM. Oh, but that is exactly the problem: You will not know that it's the RAM that's causing whatever hairy problem you're dealing with at the time. I say the easy way is to change the upgrade instructions for rc14. If you don't want the 4GB restriction to apply, the instructions should say NOT to copy the the new syslinux.cfg that is in rc14. If you do want the " append initrd=bzroot mem=4095M" parameter used to restrict the memory to 4GB, then the new syslinux.cfg should be copied over. Quote Link to comment
Pauven Posted June 12, 2013 Share Posted June 12, 2013 No need to know it -- just use the 4GB switch if you have > 4GB ... period. Knowledgeable folks who want to experiment a bit without it can do so; but for everyone else, it limits the RAM to 4GB and avoids any of the issues caused by more RAM. Certainly seems better than trying to deal with multiple kernels. I'd like to re-iterate my own vote on this matter, which I shared in the 'Your Chance to Chime In' thread (my whole post is here: http://lime-technology.com/forum/index.php?topic=25306.msg221114#msg221114) 2) Release 5.0.0-x32-Final. Include in the release notes that this 32-bit version does not support memory configurations greater than 4GB, which have been noted to sometimes result in performance issues. Also list any hardware platforms that may have performance issues which may or may not be related to the amount of installed RAM. Users are certainly entitled to run unRAID on any hardware configuration they prefer, but should be informed that choosing to run certain problematic hardware or excessive memory limits their support. Of course, any currently 'Known Issues' should be documented in the release notes. Basically, no one should be installing more than 4GB on a 32-bit OS, and unRAID itself really doesn't use it or need it. Users installing additional memory are either doing so mistakenly, or are running additional add-ons and/or servers in the same OS space - in which case they do not represent the 'supported unRAID install'. Attempts to workaround this 32-bit OS limitation are continuing to delay 5.0 Final. And the sooner we get 5.0 Final out the door, the sooner Tom can focus on 5.1 64-bit, and completely eliminate these memory related issues. And I really, really hope that all the users that need more than 4GB understand that by accepting this sacrifice now, you will reap the rewards of 64-bit unRAID sooner. -Paul Quote Link to comment
mejutty Posted June 12, 2013 Share Posted June 12, 2013 I just noticed this on my RC14 running in esxi with 4096Mb of ram given to unraid. When I boot with the non forced memry option I get this total used free shared buffers cached Mem: 4154332 268148 3886184 0 3952 209160 Low: 873492 49784 823708 High: 3280840 218364 3062476 -/+ buffers/cache: 55036 4099296 Swap: 0 0 0 when I boot with the default 4gb option I get total used free shared buffers cached Mem: 3113948 263120 2850828 0 3952 209160 Low: 881684 44756 836928 High: 2232264 218364 2013900 -/+ buffers/cache: 50008 3063940 Swap: 0 0 0 It's like it forces it to 3gb instead of 4gb. I saw a post that says if you use a non-pae kernel you would be limited to 3gb so why am I being limited?? Quote Link to comment
WeeboTech Posted June 12, 2013 Share Posted June 12, 2013 Is it possible to introduce some logic where it checks how much memory the system has and boots normally if its 4GB or less and limits to 4GB if it's more than 4GB? I think that's what the 4GB parameter does. But in any event, you can simply move the "default" line to one of the other options and it won't be invoked. This is all fine if the 4gb parameter works the way you claim it does but in my system it doesn't. Now it may be that my setup is really non standard (unraid runs as a virtual machine with 1gb of ram while the machine as a whole has 16gb mostly allocated to the other vms) but its a bug. It may be unique to me, it may be unique to just those of us running unraid on an esxi machine but it is an issue that we need to identify because if the first attempt to run unraid generates a kernel panic people aren't going to try again. Just remove these 4 lines from the new syslinux.cfg BEFORE you try to boot. label unRAID OS (4G RAM limit) menu default kernel bzimage append initrd=bzroot mem=4095M and add the "menu default" to the first option. Actually all that has to be done is move the menu default line to the other section. Tom, is the next rc going to have two kernels, or just one without PAE? Quote Link to comment
aaronwt Posted June 12, 2013 Share Posted June 12, 2013 I tried out rc14 on my unRAID1 setup. I replaced the three files but it got stuck partway through the boot. Something about losing a connection which I guess is my external enclosures. It never got to the point where it recognized the 17 drives in my external, port multiplier, enclosures. I tried a second time with the same results. So I copied the three files from rc12a back onto the flash drive and it booted normally. I have no idea what the issue was. I'll need to try it on my second unRAID setup tomorrow, which only has eight drives in external enclosures, to see if it has a similar issue. Quote Link to comment
WeeboTech Posted June 12, 2013 Share Posted June 12, 2013 under ESX When I boot with mem=4095M and 1GB the kernel crashes. When I boot with mem=4095M and 1.2GB the kernel crashes. When I boot with mem=4095M and 1.3GB the kernel crashes. When I boot with mem=4095M and 2GB the system comes up, however I would expect it to crash at some point since we've told linux that you have more memory then you really have. When I boot with 1GB of memory without the mem= parameter the kernel comes up. Quote Link to comment
madburg Posted June 12, 2013 Share Posted June 12, 2013 Based on what JoeL stated in the RC13 thread that the default powerdown script provided by unRAID is dependent on emhttp running, which strengths that the oom code needs to be added inorder to lower the chance that emhttp is killed. Has anyone had the chance to see if it has been added in RC (e.g. Go script, rc.local, etc...)? If you all got hit by a bus tomorrow I would like to know that unRaid can take care of itself without add-ons I don't use. 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.