make_net_recovery error:gzip failed file too large

[Jerry L. Sims]

*** The following make_net_recovery failed with error: "gzip failed, file too large"

/opt/ignite/bin/make_net_recovery -s it-hp36 -a it-hp36:/IUXarchives/it-hp21 -x inc_entire=vg00

*** This is the output:

======= 01/25/04 01:00:08 PST Started /opt/ignite/bin/make_net_recovery. (Sun
Jan 25 01:00:08 PST 2004)
@(#) Ignite-UX Revision B.4.4.29
@(#) net_recovery (opt) $Revision: 10.611 $


* Testing pax for needed patch
* Passed pax tests.
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
0306E2C4676/recovery/2004-01-25,01:00/system_cfg vg00
* Backing Up Volume Group /dev/vg00
* /usr/sbin/vgcfgbackup /dev/vg00
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
* Creating Map Files for Volume Group /dev/vg00
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg00.mapfile /dev/vg00
vgexport: Volume group "/dev/vg00" is still active.

* Backing Up Volume Group /dev/vg01
* /usr/sbin/vgcfgbackup /dev/vg01
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
* Creating Map Files for Volume Group /dev/vg01
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg01.mapfile /dev/vg01
vgexport: Volume group "/dev/vg01" is still active.

* Backing Up Volume Group /dev/vg02
* /usr/sbin/vgcfgbackup /dev/vg02
Volume Group configuration for /dev/vg02 has been saved in /etc/lvmconf/vg02.conf
* Creating Map Files for Volume Group /dev/vg02
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg02.mapfile /dev/vg02
vgexport: Volume group "/dev/vg02" is still active.

* Backing Up Volume Group /dev/vg03
* /usr/sbin/vgcfgbackup /dev/vg03
Volume Group configuration for /dev/vg03 has been saved in /etc/lvmconf/vg03.conf
* Creating Map Files for Volume Group /dev/vg03
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg03.mapfile /dev/vg03
vgexport: Volume group "/dev/vg03" is still active.

* Backing Up Volume Group /dev/vg04
* /usr/sbin/vgcfgbackup /dev/vg04
Volume Group configuration for /dev/vg04 has been saved in /etc/lvmconf/vg04.conf
* Creating Map Files for Volume Group /dev/vg04
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg04.mapfile /dev/vg04
vgexport: Volume group "/dev/vg04" is still active.

* Backing Up Volume Group /dev/vg05
* /usr/sbin/vgcfgbackup /dev/vg05
Volume Group configuration for /dev/vg05 has been saved in /etc/lvmconf/vg05.conf
* Creating Map Files for Volume Group /dev/vg05
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg05.mapfile /dev/vg05
vgexport: Volume group "/dev/vg05" is still active.

* Backing Up Volume Group /dev/vg07
* /usr/sbin/vgcfgbackup /dev/vg07
Volume Group configuration for /dev/vg07 has been saved in /etc/lvmconf/vg07.conf
* Creating Map Files for Volume Group /dev/vg07
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg07.mapfile /dev/vg07
vgexport: Volume group "/dev/vg07" is still active.

* Backing Up Volume Group /dev/vg08
* /usr/sbin/vgcfgbackup /dev/vg08
Volume Group configuration for /dev/vg08 has been saved in /etc/lvmconf/vg08.conf
* Creating Map Files for Volume Group /dev/vg08
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg08.mapfile /dev/vg08
vgexport: Volume group "/dev/vg08" is still active.

* Backing Up Volume Group /dev/vg09
* /usr/sbin/vgcfgbackup /dev/vg09
Volume Group configuration for /dev/vg09 has been saved in /etc/lvmconf/vg09.conf
* Creating Map Files for Volume Group /dev/vg09
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg09.mapfile /dev/vg09
vgexport: Volume group "/dev/vg09" is still active.

* Backing Up Volume Group /dev/vg10
* /usr/sbin/vgcfgbackup /dev/vg10
Volume Group configuration for /dev/vg10 has been saved in /etc/lvmconf/vg10.conf
* Creating Map Files for Volume Group /dev/vg10
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg10.mapfile /dev/vg10
vgexport: Volume group "/dev/vg10" is still active.

* Creating Control Configuration.
* Creating Archive File List
* Creating Archive Configuration

* /opt/ignite/bin/make_arch_config -c /var/opt/ignite/recovery/client_mn
t/0x00306E2C4676/recovery/2004-01-25,01:00/archive_cfg -g /var/opt/ign
ite/recovery/client_mnt/0x00306E2C4676/recovery/2004-01-25,01:00/flist
-n 2004-01-25,01:00 -r 64 -d Recovery\ Archive -L
/var/opt/ignite/recovery/arch_mnt -l it-hp36:/IUXarchives/it-hp21 -i 2
-m t
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Networking Archive

* /opt/ignite/data/scripts/make_sys_image -d
/var/opt/ignite/recovery/arch_mnt -t n -s local -n 2004-01-25,01:00 -m
t -w /var/opt/ignite/recovery/client_mnt/0x00306E2C4676/recovery/2004-
01-25,01:00/recovery.log -u -R -g /var/opt/ignite/recovery/client_mnt/
0x00306E2C4676/recovery/2004-01-25,01:00/flist -a 4833590

* Preparing to create a system archive
* The archive is estimated to reach 2416795 kbytes.
* Free space on /var/opt/ignite/recovery/arch_mnt
after archive should be about 9214413 kbytes.

* Archiving contents of it-hp21 via tar to
/var/opt/ignite/recovery/arch_mnt/2004-01-25,01:00.

gzip: stdout: File too large
ERROR: The gzip command failed (exit status 1)
ERROR: The gzip command failed (exit status 1)

ERROR: The make_sys_image command failed. The system recovery archive will
not be created.


======= 01/25/04 01:14:41 PST make_net_recovery completed unsuccessfully

*** This is output from IUXserver ( it-hp36 )
showing file size reaching about 2.1Gb, also it
shows other clients that executed successfully.

/IUXarchives/it-hp21
total 6546536
drwxr-xr-x 2 bin bin 96 Jan 26 09:23 .
drwxr-xr-x 8 root root 2048 Jan 23 16:26 ..
-rw------- 1 bin sys 1205420701 Jan 22 14:54 2004-01-22,14:40
-rw------- 1 bin sys 2142371840 Jan 26 09:36 2004-01-26,09:22

/IUXarchives/it-hp22:
total 3727916
drwxr-xr-x 2 bin bin 96 Jan 25 02:00 .
drwxr-xr-x 8 root root 2048 Jan 23 16:26 ..
-rw------- 1 bin sys 954465207 Jan 22 15:19 2004-01-22,15:09
-rw------- 1 bin sys 954207451 Jan 25 02:10 2004-01-25,02:00

/IUXarchives/it-hp23:
total 5395024
drwxr-xr-x 2 bin bin 96 Jan 25 03:00 .
drwxr-xr-x 8 root root 2048 Jan 23 16:26 ..
-rw------- 1 bin sys 1380632466 Jan 22 15:41 2004-01-22,15:28
-rw------- 1 bin sys 1381601206 Jan 25 03:13 2004-01-25,03:00

/IUXarchives/it-hp37:
total 5986704
drwxr-xr-x 2 bin bin 96 Jan 25 04:00 .
drwxr-xr-x 8 root root 2048 Jan 23 16:26 ..
-rw------- 1 bin sys 1532593463 Jan 22 16:14 2004-01-22,16:01
-rw------- 1 bin sys 1532579429 Jan 25 04:13 2004-01-25,04:00

/IUXarchives/it-hp38:
total 3476476
drwxr-xr-x 2 bin bin 96 Jan 25 05:00 .
drwxr-xr-x 8 root root 2048 Jan 23 16:26 ..
-rw------- 1 bin sys 889834019 Jan 23 14:44 2004-01-23,14:34
-rw------- 1 bin sys 890100574 Jan 25 05:10 2004-01-25,05:00

*** I utilized "fsadm" to changes it-hp36:IUXarchives to "largefiles":

it-hp36 [/]# fsadm -F vxfs /IUXarchives
largefiles

*** but I continue to get the same error. If I execute the following command to make client
( it-hp21:/var ) smaller it works fine:
/opt/ignite/bin/make_net_recovery -s it-hp36 -a it-hp36:/IUXarchives/it-hp21 -x inc_entire=vg00 -x exclude=/var/opt/ignite/recovery/archives/it-hp36 -P s

Please advised. Thanks

[Jeff Schussele]

Hi Jerry,

Here's my pet-peeve again!
It's because gzip 1.2.4 is bundled with the OS & it will not reliably handle +2GB files.
You need gzip 1.3.1 or higher - gzip 1.3.5 is available here:

http://hpux.cs.utah.edu/hppd/hpux/Gnu/gzip-1.3.5/

1.3.1 & 1.3.3 are available at gnu.org.

A Note: They will install into /usr/local/bin by default, but Ignite expects to see gzip in /usr/contrib/bin. The install can be redirected into /usr/contrib/bin at install - you just have to specify the location.

Maybe one day HP will come into the 21st century with gzip - I HOPE!!!

Rgds,
Jeff

[Robert-Jan Goossens]

Hi,

Just a shot in the dark, after you have executed the fsadm command to enable large files, did you REexport the filysystem ?

Robert-Jan

[Jerry L. Sims]

Jeff, thnaks for the info:
1)*** How do I tell what release of "gzip" I have on my 11i system? I executed the following command, but it does not indicate
version "1.2" or "1.3":
# swlist -l fileset | grep -i gzip
SW-DIST.GZIP B.11.11.0112 Gnu gzip Tools

2)*** from the gnu site they have PA-RISC
for 11.0, but not for 11i. is 11.0 ok?

Robert, thanks for reviewing the message:
1)*** yes, I did execute the exportfs -av

[Jeff Schussele · Accepted solution]

Hi (again) Jerry,

gzip -V

Rgds,
Jeff

[Jeff Schussele]

Sorry - forgot question #2.

YES - the 11.0 ver runs fine on 11.11 (11i ver 1).

Jeff

[Jerry L. Sims]

Hello Jeff,

***I don't believe the gzip installed correctly? It only installed (2) filesets, which looks like man pages.
I still show the following :

# gzip -V
gzip 1.2.4 (18 Aug 93)
Compilation options:
DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H

*** out put from /var/adm/sw/swagent.log:
======= 01/26/04 12:15:47 PST BEGIN install AGENT SESSION (pid=12147)

* Agent session started for user "root@it-hp36.peoplesoft.com".
(pid=12147)

* Beginning Analysis Phase.
* Source: it-hp36.peoplesoft.com:/depot/patches
* Target: it-hp36:/
* Target logfile: it-hp36:/var/adm/sw/swagent.log
* Reading source for product information.
* Reading source for file information.
* Executing preDSA command.
NOTE: The used disk space on filesystem "/usr" is estimated to
increase by 400 Kbytes.
This will leave 1664200 Kbytes of available user disk space
after the installation.
NOTE: The used disk space on filesystem "/var" is estimated to
increase by 32 Kbytes.
This will leave 4310376 Kbytes of available user disk space
after the installation.

* Summary of Analysis Phase:
* 2 of 2 filesets had no Errors or Warnings.
* The Analysis Phase succeeded.


* Beginning the Install Execution Phase.
* Filesets: 2
* Files: 34
* Kbytes: 263
* Installing fileset "gzip.gzip-MAN,r=1.3.5" (1 of 2).
* Installing fileset "gzip.gzip-RUN,r=1.3.5" (2 of 2).
* Running install clean command /usr/lbin/sw/install_clean.
NOTE: tlinstall is searching filesystem - please be patient
NOTE: Successfully completed

* Beginning the Configure Execution Phase.

* Summary of Execution Phase:
* 2 of 2 filesets had no Errors or Warnings.
* The Execution Phase succeeded.


======= 01/26/04 12:17:04 PST END install AGENT SESSION (pid=12147)

*** whats in depot :
it-hp36 [/var/adm/sw]# swlist -d @ /depot/patches
# Initializing...
# Contacting target "it-hp36"...
#
# Target: it-hp36:/depot/patches
#

#
# Bundle(s):
#

GOLDAPPS11i B.11.11.0312.4 Gold Applications Patches for HP-UX 11i v1, December 2003
GOLDBASE11i B.11.11.0312.4 Gold Base Patches for HP-UX 11i v1, December 2003
#
# Product(s) not contained in a Bundle:
#

gzip 1.3.5 gzip

[Geno Church_1]

Are we sure it's a gzip issue....Could it be the default ulimit is not large enough. Try setting the ulimit to ulimit 9999999 and try it again.

Geno

[Chris Watkins_1]

I'm not convinced it's a gzip issue either.
I have on my ignite server, an archive of around 6GB
(An old test server that has but a single large drive)

I am runing the same version of gzip as the author here.

umount the filesystem from the remote machine(s),
exportfs -u the filesystem, umount it locally, and remount...
then export it again. (or simply re-run your command again)

I do believe that "largefiles" as a mount option is now
ignored by the OS... but if it makes you feel better, do:
mount -o remount,largefiles=true,more_options /IUXarchives
(If no onlinejfs, just umount and remount with largefiles=true)

Then it will show from a "mount" command as being "largefiles" enabled.
(Whether or not the OS ever cares about seeing it, I dunno.
I have tried it both ways and notice no difference here)

[Jeff Schussele]

Hi Geno/Chris,

Believe what you wish, but go back & read the org error msgs - they all point to gzip - period. Also in my first post note the word "reliably" - sometimes it handles them & sometimes it doesn't.

I submitted a JAG to HP almost a FULL year ago - JAGae63284 - with no action to date. After that I submitted an enhancement request - still NO action. I've even petitioned the author to "bless" gzip 1.3.1 as a "stable" release because I now believe that's why HP is dragging it's feet on this. For God's sake 1.3.1 has been released for OVER 2 years - I think it's stable. I've NEVER had a hiccup out of it. My DBAs love it & abso-freaking-lutely *hated* the 1.2.4 for compressing their dumps because it worked one day & not the next. Is that the kind of tool you want to rely on?

Believe me, the problem IS there. Find your self a +2GB file & try to gzip it & see what happens. It simply is not up to the job of *consistently* handling large files.

Jerry - Yes, there's only two filesets MAN & RUN in the pkg. If you successfully installed into /usr/contrib/bin try the Ignite again & let us know the results.

Rgds,
Jdeff