Release 2.060324 available for limited release

[limetech]

Beta testers: the next revision of UnRaid software is available for download.  This release includes only a few changes from 2.060315, but includes a very important utility for fixing a potential problem with the Flash drive.

 

One of our beta testers reported an ominous error encountered trying to boot the 2.060315 release:

 

Error 18: Selected cylinder exceeds maximum supported by BIOS

 

After much testing and long hours we were able to reproduce this problem and determine the cause: there is a bug in the D865GLCLK bios having to do with disk access via INT13 mechanism to a USB device.  This is the method of access used by the boot-loader to load the operating system into memory.  If the physical location of the system image on the Flash is beyond a certain logical block threshold, this error will occur.

 

This release includes a program called

fix18

which patches the Flash to correct this problem.  This program only needs to be run once on the Flash.  Unfortunately, this program must be run on almost all Flash devices currently in the field.

 

Note: to apply this patch you must boot version 1.050930 of the firmware, hopefully in your

previous

directory.  If you have deleted this version from your Flash, email me at [email protected]

 

Following is the contents of the

readme.txt

file for this release.

---

Lime Technology, LLC

UnRaid Firmware 2.060324 Release Notes
======================================

Firmware Upgrade Instructions
-----------------------------

The following procedure is for a Windows XP system.


IMPORTANT
---------

There is a bug in the Intel D865GLCLK bios which can cause the following error to occur during the boot process:

"Error 18: Selected cylinder exceeds maximum supported by BIOS"

This release includes a program called "fix18" to correct this problem.  If you are currently running version 1.050930 firmware, follow these steps to run this program before upgrading for the first time:

1. Find your UnRaid server under My Network Places and then click on the 'flash' share to open it.

2. Copy the file 'fix18' from the unpacked 'UnRaid-x.xxxxxx' folder to the Flash share.

3. Click Start, then Run, and in the dialog box, type "telnet tower" (without the quotes).  If you have renamed your server from the default name "tower" then use that name here instead.

4. In the window that opens, you will see a login prompt.  Type "root" (without the quotes) and hit Enter.  Then type "/boot/fix18" (again, without the quotes) and hit Enter.

You may now close the telnet window and proceed with the firmware update.  You only need to do this once.


Upgrading
---------

Upgrading the UnRaid system firmware consists of unpacking the downloaded zip file and copying the contained files onto the USB Flash.

1. Find your UnRaid server under My Network Places and then click on the 'flash' share to open it.

2. Right-click the 'current' directory and delete it (but see Note 1 below first).

3. Drag the 'current' directory from the unpacked 'UnRaid-x.xxxxxx' folder to the Flash 'system' directory. 

4. In the Management Utility, Stop the array, and then click Reboot (see Note 2 below).

Note 1
------
The Flash 'system' directory contains these three directories:

current - contains the "current" firmware
previous - contains a "previous" revision firmware
grub - contains system files necessary for booting

There is enough space on the Flash for two sets of system firmware, contained in the directories 'current' and 'previous'. By default, when the UnRaid system boots, it will load the firmware contained in the 'current' directory. It is possible to interrupt the boot process by pressing any key during the "GNU GRUB" menu that appears immediately following the motherboard bios startup. You may then have the system boot the firmware contained in the 'previous' directory by selecting it in the GRUB menu. This feature has been implemented as a way to "fall back" to a previous firmware version.

If you want to preserve the 'current' running firmware, then in Step 2, instead of deleting the 'current' directory,
  a) right-click the 'previous' directory and delete it, then
  b) right-click the 'current' directory and rename it to 'previous'.

Note 2
------
If you are currently running firmware version 1.050930, there is no Reboot button.  In this case, after Stopping the array, you may either simply power-off/power-on the server, or at the console, or telnet window, after logging in, type the command "reboot".


Additional Information
----------------------
You may also plug the USB Flash into your Windows system to peform the update; but, DO NOT use any utility to defrag, re-partition or re-format the USB Flash; doing so may render the Flash unbootable.


Summary of changes from 2.060315 to 2.060324
--------------------------------------------

Improvement: The server will now recognize cases where the Ethernet cable is plugged and unplugged, and set up the network interface appropriately. Previously, if the server was booted without the Ethernet cable plugged in, it's network interface would not be initialized (you had to reset the server after plugging in the cable).

Bug Fix: Fixed problem with setting the timezone.

Bug Fix: Fixed problem causing numerous "sys_path_to_bdev failed in sysquotas.c" syslog messages.

Bug Fix: Fixed problem introduced in 2.060315 where certain Windows programs experienced severe slowdown writing to shares.


Known Issues
------------

- When the array is stopped, there is a button on the Management Utility to re-boot the system.  After clicking this button the UnRaid server will reboot and the Management Utility will display the message "Wait...".  The Management Utility will not automatically reconnect to the server, however.  After the server has been rebooted, you can manually reconnect by clicking the browser's Refresh button.

- SATA support has the following restrictions:
1. Can not read SATA hard drive temperatures.
2. Can not spin down SATA hard drives.
3. Supports only Intel on-board SATA controllers, and Promise SATAII-150 TX4.
4. System occasionally will "hang" writing the Master Boot Record of new SATA disks.  Upon manual reset, the disk MBR is correctly written and you can proceed.


Summary of changes from 1.050930 to 2.060315
--------------------------------------------

- New Feature: SATA support. Upgraded to Linux kernel 2.4.31 for added SATA stability.  Supports Intel SATA (ata_piix module) and Promise SATAII150-TX4 (sata_promise module).

- New Feature: Added timezone support.

- Improvement: Incorporate latest Marvell Yukon GigEthernet driver.

- Improvement: Enable RX Polling (NAPI) in both Intel PRO/1000 and Marvell Yukon GigEthernet drivers.

- Improvement: Numerous changes to the Management Utility to improve responsiveness.

- Improvement: Improved parity-sync performance.

- Improvement: Disk statistics are now cleared each reset.

- Improvement: For Intel D865GLCLK motherboard bios, no longer necessary to set Advanced/Drive Configuration to [Legacy] (it can be set to either [Legacy] or [Enhanced] - latter needed to access on-board SATA). Note that if  you want to re-boot version 1.050930 firmware, however, you must ensure this is set to [Legacy].

- Bug Fix: Fixed interoperability problem with Firefox 1.5 where clicking a button would cause the window to continually refresh.

- Bug Fix: Fixed problem where 'System' and 'Hidden' bits were not working correctly on shared files.

- Bug Fix: Correct SO_RCVBUF typo in smb.conf.

- Bug Fix: Fixed problem recognizing "factory-cleared" status on certain new disks.

- Bug Fix: Fixed problem which caused Management Utility to crash if a disk is disabled and exactly 1 other disk is missing or wrong.

- Bug Fix: Fixed problem where system still "remembered" removed disabled disk identity.

- Other: Added missing license.txt file and included source code of modifed GPL files.

- Other: Starting with this release, the 'go' script has been moved from the root directory of the Flash to the system firmware directory, i.e., either 'system\current' or 'system\previous'.  If you made any customizations to the 'go' script you will need to edit the new 'go' script and place your changes there.  You can leave the old 'go' script on the Flash if you want, in case you ever boot version 1.050930 again.

The firmware directory also contains a 'go-sata' script.  This can serve as a template for creating your own 'go' script which sets up SATA drives.  Refer to the Support page on our website for more information about SATA support in this release.

[Joe L.]

Tom,

 

Since it was me who reported this error, and since I was able to get around it and successfully boot up on the 2.060315 beta by deleting the new release files and then copying them in a way so they were below the block limit caused by the bios bug, I have a question related to the "fix18" program.

 

I'm currently running the 2.060315 beta version and I assume most of the beta testers are too.

I think we could use some advice on how to upgrade from 2.060315 to 2.060324.

 

Do you suggest we re-boot, choose the "previous" release on the GRUB menu, come up on the "previous" (original 2.060315) release, then copy the new beta 2.060324 release files to the "current" folder, run the fix18 program, and then reboot to the new beta?  This would let me boot the original version, or the newest beta, with the newest beta being the default in the GRUB menu and the 2.060315 release gone from the drive.

 

Or

 

Can we  right-click the 'system/previous' directory on the flash drive and delete it from a windows box, then right-click the 'system/current' directory and rename it to 'system/previous'. and finally drag the 'current' directory from the unpacked 'UnRaid-2.060324' folder to the Flash 'system' directory.

 

This would result in the two folders (current and previous) having two different beta versions available to boot from and the original files would be gone.  (Probably a good idea to first copy the "previous" folder containing the original release to a windows folder just in case I ever needed them.)

 

Now, before I reboot to the newest beta "current" release, can I run the fix18 program?  It would be run under the 2.060315 beta.  Is there something special about running it under the original release vs the first beta release. (Assuming, of course, that you could boot the first beta release and not encounter the "Error 18: selected cylinder exceeds maximum supported by BIOS" message as I had originally)

 

Obviously, if I can't boot with the first beta release, I would need to run the fix18 program using the original release, but the questions is

"If I am currently able to boot the 2.060315 release, can I run the fix18 script under it and then install and boot the newest beta?  Must I revert to the original release to run the fix18 script?"

Thanks for following up on this, especially if I was the only person reporting it.  As you said, it is a very ominous error message and would have eventually resulted in a lot of support calls and messages.  As you said in my e-mail to you, the automatic fallback to boot the OS in the "previous" folder worked perfectly and I was able to keep the unRaid server on-line even though the BIOS error occurred.  Good planning on your part.

 

Isn't beta-testing fun...

 

Joe L.

[rharvey]

My upgrade today to 324 and the fix18 was not successful and unrecoverable.  I have emailed Tom with what happend and I'm waiting on a response.  I share this ONLY so you all may know the risk.  It looks to me like the fix18 patch is at issue here because my system now boots up to a point where I see the Grub loader and then POOF it does a full hard reset of the system, right back like a cold start.  I never see the current/previous menu at all which leads me to think it's not the new code but the fix18 patch that caused this.

[Joe L.]

rharvey,

 

Sorry to learn of your upgrade problem.  I think I''ll wait till Tom responds to our posts before I do anything to my flash drive to upgrade my server.  Might save me from losing a few more hairs.

 

Are you trying to boot into the new beta, or the old (original) release?

 

Did you, by any chance, change the BIOS option as Tom described in his earlier release notes?

- Improvement: For Intel D865GLCLK motherboard bios, no longer necessary to set Advanced/Drive Configuration to [Legacy] (it can be set to either [Legacy] or [Enhanced] - latter needed to access on-board SATA). Note that if  you want to re-boot version 1.050930 firmware, however, you must ensure this is set to [Legacy]. If you are trying to boot the original and you set this to enhanced, it might be the cause of your issue.

 

It is worth a try to switch the BIOS Advaced/Drive Configuration on the motherboard from what it is to the opposite value. You can always switch it back.

 

Joe L.

 

[TCIII]

Hi Joe L/All.

 

I posted this response in the "Release 2.060315 available for limited release" thread, but thought that it might be good to post it in the latest release thread because 2.060324 may have the same problem! :'(

 

When I would rip a DVD to my number one unRaid server with CloneDVD it would take 15-20 minutes to rip a standard 2hr DVD with just the main title and AC3 sound track.

 

Since upgrading to the new OS (2.060315), the same 15-20 minute rip is indicating up to 3 hours!

 

So I deleted the new OS current folder and renamed the original previous OS to "current" and rebooted.

 

Going back to the original OS resulted in a 15-20 minute rip indication for a 2hr DVD.

 

There is definitely something wrong with the new OS as far as ripping or streaming a large block of data to the server.

 

Regards,

TCIII

 

[Joe L.]

Hi Joe L/All.

 

I posted this response in the "Release 2.060315 available for limited release" thread, but thought that it might be good to post it in the latest release thread because 2.060324 may have the same problem! :'(

 

When I would rip a DVD to my number one unRaid server with CloneDVD it would take 15-20 minutes to rip a standard 2hr DVD with just the main title and AC3 sound track.

 

Since upgrading to the new OS (2.060315), the same 15-20 minute rip is indicating up to 3 hours!

 

There is definitely something wrong with the new OS as far as ripping or streaming a large block of data to the server.

 

Regards,

TCIII

 

That drop in performance with certain apps is one of the items that Tom addressed in the 2.060324 beta release as per his release notes.

He had included a newer version of SAMBA in the 2.060315 beta and its performance suffered the problems you described.

He went back to the older version of SAMBA in the 2.060324 release so performance should be back where it was.

 

 

-----------------------------------------------------------------------------------------------------

Back on topic...?

 

I have been waiting for Tom to respond to my original beta-upgrade questions before upgrading the first beta to the second.  In the absence of his response, what have other beta-testers done?

 

Besides rharvey, who had a bad upgrade experience and ended up with an unbootable flash drive...  :'( :'( :'(

 

• Has anyone else installed the 2.060324 beta release?
   
  
• if yes, does your previous folder have the first 2.060315 beta release in it, or the original non-beta unRaid release?
   
  
• if you did install the 2.060324 release, was it successful?  Are you able to choose which version to boot from the GRUB boot menu?
   
  

 

Joe L.

[limetech]

Here is some additional information about the upgrade process.

 

For everyone whose Flash did not ship with version 1.060324 pre-installed, there is a bug in the motherboard bios which affects the way the boot loader loads the operating system into memory.  [Ok, since we now know how to avoid this bug, one might say it was our testing bug for not noticing this problem earlier - point taken.]

 

The affect of the bug is this, these files:

  /grub/menu.lst

  /grub/stage1

  /system/current/bzimage

  /system/current/bzroot

  /system/previous/bzimage

  /system/previous/bzroot

 

must reside within the first 64MB of the Flash, or else the boot loader will get so-called "Error 18".  This is because the boot loader uses cylinder/head/sector addressing to access the Flash, and there is a bug in the bios that prevents accessing beyond 64MB on the USB Flash (doesn't happen with real hard drives).  The "fix", for us, is to tell the boot loader to use "LBA" addressing instead of "C/H/S".  Unfortunately this flag is set at the time the boot loader is installed.  Starting with 2.060324, we are setting this flag on all new Flashes shipped.

 

But for everyone else... There are some ways to deal with this problem.  The easiest is probably to simply ensure that the above files are located properly.  You can do this by first deleting the /system/current and /system/previous directories, then copy the update /system/current contents to the flash.  You could even do this: plug Flash into PC, copy important files to a scratch folder on the PC.  Delete entire contents of Flash.  Then copy in this order:

  first - /system/grub/*

  next - /system/current/*

  next - /system/previous/*

  next - all the files in the root (ie, model.cfg, network.cfg, disk.cfg, ident.cfg)

 

Alternately, if you are running 1.050930, then you can run the 'fix18' script located in the update.  This will re-install the boot loader with the "LBA" flag set, thus avoiding all future problems with this.  One caution: apparently with more than 8 hard drives installed, this 'fix18' won't work properly.  So, you should power off all your normal parity+data drives, reboot, copy 'fix18' over, telnet it, and run it.  Now all should be well 

 

Finally, since you, the user, shouldn't have to deal with this mess, send me an email at [email protected] with your current Flash serial number and I'll send you a new Flash.  You can see the serial number in the file model.cfg in the Flash share.

 

 

[rharvey]

Turns out that per Tom's message about the fact that I have 12 drives installed had caused the fix18 script to fail but there was no way for me to know it failed until I attempted to re-boot.  Tom suggested I turn off ALL drives, re-boot and then apply the fix18 patch and then do the upgrade.  All worked fine and I'm now running 324 with all 12 drives active.  No issues so far but I have really done no testing.

[TCIII]

Hi all,

 

I just downloaded Release 2.060324 and installed it today on my #2 unRaid server per Tom's instructions. Tom was very responsive to a couple of questions I had before I did the update and everything is going fine now.

 

I plan to update my main unRaid server tomorrow following the same procedure as for my #2 unRaid server. All I can say is double check each step of the procedure laid out by Tom before you hit the return key and you will be fine.

 

After copying the fix18 to the root drive of my #2 server and making the original OS version the current version, I stopped the array and then powered it down. I turned off all of my drives before powering up the array. After the boot up, I ran the fix18 from the telnet window, got a completed response, then told the OS to reboot.

 

The OS came back up and I then changed the current original OS to previous and moved the current 2.060324 to the flash drive, stopped the array and rebooted from the telnet window. The OS rebooted correctly and I now have the latest OS installed and working.

 

The next thing to do is to try and rip a DVD directly to the array to make sure there are no problems like with the first OS update.

 

Regards,

TCIII

[Joe L.]

Thanks to Tom's recent instructions I too have now installed the newer 2.060324 beta on my unRaid server. 

 

Everything went smoothly.

 

just in case, I first made an image of the unRaid drive using

dd if=/dev/sda of=/mnt/disk1/WorkingUnRaid.img

 

I then copied that image file to a windows drive using windows explorer... I could use it to put things back the way they were if anything went wrong and the drive would not boot. (As it turns out, I did not need this as everything worked as expected, but I am cautious)

 

I then booted up on the previous (original release) version by typing "reboot" and selecting "Previous" in the GRUB menu.  Since I only have 4 drives I did not power them all down before rebooting.  I understand this is necessary if more than 8 drives are installed.  Guess I got lucky, or at least as bit luckier than rharvey. (He got to discover that nasty bug in the fix18 process when more than 8 drives are installed )

 

I then installed and ran the fix18 program.  It completed in about two seconds.

 

Next, I replaced the 2.060315 files in the system/current directory with those from the newer 2.060324 beta release.  ("previous" now has the original release, "current" has the 2.060324 release, the 2.060315 files are no longer on the flash drive.)

 

Last, I typed "reboot" after logging in as root.

 

Everything came up as expected with no problems.

 

I can now set the date using the unRaid web-interface and it acts sanely...    I'll see how performance is over the next few days. So far, it looks fine.

 

Thanks Tom, for your hard work on our behalf.  I know these first few rounds of beta testing have been rough.  Now that the kinks are worked out in the process, it should go smoother.

 

Joe L.

[erikatcuse]

Installed the patch and the new software works as far as I can tell

 

Erik

[JM2005]

Any news on How the Beta Firmware is doing?

[BLKMGK]

Any news on How the Beta Firmware is doing?

 

I'll second that - any news? I've still got the first beta on mine and the weirdness with file placement had me holding back from trying the new update. Have performance issues improved with the new code? Everything working?

 

Thanks!

[dschur]

Another native getting restless here also.

 

I'd love to see/hear any movement. I'm sending a friend your way this week for an order also.

 

 

[BLKMGK]

It's now JULY - has development ceased?

[limetech]

It's now JULY - has development ceased?

No.  But porting to linux 2.6 has proven to be more work than anticipated...

[Joe L.]

Many unRaid users have reported problems upgrading/replacing disks under the 324 release.  I have confirmed this as a problem if the replacement disk is blank (fresh out of the box from the factory, unpartitioned, and unformatted)

 

In a different thread Tom tried to duplicate the failure, but he could not. I suspect he tried using disks that already had been partitioned and formatted that he had laying around in his lab.  The 324 upgrade/replace process works if the disk is already partitioned/formatted, so Tom's attempts to duplicate the bug we are seeing were not successful, but if the disk is new (unpartitioned/formatted) the initial series of "writes" made by the 324 release to upgrade/replace a disk all fail, and it marks the disk as DISABLED. (the writes possibly intended to clear the drive contents)

 

Once the disk is marked as disabled, nothing will get it back on-line I am aware of other than removing it, resetting the array, and then re-installing it.  Of course, if you have a failed disk you might lose data if you had not copied it off somewhere else in that process.

 

Tom, give it a try.  use "dd if=dev/zero of=spare-target-disk" to zero a disk, and then try using that target disk as an "upgrade/replacement"  I'll bet the upgrade fails for you too on the 324 release. (The original release of unraid works, so those of us with the "previous" choice in our boot menus can use it to replace/upgrade drives) Those with only the 324 release....Let's say Tom might expect a lot of frantic support requests when the time comes to replace/upgrade a drive.

 

Joe L.

[Cornelius]

hey guys...

 

where can i download the update....

i cannot find the link...

 

thx

[TCIII]

Cornelius,

 

Email Tom directly and he will send you a site location where you can down load version 2.060324.

 

Regards,

TCIII

[rharvey]

hey guys...

 

where can i download the update....

i cannot find the link...

 

thx

 

Right Here

 

http://lime-technology.com/Downloads/

 

 

[Cornelius]

Thanks...