A.P. Lawrence

Best of the Newsgroups: mixing scsi and non-sscsi disk, booting scsi when ide present, mfm or esdi controller old xenix crash

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.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.

Control Spam and Viruses

Run your own mailserver

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<

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Unix and Linux Support

/Bofcusm/1805.html copyright 1997-2004 Bela Lubkin All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here