Video Screencast Help

Ralus with Kernel 3.x

Created: 19 Mar 2012 | 8 comments


I started a discussion about a issues with Arch Linux and Kernel 3.x last year:

The client was not supported by Symantec and kernel 3.0 was new.

Now I have the same problem with the supported platform debian. I get the error "GetIfAddrs(LINUX): failed err = 11" in beremote.log when I start VRTRalus.

Kernel:, 64 bit.

Is kernel 3.x not supported by backup exec?

Has anybody a linux system with Ralus and kernel 3.x?

I have BE 2010 R3



Comments 8 CommentsJump to latest comment

pkh's picture

So far from the discussions that I have read, kernel 3.0 is not supported.  Reverting to kernel 2.6 generally solves the problem.

michael.peter's picture

Argh, that is really annoying. Kernel 3.0 is released since 9 month.

I got this feeling, Symantec doesn't wont any linux customer. Otherwise I can't explain, why ralus is so outdated.

With 2010 R2 they didn't even support Debian.

I think I have to look for another Backup software with better Linux support.

pkh's picture

Debian 4 & 5 is supported by BE 2010.  See the SCL below

BE 2010|2010 R2|2010 R3 Software (SCL)

Have you taken a look at NetBackup which is more for heterogenous environment.

tjmcgrew's picture


I'm not sure why Symantec isn't fixing this issue, as it seems it should be a trivial fix. The issue is related to a bugfix in kernel 2.6.39 which changed the return value of 2 system calls.

I have successfully gotten this working on kernel 3.3.2 by applying the following kernel patch:

Maybe that will help you.

renato.envisia's picture


 I'm not very adept in Linux, how would I apply this kernel patch in Ubuntu?


tjmcgrew's picture

I'm not very familiar with the Ubuntu way of compiling a kernel, but reading might help you. 

jayaramk19831's picture

Hi michael

The issue of ERR=11 is because of an issue in the 2.x/3.0 version of the Kernel which causes incorrect error codes to be returned for some ioctl calls that beremote uses for its work. This has been seen specifically on Ubuntu and Debian Linux versions

Here is the bugzilla id which specifically mentions this issue.

You would have to patch the kernel with the fix specified in the above link through your Linux vendor so that beremote would not fail / crash with the current scenario even on 3.x kernel versions.

This has been seen on Debian and Ubuntu newer kernels so far so I would recommend you to get the latest kernel patches and then run RALUS on the system you are trying to take a backup of.



philweb's picture

Hi there,

Had the same problem. Instead of patching the kernel, i decided to patch BackupExec. Since kernel patching is a bit drastic.

Basically you just have to flip 2 bits. I consider this modification as safe, as the failing function call had no effect on older linux kernel versions either.

I documented my solution here:

Maybe someone at symantec reads this and considers removal or conditional call of the problematic call in the next agent release.