News Group Posts

mixing scsi and non-sscsi disk, booting

scsi when ide present, mfm or esdi controller old xenix crash

From: Bela Lubkin <belal@sco.com>
Subject: Re: vintage computer
Date: Wed, 27 Nov 2002 09:55:56 GMT
References: <20021125214315.GB1626@jpradley.jpr.com>
<3de4091c$0$79562$8eec23a@newsreader.tycho.net>
<20021127024148.GB1281@jpradley.jpr.com> 

Jean-Pierre Radley wrote:

> John DuBois typed (on Tue, Nov 26, 2002 at 11:51:57PM +0000):

> | If it's complaining about not being able to read /boot, it's successfully read
> | masterboot, hdboot0, and hdboot1, so it may be that the hardware is all fine,
> | and the problem is just disk corruption.  In that case, you might bring both
> | drive and the controller card currently in use to another machine, even one
> | running 5.0.x, configure XENIX fs support in, and try mounting the root
> | filesystem and either patch it up or copy the data to another drive.
> 
> Which can't work if my 5.0.X drive is SCSI, can it, since I don't think
> non-SCSI drives can coexist with SCSI drives?

It's a little tricky to boot such a system, yes...

There are two problems to overcome.  One is convincing the BIOS to boot
your SCSI disk despite the presence of an ST506 disk.  The other is
convincing Unix to pay attention to the SCSI disk first.

BIOS: it's easy on many newer systems, just tell BIOS setup to boot from
SCSI.

On an older system, the trick is to completely trump the boot sequence
by booting from a boot floppy.  Make sure IDE support is in the kernel
("wd" driver, supports ancient ST506 and ESDI controllers as well as
IDE).  Also make sure Xenix filesystem support is in (`mkdev xenix`).
Relink, reboot, run `mkdev fd`, create a boot floppy.  (All this with
the ST506 controller _not_ in the system.)  Then power off, insert ST506
controller+drive, and boot from the floppy.

That'll get you to the kernel problem. /boot will load the kernel off
the floppy, the kernel will start up, and it will want to root off the
ST506 drive.  You probably shouldn't ever try that, but if you do, I'll
whimsically speculate about the possible outcomes.  Useful text
continues at the word "anyway", below.

If the controller or drive is broken, or just won't work in your
much-newer system, not much interesting happens.  Probably a panic due
to can't mount root.

If the controller and drive are working, but disk parameters are wrong,
probably the same thing.

If controller and drive are working but the partition table, division
table, or inode table of the root filesystem are corrupt, about the
same.

If it's a fully functional Xenix root filesystem (e.g. maybe nothing at
all wrong with it, the problem your client is having could be caused by
the _rest_ of the system having gone bad) -- what happens then?  That
is, what happens if you boot an OpenServer kernel (with appropriate
hardware and filesystem support) with a Xenix root filesystem?  (You'll
probably have to use "fd(64)unix root=hd(40)" else it'll try to root on
hd(42), which will be /u at best, and die due to no /etc/init.)

I think what happens now is that the Xenix /etc/init gets loaded.  It
works.  It runs sulogin to prompt for root password, or ^D to go to
multiuser mode.  You enter the root password.  You get a shell prompt.

An attempt to go multi-user would fail, because the OSR5 kernel doesn't
know it's licensed until ifor_pmd starts (which obviously isn't present
on this Xenix root filesystem).  An unlicensed kernel is limited to
something like 20 concurrent processes.

All this applies to 386 Xenix only.  For 8086 or 286 Xenix, it could
still work, but you would need the OpenServer /etc/x286emul binary and
all of its support files (at least: /usr/lib/libc.so.1 and /dev/zero;
probably more).  Plus, if you've installed the security fix that broke
286 execution, you would have to rebuild your kernel to disable that
(allow_dscr_remap=1 in /etc/conf/pack.d/kernel/space.c) (note that this
has been fixed properly in 507).

Oh, and all of this can only work if the device nodes in the Xenix root
filesystem have the same major/minor numbers as in Unix.  I _think_ this
might actually be true for the few device nodes needed to get to
single-user mode.

Well, anyway...  What you really want to do is boot a Unix kernel with a
Unix root filesystem, and mount the Xenix stuff.  The last remaining
trick is to use "hd=Sdsk" to override the kernel's tropism towards
ST506/IDE.  So you're going to boot the boot floppy and enter
"fd(64)unix hd=Sdsk".

Oh, one further trick.  You'll need device nodes to access the Xenix
drive.  `mkdev hd` is a bad idea because (1) it doesn't believe in
systems with SCSI root and ST506/IDE secondary drives, and (2) it's a
real pain to undo what it does, and this is a temporary condition you're
setting up.

All you really need is some nodes.  For that, you need to know the major
number of the "wd" driver:

  # grep wd /etc/conf/cf.d/mdevice
  wd      IRocrwi BiRbcCHhdg              wd      53      53      1       2       -1
                                                  ^^
  # MAJ=`awk '$1 == "wd" { print $5 }' /etc/conf/cf.d/mdevice`
  # echo $MAJ
  53

Let's make whole-disk and active-partition nodes, using "hdX" as the
base name (like "hd0", "X" for "Xenix"):

  # mknod /dev/rhdX0    c 53 0
  # mknod /dev/hdX0     b 53 0
  # mknod /dev/rhdXa    c 53 47
  # mknod /dev/hdXa     b 53 47

Now run `divvy /dev/hdXa`.  If you're lucky, a division table shows up,
with start/end blocks but no names.  Give them names (if you keep "hdX"
in each name then cleanup will be easier).  0 is almost certainly root,
1 swap, so name those "hdXroot" and "hdXswap".  If 2 is in use, it's
probably "hdXu".

Up to here you have not attempted to write anything to this disk.  It's
probably a good idea to keep it that way.  So, always mount read-only:

  # mount -r /dev/hdXroot /mnt

Even better, once you've got divisions and divvy shows sensible looking
filesystem types (which means the disk parameters are right),
immediately copy the data.  Then you can set the physical drive aside
for safe keeping until you know that you can properly access the data.

To do this, name each division that has start/end blocks.  Then `dd`
them elsewhere:

  # dd if=/dev/hdXroot of=/recovery/hdXroot bs=64k   # bs for speed
  # dd if=/dev/hdXu of=/recovery/hdXu bs=64k

If you get no I/O errors, that's a miracle; and if you do, a bummer.
Supposing you get the data, then:

  # marry -a /recovery/hdXu
  # mount -r /dev/marry/recovery/hdXu /mnt

Anyone still with me?

>Bela<
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.