unRAID Server Release 4.5.4 Available

[purko]

...so [red]I took the flash drive from the tower[/red] and...

You shouldn't have done that!  

 

Your flash drive is exported as share, so you could have done the upgrade over the network.  Every time you unplug the flash drive fom the server you risk damaging something.  What likely happened is that you didn't "safely" eject the flash drive from the computer you plugged it in, which corrupted its filesystem.  Put the flash disk in a windows computer and run chkdsk on it to check the filesystem.  Then copy the new bzimage/bzroot to it again.  This time use "safe eject" before unplugging it.

 

[Calvin]

I suppose I was not clear.  Yes, it know its a share and yes that is how I copied the files over to it over the network.  I've upgraded a couple of time since I bought the system.  I only took the thumb drive out to restore the original files when the system would no longer boot after the upgrade.  This was the first time I've ever unplugged it since I bought it.

 

After I restored the files, it booted fine.  There is nothing wrong with the flash drive itself.

[prostuff1]

I suppose I was not clear.  Yes, it know its a share and yes that is how I copied the files over to it over the network.  I've upgraded a couple of time since I bought the system.   I only took the thumb drive out to restore the original files when the system would no longer boot after the upgrade.  This was the first time I've ever unplugged it since I bought it.

 

After I restored the files, it booted fine.  There is nothing wrong with the flash drive itself.

 

You may want to put the 4.5.4 files back on and then re-syslinux the thumb drive.  I know i have had to (and others have mentioned it) do that once to get the server to boot after an upgrade. There is no need to completely wipe the drive, just run syslinux again and you should be good.

[limetech]

Wow.  searching my email shows its a MD-1500/LL that I bought in 2007. 

 

I think the problem is that the system image size has increased beyond a certain value, and the 'ldlinux.sys' file on your flash (from 2007) can not load it correctly.

 

After shutting down your server, you need to remove Flash and plug into your PC.  Now backup the contents of your 'config' directory, e.g., drag to windows desktop.

 

Next download the version of syslinux found here:

http://lime-technology.com/download/cat_view/55-utilities

 

Now follow instructions for installing the latest release found here:

http://lime-technology.com/support/unraid-server-installation

 

Finally, restore the 'config' directory to the flash.

 

If this is unclear, then send me an email: [email protected].

 

 

[limetech]

Hopefully this is finally addressed in unRAID vNext with Samba 3.5

 

Samba 3.5 mar 1 2010 has a fix for

 

BUG 6837: Fix "Too many open files" when trying to access large number of

      files with Windows 7.

 

I believe we are running 3.4.5 with 4.5.4. It would be worth looking to see if there is a patch for bug 6837 that you can install...ot try my suggestion above.

 

 

So when is unraid 4.5.x with Samba3.5 going to be released?

 

B2

 

This is a bit of a quandary.  There are massive changes in Samba between 3.4.x and 3.5.x.  To upgrade to samba 3.5 would ordinarily be done first as a new release 'beta'.

 

Current release is 4.5.4.

 

I am about to release 4.5.5 which has some minor bug fixes, but also increases array width to 21 drives.  I would not feel 'comfortable' incorporating samba 3.5 in this release.

 

To upgrade to samba 3.5, I should release 4.6-beta1.

 

But I would rather release 5.0-beta1, which includes samba 3.5, but is certainly "beta" & should not be used for 'production' servers.

 

What do do, what to do....

[Joe L.]

I vote for "B"   

[bubbaQ]

I vote for "B"   

 

Ditto.

[limetech]

I believe we are running 3.4.5 with 4.5.4. It would be worth looking to see if there is a patch for bug 6837 that you can install...or try my suggestions above.

 

This bug is fixed in Samba 3.4.4

http://www.samba.org/samba/history/samba-3.4.4.html

 

So probably something else going on.

[bubbaQ]

I vote for "B"   

 

Or option c)  closed alpha for 5.0-alpha1 with a few adventurous volunteers.

[BRiT]

Option B) or Option C) if I'm included.

 

Should be really interesting to see what's needed to get a 5.x up and running on a full Slackware 13.1.

[WeeboTech]

Bug fixes and stability should be the priority for reliable customer service.

 

4.6-beta1. I'm on the fence about if 5.0 is nearby.

Which brings the question, How close is 5.0-beta to being a beta testable distribution? 

[Joe L.]

I feel I should clarify.  I said "B" without making it clear how I labeled the choices.

 

I labeled the choices as:

• 
  A.  I am about to release 4.5.5 which has some minor bug fixes, but also increases array width to 21 drives.  I would not feel 'comfortable' incorporating samba 3.5 in this release.
   
  
• B. To upgrade to samba 3.5, I should release 4.6-beta1.
   
  
• C. But I would rather release 5.0-beta1, which includes samba 3.5, but is certainly "beta" & should not be used for 'production' servers.

 

Bugfix should come first...Exactly as WeeboTech described.  Too many complaints about window's disconnects and errors with too many open files to ignore them just for 5.0alpha/beta series.  (As much as I would love to see the 5.0 series)

 

So really,my choice is "A" (Since it is ready) followed shortly thereafter by "B" 

If "B" fixes the SAMBA bug with Windows7, then onward to "C" 

To go directly to "C" would introduce all kinds of other beta-version complications...

 

Joe L.

 

 

[purko]

I labeled the choices as:

• 
  A.  I am about to release 4.5.5 which has some minor bug fixes, but also increases array width to 21 drives.  I would not feel 'comfortable' incorporating samba 3.5 in this release.
   
  
• B. To upgrade to samba 3.5, I should release 4.6-beta1.
   
  
• C. But I would rather release 5.0-beta1, which includes samba 3.5, but is certainly "beta" & should not be used for 'production' servers.

That's not really a "Either-Or" choice here. They can all be done in that order. (#A should be done in any case).

 

There may be a long time before we get from 5-beta to 5-stable. In the mean time minor upgrades to the stable version 4 should continue.

 

[purko]

I am about to release 4.5.5 which has some minor bug fixes, but also increases array width to 21 drives.

...

Probably will be a 4.5.5 to add a couple drivers and some misc fixes.  I can also throw in a few script call-outs as well.

How are the script call-outs coming?

 

[Kaygee]

I vote for D or E, the one with the working and stable LSI drivers or the one with the working and stable LSI driver and a patch for the 88sx6141 driver in the AHCI driver?

 

I am biased though. 

 

I do have some sympathy though, it is very hard to decide what is the right release to do, especially when you have limited resources to work with. I worked for a big S/W house for ten years and it was always difficult. From sales perspective vNext is always going to lure new customer. However your existing customer want Vfixed.

I'd personally do B, providing all is well, release 4.5.5 with Samba 3.5. This gives you a stable working product in the Win7 market.

Then get alpha/beta 5.0x shipping. I'll happily build a test box and exercise a dozen or so different sata controllers in exchange for an alpha build. 

[prostuff1]

IF a 5.0 beta comes out I wil get that sucker up and running on my test server (which still needs unpacked from its box after my move) sooner rather than later.

[NAS]

Hopefully this is finally addressed in unRAID vNext with Samba 3.5

 

Samba 3.5 mar 1 2010 has a fix for

 

BUG 6837: Fix "Too many open files" when trying to access large number of

     files with Windows 7.

 

I believe we are running 3.4.5 with 4.5.4. It would be worth looking to see if there is a patch for bug 6837 that you can install...ot try my suggestion above.

 

 

So when is unraid 4.5.x with Samba3.5 going to be released?

 

B2

 

This is a bit of a quandary.  There are massive changes in Samba between 3.4.x and 3.5.x.  To upgrade to samba 3.5 would ordinarily be done first as a new release 'beta'.

 

Current release is 4.5.4.

 

I am about to release 4.5.5 which has some minor bug fixes, but also increases array width to 21 drives.  I would not feel 'comfortable' incorporating samba 3.5 in this release.

 

To upgrade to samba 3.5, I should release 4.6-beta1.

 

But I would rather release 5.0-beta1, which includes samba 3.5, but is certainly "beta" & should not be used for 'production' servers.

 

What do do, what to do....

 

For what it worth I would vote for every stable being preceded with a beta.

 

The recent trend to release "stables" without any community testing is a BIG step backward IMHO.

 

The last true beta we had was:

 

# 4.5-beta13__ 2009-12-04

 

Since then we have approximately had:

 

# 4.5 final ____ 2009-12-09

# 4.5.1 no official release notes or forum post

# 4.5.3 ______ 2010-03-03

# 4.5.3-TEST _ 2010-05-06

# 4.5.4 ______ 2010-05-15

 

and now there is talk about another stable without any public beta testing.

 

We should learn from the need to even have had a "4.5.3-TEST".

 

Use the community at your disposal. More betas, less stables

 

 

 

 

 

 

 

[WeeboTech]

Since the community speaks out on what it wants, what about adding a poll and get a direct qualifying answer.

[purko]

That poll should have the option "All of the above". 

 

[bubbaQ]

A closed alpha for 5.0 would let some others do some debugging and testing for Tom, without burdening him with support since the closed alpha could be easily limited to people who can swim in the deep end w/o a lifeguard.  That could free him up to concentrate on 4.x until the date when the alpha testers are to report back. 

 

Basically, it would allow some parallel processing instead of purely sequential.

[BRiT]

I'd say everything should be marked as a release candidate X.Y.Z-RC# [eg: 4.5.4-RC1], and then people are free to use it or not. If it's deemed as stable, then a simple external version file gets updated so the package becomes X.Y.Z [eg: 4.5.4] which generates some warm-fuzzy feelings for some. That way no new bzimage/bzroot has to be recreated for a trivial non-functional cosmetic change.

 

Unfortunately it seems emhttp/shfs need to be recompiled or edited with the new version string which requires a new bzimage/bzroot to be created. Even though that change is ever so slight, there's a possibility for issues to creep up then.

[xamindar]

and now there is talk about another stable without any public beta testing.

 

We should learn from the need to even have had a "4.5.3-TEST".

 

Use the community at your disposal. More betas, less stables

I agree, get rid of this Microsoft mentality of releasing what should be a beta version as a full version. It would be nice to see a new version posted as beta for a month or so and then after there is confidence that any critical bugs have been ironed out and fixed, release it as final.

[limetech]

and now there is talk about another stable without any public beta testing.

 

We should learn from the need to even have had a "4.5.3-TEST".

 

Use the community at your disposal. More betas, less stables

I agree, get rid of this Microsoft mentality of releasing what should be a beta version as a full version. It would be nice to see a new version posted as beta for a month or so and then after there is confidence that any critical bugs have been ironed out and fixed, release it as final.

 

Patches to released versions generally are for isolated bug fixes or minor additions such as drivers for different hardware.  In these cases I almost always am working with the person(s) who request the change.

 

4.5.2 was a bit special in that I had to quickly generate a release to support h/w needed to ship in servers.

 

The -TEST version was also a special case, released to get help from the Community to solve that format problem.

[WeeboTech]

The -TEST version was also a special case, released to get help from the Community to solve that format problem.

 

I agree here. That was an odd one.

[prostuff1]

A closed alpha for 5.0 would let some others do some debugging and testing for Tom, without burdening him with support since the closed alpha could be easily limited to people who can swim in the deep end w/o a lifeguard.  That could free him up to concentrate on 4.x until the date when the alpha testers are to report back. 

 

Basically, it would allow some parallel processing instead of purely sequential.

 

I like this idea and I would be more than welcome to be part of that list.  I think there are enough people here that would be willing to be in an alpha test group to help Tom out with some very early testing.