Booting from SCSI drive at address 1 vs. 0

[Bill Eggers]

lupine!infopiz!mark at uunet.uu.net (Mark Pizzolato 415-369-9366) writes:
>We've got lots of Sun 3/60s and LOTS more SCSI disk drives.  From time to
>time it has been desirable to boot Sun OS 3.x from a SCSI disk whose SCSI
>address is other than 0.  We have been totally unsuccessful with regard to
>achieving this result.  Any ideas?

Back about a year ago, while we were waiting for a 3/60 to be delivered to
the Chemistry Dept., our local Sun sales rep let us borrow a 3/260 which
had 2 xy disks.  Disk xy0 had 3.X loaded onto it.  Since our sales rep
said we could do anything we wanted to the disk, I decided to try and
install 4.0 on xy1.  I don't know how relevant this will be to 3.X, plus
I'm doing this from memory, so I may have forgotten something, but I think
this can be of some help, and I remember other questions on the net about
this same topic.  In my discussion, I'll talk about the changes I made,
and you can figure out The appropriate changes for SCSI disks.

The first thing which was necessary was to do everything onto xy1.  The
xy0 disk never was involved in the setup process.  This involved doing the
standalone copy to a different controller and/or disk number, say from
st(0,0,2) to xy(0,1,1) instead of xy(0,0,1).  Of course, you also have to
change the swap and root device specifications on the disk when it asks
you these things.  Even if I ran the miniroot from xy0, and put the
bootblocks on xy1, it wouldn't boot, I seem to remember some wierd
checksum error after I set up everything and tried 

b xy(0,1,0).

Then, when I ran 4.0 suninstall, I had to be sure that it wouldn't clobber
xy0.  Suninstall tries to be smart, but in my case, it did certain things
which I didn't want.  I forget what the exact details were, but you may
have to fool suninstall into just processing the xy1 disk.  This involves
some editing of the various files which suninstall uses, located in
/usr/etc/install/files.  It might be interesting when you have everything
set up, to kill suninstall before you run the actual installation and look
at the files created there.  The most important file to look at is called
"disklist".  This file tells suninstall which disks are known to the
system.  Just to be safe, you must change this file so that it only
contains the line

xy1

instead of the two lines

xy0
xy1

Also, when you partition out the disk,  suninstall may give you a hard
time about not putting things on xy0, and if it does, then put some junk
partitions into it.  Don't worry, if you change "disklist" properly, it
will never look at this info and xy0 will be untouched.  Then, go back
into suninstall, and without changing the setup, go run the installation.
If you go change things, especially the disk setup, suninstall may barf at
the file changes you made.  However, you're smarter than suninstall.
Other possible steps can be tried, but the important thing is to
understand how suninstall uses these files, and if you look at the
contents of /usr/etc/install/files, you'll get a feeling for what I have
described.

Finally, you will still have to reconfigure the kernel so that it knows
that the root is on xy1.  I think the line

config          vmunix          root on xy1

was sufficient, at least for me.

Well, this is how it is done with 4.0 and xy disks.  For 3.X, all this may
be useless, depending on how hard it is to work with setup.  I've never
set up 3.X machines, so I don't know what is involved here.  I even once
tried to mount 3.X partitions from xy0 when running 4.0.  When I did an
fsck, it started changing sizes of directory files, and I got a bit
nervous so I stopped it.  It probably wouldn't have done much harm, and I
didn't really care.  (Imagine problems with duplicate inodes, etc?)

Enjoy!

			Bill