01-15-2013 01:11 PM
We have been successfully running 2 Linux backups (CentOS 5) for years. Last week the administrator ran updates and broke the backups. The 12.5 agent aborts when you try to access it. I updated one of the servers to the 2010 agent (all patches), the agent does not abort, but also does not work properly. BE 12.5 can't connect to the Linux agent at all, BE 2010 seems to go into some sort of loop when trying to access the agent. I can see the initial [ROOT] entry but any attempt to display its contents results in a very long wait and eventual abort of BE 2010. I cannot try a kernal rollback until this weekend, so wanted to see if anyone has another idea.
01-15-2013 03:05 PM
Hi
Try uninstalling remote agent and reinstalling 12.5 remote agent back and then check
Also ensure the root is part of beoper group as it should be added automatically when remote agent is installed
Ensure your opt\vrtsralus directory is given more permission and then check if that helps
I presume when you telnet on port 10000 vice versa it is working
Additionally with BE2010 when using the agent try disabling the ipv6 on the centos and then check to see if that helps
CentOS is not on the compatibility list of BE12.5 and BE2010:
http://www.symantec.com/business/support/index?page=content&id=TECH137682
Hope that helps
Thanks
01-15-2013 03:19 PM
Same as Red Hat so compatibility shouldn't be an issue, has been working for years, until the last kernel update. I did another debug display and found that the directory listing goes into an endless loop, finding the same files and folders over and over and over, I'm sure this is what eventually blows up BE. Will try uninstalling and reinstalling, but if you have any other thoughts please let me know. Thanks.
01-22-2013 04:13 AM
i can confirm it is a kernel issue. the agent is not working on kernel 2.6.18-348.el5 . after booting into 2.6.18-308.16.1.el5 it is working again. it is reproducible by creating a new backup selection list and browse the server. after clicking [root] the gui freezes. when examining the output of /opt/VRTSralus/bin/beremote --log-console it looks like there is an infinite loop browsing the contents of / . it starts with VX_FindFirst and will continue to loop through the contents of root with VX_FindNext . it never reaches FS_NO_MORE .
01-22-2013 06:56 AM
The problem system is actually RHEL and not CentOS, but the kernel version is the same. I wonder if it is a RHEL or Symantec issue and who gets to fix it?
01-22-2013 07:00 PM
BE 12.5 supports RHEL 5.0 to RHEL 5.2. See the SCL below
If you are running these OS's, you can log a formal support case with Symantec.
However, if you are running newer updates of RHEL, i.e. newer than RHEL 5.2, or CentOS, then you are on your own because these are not supported. From the title of your post, you are either running RHEL 5.9 or CentOS 5.9, both of these are not supported by BE 12.5. Neither does BE 2010 support them.. Even BE 2012 does not support RHEL 5.9, only up till RHEL 5.8. See the SCL's below
01-22-2013 11:48 PM
i think we know there is no official support for rhel/centos 5.9. on the other hand, more and more users will update their 5.8 servers to 5.9 and it would be a positive gesture from symantec to provide a patch (or workaround) for this issue. in time they will have to support 5.9 anyway and to my opinion the possibility of entering an infite loop is a bug in the software anyway. It will put all the backup jobs on hold as a backup of a 5.9 system will hang infinite on 365 bytes. the bug is in the listing of the root filsystem (as stated earlier) and should be very easy to reproduce and fix.
01-23-2013 12:01 AM
David: Add this in as an idea on the link below:
https://www-secure.symantec.com/connect/backup-and-recovery/ideas
Enough votes and it might be considered for a future release.
Thanks!
01-23-2013 05:13 AM
I can confirm it, too. With the kernel 2.6.18-348.el5 we have the same problem, Backup freezed at 365 byte. If you use a 32Bit Kernel 2.6.18-348.el5PAE there is no problem.
01-24-2013 12:40 AM
Hi,
thanks for the suggestion, but i don't think this fits in the category "ideas". I know 5.9 is not supported by symantec, but a simple bugfix would keep customers happy instead of ending up with lots and lots of frustrated customers who end up with big issues after doing "yum update". what is more simple than debugging an infinite loop issue? it would take a programmer 15 minutes to fix i assume.
david
01-24-2013 12:56 AM
If possible to test on a test system, try installing the following path & install RALUS ~
https://bugzilla.kernel.org/show_bug.cgi?id=33992
01-24-2013 05:13 AM
I dont' think this will help as the kernel version has not changed, only redhat patches have been applied during the upgrade. This also makes it more difficult to apply this patch to the running kernel. looking through the changelist , maybe this fix is related to the issue:
https://bugzilla.redhat.com/show_bug.cgi?id=814418
01-24-2013 05:18 AM
Does anyone know if BE2012 is affected? May just be time for an upgrade.
01-28-2013 02:06 AM
We too have this issue.
It's all very well saying that 5.9 is not supported... compatibility list... bla bla bla...
Please Symantec listen to your customers and GET IT SUPPORTED!!
I could understand if you were only going to support RHEL 6/7 on 2012, but a minor kernel update like this for a currently supported O/S should get support for current BE 2010 r3. Especially seeing as how there's quite a big fuss around the way the new BE 2012 works.
If microsoft can prolong support for XP, then you can prolong support for 2010 !
01-28-2013 03:31 AM
a workaround seems to be to use the 32 bits ralus agent (VRTSralus-13.0.5204-0.i386.rpm). I removed the 64bits package and installed this package, manually created the directory /opt/VRTSralus/data/ and reestablished the trust relationship.
after this the agent is working. you might have to install some extra compat* packages for the 32 bit agent to work.
it would still be nice if symantec could fix the issue in the 64 bits version... i did some research with strace, but could not find anything. must be some sort of memory issue i assume.
01-29-2013 02:04 AM
Yes looks like this may be a kernel issue then in fact:
Backed up 12522668 files in 1 directory.
Yeah. it's backing up the same 2 files in / over and over again.
01-29-2013 02:39 AM
SOLVED
You have move library
mv /opt/VRTSralus/VRTSvxms/lib/map/libext2fs.so /opt/VRTSralus/VRTSvxms/lib/map/libext2fs.so.bak
You have create symbolic link to library S.O.
/opt/VRTSralus/VRTSvxms/lib/map/libext2fs.so -> /lib64/libext2fs.so.2
01-29-2013 03:17 AM
solved indeed! much better than the 32 bits solution.
thanks,
david
01-29-2013 03:35 AM
Whoo hoo!
Confirmed as working! Thankyou Vicente!!
Seems a bit of a dirty fix mind, but anyone from Symantec care to comment on why this works??
01-29-2013 04:10 AM
...they might not hey, especially if it is unsupported for now...