Need help cloning drive. (UW 2.1/UW 7.1)
CHoaglin
A little background on my problem first:
I'm working with a voice-over-IP box made by lucent, which happens to
essentially be a passive-backplane single board setup in a rackmount AT card,
running Unixware 2.1.2 from a Quantum Fireball 4.3GB single-ended SCSI drive.
Trouble is I don't know the root password. I've been round and round with it,
figuring out how to work with the drives, get them recognized, load hba
drivers, break out of installers to do all that, etc. (With a lot of helpful
advice from Tony Lawrence and Frank, thanks guys!)
At this point I have obtained a set of 7.1.3 install media, and installed it
another another drive on the SCSI bus, which I am booting from. I can see the
original drive with fstyp, prtvtoc, fsck, mount, etc, and I'm familiar with how
to edit the password file to reset the password.
Note: I have already tried to reset by booting from various 2.1.x install
disks, but they won't seem to see my HBA, so there are no devices in /dev/dsk
or /dev/rdsk besides floppy devices (things starting with f) My host adapter is
not really a particular model, but it's AIC-7880(or I think that's the chip
number)
based(SCSI is on board on the single board computer that runs the box)
Under 7.1.3 it works with the "adsl" driver.
The issue right now is that it claims the drive is corrupted and wants to do a
full fsck of the drive before allowing me to mount it, and I'm slightly
apprehensive about letting 7.1.3's fsck loose on a drive is native to 2.1.2,
especially given it being my only copy of the data.
Also, the 2.1.2 drive boots fine on its own, so I would doubt that it is
*actually* corrupted.
For reference:
fstyp -v /dev/rdsk/c0b0t1d0s1
vxfs
(so it's using vxfs)
Also, here is the result of a prtvtoc /dev/rdsk/c0b0t1d0s0
slice 0: DISK permissions: VALID UNMOUNTABLE
starting sector: 63 (cyl 0) length: 8417997 (4110.35 cyls)
slice 1: ROOT permissions: VALID
starting sector: 562275 (cyl 274) length: 3534300 (1725.73 cyls)
slice 2: SWAP permissions: VALID UNMOUNTABLE
starting sector: 48195 (cyl 0) length: 514080 (251.02 cyls)
slice 7: BOOT permissions: VALID UNMOUNTABLE
starting sector: 63 (cyl 0) length: 34 (0.02 cyls)
slice 8: ALT SEC/TRK permissions: VALID UNMOUNTABLE
starting sector: 97 (cyl 0) length: 15968 (7.80 cyls)
slice 10: STAND permissions: VALID
starting sector: 16065 (cyl 7) length: 32130 (15.69 cyls)
slice 12: HOME permissions: VALID
starting sector: 4096575 (cyl 2000) length: 4209030 (2055.19 cyls)
slice 15: VOLPRIVATE permissions: VALID UNMOUNTABLE
starting sector: 8305605 (cyl 4055) length: 16065 (.84 cyls)
When I try to mount it, it hiccups like so:
mount -F vxfs /dev/dsk/c0b0t1d0s1 /mnt
UX:vxfs mount: ERROR: /dev/dsk/c0b0t1d0s1 is corrupted. needs checking
When I try to fsck it wants to do a full one:
fsck -F vxfs /dev/dsk/c0b0t1d0s1
log replay in progress
US:vxfs fsck: ERROR file system does not contain a valid log
UX:vxfs fsck: ERROR: cannot perform log replay
full file system check required, exiting ...
-----------
My questions:
1. Will 7.1.3's fsck successfully work on a 2.1.2 drive?
2. How can I clone the drive to make a backup copy before attempting to fsck it
fully (fsck -F vxfs -o full /dev/dsk/c0b0t1d0s1) (or should I be fsck'ing it as
a raw device rather than block device?) I understand that unixware is very
picky about geometry being the same between two drives and dd will most likely
not work properly because the slices would end up in the wrong places.
Something I read mentioned using dump/restore instead, but restore doesn't seem
to be a valid command on 7.1.3. I'm prepared to buy an other identical drive
with the same geometry if I have to to make it work.
3. How can I configure the system to echo shell sessions to the COM port? It
would make it easier to cut and paste shell commands and results for anybody
trying to assist me.
4. Anybody have install CD's for 2.1.2 or 2.1.3, and how does it handle loading
HBA drivers?
5. Will any of the "Supertar" products help me copy the data from one drive to
another?
Hoping I can find a solution since I've been battling with this off and on
since late december.
Thanks in advance
-Chris
Ian Wilson
> A little background on my problem first:
<lotsa stuff removed>
>
> -----------
> My questions:
>
> 1. Will 7.1.3's fsck successfully work on a 2.1.2 drive?
I don't know ...
> 2. How can I clone the drive to make a backup copy before attempting to fsck it
> fully (fsck -F vxfs -o full /dev/dsk/c0b0t1d0s1) (or should I be fsck'ing it as
> a raw device rather than block device?) I understand that unixware is very
> picky about geometry being the same between two drives and dd will most likely
> not work properly because the slices would end up in the wrong places.
> Something I read mentioned using dump/restore instead, but restore doesn't seem
> to be a valid command on 7.1.3. I'm prepared to buy an other identical drive
> with the same geometry if I have to to make it work.
dd'ing the whole drive should always work if the drives have identical
geometry. It should be safe to dd it and work on the dd'd copy not the
original.
> 3. How can I configure the system to echo shell sessions to the COM port? It
> would make it easier to cut and paste shell commands and results for anybody
> trying to assist me.
man script?
> 4. Anybody have install CD's for 2.1.2 or 2.1.3, and how does it handle loading
> HBA drivers?
I don't know ...
> 5. Will any of the "Supertar" products help me copy the data from one drive to
> another?
Almost certainly, and the Supertar vendors are very helpful so phone
them up and ask them.
--
Ian Wilson
Bela Lubkin
> When I try to mount it, it hiccups like so:
> mount -F vxfs /dev/dsk/c0b0t1d0s1 /mnt
> UX:vxfs mount: ERROR: /dev/dsk/c0b0t1d0s1 is corrupted. needs checking
>
> When I try to fsck it wants to do a full one:
> fsck -F vxfs /dev/dsk/c0b0t1d0s1
> log replay in progress
> US:vxfs fsck: ERROR file system does not contain a valid log
> UX:vxfs fsck: ERROR: cannot perform log replay
> full file system check required, exiting ...
>
> -----------
> My questions:
>
> 1. Will 7.1.3's fsck successfully work on a 2.1.2 drive?
Chances are it would, but you don't want to take chances here.
SCO OpenServer, in this situation, will allow you to mount the
filesystem read-only without running `fsck`. Try that: `mount -r -F vxfs
...` -- does it go through? If so, now you can make a backup using a
supertar or regular tar/cpio.
> 2. How can I clone the drive to make a backup copy before attempting to fsck it
> fully (fsck -F vxfs -o full /dev/dsk/c0b0t1d0s1) (or should I be fsck'ing it as
> a raw device rather than block device?) I understand that unixware is very
> picky about geometry being the same between two drives and dd will most likely
> not work properly because the slices would end up in the wrong places.
I started to write an answer heading for a goal of getting all the files
extracted off the box. Then I realized that wasn't what you wanted at
all -- you want to change the root password without disturbing the
existing, working system. Right?
Well, here are some things you can try. There should be enough hints
here for you to get things to work. I can't give you an actual step by
step program to follow, you need to put it together with your wits,
trial and error.
Geometry shouldn't be an issue at the slice level. UW713 recognizes the
contents of the root slice as a VxFS, so it's clearly found the right
start block. To take advantage: dd the entire root slice into a file.
(While you're doing that, you should probably make dd images of the
other slices as well, for safe keeping. The /home slice is over 2GB,
which could be an issue if you don't have a filesystem on the UW713 box
with large files enabled. But it's only a little over 2GB, so you can
just compress it on the way in, something like `dd if=/dev/[slicename] |
compress > /save/UW212-home.Z`)
Now, on a new trashable disk, set up a UW7 partition with a mountable
slice at least as big as the one you're trying to get into. Make sure
that slice is not mounted, then dd the root slice image onto it. (You
could do this directly, slice to slice, but you want to keep a safe copy
of the original anyway; having it in a file as well as on the original
disk adds safety.)
As long as the target slice is larger than the source, things should be
fine. The filesystem isn't going to care about living in a larger box.
Once it's all dd'd, now you can experiment with fsck'ing the copy.
Suppose that succeeds and you can now mount the filesystem. Now you
should be able to modify the password files to get you in as root. If
you're satisfied that you've done all that correctly, now you can
unmount the root-copy slice and dd it back over the original root slice
(making sure to copy only the original size). By doing this you're
destroying the original, so now you want to be especially sure you have
that file copy in a safe place.
Then you boot from the (rewritten) UW212 root slice, see if it's still
happy with itself. If not, you boot UW7 again and dd the original
(unmodified) root slice image back onto the disk. Here's where it might
turn out to be important that you have copied of all the slices. If the
UW713 `fsck` _does_ cause a problem, the modified system could crash
hard, in a way that damages the other filesystems. This seems very
unlikely, but you shouldn't risk it.
Where I talk about using slices on a trashable disk, you could also use
the marry(1M) command. This makes a regular file into a block device,
thus allowing you to mount it. If you do it this way, remember that you
should still copy the data. You'll want a sequence like:
dd if=/dev/[old-root-slice] of=/save/UW212-root
dd if=/dev/[old-home-slice] of=/save/UW212-home
... save other slices ...
cp /save/UW212-root /save/UW212-root.unmodified # important backup copy!
marry -a /save/UW212-root
fsck -F vxfs -o full /dev/marry/save/UW212-root
mount -F vxfs /dev/marry/save/UW212-root /mnt
... fix root password ...
umount /mnt
dd if=/save/UW212-root of=/dev/[old-root-slice]
... reboot from UW212 root ...
... if that no longer boots:
... reboot UW713 root ...
dd if=/save/UW212-root.unmodified of=/dev/[old-root-slice]
... reboot from UW212 root ...
... if still problems:
... reboot UW713 root ...
dd if=/save/UW212-home.unmodified of=/dev/[old-home-slice]
... restore other slices ...
... reboot from UW212 root ...
Good luck,
>Bela<