Video Screencast Help

Update RALUS to support Linux kernel 3.0 ioctl()

Created: 02 Mar 2013 • Updated: 02 Mar 2013 | 3 comments
frio's picture
5 Agree
0 Disagree
+5 5 Votes
Login to vote

Even though the enterprise is going little slower than desktop distributions, upcoming versions of currently supported distributions will also start shipping kernels based on > 3.0. A behaviour of ioctl() has changed and RALUS 14.0.798SP1 fails to start with a segfault.

Debian wheezy (Linux 3.2) and RHEL 7 (as it is based on Fedora 18) will also be using Kernels > 3.0.
While Ubuntu was supported until 11.10, the current LTS release has remained unsupported until now.
(Actually Linux kernel 3.0 has been out into the wild since Summer 2011...)

Currently no RALUS version exists that would support execution of the agent without some ugly hacks.
The link to the following blog has been posted a couple of times in the forums:

Locally patching kernels (and mantaining) kernels to old behaviour is unacceptable on production system thus it should definitley be on the application side to adopt this change. "Hacking" the RALUS agent isn't really an option too (and for sure this is unsupported and unsupportable by Symantec support)

Comments 3 CommentsJump to latest comment

Artegic's picture

I'm testing RALUS 14.0.1798.1364 from BE 2012 SP4 with kernel 3.12.1-1.el6.elrepo.x86_64 and so far it works fine. No segfault. So the issue appears to be fixed even though nobody from Symantec seems to want to commit to that.

Note that Symantec does not "support" Linux kernels or releases thereof, only specific versions of specific Linux distributions. Therefore the question of whether RALUS supports kernel 3.x does not make sense to a Symantec support engineer. You'll have to pick an enterprise distribution that already runs on a 3.x kernel and then ask Symantec to support RALUS for that distribution.

Login to vote
Artegic's picture

RALUS from BE 2012 SP4 continues working perfectly fine on a server with kernel 3.12. So I guess this idea may be considered implemented even though Symantec won't admit it.

Login to vote
chaos_prevails's picture


I can confirm that RALUS from BE 2012 SP4 (with or without the hotfixes):

  • 1366HF215906
  • 1368HF216746
  • 1373HF217347

(look here for a nice overview and find the hotfixes in C:\Program Files\Symantec\Backup Exec\Agents)

works again with Kernel >= 3.x (specifically with Ubuntu 14.04.2 LTS, whether its on the SCL or not). So no need any more to patch, just install the RALUS, then SP4 and then optionally the Hotfixes.

But: there is another nasty bug which took me quite some time to figure out: the hostname should not be too long, otherwise it gets mangled and the backup fails with

Backup- \\servername_mangled.domain_mangled.TLD\[ROOT]V-79-57344-33967 - Directory not found. Cannot backup directory /\servername.domain.TLD\[ROOT] and its subdirectories.

The hostname gets mangled as soon as it exceeds a certain length. I guess probably related to this bug from Netbackup client where a hostname should not be longer than 12 characters?:

So a server which you named say "raluslunatic" in your domain and you would add it as "" becomes "" (last letter of host left out, a "t" added to your domain - at least in my case). If you look into your "Backup and Restore" Tab under "All Servers" your server is shown twice: once with the correct name, once with the mangled name.

As soon as I added the server with just the hostname (e.g. raluslunatic, without the domain and TLD) it worked flawlessly (at least so far after a weekend backup).

I just filed a bug here (didn't find any place else where to file a bug for BE ...):

Login to vote