unRAID Server Release 6.0-beta14b-x86_64 Available


limetech

Recommended Posts

Although I know everyone is anxious to get their hands on the latest beta, please take appropriate precautions. As a rule of thumb, the longer between betas the more changes have been made to unRaid. And we know the kernel version has changed by a whole version number.

 

You might give a bit of time for others to test the waters before jumping in!

 

I suggest

Link to comment
  • Replies 476
  • Created
  • Last Reply

Top Posters In This Topic

Although I know everyone is anxious to get their hands on the latest beta, please take appropriate precautions. As a rule of thumb, the longer between betas the more changes have been made to unRaid. And we know the kernel version has changed by a whole version number.

 

You might give a bit of time for others to test the waters before jumping in!

 

I suggest

 

are you saying wait till tommorow for the -a release or friday for the -b release ?

Link to comment

Although I know everyone is anxious to get their hands on the latest beta, please take appropriate precautions. As a rule of thumb, the longer between betas the more changes have been made to unRaid. And we know the kernel version has changed by a whole version number.

 

You might give a bit of time for others to test the waters before jumping in!

 

I suggest

 

are you saying wait till tommorow for the -a release or friday for the -b release ?

 

OK, that actually did make me laugh out loud! Rapier wit...

Link to comment
I know there are some crazies out there ( you know who you are ;) ) who get very passionate about power savings but there is just so many other more important things in life to worry about IMHO.

 

I presume that there is also a commensurate reduction in heat output when the cpu 'throttles'.  Running in ambient temperatures in the mid 30s (Celsius), this is important to me.

Link to comment

... Tom is packaging up the final release ...

 

I presume "final release" in this context means Beta 15 ... right?

 

Yes.

 

Jonp quick question regards imminent release, will we still need the separate libvirt plugin or will the new shiny VM manager now include it?

 

You will need to remove dmacias plugin.  No plugins will be necessary anymore for this.  Leaving the previous plugins in place will cause problems.  I will make sure we list this in the announcement post.

 

how about re-importing existing VM's ?

 

Even better, you won't need to "re-import" anything.  Your existing VMs will work as-is with the new manager.

Link to comment

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

Link to comment

... We're looking into all this and testing thoroughly ...

 

Good thing "today" has a valid definition that means "... the present time or age "  :)

... so anytime in the next week or so will easily meet that definition  8) 8)

 

... In all seriousness, take your time and get it right => that's FAR better than just putting it out with the bug you found tonight.

 

Link to comment

 

You will need to remove dmacias plugin.  No plugins will be necessary anymore for this.  Leaving the previous plugins in place will cause problems.  I will make sure we list this in the announcement post.

 

I figured that might be the case, please do emphasise this in the release and  announcement notes, thanks jonp

Link to comment

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

Link to comment

 

 

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

We don't upgrade the kernel without just cause. 

Link to comment

 

 

no Xen update?

 

No.  Not for beta 15.

 

Also, just a quick update.  We found a bug as we were going through final release testing that is holding this up right now.  I'll spare all the details, but in short, it has to do with the fact that the btrfs progs for 3.19.1 are not 100% compatible with the Linux 4.0 kernel.  We are looking to roll back to the previous kernel, but to do so, we would need to manually apply a patch that is slated for inclusion in the 3.19.5 kernel (which is not yet released).  We're looking into all this and testing thoroughly.

 

You guys are joking, right? If you keep changing kernels like we change underwear, there will never be a stable release. Think long and hard about the bugs that do indicate kernel updates are important enough to effectively postpone the whole project to the end of time. Bet you the 4.0 or even 3.19.5 kernel will introduce yet another little gotcha, and you will be back where you started.

 

Get a stable release out already, even if there is going to be a couple of known issues.

 

We don't upgrade the kernel without just cause.

 

Causes you have not disclosed, since you don't have a bug tracker. But is seems a lot of hinges on BTRFS and features of that filesystem that were not stable when you started V6 development, and it seems still are not stable. I know you have promised a cache-pool as a feature, but V6 would be a fine product without that feature. Stabilize it, then take the next step when BTRFS is ready for prime time.

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.