unRAID Server Release 6.0-beta3-x86_64 Available


limetech

Recommended Posts

so...unless im missing something, so far 6.0 b3 has no known issues regarding the basic functions of unraid itself, yeah?,

 

A couple of people reported problems in b2 with using NFS.  As far as I understand, no attempt has been made to characterise or address these.  Is anyone who has installed b3 using NFS heavily and, of so, have you encountered any problems?

Link to comment
  • Replies 661
  • Created
  • Last Reply

Top Posters In This Topic

I am in communication with WeeboTech to get powerdown updated.  I am experiencing a lockup when powering down after mounting a drive with SNAP.

 

That is one of several circumstances in which the filesystems will hold up the shutdown processing.  Powerdown overcomes some, but not all of them.  If Weebo knows how to improve the powerdown script to accommodate the circumstances which are currently unaddressed, that would be great.  However, be assured that powerdown works as well with the v6 betas as it does with v6 releases.

 

I suspect that no unRAID user suffers as many power outages as I do, and I cannot remember how long it is since I suffered an unsafe shutdown - certainly many months.

Link to comment

I am in communication with WeeboTech to get powerdown updated.  I am experiencing a lockup when powering down after mounting a drive with SNAP.

 

That is one of several circumstances in which the filesystems will hold up the shutdown processing.  Powerdown overcomes some, but not all of them.  If Weebo knows how to improve the powerdown script to accommodate the circumstances which are currently unaddressed, that would be great.  However, be assured that powerdown works as well with the v6 betas as it does with v6 releases.

 

I suspect that no unRAID user suffers as many power outages as I do, and I cannot remember how long it is since I suffered an unsafe shutdown - certainly many months.

 

I have revised the powerdown package.  There are certain circumstances where powerdown would hang up.  It depends on the plugins you have installed and how cleanly they would shut themselves down when the array was stopped.  I could actually cause a hang up with a bare metal unRAID v6 and then mounting a drive outside the array.

Link to comment
I have revised the powerdown package.

 

Great!  Is this available somewhere? - I need to reference the updated version from my apcupsd plugin.

 

There are certain circumstances where powerdown would hang up.  It depends on the plugins you have installed and how cleanly they would shut themselves down when the array was stopped.  I could actually cause a hang up with a bare metal unRAID v6 and then mounting a drive outside the array.

 

Exactly as it would in V5, or even V4.  Have you tried making a telnet connection to the server, setting your default directory to one of the disk shares, and then attempting to shutdown?

Link to comment

I have revised the powerdown package.

 

Great!  Is this available somewhere? - I need to reference the updated version from my apcupsd plugin.

 

 

I would like some beta testing done first and then I will put it up on WeeboTech's Google Code repository.  Right now I'm trying to catch his repository up with some updated versions scattered about the forum.

 

It' available here if you'd like to beta test it.  http://lime-technology.com/forum/index.php?topic=31735.0

Link to comment

Found the NFS problem, fixed in -beta4.

 

Here is a workaround.  First, in the webGui select the disk/share you are exporting via NFS.  Next change the security mode to "Private".  Then in the Rule field enter this:

 

*(sec=sys,rw,insecure,anongid=100,anonuid=99,all_squash)

 

Click Apply.  Your NFS client mounts should work now.

Link to comment

Memory Ballooning is not turned on. Since you have tons of memory throw more at Dom0 cause with cache directiores it needs it.

How do we do that?  I have plenty of RAM on my unRAID machine so am quite happy to make more available for unRAID itself    Is it simply a case of altering the line in syslinux.cfg to control the amount of memory allocated to Dom0?  I was assuming that the current entry limits unRAID to 2GB - is that a correct interpretation of that entry?

Link to comment

Memory Ballooning is not turned on. Since you have tons of memory throw more at Dom0 cause with cache directiores it needs it.

How do we do that?  I have plenty of RAM on my unRAID machine so am quite happy to make more available for unRAID itself    Is it simply a case of altering the line in syslinux.cfg to control the amount of memory allocated to Dom0?  I was assuming that the current entry limits unRAID to 2GB - is that a correct interpretation of that entry?

 

Yes - change it to read: dom0_mem=4194304

 

root@NAS:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  4096     8     r-----      26.6

 

 

Link to comment

 

Would love nano as well but I guess that's an older issue.

 

Peter

 

Would love to see nano also.

 

I would like to see nano but not by default. Since it is tiny but also has a dependency it is a perfect candidate for any plugin system to be used as a demo or easy intro into installing a plugin for new users.

Link to comment

Had a hard server crash tonight, see below, will post more as requested/needed. It did come back up after i pulled the power.

 

I would turn off cache directories for starters and element that from the equation.

 

Tom,

 

A few recommendations...

 

1. Do not assign a set amount of memory to Dom0 and make syslinux.cfg look like this:

 

label Xen 4.3.1 / unRAID OS
  kernel /syslinux/mboot.c32
  append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot
label Xen 4.3.1 / unRAID OS Safe Mode (no plugins)
  kernel /syslinux/mboot.c32
  append /xen  --- /bzimage --- /bzroot unraidsafemode

 

Since a lot of people use a Cache Directories (a memory hog), let Dom0 get assigned all the memory. That way if memory runs low, the VM has the issues / crash (as a previous use a few posts up experienced) and not unRAID.

 

Even with all the memory assigned to Dom0 (unRAID), the VMs can still use / grab it but unRAID has the priority and will take back what it needs.

 

Note - By default, this how most Linux Distros handle it.

 

2. You will probably want to dedicate at least one CPU to Dom0 by default.

 

label Xen 4.3.1 / unRAID OS
  kernel /syslinux/mboot.c32
  append /xen dom0_max_vcpus=1 dom0_vcpus_pin --- /bzimage --- /bzroot
label Xen 4.3.1 / unRAID OS Safe Mode (no plugins)
  kernel /syslinux/mboot.c32
  append /xen --- /bzimage --- /bzroot unraidsafemode

 

  a) Dedicating a CPU core only for dom0 makes sure dom0 always has free CPU time to process the IO requests for the domUs.

 

  b) When dom0 has a dedicated core there are less CPU context switches to do, giving better performance.

 

  c) Assigning more than one isn't going to make Dom0, write files faster to unRAID or make the VMs run any faster.

 

3. Cosmetics - I would put the version number of Xen in syslinux.

 

As you know unRAID 4.3.2 and 4.4 are both due out this month around the same time. Depending on where we are at in the beta process and if / when you are comfortable updating to either 4.3.2 or 4.4 it will make supporting the users easier if they (and those of us supporting them) see / know which version of Xen they are running (assuming you eventually update to 4.3.2 or 4.4 through the beta process).

 

4. Make the following changes in /etc/default/xendomains:

 

XENDOMAINS_SAVE=

 

XENDOMAINS_RESTORE=false

 

XENDOMAINS_AUTO=/etc/xen/auto <--- Symbolic link or point this to a directory you create on the unRAID Flash Drive.

 

If we Symbolic link or copy our VM cfg files into the XENDOMAINS_AUTO folder the VMs will autostart on boot (there is an automatic delay from each VM starting so they do not start all at once).

 

 

 

Link to comment

I would like to see nano but not by default. Since it is tiny but also has a dependency it is a perfect candidate for any plugin system to be used as a demo or easy intro into installing a plugin for new users.

 

I might have missed it but I hope that is sarcasm.

 

Not sarcasm.

Link to comment

Not sarcasm.

 

With all the guides that need to be written around Xen / KVM, all manual editing of cfg files for VMs that needs to be done by users (many novices) and due to the 10 or so people who have already had issues with DOS characters in their cfg files... It makes life more difficult on people who write guides, the users with little to no Linux experience and those of us supporting the novices.

 

I am posting a XBMC VM Appliance later today and I will just include a bzroot with nano in it (and the changes listed a few posts up).

 

That way users can follow my guide (which has some nano commands in it) and I don't have to wait for someone to write a plugin to install nano, explain to people how to get the plugin, install it, etc. or explain vim or mcedit.

Link to comment

We are doing something wrong if we get into stable and require users to use SSH and nano for basic new feature operation. That would be a fundamental departure of previous design tenants as far as I am concerned.

 

Nano is "A" solution to the DOS char problem etc but it isnt the only one and IMHO not the right one either. A proper text editor (of which there are many) and presenting the configs via the config directory is still the correct approach.

 

I am not saying I can see the future and that is the way it will be done, there could be gotchas, but we should not accept a creeping design tenant change "just because".

 

But we are in beta for a reason to iron all these things out :)

Link to comment

We are doing something wrong if we get into stable and require users to use SSH and nano for basic new feature operation. That would be a fundamental departure of previous design tenants as far as I am concerned.

 

What is your recommendation?

 

We could install a Linux Desktop and use the libvirt GUI.

 

We could get some users focused on writing a WebGUI or plugin.

 

I am not a programmer or else I would lead this effort. Are you one? If so, would you be willing to give up some of your free time to help?

 

Nano is "A" solution to the DOS char problem etc but it isnt the only one and IMHO not the right one either. A proper text editor (of which there are many) and presenting the configs via the config directory is still the correct approach.

 

That might be how you roll but almost ANY guide that a user is going to see on the web for Ubuntu, Arch, CentOS, Fedora, Linux Mint, Debian, OpenSUSE, etc. where the users are asked to edit / make changes to something... 95% of them use nano as the editor of choice.

 

I am not saying I can see the future and that is the way it will be done, there could be gotchas, but we should not accept a creeping design tenant change "just because".

 

nano is also installed by default in almost every Linux Distro I have ever tried in the last 5+ years so I think it's safe to consider it well tested and proven to be reliable.

 

Since a nano plugin with a guide on how to install it doesn't exist... No worries.

 

In the VM Appliances I post here, I will just include a bzroot with nano installed (plus the other changes I suggested earlier). This will make it easier for the users and people like me who have to write guides / support users where editing of files is going to happen (until a WebGUI or plugin is written).

Link to comment

 

In the VM Appliances I post here, I will just include a bzroot with nano installed (plus the other changes I suggested earlier). This will make it easier for the users and people like me who have to write guides / support users where editing of files is going to happen (until a WebGUI or plugin is written).

 

Thant was my thinking with the request - a tool to use during this beta period to help with setup, guides etc. It's a PAIN to be at unRAID CL doing stuff and then have to move off to another environment to edit a text file.

 

 

Link to comment

I probably shouldn't be jumping into this, so just consider this the forum equivalent of me poking my head in the room and then running for my life ... or consider it an honest question of curiosity:

 

Is nano that much better than the editor already included in Midnight Commander?

 

I have found mcedit caused my a few headaches with files this week.

 

Nano just works and is so tiny. Can't believe the intensity of debate over nano!

 

Sent from my Nexus 5 using Tapatalk

 

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.