Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: eggers@cs.buffalo.edu (Bill Eggers) Newsgroups: comp.sys.sun Subject: Re: Booting from SCSI drive at address 1 vs. 0 Keywords: Hardware Message-ID: <5094@cs.Buffalo.EDU> Date: 25 Apr 89 10:50:47 GMT References: <1354@infopiz.uucp> Sender: usenet@rice.edu Organization: SUNY/Buffalo Chemistry Lines: 76 Approved: Sun-Spots@rice.edu Original-Date: 8 Apr 89 00:52:52 GMT X-Sun-Spots-Digest: Volume 7, Issue 246, message 1 of 12 lupine!infopiz!mark@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