reading file systems off drive on old SCO Unix (kernel 3.2v4) on Linux
Richard Pitt
from an old SCO system I put in back in 1993 onto a Linux system.
The DC6525 tape drives we bought at that time (I got one and the customer
got one) now won't read each other's tapes :(
Yesterday I pulled the DC6525 out and put in a DAT in its place on the
theory that I'd be able to pull that drive out and put it into my
computer after the backup.
The power supply died on restart :(
Mother board is 12 slot EISA 486 and requires BIG supply :(
the original (that died last year) was 400 watts. I replaced it with a
320 watt and that is the one that died.
While I now have such a supply, I'd like to know if anyone has
successfully transplanted SCSI disk drives from an old SCO box to a Linux
box and read the file systems. I know the 'partitions' have 'divisions'
and it seems that Linux doesn't understand division tables.
On the other hand I thought maybe someone had been in my position and
maybe done the math on where to point dd in order to pull a specific file
system out of the mess onto a file I might mount with the loopback device
on Linux.
I don't think any of the file systems on this box are more than 2 Gigs -
most are less than 1 Gig.
Any thoughts?
richard
--
Richard C. Pitt C.E.O. Belcarra Technologies
ric...@belcarra.com direct: 604-644-9265 www.belcarra.com
Software Systems - design and implementation: Internet, Linux, Communications
USB, RNDIS, ATM, E-mail, SQL, Encryption, Security, Web, Embedded Systems
Tony Lawrence
> I'm in the unenviable position of having to read about 4 Gigs of files
> from an old SCO system I put in back in 1993 onto a Linux system.
>
> The DC6525 tape drives we bought at that time (I got one and the customer
> got one) now won't read each other's tapes :(
That may just be a matter of hardware block size. See
http://www.aplawrence.com/Unixart/tapes.html#compat
>
> Yesterday I pulled the DC6525 out and put in a DAT in its place on the
> theory that I'd be able to pull that drive out and put it into my
> computer after the backup.
>
> The power supply died on restart :(
> Mother board is 12 slot EISA 486 and requires BIG supply :(
> the original (that died last year) was 400 watts. I replaced it with a
> 320 watt and that is the one that died.
>
> While I now have such a supply, I'd like to know if anyone has
> successfully transplanted SCSI disk drives from an old SCO box to a Linux
> box and read the file systems.
Not that I am aware of, no.
>I know the 'partitions' have 'divisions'
> and it seems that Linux doesn't understand division tables.
>
> On the other hand I thought maybe someone had been in my position and
> maybe done the math on where to point dd in order to pull a specific file
> system out of the mess onto a file I might mount with the loopback device
> on Linux.
>
> I don't think any of the file systems on this box are more than 2 Gigs -
> most are less than 1 Gig.
>
> Any thoughts?
>
Get it running under SCO and then use the tape drive(s) to transfer -
assuming you can't make the tapes work otherwise.
--
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Linux Skills Test: ftp://aplawrence.com/pub/linuxquestions.zip
Bela Lubkin
> I'm in the unenviable position of having to read about 4 Gigs of files
> from an old SCO system I put in back in 1993 onto a Linux system.
> ... I'd like to know if anyone has
> successfully transplanted SCSI disk drives from an old SCO box to a Linux
> box and read the file systems. I know the 'partitions' have 'divisions'
> and it seems that Linux doesn't understand division tables.
>
> On the other hand I thought maybe someone had been in my position and
> maybe done the math on where to point dd in order to pull a specific file
> system out of the mess onto a file I might mount with the loopback device
> on Linux.
>
> I don't think any of the file systems on this box are more than 2 Gigs -
> most are less than 1 Gig.
>
> Any thoughts?
Yes -- you would be a good candidate for Radek Tomis' utility `fsrd`.
Go to ftp://ftp.armory.com/~rts/fsrd/, play around...
What you're looking for is something like:
fsrd -f S51K /dev/[whole-disk-device] search -h
This will produce a lot of hard-to-understand output which _does_ have
what you're looking for in it. Plus a lot of chaff. ;-}
>Bela<
Jean-Pierre Radley
| Yes -- you would be a good candidate for Radek Tomis' utility `fsrd`.
| Go to ftp://ftp.armory.com/~rts/fsrd/, play around...
I can't get to such a URL nohow...
--
JP
John DuBois
Works in lynx, doesn't in netscape. The path that netscape extracts from the
above url is /~rts/fsrd/ (which doesn't work) while lynx extracts ~rts/fsrd/
(which does). The equivalent URL with rts' ftp home dir given explicitly is:
ftp://ftp.armory.com/pub/user/rts/fsrd/
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Richard Pitt
Thanks Bela (long time no talk to by the way - I'll tell Stuart Lynne
you're alive and well ;)
I'm going to try this tomorrow - tonight I'm backing up the system to a
spare 9Gig SCSI drive I had kicking around.
Richard Pitt
> Richard Pitt wrote:
>> I'm in the unenviable position of having to read about 4 Gigs of files
>> from an old SCO system I put in back in 1993 onto a Linux system.
>>
>> The DC6525 tape drives we bought at that time (I got one and the
>> customer got one) now won't read each other's tapes :(
>
> That may just be a matter of hardware block size. See
> http://www.aplawrence.com/Unixart/tapes.html#compat
>>
>> Yesterday I pulled the DC6525 out and put in a DAT in its place on the
>> theory that I'd be able to pull that drive out and put it into my
>> computer after the backup.
>>
>> The power supply died on restart :(
>> Mother board is 12 slot EISA 486 and requires BIG supply :( the
>> original (that died last year) was 400 watts. I replaced it with a 320
>> watt and that is the one that died.
>>
>> While I now have such a supply, I'd like to know if anyone has
>> successfully transplanted SCSI disk drives from an old SCO box to a
>> Linux box and read the file systems.
>
> Not that I am aware of, no.
hmmm... maybe the SCO systems have been too reliable ;)
>
>>I know the 'partitions' have 'divisions'
>> and it seems that Linux doesn't understand division tables.
>>
>> On the other hand I thought maybe someone had been in my position and
>> maybe done the math on where to point dd in order to pull a specific
>> file system out of the mess onto a file I might mount with the loopback
>> device on Linux.
>>
>> I don't think any of the file systems on this box are more than 2 Gigs
>> - most are less than 1 Gig.
>>
>> Any thoughts?
>>
>>
> Get it running under SCO and then use the tape drive(s) to transfer -
> assuming you can't make the tapes work otherwise.
Actually, I'm backing the system up to a spare 9Gig drive I had kicking
around (Seagate 5 1/4" full height - just the thing to match this ancient
beast ;)
The saga of the tape drives was:
(Note that I put this system together in 1994 and had had almost nothing
to do with it in over 7 years. In the mean time it had been moved to a
new location.)
When my DAT tape drive in, the system wouldn't boot. Turned out
the power supply fan had died (almost wouldn't turn by hand) and when I
re-powered the system it didn't come up.
This was Sunday, and we went to one of the only places in the are (Cal's
computers on Grandview Hwy in Vancouver) that is open on Sunday and might
have parts. We got a used 250watt (the original was 400watt but we no
longer had 3 full-height drives of 40watts each) and headed to the site
again.
Turned out the used supply was no good either - and the fan in it was not
working either :(
Arranged with a friend (Ken Cillis) to get a spare 300watt supply he had
and headed home for the evening.
I put that in this morning - the system booted and I went back to my
DC6525 drive to get a backup. Rather than putting the drive in the case,
I left it out on the side so could see it and the tape in it. I put in
what had been a new tape when I started the data conversion a couple of
days previously. I watched the drive try to rewind the tape -
unsucessfully :(
Seems that some time in the not too distant past I must have put a tape
in that was seized - the drive wheel on my drive was melted down to a
bare nubbin and the tape that was in it had rubber all over its drive
wheel - totally screwed :( With the drive sitting out in the open, this
was now obvious.
The same thing happened (although not as bad) to the customer's drive -
nothing would run in it.
I ran around today looking for options - found a DC6150 from another
customer's old system recently replaced but figured that with ~4Gigs to
transfer I'd rather do something else. While in my office I also picked
up a couple of external drive boxen from an old SPARC system - each with
a Seagate full-height 9Gig drive in it.
Went about 50miles out of Vancouver to another customer site where I
picked up an old system with another old DC6525 tape drive in it.
When I got back to the customer site I broke my normal "if it ain't
broke, don't fix it rule" and started changing things instead of just
substituting identical parts.
The first thing I did was configure the system to have one of the 9Gigs
connected (mkdev hd and answer the questions) rebooted to finish and ran
up against a problem. I'd removed the tape drive and put the 9Gig in its
place. The system started giving "ct error" because the tape drive wasn't
there - more :(
I stole the drive cable from the old computer I'd scrounged - it had 5
connectors to the customer's 3 connectors so I could add the tape and the
9Gig at the same time. Rebooted the system and waited interminably while
it cleaned all the file systems and checked the calendar database, etc.
when until it finally came up.
With both the old tape drive and the new 9Gig, the system came up.
I ran mkdev hd to get the system to add /dev/rdsk/3s0 (the node for the
whole new drive) so I didn't have to figure out what it would be and
exited before it actually wrote the division table.
I then ran:
cd /
tar -cvbf 20 /dev/rdsk/3s0 .
so I now have a 9Gig disk drive with a tar archive on it of the whole
(about 4Gig) file system and I can read it with Linux :)
more in the morning.
Bela Lubkin
> I stole the drive cable from the old computer I'd scrounged - it had 5
> connectors to the customer's 3 connectors so I could add the tape and the
> 9Gig at the same time. Rebooted the system and waited interminably while
> it cleaned all the file systems and checked the calendar database, etc.
> when until it finally came up.
You went to multi-user mode... go single-user to save time; mount
filesystems read-only if they want to be checked and you know they're
fine.
> With both the old tape drive and the new 9Gig, the system came up.
>
> I ran mkdev hd to get the system to add /dev/rdsk/3s0 (the node for the
> whole new drive) so I didn't have to figure out what it would be and
> exited before it actually wrote the division table.
>
> I then ran:
> cd /
> tar -cvbf 20 /dev/rdsk/3s0 .
>
> so I now have a 9Gig disk drive with a tar archive on it of the whole
> (about 4Gig) file system and I can read it with Linux :)
_Maybe_ that's what you have...
`mkdev hd` tends to unwind all of its work if you quit in the middle.
Did you check to make sure that /dev/rdsk/3s0 existed when you were done
with `mkdev hd`? If it didn't, what you have is a root filesystem with,
among other things, a large tarball _file_ named /dev/rdsk/3s0.
... however, it's probably OK. If the device node didn't exist, and if
the filesystem really has ~4GB on it, the tarball would have grown to
2GB; then you would have gotten some sort of file-too-big error message
that would have alerted you to the problem.
>Bela<
Dan Martin
Dear Richard,
If you have a spare 9 gb drive kicking around, try installing it
in your customer's machine and making (2) 4.5 gb partitions. Make
divisions and filesystem(s) on one, but not both partitions. Copy
the files you need to the new disk, new filesystem, then try to tar
the files to 2nd partition using whatever its block device name is.
Then when you've got the drive back in your shop, you have 2 methods
to try getting the data off of it and onto Linux, the 2nd being:
tar xvf /dev/disk2_partition2
I think you have a better chance using tar since you don't have
to deal with an SCO filesystem under Linux.
Good luck,
Dan
Good luck,
Dan
Brian K. White
if you can do that, then just write a tar to the disk and then untar
under linux. no filesystem just tar cvAf /dev/dsk/1s0 /path/to/data
then on linux untar similarly. (different device names under linux of
course, and the 1s0 assumes this is the 2nd drive in the system) or
you can make a filesystem (htfs and dtfs probably won't work on linux)
to the same whole-disk device, and linux will be able to mount that.
msdos and xenix definetly work. haven't tried the middle ground
between the two extremes of xenix and htfs. but even dos & xenix are
good enough to hold a couple tar files. I don't know about msdos fs,
but xenix fs can't be over 512 megs, so that's out. you can also use
fdisk partitions instead of the whole disk, just not divvy partitions
within a fdisk partition. put everything in one tar directly to the
whole-disk or a whole-fdisk-partition seems like the easiest way to
me, unless you can get the tape working.
Bill Vermillion
>When my DAT tape drive in, the system wouldn't boot. Turned out
>the power supply fan had died (almost wouldn't turn by hand) and when I
>re-powered the system it didn't come up.
>This was Sunday, and we went to one of the only places in the
>are (Cal's computers on Grandview Hwy in Vancouver) that is
>open on Sunday and might have parts. We got a used 250watt (the
>original was 400watt but we no longer had 3 full-height drives
>of 40watts each) and headed to the site again.
>Turned out the used supply was no good either - and the fan in
>it was not working either :(
The fans are pretty bad. In a similar situation I put a fan at the
back of the system - a small one that clips on a board - as a
termporary solution and had it blow into the power supply. Kept
things running quite awhile until I was able to get things fixed
properly.
In another instance a long time ago - on a desktop type - I took
off the cover and put a fan blowing down into the system - a
standard table fan - until we could get a power supply. Neither of
these were pretty but they kept things running and cool enough
so nothing was toasted and the were the old AT style mobos.
Just something to think about in case you run into this in the
future.
Bill
--
Bill Vermillion - bv @ wjv . com
Richard Pitt
On Tue, 10 Dec 2002 01:56:11 -0800, Bela Lubkin wrote:
> Richard Pitt wrote:
>
>> I stole the drive cable from the old computer I'd scrounged - it had 5
>> connectors to the customer's 3 connectors so I could add the tape and
>> the 9Gig at the same time. Rebooted the system and waited interminably
>> while it cleaned all the file systems and checked the calendar
>> database, etc. when until it finally came up.
>
> You went to multi-user mode... go single-user to save time; mount
> filesystems read-only if they want to be checked and you know they're
> fine.
problem is that this system is in constant use :(
>
>> With both the old tape drive and the new 9Gig, the system came up.
>>
>> I ran mkdev hd to get the system to add /dev/rdsk/3s0 (the node for the
>> whole new drive) so I didn't have to figure out what it would be and
>> exited before it actually wrote the division table.
>>
>> I then ran:
>> cd /
>> tar -cvbf 20 /dev/rdsk/3s0 .
>>
>> so I now have a 9Gig disk drive with a tar archive on it of the whole
>> (about 4Gig) file system and I can read it with Linux :)
>
> _Maybe_ that's what you have...
>
> `mkdev hd` tends to unwind all of its work if you quit in the middle.
> Did you check to make sure that /dev/rdsk/3s0 existed when you were done
> with `mkdev hd`? If it didn't, what you have is a root filesystem with,
> among other things, a large tarball _file_ named /dev/rdsk/3s0.
>
> ... however, it's probably OK. If the device node didn't exist, and if
> the filesystem really has ~4GB on it, the tarball would have grown to
> 2GB; then you would have gotten some sort of file-too-big error message
> that would have alerted you to the problem.
>
Ok - now I've done a couple of runs with the hard disk as backup device
but I can't seem to get past about 500K before getting a "write error" -
and I KNOW the drive is 9 Gigs.
I've used all the tar mantras I can think of, changed /etc/default/tar's
default and anything else I can think of, all to no avail. The damned
thing just refuses to push more than 500Megs to /dev/rdsk/3s0 (and yes,
it did write to the drive because I pulled it off on the Linux system
with no problem)
Then the damned EISA config died and I spent all day looking for the
configuration disk :(
this machine is really on its last legs - CMOS battery is dead and no
spot to put on an extra battery that I can find (uses one of the first
integrated battery/clock chip, soldered on the board - good for 10 years
and "Nobody would run this system that long")
I'm about 3/4 into a bottle of wine to forget the whole day - the system
recovery from hell!
Bela Lubkin
> Ok - now I've done a couple of runs with the hard disk as backup device
> but I can't seem to get past about 500K before getting a "write error" -
> and I KNOW the drive is 9 Gigs.
You know it, does the OS know it? Run `hwconfig -h`, find the %disk
line for this drive, multiply out its cyls * hds * secs * 512
bytes/sector. How big does the OS think it is?
You said 500K, but I bet you meant 500MB. That's an old BIOS limit,
1024 cylinders * 16 heads * 63 sectors/track. To get around that you'll
need to run `dparam` on the drive, overriding its parameters. Or
actually run `mkdev hd` with the right arguments to get at that drive --
it'll run something that gives an easier menuing interface to dparam.
Now, what parameters should you actually use? I'm really not sure.
I forget whether you said this was a SCSI or an IDE disk. Probably SCSI
-- 3.2v4.2 would have had even worse problems with a 9GB IDE disk.
That's good: SCSI disks are fundamentally LBA, OSR5 just pretends they
have "geometry". It doesn't matter what geometry you claim as long as
it multiplies out to the right size (or a bit less). e.g. use 64 heads,
32 sectors/track, 8000 tracks. That's ~8GB, an underestimate, but
that's fine.
> I've used all the tar mantras I can think of, changed /etc/default/tar's
> default and anything else I can think of, all to no avail. The damned
> thing just refuses to push more than 500Megs to /dev/rdsk/3s0 (and yes,
> it did write to the drive because I pulled it off on the Linux system
> with no problem)
Well, that's another way to do it -- transfer half a gig at a time.
Stack the deck by doing:
tar cf - dirs | compress -H > /dev/rdsk/3s0
then on linux,
gzcat < /dev/hd(whatever) | tar tvf - # then xvf
(gzcat can read `compress -H` format).
>Bela<
Steve Fabac
Richard,
What SCSI controller is on the old system vs the new system where you
try to read the tar archive?
I have found that SCSI bad track mapping is different from Adaptec
1542CF to Adaptec 2940. In my case, I was upgrading a system by
moving the old hard disk to a new system. The old system was 1542CF and
the new system was 2940. It looked like it was working but some files
were corrupted after copying using cpio. Checksum calculated on some
files on the old disk in the new system did not agree with checksums
calculated on the old disk booted in the old system.
My solution was to move the 1542 controller from the old system to the
new system and connect the old drive to the 1542 in the new system.
The new hard disk booted from the 2940 and I ran mkdev hd and added
the old drive to the kernel using the 1542 controller. All files copied
ok.
>
> Then the damned EISA config died and I spent all day looking for the
> configuration disk :(
>
> this machine is really on its last legs - CMOS battery is dead and no
> spot to put on an extra battery that I can find (uses one of the first
> integrated battery/clock chip, soldered on the board - good for 10 years
> and "Nobody would run this system that long")
>
> I'm about 3/4 into a bottle of wine to forget the whole day - the system
> recovery from hell!
>
> richard
>
> --
> Richard C. Pitt C.E.O. Belcarra Technologies
> ric...@belcarra.com direct: 604-644-9265 www.belcarra.com
> Software Systems - design and implementation: Internet, Linux, Communications
> USB, RNDIS, ATM, E-mail, SQL, Encryption, Security, Web, Embedded Systems
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Richard Pitt
> Richard Pitt wrote:
>
>> Ok - now I've done a couple of runs with the hard disk as backup device
>> but I can't seem to get past about 500K before getting a "write error"
>> - and I KNOW the drive is 9 Gigs.
>
> You know it, does the OS know it? Run `hwconfig -h`, find the %disk
> line for this drive, multiply out its cyls * hds * secs * 512
> bytes/sector. How big does the OS think it is?
>
> You said 500K, but I bet you meant 500MB. That's an old BIOS limit,
> 1024 cylinders * 16 heads * 63 sectors/track. To get around that you'll
> need to run `dparam` on the drive, overriding its parameters. Or
> actually run `mkdev hd` with the right arguments to get at that drive --
> it'll run something that gives an easier menuing interface to dparam.
Sorry - yes, 500 Megs
(and to the previous poster, the problem is on the writing side, not the
reading - the controller is a 1542c in the SCO box and a 2960 in the
Linux box - seem to be ok)
dparm - ok
or mkdev hd - that's ok too - will try it. I previously just let it run
long enough to get the device nodes installed. this time I'll let it go
farther.
will keep you informed - lots of fun "meatball sysadmin" that's what I
like (but it sure is frustrating!)
>
> Now, what parameters should you actually use? I'm really not sure.
>
> I forget whether you said this was a SCSI or an IDE disk. Probably SCSI
> -- 3.2v4.2 would have had even worse problems with a 9GB IDE disk.
> That's good: SCSI disks are fundamentally LBA, OSR5 just pretends they
> have "geometry". It doesn't matter what geometry you claim as long as
> it multiplies out to the right size (or a bit less). e.g. use 64 heads,
> 32 sectors/track, 8000 tracks. That's ~8GB, an underestimate, but
> that's fine.
SCSI - 8 Gigs should be more than enough as the whole system is only
about 4.5Gigs.
Thanks guys!
richard
>
>> I've used all the tar mantras I can think of, changed
>> /etc/default/tar's default and anything else I can think of, all to no
>> avail. The damned thing just refuses to push more than 500Megs to
>> /dev/rdsk/3s0 (and yes, it did write to the drive because I pulled it
>> off on the Linux system with no problem)
>
> Well, that's another way to do it -- transfer half a gig at a time.
> Stack the deck by doing:
>
> tar cf - dirs | compress -H > /dev/rdsk/3s0
>
> then on linux,
>
> gzcat < /dev/hd(whatever) | tar tvf - # then xvf
>
> (gzcat can read `compress -H` format).
>
>>Bela<