BackupExec 12.5 and 2010 fails on CentOS 5.9

[AlJ]

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.

[AJ51]

Can you explain the fix, step 2 seems to be referenceing a lib that has been renamed in step 1?

[Captain_Bash]

Step 2 makes a link to a library in /lib64

Here's how I applied the fix line by line:

~ > cd /opt/VRTSralus/VRTSvxms/lib/map/

/opt/VRTSralus/VRTSvxms/lib/map/ > ll

total 256
-r-xr-x--- 1 root bin  52942 Apr  4  2011 libdisk.so
-r-xr-x--- 1 root bin  72900 Apr  4  2011 libext2fs.so
-r-xr-x--- 1 root bin  60135 Apr  4  2011 libgfsp.so
-r-xr-x--- 1 root bin  52942 Apr  4  2011 librawp.so
 

/opt/VRTSralus/VRTSvxms/lib/map/ > mv libext2fs.so libext2fs.so.old

/opt/VRTSralus/VRTSvxms/lib/map/ > ln -s /lib64/libext2fs.so.2 libext2fs.so

/opt/VRTSralus/VRTSvxms/lib/map/ > ll

total 256
-r-xr-x--- 1 root bin  52942 Apr  4  2011 libdisk.so
lrwxrwxrwx 1 root root    21 Jan 29 11:30 libext2fs.so -> /lib64/libext2fs.so.2
-r-xr-x--- 1 root bin  72900 Apr  4  2011 libext2fs.so.old
-r-xr-x--- 1 root bin  60135 Apr  4  2011 libgfsp.so
-r-xr-x--- 1 root bin  52942 Apr  4  2011 librawp.so

/opt/VRTSralus/VRTSvxms/lib/map/ > /etc/init.d/VRTSralus.init stop

Stopping Symantec Backup Exec Remote Agent ....
Stopping Symantec Backup Exec Remote Agent:                              [  OK  ]

/opt/VRTSralus/VRTSvxms/lib/map/ > /etc/init.d/VRTSralus.init start

Starting Symantec Backup Exec Remote Agent ......
Starting Symantec Backup Exec Remote Agent:                              [  OK  ]

/opt/VRTSralus/VRTSvxms/lib/map/ >

Hope that helps

[pentium3NL]

Dear Everyone, Thank you for this sollution, this SOLVED our problem. With symantec helpdesk they were still debugging on mountpoints when we made no changes there: -- code /etc/init.d/VRTSralus.init stop; sleep 5; mv /opt/VRTSralus/VRTSvxms/lib/map/libext2fs.so /home/user_admin/libext2fs.so.backup; ln -s /lib64/libext2fs.so.2 /opt/VRTSralus/VRTSvxms/lib/map/libext2fs.so; /etc/init.d/VRTSralus.init start Stopping Symantec Backup Exec Remote Agent ... Stopping Symantec Backup Exec Remote Agent: [ OK ] Starting Symantec Backup Exec Remote Agent ...... Starting Symantec Backup Exec Remote Agent: [ OK ]

[ikemay1337]

Fixed it for me too!

Thanks a ton, Vicente

[A_Gilmore]

[Edit]

This postponed the issue for me, but did not result in working backups. /lib64/libext2fs might have the same name, but does not provide the same code at all. 

Therefore, I'm having to downgrade my kernel version to get backups again. Boo.

[Old post below

This also solved this issue for me, after much hair pulling and concern. Breaking stuff in stable updates is pure suckiness. Vendors packaging obsolete copies of system libraries... also sucks.

It'd be nice if this got more visibility from both Redhat and Symantec for potentially impacted folks.

Kernel version 2.6.18-348.1.1.el5

Redhat Enterprise Linux 5.9

I've not explored if the 348.3.1 kernel build fixes this problem.]

[xeless_it]

We had got the infinite loop too with backup exec 2010 R3, and Fedora 19, kernel 3.x .

It started when we give a new drive to the linux. The BE couldn't list the folder.

Solution in our case:

reformat the ext3 fs to ext4 fs.