unRAID Server Release 5.0-rc14 Available

[garycase]

 

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  ].

 

[Dephcon]

FYI, the banner link to rc14 goes to the rc13 page.

[johnodon]

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

[eek]

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]

[Dephcon]

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?

[garycase]

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.

 

[eek]

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.

[limetech]

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.

[garycase]

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.

 

[garycase]

... but of course it's better if it's resolved so that's not necessary 

[limetech]

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.

[garycase]

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.

 

[Joe L.]

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.

[johnodon]

So far it seems like this kernel has caused the least amount of grief.  My vote is to stay with it.

 

John

[garycase]

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 

[garycase]

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.

 

[garycase]

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.

 

[garycase]

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.

 

[Frank1940]

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. 

[Pauven]

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

 

 

[mejutty]

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??

 

[WeeboTech]

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?

 

[aaronwt]

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.

[WeeboTech]

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.

 

 

 

 

 

[madburg]

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.