From: Farmer, John (john.farmer@tycohealthcare.com)
Date: Fri Mar 19 2004 - 13:40:50 EST
This summary is prepared from a query that was original submitted to
tru64-managers back on Feb 24th.
Thanks to those who replied. As usual Dr. Blinn was a great help and
offered some suggestions of things to try.
The systems running 5.1B (which were test not production) were unpatched. I
had reviewed the aggregate patch kit and did not locate any references to a
repair to vdump. However, as part of due diligence I applied the entire
patch kit and the problem went away.
Although not listed as a repair to vdump something in patch kit 3 resolved
the inaccurate vdump/vrestore problem. Dr. Blinn recalled mention of a
vdump problem that was introduced in an earlier patch kit and then repaired
in a later kit. In my case there were no patches installed to begin with.
The system had existed as a full install (all mandatory and all optional
components) from the 5.1B cd.
Additionally, I would like to note that the file command can be used as an
additional check that this problem is being encountered:
> # file /mnt/stage/disk.label {Source file}
> /mnt/stage/disk.label: commands text
> # file /usr6/stage/disk.label {Destination file}
> /usr6/stage/disk.label: data or International Language text
John Farmer
-----Original Message-----
From: Farmer, John
Sent: Tuesday, February 24, 2004 12:23 PM
To: 'tru64-unix-managers@ornl.gov'
Subject: Inaccurate copy of filesystem using vdump.
AlphaServer 4100 running 5.1B (far end of NFS mount) ( mount -t cdfs -o
nodefperm,noversion,rrip /dev/disk/cdrom0c /mnt)
AlphaServer GS60E running 5.1B (near end of nfs mount. i.e. the nfs client)
(mount -t nfs /mnt@ussc38.ussurg.com /mnt2)
I am attempting to copy a remotely mounted cdrom using vdump in the manner
described in the man pages for vdump. I have done this many times before
without incident so I am really unclear regarding what happened this round.
A file named disk.label on the target side of the copy does not accurately
match the file on the source side of the copy. (see below). The copy
contains only nulls.
# mount -t nfs /mnt@ussc38.ussurg.com /mnt2
# vdump -0 -u -f - /mnt2 | (cd /install2 ; vrestore -x -f -)
path : /mnt2
dev/fset : /mnt@ussc38.ussurg.com
type : nfsv3
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vrestore: Date of the vdump save-set: Tue Feb 24 11:32:17 2004
vrestore: Save-set source directory : /mnt2
vrestore: Target directory : /install2
vdump: Dumping 489381888 bytes, 1417 directories, 2414 files
vdump: Dumping regular files
vdump: Status at Tue Feb 24 11:33:00 2004
vdump: Dumped 489918690 of 489381888 bytes; 100.1% completed
vdump: Dumped 1417 of 1417 directories; 100.0% completed
vdump: Dumped 2414 of 2414 files; 100.0% completed
vdump: Dump completed at Tue Feb 24 11:33:00 2004
# cat /mnt2/stage/disk.label
[General]
Label=Tru64 8.1.7
Number=1
Size`0.0
ReservedSize0.0
# cat /install2/stage/disk.label
# exit
Script done, file is /usr/users/JFarmer/mntcopy.log
Any help would be appreciated. I was able to successfully copy the files by
issuing cp -pR but really need to know why the above failed.
John
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:54 EDT