Hello Manager,
First let me apologize for not posting the summary for about a week and
a half, I had jury duty right after, and had no time to summarize.
Which also explains some of the results.
Secondly, let me thank the following people for their responses and
help:
Ian Mortimer
Robert Carsey
Kevin Partin
Chris H. Ruhnke
Colin Walters
William J. Bochnik
Larry Clegg
John Ziomek
alan_at_nabeth.cxo.dec.com
Special thanks to the following, because they provided me with explicit
instructions and/or continued correspondence with me when I ran into
trouble
Dr Tom Blinn
David J. DeWolfe
John J. Francini
Thirdly, I'd like say, with all the help I had, nothing worked. Not to
say the advice was bad, but we were in a terrible rush, and I'd like to
belive that the machine was _especially_ tempermental.
The quick summary everyone agreed with: No, do not use the 4.0f disk to
boot and create AdvFS filesystems if you put 5.0a on it afterwards,
reason being, they are not really compatible. What we ended up doing
since I was not able to resize the / partition is to make /tmp a
parition on its own. This quick and simple solution allowed us the
system to function the way we needed.
Here are some good words of advice for those of you who search through
the archives for help, because they are excellent help.
---from Dr. Tom Blinn-----
The on-disk AdvFS format differs between V4.0x and V5.0A. You really
don't want to use V4.0F to reconfigure the system. However, since you
have a second disk, why not just configure the second disk as you would
have configured the first one (set up the partitions, create the AdvFS
domains and file systems, etc.), then copy the system image from your
existing disk to the new one, then swap disks. Because it's V5.x, you
will need to update the disk names, since what was dsk0 needs to be now
dsk1, and you want to be sure you find all the places (/etc/fstab, the
/etc/fdmns directories maybe, /etc/sysconfigtab will have references to
the swap partition, and so on). Then use the new disk to reconfigure
the old disk, if you like, and move everything back.
You might even just set up the new disk with enough of a system to be
able to hold a full backup of the existing disk, then boot off the new
disk, reconfigure the old disk, restore the backup, and you would be
in business.
--- 2nd response from Dr. Tom Blinn----
It's not really completely obvious. The simplest way is probably to use
"dd" on the raw disk:
dd if=/dev/rdisk/dsk0c of=/dev/rdisk/dsk1c bs=32k
It's best to do this in single user mode with everything except the root
file system unmounted; that way you only need to fsck the root partition
of the target disk (and with AdvFS you don't need to do that). This
makes
an exact disk block to disk block copy. But things like the /etc/fstab
and /etc/fdmns links and /etc/sysconfigtab in the copy still point to
the
original (dsk0) disk, and you have to go find those references and fix
them up.
This only works, BTW, if the target disk has a zero-d disklabel, as it's
going to copy the label as well from the source disk.
Anyway, once you get things copied, you can then boot off the copied
disk,
reorganize the original disk, changing the partitions, re-establish all
of
the AdvFS file systems on the original disk, then use vdump and vrestore
to copy the file systems over. You should also be able to use tar or
any
other archiver, but vdump piped to vrestore is the best bet. And if you
want to make it relatively easy, since you've probably got a LOT of
space
on the "copy" disk, make vdump backups into a file FIRST before you copy
over the disk -- they will get copied along with everything else, but
they
will not have the changed fstab etc. from the copy disk, and then you
can
just restore them onto the original disk once you reorganize it, and you
will have your original file systems back, etc.
After you've done this once or twice, it becomes easy; the first time it
will be hard. So I do encourage the "back everything up" method.
---3rd response from Dr. Tom Blinn---
It's not really completely obvious. The simplest way is probably to use
"dd" on the raw disk:
dd if=/dev/rdisk/dsk0c of=/dev/rdisk/dsk1c bs=32k
It's best to do this in single user mode with everything except the root
file system unmounted; that way you only need to fsck the root partition
of the target disk (and with AdvFS you don't need to do that). This
makes
an exact disk block to disk block copy. But things like the /etc/fstab
and /etc/fdmns links and /etc/sysconfigtab in the copy still point to
the
original (dsk0) disk, and you have to go find those references and fix
them up.
This only works, BTW, if the target disk has a zero-d disklabel, as it's
going to copy the label as well from the source disk.
Anyway, once you get things copied, you can then boot off the copied
disk,
reorganize the original disk, changing the partitions, re-establish all
of
the AdvFS file systems on the original disk, then use vdump and vrestore
to copy the file systems over. You should also be able to use tar or
any
other archiver, but vdump piped to vrestore is the best bet. And if you
want to make it relatively easy, since you've probably got a LOT of
space
on the "copy" disk, make vdump backups into a file FIRST before you copy
over the disk -- they will get copied along with everything else, but
they
will not have the changed fstab etc. from the copy disk, and then you
can
just restore them onto the original disk once you reorganize it, and you
will have your original file systems back, etc.
After you've done this once or twice, it becomes easy; the first time it
will be hard. So I do encourage the "back everything up" method.
---from John J. Francini---
Your best bet is to do something we do all the time: clone the system
disk onto the other disk, and swap the two drives.
Assuming this machine has a VGA display, you can run diskconfig to
visually set up the partitions as you wish on the second drive --
making sure that you set the boot blocks up for AdvFS.
Take the system down to single-user or reboot with the -s flag. Make
sure that all the filesets of the system disk are mounted by doing:
# bcheckrc; swapon -a; update
Then do something like this:
# mkfdmn /dev/disk/dsk1a clone_root
# mkfdmn /dev/disk/dsk1g clone_usr
# mkfdmn /dev/disk/dsk1h clone_var
# mkfset clone_root root; mkfset clone_usr usr; mkfset clone_var var
# mkdir /clone_root /clone_usr /clone_var
# mount clone_root#root /clone_root
# mount clone_usr#usr /clone_usr
# mount clone_var#var /clone_var
# vdump -0 -f - / | (cd /clone_root; vrestore -x -f -) &
# vdump -0 -f - /usr | (cd /clone_usr; vrestore -x -f -) &
# vdump -0 -f - /var | (cd /clone_var; vrestore -x -f -) &
When you're all done, shut the system down, swap the two drives, and
reboot.
Voila, you've now got your system residing on a disk partitioned the
way you like it.
---from David J. DeWolfe---
We're running 4.0f and have done absolutely nothing with 5.x yet.
Hopefully
the information still applies
I have never used the AdvFS GUI nor the diskconfig GUI, I do all that
type
of stuff from the command line
Given that, here's what we do and I'll use /dev/rz1 as the disk I'm
going
to copy everything to:
Set up the disk partitions:
# disklabel -r rz1 > /tmp/disklabel.rz1 (save the existing
label)
# disklabel -z rz1 (zero out any existing
label)
# disklabel -rw -t advfs rz1 <disktype> ("-t xxxx" makes it
bootable)
# disklabel -e rz1 (resize partitions)
Create Advfs domains/file sets:
# mkfdmn /dev/rz1a clone_root (for example)
# mkfdmn /dev/rz1g clone_usr (for example)
# mkfset clone_root root
# mkfset clone_usr usr
# mkfset clone_usr var
# mkfset clone_usr log
# mkfset clone_usr tmp
Create mount points for the "clone" file systems:
# mkdir /clone_root
# mkdir /clone_usr
# mkdir /clone_var
# mkdir /clone_tmp
# mkdir /clone_log
Shutdown the system and come up in single user mode:
Once there:
Mount the file systems in /etc/fstab:
# bcheckrc
Mount the "clone" file systems:
# mount -t advfs clone_root#root /clone_root
# mount -t advfs clone_usr#usr /clone_usr
# mount -t advfs clone_usr#var /clone_var
# mount -t advfs clone_usr#tmp /clone_tmp
# mount -t advfs clone_usr#log /clone_log
Clone the running system
# vdump -0f - / | vrestore -xf - -D /clone_root
# vdump -0f - /usr | vrestore -xf - -D /clone_usr
# vdump -0f - /var | vrestore -xf - -D /clone_var
# vdump -0f - /tmp | vrestore -xf - -D /clone_tmp
Modify /clone_root/etc/fstab so that it looks like:
clone_root#root / advfs rw
clone_usr#usr /usr adfvs rw
clone_usr#var /var advfs rw
clone_usr#tmp /tmp advfs rw
clone_usr#log /log advfs rw
/proc /proc procfs rw
shutdown and boot off of rz1
---original query-----
> Our new ES40 came from the factory with the partition sizes completely
> different from what we had asked for. I realize the solution to this is
> to backup, boot with CD, resize the partitions, and restore from
> backup.
>
> Problem: We do not yet have the 5.0A CD, our vendor claims that when
> there is an OS change, they need to send back all their older OS back to
> Compaq and then eventually they will get an exchange. He says that our
> copy will be shipped to us from Compaq directly. Sounds fishy, but oh
> well. I've been waiting almost 2 weeks, and I need to finish
> configuring this machine very very soon. Is it possible to boot with a
> 4.0F CD that I do have, and complete this operation? Does anyone think
> I will run into complications? Does anyone have any other solutions?
> The machine has two 18.2 GB disks, one of which is completely
> unallocated at the moment, and can be used in anyway to fix my partition
> sizes? It is using AdvFS, so is there any cool AdvFS tricks I can use
> to my advantage? It also has a DLT drive, and I've already backed up
> everything.
--
Kevin Dea
System Administrator
Alpine Electronics Research of America
Received on Tue Sep 19 2000 - 17:59:16 NZST