SUMMARY: What is wrong with my commands?

From: Dr. Otto Titze, Kernphysik TUD, +49 6151 162916 <TITZE_at_ikp.tu-darmstadt.de>
Date: Mon, 02 Apr 2001 23:22:19 +0100 (CET)

Hi,

thanks to all who responded.

From: "Davis, Alan" <Davis_at_tessco.com>
From: "Thomas M. Payerle" <payerle_at_physics.umd.edu>
From: "Dr. Thomas.Blinn_at_Compaq.com" <tpb_at_doctor.zk3.dec.com>
From: alan_at_nabeth.cxo.dec.com

>A) The default partition size for the "a" partition was different than
>what was in the label, and you were editing the disklabel by opening
>the "a" partition (this is the default).
>
>To do what you were trying to do SAFELY, you must read the label off
>the disk using "disklabel -r" saving it to a file, then zero out the
>label on the disk, then re-write the label from the file to the disk
>with the "disklabel -R -r -t advfs /dev/rrz1a RZ28S <savedlabelfile>"
>or you might change the location or size of existing partitions and
>lose the file systems they contain.
 
Here I see my fault: I tried it with a label saved in a file but
I didn't zero the label before

>B) There was never a V3.5, and V4.0A is no longer supported. All you are
>seeing is something you BELIEVE used to work. The correct syntax for
>vdump is exactly what you wound up using; the syntax that you think
>used to work probably didn't. It would work with "tar" which works
>on directories, but not with vdump (or even perhaps dump), which wants
>to know what file system mount point you want to dump.
 
This is not quite true. Maybe there was no Version 3.5. But I used
exactly this command on a version 3.x on October 26, 1998 when I
was upgrading from version 3.something to V4.0 (as it now turns out)

>Alan Nabeth:
> re: B.
>
> It would seem something did change. Since I get the same
> symtom on V4.0D, V4.0G and V5.1, it would seem to be an
> intentional change that you'll have to deal with. Reporting
> it as a bug wouldn't do any good because V4.0A is long since
> unsupported. You might want to investigate the vdump manual
> page description of the -D option to see if that offers a
> work-around that is more convenient than using bare file
> system names.

Again thank you all!

Regards
Otto

PS: Regarding "V4.0A is no longer supported" does that mean that I
have no chance to go from V4.0 to V4.0A (and then go to V4.0d)?
Or could I find somewhere this patch/upgrade?

The problem on this old box are a lot of things installed and therefore
I had prefered the installupdate. (I have already on one disk a V5.1
installed and could of course start from this, or make a new install of
V4.0D, my other boxes go not higher than V4.0d yet)

------------
Original question was:

A)Problem manipulating disks:
With diskconfig disk was partitioned and ADVFS on rz1a. Forgot
boot. Tried as I did in the past(and that worked):

bash# disklabel -rw -t advfs /dev/rrz1a RZ28S sys rzaboot.advfs
bootrza.advfs
This gave the message:
disklabel: ioctl DIOCSDINFO: Open partition would move or shrink
Use alternate partition

What does this message mean? I tried different method with
disklabel also with a saved partition table file, always
unsuccessful. Why?
(Solution was to make it bootable with diskconfig)

B)Vdump | vrestore command:
The following command worked in the past (V3.5?) but not now
(V4.0A):

bash# cd /usr ; vdump -0f - . | (cd /r0d ; vrestore -xf -)
path : /usr
dev/fset : user_domain#user
type : advfs
advfs id : 0x321d799b.0007dd00.1
vdump: . is not a mounted fileset; mount fileset or use -D to dump.
vrestore: unable to use save-set; invalid or corrupt format

Why?
But this one works:

bash# vdump -0f - /usr | (cd /r0d ; vrestore -xf -)
path : /usr
dev/fset : user_domain#user
type : advfs
advfs id : 0x321d799b.0007dd00.1
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories

Did there something change?
Received on Mon Apr 02 2001 - 21:23:19 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT