Re: Help in installing a bad drive


----- Original Message -----
From: "Ian Wilson" <scobloke2@xxxxxxxxxxxxx>
Newsgroups: comp.unix.sco.misc
To: <distro@xxxxxxx>
Sent: Thursday, December 01, 2005 5:48 AM
Subject: Re: Help in installing a bad drive


> SDS wrote:
>> I'm in the process of doing a drive recovery for a client, and upgrading
>> him to OSR 5.0.7.
>>
>> So far I have installed a new hard drive with most of OSR 5.0.7 (less
>> some of the updates) and it boots and runs fine.
>>
>> I put the "bad" drive in as a second SCSI drive, ran mkdev hd, and in the
>> divvy process found that the numbers (but not the names of course) were
>> precisely what I had recorded for his system about 5 years ago. (I
>> wasn't supporting is OS, just Medical Manager, but printed out the divvy
>> numbers, why I don't know) Anyhow, this gives me hope that the drive
>> isn't totally trashed, and that only some of the boot programs were
>> trashed.
>>
>> This second drive doesn't mount yet because it is not in the
>> /etc/default/filesys, but it does show up as /dev/dsk/1S0. In divvy the
>> "whole disk" reports itself as hd1a.
>>
>> The decision I have to make is whether to name the partitions on the old
>> drive the same as before or rename them. For the time being I have
>> renamed them as:
>>
>> oldboot
>> oldswap
>> oldroot
>> oldu
>> oldrecover
>> and of course hd1a
>>
>> And the file types remain unchanged for those partitions.
>>
>> I have a concern that if I change the names of those divisions, the
>> directory structure, typically:
>>
>> /usr
>> /usr2/med
>> /usr2/med/meddata
>> /usre/med/medprogs
>>
>> etc.
>>
>> may not show up.
>
> They won't show up until you mount them somewhere. You can choose where to
> mount them.
>
>> On the other hand, if I delete the word old from those drive partitions
>> and put those names into filesys I may end up with some sort of duplicate
>> partition names.
>
> Indeed, I'd do more or less what you have done, prefix the division names
> on the old drive.
>
>> Any suggestions on how to best install and mount this old drive would be
>> appreciated.
>
> I'd finish using divvy to assign names to the divisions then
> mkdir /mnt/oldroot
> mount /dev/oldroot /mnt/oldroot
> cd /mnt/oldroot
> lf usr
> ...
> You might want to use fsck etc first.
>
> Of course, if the data is valuable and you don't have backups, I'd suggest
> you consider consulting a data recovery specialist before touching the old
> disks.

I'll vouch for that.

A few weeks ago it cost me under $2k to send an ancient xenix ide drive to
Seagate and in about a day they emailed me 2 file listings.
One for the entire root (/) fs (to detect absent files in case part of the
disk corruption happened actually inside the superblock itself)
And one that showed the names of files that were known to touch corrupt disk
sectors.
After looking over the lists myself and eliminating bad files that I knew
were part of the OS and that were not cruicial or irreplaceable,
and checking with the BBX application author that none of the bad files that
were in the app were show-stoppers,
(note, even a "bad" database file that had bad sections was still mosty good
and the good records recoverable by the app author)
and emailing a go-ahead back to Seagate, the next day I had the original
drive and a cd with all 4 of:
tar, tar.gz, cpio, cpio.gz
since they just happened to all fit. (only about 200 megs of data on the
xenix filesystem)
originally the tech already had the tar & compressed tar ready to go, then
added the cpio when I asked for that.
20 minutes after the fedex delivery I had the compressed cpio uploaded to
the customers 5.0.6 box and unpacked and ready for the application author to
mine it.

I was very pleasantly surprised on several points:
* flexability of delivery of results.
Since I didn't happen to need the raw hard drive and other partitions and
divvy partitions all back in it's original bootable state, and since the
data would fit in under 2 gigs, it was practical to make a tar or cpio and
they were fine with that. Since the data was under 700 megs, it was
practical to put it on a CD and they were fine with that. I would have not
been overly upset or surprized if they only did one standard thing like make
a tar and balked at doing a cpio, but they didn't blink. Other options
included me sending a hard drive for them to fill, or them supplying a new
hard drive filled.
* not baffled by xenix fdisk, divvy, & filesystems. I didn't remember (and
couldn't look, and I did try and do know how if the drive were'nt
electrically dead) if this drive had a /u filesystem or other filesystems.
So when answering questions about what files I needed most etc... I had to
say things like "all of /u if there is a /u seperate /u fs..." . I expected
problems on that score and there weren't. They knew to get the contents of
/, there was no /u as it tured out, and they knew to ignore /stand, swap
etc... the other divvy partitions that don't matter. I'm sure if I wanted
/stand I would have got it and not an empty /stand mount point directory. I
was expecting to have to accept a raw dd of the whole disk because they
wouldn't be able to read a xenix partition. I could do that but this was
sooo much nicer to just get a nice tar in my lap.

The application author was actually already in the process of slowly
migrating the installation from the xeinx box (his install) to the unix box
(my install & new app) and was planning on spending a full weekend on-site
transferring files over 9600 baud 3-wire (xon/xoff) serial using TERM. (Yes,
I can get the data off a working xenix box numerous ways much faster, and
did offer, but he just wanted to do what he was familiar with and had done
many times before and it wasn't worth me stepping on any toes over it.)
Considering that it's not unheard of to spend that kind of time & effort
even when things are working fine, I think it actually turns out to be cost
effective to use the recovery service even when the drive isn't dead. The cd
was way easier to deal with than any of the other possible options:
* mounting the xenix hd in the unix box,
* adding a 2nd hd to the xenix box and writing to it without divvy then
using a linux boot disk to upload that over the net,
* write to the existing tape drive then using a linux boot disk to upload
that over the net (50/50 chance there even exists a linux driver for the
tape given all the old non-scsi, non-ide tape controllers),
* use a linux boot disk to upload a dd image of the whole hd to unix and use
marry on unix to read it,
* installing the unix box's tape drive in xenix box temporarily,
* installing the xenix box's tape drive in the unix box temporarily,
* kermit/term/rzsz/uucp etc... over plain serial,
* installing a digiboard (or other) intelligent serial card in the xenix box
to at least run at 115k with hardware flow,
(it had a multiport card but I don't think it was intelligent and I don't
think it's driver offered the hack that Digiboards does that makes high
speed and hardware flow even possible on xenix where xenix itself does not
natively understand anything beyond 9600 and you have to pretend to be a
modem to get hardware flow)
etc...

Actually the linux boot-dd-marry idea I only just now thought of.
That might have been the easiest and fastest, and wouldn't bother the app
author since I wouldn't have to do anything "risky" like take apart the
xenix box and I could have just presented a fait accomplie.
I didn't think of it when the drive still worked.
I think the recovery house was more practical than all the other options
though.

The actual service I used was a link off of www.seagate.com, and based on
suspiciously identical submission forms and shipping addresses, I think it's
the same actual company that iomega uses for the data recovery link off ther
site too.
I give them 5 out of 5 on pretty much any factor you want to measure.
(competence/knowledgeability, speed, flexability,
courteousness/professionalism, etc...) The cd was even nicely packaged in a
dvd case and labeled and printed with the date & customers company name no
handwriting etc...

Brian K. White -- brian@xxxxxxxxx -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

.