Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Update RALUS to support Linux kernel 3.0 ioctl()

Created: 02 Mar 2013 • Updated: 02 Mar 2013 | 2 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 2 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