AIX

Hello,

Getting this very strange error, made tar/zip through gnu tar

GNU Tar ( successful tar and zip without any errors )

Code:

/opt/freeware/bin/tar cvf -  /oraapp| gzip > /backup/bkp_15_6_16_oraapp.tgz

GNU unTar error

Code:

root@test8:/>gunzip < /config1/bkp_15_6_16_oraapp.tgz | /opt/freeware/bin/tar xvf -
/opt/freeware/bin/tar: This does not look like a tar archive
/opt/freeware/bin/tar: Skipping to next header
/opt/freeware/bin/tar: Archive contains obsolescent base-64 headers

(break CTRL+C)
root@test8:/>/opt/freeware/bin/tar --version
tar (GNU tar) 1.14

Native AIX unTar error

Code:

root@test8:/config1>gunzip < /config1/bkp_15_6_16_oraapp.tgz  | tar xvf -
tar: 0511-169 A directory checksum error on media; 804399264 not equal to 13879.

If I tar using native AIX tar and untar it using Native AIX tar it works fine, however, if I use GNU Tar to tar it and GNU Tar to untar it, it fails. The reason for using GNU Tar is getting files larger than 2GB

What could be the problem / issue ?


Note:
- File is not corrupt
- FTP was in binary mode
- ulimit size is -1
* works if I use native AIX tar and native AIX untar but fails if I use GNU tar.

Taking the other threads you opened into account which all seem to pertain to the same problem it is quite clear: your system is - for unknown reasons (probably some problem during package installation, but not enough data to verify that) - missing some of the shared libraries the GNU-tar binary relies on. This is why it can't do what it is supposed to do and this is why it can't process your tar-file.

It works like this: GNU-tar calls upon a function "somefunction()", but doesn't contain the code for it. Instead it relies on this code being stored somewhere else on the system (a so-called "shared library", because such files usually contain not only the code for this one but for many such functions). The normal proceedings would now be for tar to load the code representing this function from the library and then execute it. But somehow, in your case, it can't - and because this "somefunction()" is vital to the function of tar - it doesn't get done anything.

So far the general analysis of your problem. Now we need to find out what exactly is holding tar from loading the code for the function from the shared lib. There are several possible reasons:

1 - tar doesn't know where the lib is: any program is guided to the place where it can find the libraries it needs by the variable "LIBPATH" and/or "LD_LIBRARY_PATH". The format is the same as the PATH variable: a list of directories separated by a colon: /some/dir1:/some/dir2:.....

2 - tar can't read the library: maybe the user tar is started with isn't allowed to read the library - check and make sure the "r"-flag is set for world for shared libraries.

3 - The library is really missing: in this case you need to install it somehow. tar itself doesn't care how the library gets there, so install a package or even just copy the file (for test purposes! You don't want that to be a lasting state.) All this means you have to find out which libaries are missing.

I hope this helps.

bakunin

1. Did you try to test tar file on the same server after you have created it?
2. Why do use two commands? GNU tar has an option z - tar [cxt]zf is simpler.

GNU Tar works on the same server which I have created on
Source Server has

Code:

root@oraapp:/backup>lslpp -l | grep rpm.rte
  rpm.rte                   3.0.5.36  COMMITTED  RPM Package Manager
  rpm.rte                   3.0.5.36  COMMITTED  RPM Package Manager
root@oraapp:/backup>oslevel -r
5200-05

root@oraapp:/backup>

Doesn't work on Target Server -1

Code:

oraprod@clodb:/backup>lslpp -l | grep rpm.rte
  rpm.rte                   3.0.5.51  COMMITTED  RPM Package Manager
  rpm.rte                   3.0.5.51  COMMITTED  RPM Package Manager
oraprod@clodb:/backup>
oraprod@clodb:/backup>oslevel -s
/usr/bin/oslevel[627]: /tmp/sh18153548.13: 0403-005 Cannot create the specified file.
oraprod@clodb:/backup>oslevel -r
/usr/bin/oslevel[627]: /tmp/sh18153550.13: 0403-005 Cannot create the specified file.
oraprod@clodb:/backup>

Also, doesn't work on Target Server -2

Code:

#lslpp -l | grep rpm.rte
  rpm.rte                   3.0.5.36  COMMITTED  RPM Package Manager
  rpm.rte                   3.0.5.36  COMMITTED  RPM Package Manager
#oslevel -s
5300-01-00-0000
#oslevel -r
5300-01

2. Why do use two commands? GNU tar has an option z - tar [cxt]zf is simpler.[/QUOTE]

I will try this and will update you.

Using tar on different systems, or different point revisions of tar from the same vendor, or different versions completely (eg, Sun vs GNU) do not guarantee compatibility.

Generally, you can create a tar archive on one system which, when transferred to another system, might not unpack. The thing to do is that if you cannot extract an archive using a specific tar utility, try another one.

For example, read this:

@LongLink When Using Tar In Solaris | Little Handy Tips

You see that the actual pathname length is not compatible in this example (giving @longlink error) but a change to GNU gtar works fine.

Having such issues with different tar versions is no surprise.

bakunin, agent.kgb, hicksd8

on the same machine where i made backup and when i tried to restore on the same machine i got this error

Code:

root@cloapp1:/pcloneapp>/opt/freeware/bin/tar xvzf pclo_cloapp1_18_6_16_oraapp.tgz
/opt/freeware/bin/tar: This does not look like a tar archive
/opt/freeware/bin/tar: Skipping to next header
/opt/freeware/bin/tar: Archive contains obsolescent base-64 headers

My guess, is that since the this DISK is coming from IBM SAN Storage and the cache battery is dead, and I enabled "Enable Write Caching without Batteries" is the reason for above data corruption ?
I am not sure but investigating further.


agent.kgb, thanks for the z option with gnu tar

---------- Post updated at 06:28 AM ---------- Previous update was at 06:00 AM ----------

agent.kgb,
how would you combine gnu tar -z or -Z (compression) backup and restore with tee command ?

as was done by Rudic over here