unRAID Server release 4.0-beta9 available

Download.

Main change in this release is an overhaul of the disk discovery code.

unRAID Server 4.0-beta9 Release Notes

Upgrade Instructions
--------------------

If you are currently running unRAID Server 4.0-beta1 or higher, it is only necessary to copy the files:
    bzimage
    bzroot
from the new release to the root of your Flash device.  This can be done either by plugging the Flash into your PC or, but copying the files to the 'flash' share on your running server.  The server must then be rebooted.


If you are currently running unRAID Server 3.0-beta1 or higher, please follow these steps to upgrade:

1. Referring to the System Management Utility 'Main' page, make a note of each disks's model/serial number; you will need this information later.

2. Shut down your server, remove the Flash and plug it into your PC.

3. Right-click your Flash device listed under My Computer and select Properties.  Make sure the volume label is set to "UNRAID" (without the quotes) and click OK.  You do NOT need to format the Flash.

4. Copy the files:
    bzimage
    bzroot
    syslinux.cfg
from the new release to the root of your Flash device.

5. Right-click your Flash device listed under My Computer and select Eject.  Remove the Flash, install in your server and power-up.

6. After your server has booted up, the System Management Utility 'Main' page will probably show no devices; this is OK, navigate to the 'Devices' page. Using the model/serial number information gathered in step 1, assign each of your hard drives to the correct disk slot.

7. Go back to the 'Main' page and your devices should appear correctly.  You may now Start the array.


If you are installing this release to a new Flash, please refer to instructions on our website at:

http://www.lime-technology.com/wordpress/?page_id=19


Changes from 4.0-beta8 to 4.0-beta9
-----------------------------------

Bug fix: restored some network drivers which didn't get built into -beta8.


Changes from 4.0-beta7 to 4.0-beta8
-----------------------------------

Bug fix: fixed device discovery problems.

Bug fix: fixed condition where: a disabled disk that was marked 'enabled' again, but parity-sync (rebuild) was interrupted/cancelled, disk could not be marked 'disabled' again if it was removed.  Also cleaned up text describing actions system takes when starting array.

Bug fix: removed extraneous debug messages introduced in 4.0-beta5.


Changes from 4.0-beta6 to 4.0-beta7
-----------------------------------

Bug fix: remove "native" r8169 Realtek driver which conflicts with manufacturer's r1000 driver added in -beta6.

Bug fix: correct problem where formatted disks may appear 'unformatted' when array is started.


Changes from 4.0-beta5 to 4.0-beta6
-----------------------------------

Improvement: added Realtek RTL8111B/RTL8168B/RTL8111/RTL8168/RTL8111C driver version 1.05.


Changes from 4.0-beta4 to 4.0-beta5
-----------------------------------

Improvement: installed the 'at' command and associated 'atd' daemon (execute commands at a specified time and date).

Bug fix: added patch to eliminate "atkbd.c: spurious ACK on isa0060/serio0..." messages.

Bug fix: restored 'find' command inadvertantly removed in -beta3.

Bug fix: added 'stop' command present in pre-4.0 releases.


Changes from 4.0-beta3 to 4.0-beta4
-----------------------------------

Added Attansic L1 GigE driver version 2.0.7.


Changes from 4.0-beta2 to 4.0-beta3
-----------------------------------

Improvement: upgrade Samba to 3.0.24.  This release of Samba includes better support for Vista.

Improvement: upgrade Intel Pro/1000 driver to latest release (7.4.27).

Improvement: replace "stock" Marvell driver with newer skge/sky2 drivers.


Changes from 4.0-beta1 to 4.0-beta2
-----------------------------------

Improvement: added more network drivers:
    D-Link DL2000-based GigE adaptors (eg, DGE-550T)
    National Semiconductor DP83820 series (eg, D-Link DGE-500T)
    SIS 190/191
    VIA "Velocity"

Improvement: added floppy support.

Bug fix: the GUID formation for some Flash models is not generated correctly.

Bug fix: array would not start if disabled disk was not physically present.


Changes from 3.1-beta2 to 4.0-beta1
-----------------------------------

Improvement: move to linux 2.6.20 kernel.  The linux 2.6 kernel offers several advantages over linux 2.4 kernel used in previous unRAID Server releases:
  - better hardware compatibility, especially with newer hardware
  - many enhancements and bug fixes in the disk i/o code
  - more opportunities for performance tuning

Improvement: permit custom timezone.  You can select the appropriate timezone file from our website and then download to the 'config' directory on your Flash.  The main purpose of this feature is to implement proper Daylight Savings Time adjustments.

Improvement: support up to 14 hard drives.

Aaargh... V4.0-beta8 appears to have dropped support for the Attansic L1 GigE, that was added in beta4

I did a:

find / -name atl*.*

and the atl1 driver module is nowhere to be seen.

Was hoping beta8 would fix my [start] ... "stopped: configuration valid" issue, but now I can't get ethernet connectivity again... sigh.

Tom, can you please take a look at what happened to the Attansic L1 GigE driver you added earlier.

Aaargh... V4.0-beta8 appears to have dropped support for the Attansic L1 GigE, that was added in beta4

Sorry about that - try beta9.

Thanks again Tom. Once again, you're a star!

I can now [start] and [format] my new unRAID server, now testing creating some folders and copying some data across.

Just to check all is working as it should:

a. I have installed 2x 500GB Seagate SATA drives as 'disk1' and 'disk2' (no parity yet).

b. Format appeared to be near instantaneous (is this because the drives are brand new, or is this an issue?).

c. On my console, where the login prompt was, I now have:

MediaServer Login:  mkreiserfs 3.6.19 (2003 www.namesys.com) 

                                                                                                                                  mkreiserfs 3.6.19 (2003 www.namesys.com)

nb: If I press enter I get my 'Login:' prompt back.

d. Despite above, I can successfully create a folder and copy a file to it.

Despite my frustration (probably due to the hardware I have invested in being fully dependant on achieving a working V4.0 install), I realise this is all beta testing so patience is certainly a virtue.

Your prompt response to the issues, as they arrise, is certainly greatly appreciated, and a credit to you.   I think that the additional hardware support for newer motherboards with multiple onboard SATA300 ports etc. being provided by V4.0 (with it's 2.6.20 kernel etc.), is a very significant advancement for unRAID!

a. I have installed 2x 500GB Seagate SATA drives as 'disk1' and 'disk2' (no parity yet).

That's fine, you don't need to run with parity for testing purposes.

b. Format appeared to be near instantaneous (is this because the drives are brand new, or is this an issue?).

Not an issue. 'Format' is like the M$ meaning of the term 'format': it just creates a file system on each disk, in this case reiserfs, which is pretty fast.

c. On my console, where the login prompt was, I now have:

MediaServer Login:  mkreiserfs 3.6.19 (2003 www.namesys.com)

                                                                                                                                  mkreiserfs 3.6.19 (2003 www.namesys.com)

nb: If I press enter I get my 'Login:' prompt back.

That's ok.  You're just seeing a 'debugging' message being output when the file system is being created.  You see two of them because you formatted two drives.  These messages will be removed in next release.

Thanks for the reassurance Tom.

I'll now go out and buy a 3rd Seagate 500GB SATA drive, so I can proceed to test parity build and a simulated drive failure recovery, on my Asus P5B-E setup.

You could test parity build with 2 drives: parity and disk1.

Interesting note: if you only have parity & disk1 (2-drive array), then after parity sync completes, the parity drive is actually an exact copy of disk1 (because we use "even" parity).  This is really a "raid-1", though unraid driver is not optimized for it.  There are a number of interesting features we can implement using this in the future.

You could test parity build with 2 drives: parity and disk1.

 

Interesting note: if you only have parity & disk1 (2-drive array), then after parity sync completes, the parity drive is actually an exact copy of disk1 (because we use "even" parity).  This is really a "raid-1", though unraid driver is not optimized for it.  There are a number of interesting features we can implement using this in the future.

Are you thinking in terms of multiple arrays?

Are you thinking in terms of multiple arrays?

Yes, for purpose of implementing a write-cache.