Even the kernel provided by limetech "knows" how to do xz -- it just isn't used.

 

It is a kernel compile option.  All I did was choose xz instead of gzip for what the kernel image should be compressed with.

 

I then also compressed the bzroot with xz, saving a lot of megabytes.  The stock kernel would also be able to use xz compressed bzroot files as it is already compiled in.

 

You have to use crc32 with xz for bzroot as this is the only scheme the decompressor in the kernel understands.  ie: xz --check=crc32

b15 has been relatively stable so far, until now.  Web GUI is unresponsive but unMENU still is accessible.

 

b15? there is no b15 yet....

(I'm using 5b13 with a mix of NFS (media streaming music, avi and bluray rips on openelec linux xbmc) from user mnts and smb with no transfer issues)

 

What is your equipment setup?

 

Unraid server:

System: Gigabyte - GA-K8NXP-SLI

CPU: AMD AthlonTM 64 X2 Dual Core 4400+ - 2.2 GHz

Memory: 4 GB - 166 MHz

Network: 1000Mb/s - Full Duplex

 

I have an Acer Revo with openelec and wdtv live both using NFS and XBMC on win7 using SMB across HomePlug av200s - only one at a time if running HD!

 

b15 has been relatively stable so far, until now.  Web GUI is unresponsive but unMENU still is accessible.

 

b15? there is no b15 yet....

 

What?  You don't have Beta 15 yet?  You must not belong to the "elite" club... 

 

Hehe, of course, I meant B14!

Looks like kernel 3.2 may come out soon also.

Hows the 3.1.6 been working out?

 

Looks like kernel 3.2 may come out soon also.

Hows the 3.1.6 been working out?

 

 

From my limited testing of the files with 3.1.6 from elkay14, things look good.  The boot time was cut in half (The extra compression was the big factor here as the hardware that I am using only reads from the USB ports at version 1.1 speeds) and the array started automatically started on bootup unlike the stock beta.  But I wasn't having any issues the stock beta 14.  Guess we willl have to wait on some of people who are having problems with the stock beta14 to report...

It look like unRAID Server 5.0 final never going happen lol

 

beta after beta

I'd rather have beta after beta than a final that is absolute shit.

It look like unRAID Server 5.0 final never going happen lol

 

beta after beta

 

I'm sure no one is happy about the delays.

 

But 99% of the issues at this point seem to be related to the new linux kernel.

Kernel 3.1.6

 

 

Some FUSE fix 

 

http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.1.6

Looks promissing...

 

One bug was when seeking.  The other when buffering pages of data.   Either could explain the issue with subtitles.

 

Hi used elkay14 modified files with kernel 3.1.6, but still same issue over NFS  :'(

 

//Peter

 

Is it safe to upgrade  5.0-beta14 ?

 

I am using version: 4.7, my server is HP Mini Server

I have running beta14 since it come out!

 

 

Hi used elkay14 modified files with kernel 3.1.6, but still same issue over NFS  :'(

 

Owch - I have no need for NFS, but this may be indicative of other problems still in the kernel.

Is it safe to upgrade  5.0-beta14 ?

 

I am using version: 4.7, my server is HP Mini Server

 

If that uses LSI SATA controllers then beta 13 and beta 14 are AVOID AT ALL COSTS.

I've heard no bad reports regarding the HP mini and any beta.

Anyone having problems with cache_dirs?

 

for some reason it keeps restarting in my logs

 

it seems to do this every 2 hours

 

only change is that I enabled NFS shares and connected my xbmc using nfs

syslog-2011-12-26.txt

Anyone having problems with cache_dirs?

 

for some reason it keeps restarting in my logs

 

it seems to do this every 2 hours

 

only change is that I enabled NFS shares and connected my xbmc using nfs

I would normally say to take this question to the user customizations forum, but since there are NFS errors being reported, this might add another clue.

 

cache_dirs is re-starting itself because it thinks you have stopped your array.

The logic in the code is:

  # If the array is now stopped, terminate cache_dirs and re-invoke later via "at"
 num_dirs=`find /mnt/disk[1-9]* -type d -maxdepth 0 -print 2>/dev/null|wc -l`
 if [ "$num_dirs" -eq 0 ]
 then
   if [ "$background" = "yes" ]
   then
     rm -f $lockfile
     echo scheduling via at $at_command  | logger -t$program_name
     echo $at_command " 1>/dev/null 2>&1" | at now + 1 minute
   fi
 fi

 

If there are no disk directories existing when running this command, it will:

   remove the lock-file (effectively causing the current cache_dirs to terminate itself)

   reschedule itself to restart in one minute.

 

It uses this command to check for the /mnt/disk* directories:

find /mnt/disk[1-9]* -type d -maxdepth 0 -print

It should print one line per assigned data disk in the array.

 

Apparently, when you are seeing it reset when using NFS, the disk shares are not showing up in the output of the "find" command.

All I can think of is the find command failing for some reason or another.

 

Great thanks

 

will try it out

 

If that uses LSI SATA controllers then beta 13 and beta 14 are AVOID AT ALL COSTS.

 

I am wondering if there is any connection between the LSI SATA controller problems and the NFS problems?

 

I do all of the uploading to my unRAID box via CIFS/SMB through my Win 7 box.  The NFS shares are all downloads to my NETGEAR NTV550 player.  I have had no problems with using NFS while streaming bluray's to the NTV550 with NFS.  But I have no hard disks connected to the PCI SATA add-in board.  (It is in my test platform for when I convert my FreeNAS box to unRAID so I can use it to preclear new drives.)  All of my disk are connected via the motherboard IDE connections.

 

If that uses LSI SATA controllers then beta 13 and beta 14 are AVOID AT ALL COSTS.

 

I am wondering if there is any connection between the LSI SATA controller problems and the NFS problems?

 

They are not related. Tracking the issue into the kernel changelog, the mpt2sas driver broke when a fast disk detection function was inserted into the source. I could not trace the origin of the NFS problem.

 

Bin running Beta 14 on my HP Micro server N40L with 3TB Hitachi drives now for 18 days with not a single error in the log. Minor issues that could be ignored, but so far so good. The only complained that I have is the writing speed to the array, it is a bit faster on the stable 4.7 version but then it could be that the Hitachi 3TB drives are slower then my Samsung 2TB drives. In any occasion whoever it was that wanted to know if it is save to update to beta version on the HP Micro server, for me it was a brilliant move to switch to beta 14 and get the 3TB drives working.

 

O2G

That is good to hear!

 

I am considering updating to Release 5.0-beta14

 

Connecting VGA monitor to HP mini server is too much hassle

 

 

I have never upgraded from the 12a beta, and I am experiencing the BLK_EH_NOT_HANDLED error.

 

Here are some questions I have:

 

1. Does anyone know if beta14, or earlier, solves the BLK_EH_NOT_HANDLED error?

2. What is the cleanest way to ensure I am starting from a stock build, meaning no plugins, while maintaining any configuration associated with the plugins? The only addons I have on the server are sabnzbd, couchpotato, sickbeard, the UPS plugin and uumenu.

 

I intended on following the directions here: http://lime-technology.com/wiki/index.php?title=UnRAID_Server_Version_5.0-beta_Release_Notes

 

Any other tips are appreciated.

 

Thanks,

-Chris

I have never upgraded from the 12a beta, and I am experiencing the eBLK_EH_NOT_HANDLED error.

 

Here are some questions I have:

 

1. Does anyone know if beta14, or earlier, solves the BLK_EH_NOT_HANDLED error?

 

I was running 5b12a on an MSI board with no problems. Changed to the X8SIL-F and within 1 day I started to get the BLK_EH_NOT_HANDLED..... errors. I also wasn't sure about b13 or b14. But decided what the heck. Upgraded to b14 and have been running rock solid now for 12days straight. Not one BLK error. I didn't read anything about it being solved, this is just my experience. Hope it helps and I hope you stop seeing the BLK error.

 

 

 

-Alex

 

 

Sent from my iPad using Tapatalk

I have never upgraded from the 12a beta, and I am experiencing the eBLK_EH_NOT_HANDLED error.

 

Here are some questions I have:

 

1. Does anyone know if beta14, or earlier, solves the BLK_EH_NOT_HANDLED error?

 

I was running 5b12a on an MSI board with no problems. Changed to the X8SIL-F and within 1 day I started to get the BLK_EH_NOT_HANDLED..... errors. I also wasn't sure about b13 or b14. But decided what the heck. Upgraded to b14 and have been running rock solid now for 12days straight. Not one BLK error. I didn't read anything about it being solved, this is just my experience. Hope it helps and I hope you stop seeing the BLK error.

 

I run the X8SIL-F too. Let's hope 14 performs some magic. As for the plugin's, what's the most correct way to ensure I am running 'stock' with no plugins? Do I disable them through uumenu then not start uumenu, or do I do something else?

 

Thanks so much for your help!