Not a biggy, but since there are fixes about log issues I thought I drop in this feedback.

Although, I am still on 4.5.6 I haven't seen fixes in the changelog about that so I thought it maybe worth to raise it here.

 

This is that the "Move Now" function using the button on the Shares tab is not respecting the "Mover logging" setting. In case of using "Move Now" button, the mover will logging into the syslog regardless the logging is disabled or enabled.

 

This doesn't happen during the scheduled mover operation, then there is no log in syslog if logging is set to disabled.

 

 

Not a biggy, but since there are fixes about log issues I thought I drop in this feedback.

Although, I am still on 4.5.6 I haven't seen fixes in the changelog about that so I thought it maybe worth to raise it here.

 

This is that the "Move Now" function using the button on the Shares tab is not respecting the "Mover logging" setting. In case of using "Move Now" button, the mover will logging into the syslog regardless the logging is disabled or enabled.

 

This doesn't happen during the scheduled mover operation, then there is no log in syslog if logging is set to disabled.

 

 

 

Added to -rc4.

Not a biggy, but since there are fixes about log issues I thought I drop in this feedback.

Although, I am still on 4.5.6 I haven't seen fixes in the changelog about that so I thought it maybe worth to raise it here.

 

This is that the "Move Now" function using the button on the Shares tab is not respecting the "Mover logging" setting. In case of using "Move Now" button, the mover will logging into the syslog regardless the logging is disabled or enabled.

 

This doesn't happen during the scheduled mover operation, then there is no log in syslog if logging is set to disabled.

 

 

 

Added to -rc4.

 

Cool, thank you Tom!

root@Tower:~# sensors-detect

-bash: /usr/sbin/sensors-detect: /usr/bin/perl: bad interpreter: No such file or directory

 

how to solve?

root@Tower:~# sensors-detect

-bash: /usr/sbin/sensors-detect: /usr/bin/perl: bad interpreter: No such file or directory

 

how to solve?

 

Install perl from unMenu package installation...

got the fan control working again.  So would I just put those two lines in my go file and be good?

 

Yup.

 

 

Install perl from unMenu package installation...

 

could you please point me to the explanation?

 

 

Install perl from unMenu package installation...

 

could you please point me to the explanation?

 

First, do you have unMENU installed?

If not here is an overview and instructions:

http://lime-technology.com/wiki/index.php?title=UnRAID_Add_Ons#UnMENU

http://code.google.com/p/unraid-unmenu/   (instructions are on project home page, download available at "Downloads")

 

Once unMENU is installed and you have accessed your server (http://yourservername:8080) you will see a link to "Package-Manager"

This will allow you to install various add-on packages.  Scroll down until you find "perl".  Download and install this package directly from the unMENU interface.  You can also enable it to reinstall upon reboot.  

http://lime-technology.com/wiki/index.php?title=UnRAID_Add_Ons#perl_.28Larry_Wall.27s_.E2.80.98Practical_Extraction_and_Report_Language.E2.80.99.29

 

Now you can run sensors-detect from your telnet interface.

 

 

 

- Only "final" versions are shipped by Lime Tech in server products.

 

Tom, have you thought about putting out a stable release with updated kernel and samba?

 

Samba is stable at 3.5.6.  Lot's of problems with Windows-7 have been fixed,

and lots of connection timeout issues have been fixed too.

(Slackware-current is also with samba-3.5.6)

 

As for the kernel, any of these are stable...

2.6.33.7  2.6.34.7  2.6.35.9  2.6.36.1

...and bring some nice speed improvements over the 2.6.32 kernel.

 

Thanks!

 

 

- Only "final" versions are shipped by Lime Tech in server products.

 

Tom, have you thought about putting out a stable release with updated kernel and samba?

 

Samba is stable at 3.5.6.  Lot's of problems with Windows-7 have been fixed,

and lots of connection timeout issues have been fixed too.

(Slackware-current is also with samba-3.5.6)

 

As for the kernel, any of these are stable...

2.6.33.7   2.6.34.7   2.6.35.9   2.6.36.1

...and bring some nice speed improvements over the 2.6.32 kernel.

 

Thanks!

 

 

 

No, he has to put in AFP first 

got the fan control working again.  So would I just put those two lines in my go file and be good?

 

Yup.

 

Release -rc4 will have the same kernel as 4.5.6, so this will be unnecessary for you.

- Only "final" versions are shipped by Lime Tech in server products.

 

Tom, have you thought about putting out a stable release with updated kernel and samba?

 

Samba is stable at 3.5.6.  Lot's of problems with Windows-7 have been fixed,

and lots of connection timeout issues have been fixed too.

(Slackware-current is also with samba-3.5.6)

 

As for the kernel, any of these are stable...

2.6.33.7   2.6.34.7   2.6.35.9   2.6.36.1

...and bring some nice speed improvements over the 2.6.32 kernel.

 

Thanks!

 

 

 

Goal is to put 4.x series to rest & carry on with 5.0.

- Only "final" versions are shipped by Lime Tech in server products.

 

Tom, have you thought about putting out a stable release with updated kernel and samba?

 

Samba is stable at 3.5.6.  Lot's of problems with Windows-7 have been fixed,

and lots of connection timeout issues have been fixed too.

(Slackware-current is also with samba-3.5.6)

 

As for the kernel, any of these are stable...

2.6.33.7   2.6.34.7   2.6.35.9   2.6.36.1

...and bring some nice speed improvements over the 2.6.32 kernel.

 

Thanks!

 

 

 

Goal is to put 4.x series to rest & carry on with 5.0.

 

Right.  It's been a goal for more than a year.  And it may well be a goal for another year.

That's OK.  But in the mean time you'll still be shipping servers with a stable release.

And it would be nice if the stable release can be kept up to date.

 

got the fan control working again.  So would I just put those two lines in my go file and be good?

 

Yup.

 

Release -rc4 will have the same kernel as 4.5.6, so this will be unnecessary for you.

 

If there were benefits to the kernel change you made then I have no problems having to add the two lines to go.  After being given a shove in the right direction it was easy enough to figure out and fix.

Release -rc4 will have the same kernel as 4.5.6, so this will be unnecessary for you.

 

So that means all the additional power management aspects will be removed from RC4?

 

If so, that sucks for the community unless you have 5.0 rc 1 release set to go in the next few days as well.

You are probably invoking something via "at" and it is attempting to send status mail saying it ran.   unRAID does not have an e-mail command.   The message has been there for a very long time, you probably did not notice it.

 

Thank you, that is weird I never installed any email on purpose.

Thank you, that is weird I never installed any email on purpose.

 

It's not that you have/have not installed anything email related.  There is the "at" command and it will send an email out IF it can.  Since unRAID does not have a mail protocol/client installed by default the mail part of the "at" command fails and gives that error.

I install rc3 earlier tonight and then started a disk upgrade.  I have upgraded 3 or 4 disks over the past week on earlier revs and was getting around 60Mb/sec for all those rebuilds.  Now I am getting about 23mb/ sec on this new drive.

 

Drive is on the same card, next slot from an identical disk that just finished rebuilding earlier today at double the speed.  Syslog shows no errors, nothing is running in the background...  Anyone else seeing this speed differential with rc3?

 

Nothing that changed accounts for this.  You can try the rebuild under 4.5.6 to see if speed is faster.

 

I tried the downgrade with no change then I changed the drive itself and I'm back up to a rebuild with 55MB/sec.  I pre-cleared 8 drives at the same time and 2 or 3 of them took significantly longer than the others, I wonder if there is something goofy with those drives...  They are all 2TB WD EARS with 7-8 jumpers...

Thank you, that is weird I never installed any email on purpose.

 

It's not that you have/have not installed anything email related.  There is the "at" command and it will send an email out IF it can.  Since unRAID does not have a mail protocol/client installed by default the mail part of the "at" command fails and gives that error.

 

Ok now I understand. thank you.

finally made upgraded from 4.4.2 to 4.6-rc3 by copying

 

memtest

bzimage

bzroot

 

to my flash device, but when I reboot or restart my machine, it still say ver 4.4.2. I must have missed something very obvious.

 

any ideas?

finally made upgraded from 4.4.2 to 4.6-rc3 by copying

 

memtest

bzimage

bzroot

 

to my flash device, but when I reboot or restart my machine, it still say ver 4.4.2. I must have missed something very obvious.

 

any ideas?

Either you:

 

A. copied a set of the older 4.4.2 release files to the flash device

 

or

 

B. copied the files to the wrong location on the flash device.

 

The files should be copied to the top most folder on the flash drive.  That folder is normally accessible from windows as

\\tower\flash

 

On linux, that folder is mounted at /boot.  Therefore the files are seen when logged in via telnet or on the system console as

/boot/bzroot

/boot/bzimage

 

Their sizes are:

root@Tower:/boot# ls -l bzroot bzimage

-rwxrwxrwx 1 root root  2479056 Nov 23 12:44 bzimage

-rwxrwxrwx 1 root root 54941339 Nov 23 12:45 bzroot

 

Joe L.

Maybe your syslinux.cfg is configured to boot a bzimage with other name.

 

Overwrite this file and try again.

I know that this release wasn't intended to be a major revision, but I wonder whether it would be possible to address the issue I raised here.

 

I believe that the crucial point is in the last post ... a non-zero/unique fsid needs to be generated for the nfs cache share, in the same way that it is for user shares.

finally made upgraded from 4.4.2 to 4.6-rc3 by copying

 

memtest

bzimage

bzroot

 

to my flash device, but when I reboot or restart my machine, it still say ver 4.4.2. I must have missed something very obvious.

 

any ideas?

Either you:

 

A. copied a set of the older 4.4.2 release files to the flash device

 

or

 

B. copied the files to the wrong location on the flash device.

 

The files should be copied to the top most folder on the flash drive.  That folder is normally accessible from windows as

\\tower\flash

 

On linux, that folder is mounted at /boot.  Therefore the files are seen when logged in via telnet or on the system console as

/boot/bzroot

/boot/bzimage

 

Their sizes are:

root@Tower:/boot# ls -l bzroot bzimage

-rwxrwxrwx 1 root root  2479056 Nov 23 12:44 bzimage

-rwxrwxrwx 1 root root 54941339 Nov 23 12:45 bzroot

 

Joe L.

 

Joe,

 

This is what I have

 

root@storage:/boot# ls -l bzroot bzimage

-rwxrwxrwx 1 root root  2479056 Nov 23 12:44 bzimage*

-rwxrwxrwx 1 root root 54941339 Nov 23 12:45 bzroot*

root@storage:/boot#

 

Is overwriting the syslinux.cfg, the next thing to try?

 

Thanks

 

Is overwriting the syslinux.cfg, the next thing to try?

 

Thanks

 

Yes.