unRAID Server Release 5.0-rc5 Available


Recommended Posts

Download | Release Notes

 

Please post issues in the unRAID OS 5.0-rc Board

 

Here's the current state of 5.0 along with what still needs to be done for "final" release.  First some known issues:

 

- NFS stale file handles when accessing user shares.  This is not fixed in -rc5, but finally I know what the problem is.  Until this is solved I recommend not using NFS to access user shares.  I'll add more info about this in a sticky...

 

- mvsas driver issues.  This is also not fixed in -rc5, but I can reliably reproduce some failure cases.  Note, all issues with this driver appear to be related to bug(s) in error processing.  If your h/w is working properly, there is no problem and data I/O is reliable.  In addition, most errors are handled correctly.  I'll add more info about this in a sticky.

 

- media playback stutter.  Earlier the idea of creating a fully preemptable kernel might alleviate some of these issues, but in my testing I have not found this to be the case.  In addition, it cuts parity-sync rate almost in half.  So this is not going to be a productive path to follow.  This will require more testing to get to the bottom of it.

 

Here is additional functionality to be implemented:

 

- add configurable location for saving the netatalk database

- enhancements to avahi: programmable service names, enable/disable controls

- plugin manager

 

Might make it into 5.0 final, if not, will wait for 5.1:

 

- lighty (lighttpd) front-end for emhttp

- move webGui code to github as a public repository

 

Another issue someone has brought up is (again - sigh) the Realtek NIC drivers.  It turns out that Realtek's "r8168" driver compiles ok with our kernel, so I will produce a -rc5-r8168 release for those affected to test out.  The r8168 project is GPL2 and why Realtek just doesn't take ownership of this driver under linux and get rid of r8169 is a mystery to me.

Link to comment
  • Replies 82
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I can confirm that manually compiling the  8168 driver for RC4 and replacing the r8169.ko fixes my issues with my RTL8111D NIC, using r8169 under RC4 however gives me network issues when streaming multiple streams from the unRAID box.

 

I can also confirm this by rolling back to b12a which includes the r8168 driver.

 

I would love to test "-rc5-r8168" and report back with logs etc.

 

thanks

 

- WingmanNZ

Link to comment
- NFS stale file handles when accessing user shares.  This is not fixed in -rc5, but finally I know what the problem is.  Until this is solved I recommend not using NFS to access user shares.  I'll add more info about this in a sticky...

 

Are you issuing this advice because the fault can, potentially, corrupt data? Is there any reason that rc5 should be any worse in this respect than rc4, or earlier?

Link to comment
mvsas driver issues.  This is also not fixed in -rc5, but I can reliably reproduce some failure cases.  Note, all issues with this driver appear to be related to bug(s) in error processing.  If your h/w is working properly, there is no problem and data I/O is reliable.

 

I just built 2 systems, each using 3x SAS2LP-MV8 cards for a total of 6. I fixed all my problems by disabling PCI-E OPROM for all slots in BIOS. I made a thread but fixed the issues before I got a reply. They are now running RC5, and still no problems. I don't know if this is related to the issues you are talking about, but I know some people wanted to know about SAS2LP-MV8 support and they are working perfectly fine after a few BIOS tweaks for me.

 

EDIT: Had to go back to B14. MVSAS error definitely exists on the 2nd gen version of the cards too.

 

- plugin manager

 

;D

Link to comment

- NFS stale file handles when accessing user shares.  This is not fixed in -rc5, but finally I know what the problem is.  Until this is solved I recommend not using NFS to access user shares.  I'll add more info about this in a sticky...

 

Are you issuing this advice because the fault can, potentially, corrupt data? Is there any reason that rc5 should be any worse in this respect than rc4, or earlier?

 

This issue should not result in data corruption, and behavior should be the same in all releases.

Link to comment

Hi Tom, great to see progress towards 5.0-Final.

 

Quick question; the release notes state the following:

emhttp: fix issue where pressing physical power button wasn't initiating a graceful shutdown

 

Can you provide a little more information in regards to this change? Is it safe to assume that the power button will now safely shutdown the server (provided a parity check isn't initiated upon next boot) or is this still dependent on your ACPI configuration, as per Joe L's advice in the following thread (I'm aware this is an older thread but afaik the issue was still present):

 

http://lime-technology.com/forum/index.php?topic=6078.msg58196;topicseen#msg58196

Link to comment

Hi Tom, great to see progress towards 5.0-Final.

 

Quick question; the release notes state the following:

emhttp: fix issue where pressing physical power button wasn't initiating a graceful shutdown

 

Can you provide a little more information in regards to this change? Is it safe to assume that the power button will now safely shutdown the server (provided a parity check isn't initiated upon next boot) or is this still dependent on your ACPI configuration, as per Joe L's advice in the following thread (I'm aware this is an older thread but afaik the issue was still present):

 

http://lime-technology.com/forum/index.php?topic=6078.msg58196;topicseen#msg58196

 

The first post of that topic still applies, in that ACPI is required for this to work, though I would quibble with the conclusion:

 

We are now far better prepared to answer the question:

  Will pressing the "Power" button on the front of the unRAID server shut it down cleanly?

 

The answer is:

"Maybe," but more likely it will not.

 

I'd say it works 100% of the time under normal circumstances, with a properly functioning ACPI which these days is mostly true.

Link to comment

Thanks for the update :)

 

Another quick question, are there any future plans (5.1?) for additional parity control and/or a more accurate display of the parity status? This is something that has sparked some interest due to the end user possibly being mislead about the state of their parity, particularly after an unclean shutdown. I'm specifically referring to this thread: http://lime-technology.com/forum/index.php?topic=17096.0

Link to comment

I seem to be having an issue with the download link for vanilla RC5

 

I click download for RC5 and nothing happens. RC5 8168 downloads fine if i click that for a test.

 

Same here, on iPad + iCab at the moment but regardless link appears broken. I get a download prompt for -8168 but not vanilla, appears to just refresh the page?

Link to comment

Per the instructions, I've moved this question to the unRAID OS 5.0-rc Board area.

Need a little help.  I'm going from 4.7 to 5 rc5.  I'm following the instructions and I'm at the point where I reboot the server.  I do not have a monitor on my server so I rely on Putty or IE.  I prefer just using the web gui.  However, I cannot connect via my web browser.  I see mostly a blank page, but there is a Lime Tech banner at the top.  There is one button / link below the banner, but it's not in English so I don't know what it says.  The link doesn't work.  There is another button at the top right that says log, it gave me the following,

 

Jun 24 10:14:27 Tower emhttp_event: disks_mounted

Jun 24 10:14:27 Tower emhttp: shcmd (54): :>/etc/samba/smb-shares.conf

Jun 24 10:14:27 Tower emhttp: Restart SMB...

Jun 24 10:14:27 Tower emhttp: shcmd (55): killall -HUP smbd

Jun 24 10:14:27 Tower emhttp: shcmd (56): ps axc | grep -q rpc.mountd

Jun 24 10:14:27 Tower emhttp: _shcmd: shcmd (56): exit status: 1

Jun 24 10:14:27 Tower emhttp: shcmd (57): /usr/local/sbin/emhttp_event svcs_restarted

Jun 24 10:14:27 Tower emhttp_event: svcs_restarted

Jun 24 10:22:31 Tower in.telnetd[3928]: connect from 10.11.79.167 (10.11.79.167)

Jun 24 10:22:35 Tower login[3929]: ROOT LOGIN on '/dev/pts/0' from '10.11.79.167'

 

How can I access my server via my web browser so I can continue with the upgrade?

 

Is there a special port I need to use now when accessing via web gui?

 

Update: Putty works fine and so does UnMenu on port 8080.  The main web gui is not loading.  Another scary part is that UnMenu shows my Array started.  This was the part of the instructions that said it should come up at a STOP state and I will need to confirm drives are ok, reconfigure cache drivce, then START.  Not sure why the array started on it's own.  That said, the drives all look fine.  The cache drive is not configured so it looks like it saw everything was ok and just started.

I only run the UnMenu addon and the packages within there are very limited, APC, Notify, etc.  I didn't change any of these prior to my upgrade. 

 

Perhaps the first thing I need to do is set the Root password via Putty -- Yes?

 

syslog attached. 

 

Thanks!

Link to comment

For the above issue, I moved that to the correct board area, the unRAID OS 5.0-rc Board area.

 

It is now resolved.  I had to remove the PHP package re unmenu.  The main web gui is now there and working fine.

 

The only surprise was that the array started on it's own.  The Release Notes say that it will come up in a STOP state and I would have to Start it, after confirming drives looked ok and after adding the cache drive back.  That didn't happen, again it just started.  Everything looks ok however.

 

I'm now trying to figure out the email notification stuff.  Status emails and ReSync emails now all look the same, and they are not very informative.  Still doesn't tell you how much time is remaining on a resync nor if there are any errors.  I will also have to confirm that the other packages are ok, APC UPS, etc.

Link to comment

The only surprise was that the array started on it's own.  The Release Notes say that it will come up in a STOP state and I would have to Start it, after confirming drives looked ok and after adding the cache drive back.  That didn't happen, again it just started.  Everything looks ok however.

 

You read the release notes wrong, it says is that it fixed a bug that was causing the setting to revert to "Yes" after rebooting the server. You still have to set Enable auto start to "No", by default it is "Yes".

Link to comment

The release notes say:

Reboot your server. Once boot-up has completed, [b]you should see "Stopped. Configuration valid."[/b] array status with all disks assigned correctly.

 

However, I believe that this should only apply to upgrades before/after one of the early 5.0beta versions.

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.