Can't mount drive with install disk.
Chip
I can't mount my SCSI drive using
my SCO install floppy and CD.
With the information found at
http://pcunix.com/SCOFAQ/scotec1.html#root_1
I did the following:
mknod /dev/root b 1 42
# seems to work fine
fsck -o full /dev/root
# returns:
# cannot determine file system type on device root
mount /dev/root /mnt
# returns:
# mount: Bad address
When I fdisk with freebsd /dev/da1:
******* Working on device /dev/da1 *******
parameters extracted from in-core disklabel are:
cylinders=1048 heads=127 sectors/track=63 (8001 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=1048 heads=127 sectors/track=63 (8001 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 99,(ISC UNIX, other System V/386, GNU HURD or Mach)
start 63, size 8376984 (4090 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 126/ sector 63
When I fdisk in Linux:
Device Boot Begin Start End Blocks ID System
sda4 * 1 1 1020 4241128 63 GNU HURD
Should I force the mount as follows?
fsck -f ufs /dev/root
This is about all I can find from the help and man
pages.
Thanks
Chip
Tony Lawrence
> I can't mount my SCSI drive using
> my SCO install floppy and CD.
>
> With the information found at
> http://pcunix.com/SCOFAQ/scotec1.html#root_1
> I did the following:
>
> mknod /dev/root b 1 42
> # seems to work fine
I'd use (and the faq tells you to use) a different name (like hdroot),
but I'm not sure that's your problem.
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Bela Lubkin
> I can't mount my SCSI drive using
> my SCO install floppy and CD.
>
> With the information found at
> http://pcunix.com/SCOFAQ/scotec1.html#root_1
> I did the following:
>
> mknod /dev/root b 1 42
> # seems to work fine
>
> fsck -o full /dev/root
> # returns:
> # cannot determine file system type on device root
>
> mount /dev/root /mnt
> # returns:
> # mount: Bad address
Are you able to run fdisk from the boot floppy? divvy?
No!
It's good that you can boot FreeBSD and Linux and _examine_ the disk.
You absolutely should not do anything that would in any way _modify_ the
disk. This is a fairly good general rule: if one OS has filesystem
support for another OS's special filesystem types, it's _much_ safer to
use it in read-only mode. Allowing it to write in a normal fashion
(e.g. if you mounted the filesystem and copied files to it) is somewhat
dangerous. Asking a foreign OS's filesystem repair tools (fsck) to
repair a different OS's filesystem is just asking for trouble.
In this case it would probably fail immediately because it wouldn't
recognize the filesystem as type UFS. Or even before that, it would
fail because it wouldn't be able to find the _division_, a SCO-specific
subpartitioning scheme, on which the filesystem resides.
Stick with the OpenServer boot disks.
Boot. Get to a shell prompt. Run fdisk. Does it show an active Unix
partition? Good. Run divvy. Does it show divisions? If it shows
start/end blocks but not names, assign names. I forget what release of
the OS you're trying to recover (_always_ include that information). If
it's before 5.0.0, the root division will be #0, name it "hd0root". If
it's 5.0.0 or later, the root division will be #2; the boot division
will be #0 (name it "hd0boot").
After naming divisions with divvy, quit and re-run divvy. At this point
it should show filesystem _types_ that make sense. If it doesn't, there
are two possibilities: either the kenrel has the wrong idea of the disk
geometry (cyl/hds/sec), or the data on the disk is so damaged that you
will not be able to recover it.
It is _probably_ a geometry problem.
Next steps: what kind of SCIS host adapter are you using (exact brand
and model)? Is it the same exact adapter on which the drive was
originally working? If it is in _any_ way different (even so little as
being the same brand and model, but a different board out of the same
batch), tell us. If it was originally a different brand or model, tell
us what it was.
The geometry reported by FreeBSD and Linux indicates approximately a 4GB
disk. Is that right?
>Bela<
Chip
"Bela Lubkin" <be...@caldera.com> wrote in message
news:2002021214...@mammoth.ca.caldera.com...
> Are you able to run fdisk from the boot floppy? divvy?
fdisk from the boot floppy: ( I should have thought of that)
Partition Status Type Start End Size
1 Active Unix 1 132968 132968
> > Should I force the mount as follows?
> >
> > fsck -f ufs /dev/root
> No!
Got That!! (learning fast)
> Boot. Get to a shell prompt.
No problem now with install CD and disk.
>Run divvy. Does it show divisions?
NAME TYPE NEW FS # FIRST BLOCK LAST BLOCK
NON FS NO 0 0 300000
NON FS NO 1 300001 360001
root NON FS NO 2 360002 1871661
NON FS NO 3 1871662 3028086
NON FS NO 4 3028087 4184511
NOT USED NO
- -
NON FS NO 6 4184512 4184521
hd0a WHOLE DISK NO 7 0 4188491
> If it shows start/end blocks but not names, assign names.
> I forget what release of the OS you're trying to recover
> (_always_ include that information).
> If it's before 5.0.0, the root division will be #0, name it "hd0root".
> If it's 5.0.0 or later, the root division will be #2; the boot division
> will be #0 (name it "hd0boot").
I read that I should change it to:
NAME TYPE NEW FS # FIRST BLOCK LAST BLOCK
hd0boot NON FS NO 0 0 300000
NON FS NO 1 300001 360001
root NON FS NO 2 360002 1871661
NON FS NO 3 1871662 3028086
NON FS NO 4 3028087 4184511
NOT USED NO
- -
NON FS NO 6 4184512 4184521
hd0a WHOLE DISK NO 7 0 4188491
>
> After naming divisions with divvy, quit and re-run divvy. At this point
> it should show filesystem _types_ that make sense. If it doesn't, there
> are two possibilities: either the kenrel has the wrong idea of the disk
> geometry (cyl/hds/sec), or the data on the disk is so damaged that you
> will not be able to recover it.
>
> It is _probably_ a geometry problem.
>
> Next steps: what kind of SCIS host adapter are you using
> (exact brand and model)?
MYLEX MPE motherboard with
on board NCR 53c810
> Is it the same exact adapter on which the drive was
> originally working?
Yes
>If it is in _any_ way different (even so little as
> being the same brand and model, but a different board out of the same
> batch), tell us. If it was originally a different brand or model, tell
> us what it was.
Same case, board and everything, added the SCSI cdrom for
install cd, no other changes
>
> The geometry reported by FreeBSD and Linux indicates approximately a 4GB
> disk. Is that right?
Yes, Segate ST151150N 4.1 GIG
>
Thanks Bela
Chip
Bela Lubkin
> > Are you able to run fdisk from the boot floppy? divvy?
>
> fdisk from the boot floppy: ( I should have thought of that)
> Partition Status Type Start End Size
> 1 Active Unix 1 132968 132968
> >Run divvy. Does it show divisions?
>
> NAME TYPE NEW FS # FIRST BLOCK LAST BLOCK
> NON FS NO 0 0 300000
> NON FS NO 1 300001 360001
> root NON FS NO 2 360002 1871661
> NON FS NO 3 1871662 3028086
> NON FS NO 4 3028087 4184511
> NOT USED NO 5 - -
> NON FS NO 6 4184512 4184521
> hd0a WHOLE DISK NO 7 0 4188491
>
> > If it shows start/end blocks but not names, assign names.
> > I forget what release of the OS you're trying to recover
> > (_always_ include that information).
You didn't answer this.
You almost certainly have a geometry problem. Divisions are showing up,
but even for the named "root" division it does not get a sensible
filesystem type. That means that it's looking in the wrong place,
because the geometry is bad.
> > Next steps: what kind of SCIS host adapter are you using
> > (exact brand and model)?
> MYLEX MPE motherboard with
> on board NCR 53c810
>
> > Is it the same exact adapter on which the drive was
> > originally working?
> Yes
> > The geometry reported by FreeBSD and Linux indicates approximately a 4GB
> > disk. Is that right?
> Yes, Segate ST151150N 4.1 GIG
The geometry reported by FreeBSD is 1048 cylinders, 127 heads, 63
sectors/track. Now, what is the geometry that OpenServer's seeing?
From your boot disk environment, run:
dparam /dev/rhd00
and show us the results.
>Bela<
Chip
> I forget what release of the OS you're trying to recover
> (_always_ include that information).
3.2V4
> The geometry reported by FreeBSD is 1048 cylinders, 127 heads, 63
> sectors/track. Now, what is the geometry that OpenServer's seeing?
> From your boot disk environment, run:
>
> dparam /dev/rhd00
>
> and show us the results.
I could not run dparam from the boot disk
environment so I got another SCO server
( I have 43 of these things) and went through
all of the previous steps to change the root
password with the install disk and CD and log
in as root.
I now have the hard drive installed as the third
drive on a SCO server that I can get to root and
perform whatever needs to be done.
I ran dparam /dev/rhd00 # which is now the new boot drive
1022 138 0 0 0 0 0 63
also ran dparam /dev/rhd01 # second drive on system
1022 138 0 0 0 0 0 63
The problem drive is now the third drive on this system
which is SCO UNIX System v/386
release 3.2
When I try to mount this drive I get the same error I
got from the floppy and I if I run dparam /dev/rhd02
( for third drive) I get "Could not open special device,
no such file or directory.
I am a little confused about the hard drive numbering
system with SCO. I looked into the /dev and noticed
the following types available:
hd01 through 4
hd0a and d
hd10 through 14
hd1a and d
and the same with an r prefix.
I tried to fdisk, divvy and dparam all of the above options
with no luck.
I'll look through the DOCS to learn more about them
I did run divvy on the new hard drive and saw that the
file type was EAFS, the root name was on 0 not on 2
so I asume that it is an older OS version on the new server.
Thanks again for your time.
Chip
Bela Lubkin
> > If it shows start/end blocks but not names, assign names.
> > I forget what release of the OS you're trying to recover
> > (_always_ include that information).
> SCO UNIX System V/386
> 3.2V4
Close. That's enough information for this purpose, but there should be
another digit as in "3.2v4.2" or "3.2v4.0" or whatever. Provide that in
future.
> > The geometry reported by FreeBSD is 1048 cylinders, 127 heads, 63
> > sectors/track. Now, what is the geometry that OpenServer's seeing?
> > From your boot disk environment, run:
> >
> > dparam /dev/rhd00
> >
> > and show us the results.
>
> I could not run dparam from the boot disk
> environment so I got another SCO server
> ( I have 43 of these things) and went through
> all of the previous steps to change the root
> password with the install disk and CD and log
> in as root.
>
> I now have the hard drive installed as the third
> drive on a SCO server that I can get to root and
> perform whatever needs to be done.
No, you can't.
SCSI disks on OpenServer obtain their geometry from a combination of the
motherboard BIOS, host adapter, host adapter BIOS, and disk. Once the
geometry is established, it must be kept the same even if the disk is
moved to a different machine. But you don't know what the original
geometry was, and you've just changed three of the four things that
determine it.
> I ran dparam /dev/rhd00 # which is now the new boot drive
> 1022 138 0 0 0 0 0 63
>
> also ran dparam /dev/rhd01 # second drive on system
> 1022 138 0 0 0 0 0 63
>
> The problem drive is now the third drive on this system
> which is SCO UNIX System v/386
> release 3.2
>
> When I try to mount this drive I get the same error I
> got from the floppy and I if I run dparam /dev/rhd02
> ( for third drive) I get "Could not open special device,
> no such file or directory.
You are using wrong device names. Read the man page hd(HW). /dev/rhd00
is the "whole disk" device for the first hard disk. /dev/rhd01 is the
"first partition" device for the first hard disk. The two dparam's you
ran above both applied to the same piece of hardware, so it's no
surprise the numbers were the same.
There were two drives in this new machine before you touched it; those
would be /dev/rhd0? and /dev/rhd1?.
> I am a little confused about the hard drive numbering
> system with SCO. I looked into the /dev and noticed
> the following types available:
> hd01 through 4
> hd0a and d
> hd10 through 14
> hd1a and d
> and the same with an r prefix.
The ones without "r" are block devices, with "r" are raw devices.
> I tried to fdisk, divvy and dparam all of the above options
> with no luck.
You should have had lots of luck as far as those commands doing
_something_ on the various devices you tried. But none of those devices
applies to the new, 3rd hard disk.
> I'll look through the DOCS to learn more about them
>
> I did run divvy on the new hard drive and saw that the
> file type was EAFS, the root name was on 0 not on 2
> so I asume that it is an older OS version on the new server.
You must have run divvy on one of the existing drives, mistaking the
naming scheme.
You run a very high risk of damaging this new machine you've introduced,
since you're fiddling with devices that actually apply to its existing
drives.
If you were going to keep playing on the new system, you would have to:
1. make sure the 3rd drive has a different SCSI ID from anything else
on the bus, and that the cables are all correct
2. run `mkdev hd` and tell the kernel about the new drive (it will ask
for its coordinates in SCSI space: host adapter driver name,
sequence number of that adapter within that driver, SCSI ID, and
LUN -- I don't think 3.2v4.x was asking about bus numbers yet)
3. relink, reboot to let the kernel see it
4. run `mkdev hd`, give it the same SCSI coordinates, now it will run
fdisk and divvy for you
5. fail, because the geometry would still be wrong
Having gotten to that failure point, there is something you could try.
That is: once you have a whole-disk node for the disk (/dev/rhd20),
search it for evidence of the old geometry. Every time the system
boots, it prints a "%disk" message that includes the geometry. That
gets logged to /usr/adm/messages and /usr/adm/syslog. You can't access
those files _as files_ until you have recovered the disk completely, but
you can still find the strings.
So, get the drive sufficiently set up (as above), then run:
strings /dev/rhd20 | grep 'cyls=.*hds=' > /tmp/geometry-candidates
This might make a large file. When it's done, look at it.
A system I tried here produces:
14 - type=W0 unit=0 cyls=7297 hds=255 secs=63
- - cyls=1106 hds=255 secs=63 fts=stdb
- - cyls=4462 hds=255 secs=63 fts=stdb
It has three disks. I can see how big each is: multiply cyls * hds *
secs * 512. These three are 60GB, 9GB and 36.7GB drives. If your
`strings` exercise produces multiple different values, multiply them out
and decide which sounds like it applies to your drive, which (if I
remember right) is about 4.3GB.
Once you have that, you can attempt to stamp the right geometry.
Run:
dparam /dev/rhd20
Write down all the numbers. Now replace the first number with cyls, the
second number with hds, and the _last_ number with secs. Now run:
dparam /dev/rhd20 ...parameters...
filling in the original parameters with the replaced cyls/hds/secs
values. Be sure you are doing this to the right drive. I've used
/dev/rhd20, which is the whole-disk device for the 3rd drive in a
system. While you're adding the drive with `mkdev hd`, pay attention to
what number it is assigned; it won't necessarily be 2.
Once you've stamped the right geometry, run:
divvy /dev/rhd20
Since you're running 3.2v4.x, it will _not_ give sane filesystem types
until you've named the divisions. So give them names (like "oldroot",
but the specific names don't matter). Then quit divvy (tell it to
"install" the changes). Then run it again.
If you've made it this far and gotten everything right, sane filesystem
types (like "EAFS") should now appear.
The very next thing you should do is mount the filesystems READONLY,
i.e.
mkdir /oldroot
mount -r /dev/oldroot /oldroot
and BACK THEM UP to tape or whatever you use!
>Bela<
Chip
I purchased a bunch of rackmount servers with
several versions of SCO on them. I was working
with the few we have discussed because I thought
It was a crime to fdisk the SCO and reload Slackware
or FreeBsd to use as a web, mail or dns server.
You and the other members of this group have been
extremely helpful over the past week.
It looks like the SCO may be better at security then
Linux.
I know that this can open up a bag of worms in a SCO
newsgroup but what is your opinion on the ups and downs
of using Linux over SCO and vice versa for a simple web,
mail or dns server.
I ask this sincerely with the knowledge that you and the
other members I have seen in this group have a wealth of
years of using these systems, as well shown by the historical
discussions found here.
Again thank you and all of the others for the time spent
helping me to become familiar with this OS.
Chip Carpenter
Tony Lawrence
> Thanks for all of your help Bela.
>
> I purchased a bunch of rackmount servers with
> several versions of SCO on them. I was working
> with the few we have discussed because I thought
> It was a crime to fdisk the SCO and reload Slackware
> or FreeBsd to use as a web, mail or dns server.
Hardly. SCO makes for a lousy web server as any number of folks here
would have told you.
Bill Vermillion
>I purchased a bunch of rackmount servers with
>several versions of SCO on them. I was working
>with the few we have discussed because I thought
>It was a crime to fdisk the SCO and reload Slackware
>or FreeBsd to use as a web, mail or dns server.
It would never be a crime to load FreeBSD. :-)
--
Bill Vermillion - bv @ wjv . com
Chip
Fdisk it is,
I'll keep one of the SCO boxes up
just to see how it works and see if
I can learn a little more about it.
Again Thanks,
Chip
"Chip" <ccarp...@erols.com> wrote in message
news:FvBa8.85$0B3....@news1.news.adelphia.net...
Fabio Giannotti
> Behalf Of Tony Lawrence
> Sent: Wednesday, February 13, 2002 4:19 PM
> Subject: Re: Can't mount drive with install disk.
>
>
> Chip wrote:
>
> > Thanks for all of your help Bela.
> >
> > I purchased a bunch of rackmount servers with
> > several versions of SCO on them. I was working
> > with the few we have discussed because I thought
> > It was a crime to fdisk the SCO and reload Slackware
> > or FreeBsd to use as a web, mail or dns server.
>
>
> would have told you.
>
I rarely disagree with you, but I will on this. We've been using OpenServer
as web, mail and DNS servers for *years* and have had the same high uptime
and reliablity as we have when we use them as application or database
servers.
Now, I'm not saying that they are by any means the best choice, but I'd say
they are far from "lousy".
Fabio
Matt Schalit
>Thanks for all of your help Bela.
>
>I purchased a bunch of rackmount servers with
>several versions of SCO on them. I was working
>with the few we have discussed because I thought
>It was a crime to fdisk the SCO and reload Slackware
>or FreeBsd to use as a web, mail or dns server.
>
>You and the other members of this group have been
>extremely helpful over the past week.
>
>It looks like the SCO may be better at security then
>Linux.
>
>I know that this can open up a bag of worms in a SCO
>newsgroup but what is your opinion on the ups and downs
>of using Linux over SCO and vice versa for a simple web,
>mail or dns server.
Caldera OS's don't benchmark well in the TCP/IP
tests. Hence the other good advice you got. You
could happily roll up a micro-linux OS, let's say
kernel 2.2.20, plus tinydns, dnscache, ssh, and
a stats package onto a 1.68 MB diskette with all
your zone info to make an embedded Linux appliance
and run it from an old P150 with 32 MB of ram.
http://leaf.sf.net/
http://cr.yp.to/
Regards,
Matthew
>Chip Carpenter