make_net_recovery problems

[Velda]

Dear all,
First basics : I have PARISC HPUX 11.23 machines.
I usually make OS backups on DAT tapes (of vg00 only) using make_tape_recovery command, and it works beautifully. No problem there.
BUT
I have two vpars which have no DAT access, and I thought to back up their vg00 with make_net_recovery command, and it did not work.
*********
Here is the sequence I used :
make_net_recovery -x inc_entire=vg00 -s my-ignite-server -a my-ignite-server:/location-on-ignite-server/my-client-HPUX
*********
And I got the following error message :
* Archiving contents of ds21d via tar to
/var/opt/ignite/recovery/arch_mnt/2009-09-07,11:39.

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

ERROR: The make_sys_image command failed. The system recovery archive will
not be created.
************
Now I looked up the used space for vg00 for both servers, and it is 19G and 27G. Used vg00 space on servers where I use make_tape_recovery is much bigger, and it is no problem.
Any ideas?

[Johnson Punniyalingam]

Hi ,

how about your Ignite Server got enough space ? to hold you ignite Client image while you perfrom the make_net_recovery ?

Example :-

My Ignite Server /var/opt/ingnite/recovery/archives.

/dev/vg00/lvol9 41943040 25813728 16003328 62% /var/opt/ignite/recovery/archives

Thanks,
Johnson

[Velda]

Dear Sir,
Thank you for the suggestion.
I will check, but I think it should be no problem, since free space on Ignite is 56G, and the user vg00 on vpar servers is 19G and 27G respectfully.

[Velda]

Hmm, tried again, and I closely followed the tar file that is the result of the make_net_recovery command.
The whole thing crashed when the resulting file was between 2-3G?????
There was more than ample space available on the location (more than 50G).

[Torsten. · Accepted solution]

Is the destination configured with "largefiles"?

[Velda]

YES!!!
Thank you, it is this problem.
And it got you 10 pts (would be more if I coud give you more) :-)))
*********
Now back to business :
I already have some files there (and it is a LVM FS). Also an entry in the /etc/fstab :
-------------------
/dev/vg_ignite/lvol_ignite1 /ignite_backup vxfs rw,suid,delaylog,datainlog 0 2
-------------------
Any URL with directions of turning this into FS fit for large files?

[Torsten.]

See

http://docs.hp.com/en/B3929-90011/ch01s16.html

...
You can switch capabilities on a mounted file system with the fsadm command:


# fsadm -F vxfs -o largefiles|nolargefiles mount_point

[Velda]

THNKS
If I understand it correctly with fsadm command I change it to "largefiles" online, but only until next restart.
If I want the state to be permanent, I have to change the /etc/fstab in something like this :
----------------
/dev/vg_ignite/lvol_ignite1 /ignite_backup vxfs rw,suid,largefiles,delaylog,datainlog 0 2
----------------
Please confirm, and onwards I go!
Just a little comment : I do not have online JFS... I think it does not matter, but a comment just in case...

[Dennis Handly]

>If I understand it correctly with fsadm command I change it to "largefiles" online, but only until next restart.

This is permanent.

>I do not have online JFS. I think it does not matter, but a comment just in case.

You don't need it.

[Velda]

Thank you!
I will do it at once.
If there are any problems (hope not!) I will post again, if not I will close the thread.
Best regards!

[Velda]

GRRRR
That is me being frustrated.
It did not work.
Broke at the same place, with the same massage.
Any ideas?

[Torsten.]

What is your ignite version (check with swlist)?

[Velda]

On a client machine :
--------------
GZIP version :
>gzip -V
gzip 1.3.5 (HP-UX fixlevel 1)
(2002-09-30)
--------------
>swlist -l product|grep Ignite
Ignite-UX C.7.6.98 HP-UX System Installation Services
--------------
Can there be a problem because I only did a fsadm, and not remounted, or re-exported the mountpoint?
Also I am thinking of excluding /var/opt/ignite from vg00. Maybe it will help.

[Velda]

also I caught it while working, and it is pulling a 1.3.5 gzip :
------------------------
>ps -axf|grep zip
root 1992 1989 244 15:00:55 pts/0 9:52 /usr/contrib/bin/gzip
------------------------

[Velda]

I also changer /etc/fstab and added "largefiles" for this mountpoint, and umoun+mount for it.
After this fsadm showed that largefiles is OK and active.
I have run out on ideas!

[Dennis Handly]

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

What version of ignite do you have?
The only way that old version of gzip will work on large files is with non-evil cats:
cat file | gzip | cat > file.gz

[Velda]

Dear Sir,
Thank you for the question.
The version of gzip is 1.3.5, which should be able to deal with files > 2G (at least according to ITRC forum comments).
Ignite version is given in my previous post :
>swlist -l product|grep Ignite
Ignite-UX C.7.6.98 HP-UX System Installation Services

[Dennis Handly]

>The version of gzip is 1.3.5, which should be able to deal with files > 2G

Ah yes, it is using largefile options.

>/usr/contrib/bin/gzip

Do you have another gzip in /usr/local/bin/ that is older? And you are invoking the wrong one?

[Velda]

No other gzip in /usr/local/bin, I checked this out.
How can I check from where is make_net_recovery pulling the gzip it uses?
PS I even looked up when it was running and it is pulling gzip from /usr/conrib/bin, and see this :
---------------------
myserver:/usr/contrib/bin>./gzip -V
gzip 1.3.5 (HP-UX fixlevel 1)
---------------------
So this should be OK.
And I am totally flummoxed...

[Dennis Handly]

>How can I check from where is make_net_recovery pulling the gzip it uses?

Try using tusc to trace it:
tusc -fp -ea -o tusc.out make_net_recovery ...

[Velda]

Thank you for the idea, but I do not have the tusc on my systems.
But I have looked with ps which gzip was active during the make_net_recovery command, and it is the one in /usr/contrib/bin, and it is 1.3.5

So no other ideas.
Gzip should be OK, largefiles flag should be OK, and I do not know what else to look for.

[Dennis Handly]

>I do not have the tusc on my systems.

Just download it:
http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.10/

[Velda]

Maybe some other time.
For this it is not needed, since it IS pulling gzip 1.3.5

I frankly have no ideas any more.

[Dennis Handly]

>I frankly have no ideas any more.

Besides tracing which programs are executing, tusc can show the actual system call that is getting that error and printing "gzip: stdout: File too large"

[Torsten.]

I'm not sure if you already tried to re-export / re-mount. Did you?