Add-on second system disk for Personal Iris...problems

[Dave Olson]

sinclair at aerospace.aero.org (William S. Sinclair) writes:

| another front-loading disk, which is on SCSI unit #3. We want to re-install
| software on unit #3. As far as I can tell, unit #3 is properly partioned
| into partitions 0,1, and 6, like a regular system drive should be. However,
| the method suggested by SGI for installing the software does NOT work.
| They suggested changing the ROOT and BOOTFILE environment parameters as 
| follows:

| setenv root /dev/dsk/dks0d3s0

This is pointless to do BEFORE the init, since the PI doesn't keep root
in non-volatile RAM.

| setenv bootfile dksc(0,3,8)sash
| According to them, I don't have to do anything to "path".

True, path is never kept in non-volatile ram, and is rebuild from bootfile.

| Then I'm supposed to do an INIT, and go back to the console mode.
| When I get the >>, I'm supposed to go to use the INST tool on the
| boot tape. When I try to do that, I get a message (after the INST is
| copied in) to the effect that the file system on disk #1 (not #3)
| has been corrupted, in other words, it tries to do an FSCK on unit
| #1, and somehow thinks something is wrong with the entire file
| system.

The problem here is that the miniroot kernel defaults to device one as
root.  You need to do 'setenv root dks0d3s0' AFTER you do the init.

(Actually, there isn't any reason to do the init at all.  The act of
doing the setenv will reset the nvram variables.  init just clears out
any changes you may have made to the environment for non-volatile ram,
etc.)

|            The person at SGI made some remark like "Maybe you have a 
| bad tape", which sounds like a wild guess. Unfortunately, we can't
| easily switch out unit #1 since it's inside the cabinet. For some
| reason the system keeps going back to unit #1 even after we change the
| environmetal parameters. I have heard some rumor about "a cable that needs
| to be changed" if we need to boot from some other disk drive, but so far
| it's just a rumor.

It is unlikely that you have a hardware problem of any sort here.  The most
likely cause was that 'root' wasn't over-ridden, due to the init that was
done.

| Incidentally, I have several tapes with INST on them, and they all do the
| exact same thing.

Unlikely that this has anything to do with the tape itself.

| Has anyone tried to do this same thing? If so, I would like to know
| how (or if) you got the system disk going. The front loader we have on
| unit #3 is a 760 MB (unf) unit from SGI, with CDC as the OEM.
| and then doing the regular installation from the boot tape.

We have done this numerous times in house, as have other customers.  It
should work fine.

Don't forget that after installing, or changing the ID of the 'root' drive,
you need to re-generate a kernel.  The default lboot process with the
default /usr/sysgen/system generates a kernel whose root, swap, etc
devices are based on the current /dev/root and /dev/swap devices.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.