mark@uunet.uu.net (Mark Pizzolato 415-369-9366) (04/07/89)
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? This is what we have tried: 1) I build a kernel who's root and swap are on sd2a and sd2b respectively, where 'sd2' is defined in the config file as: disk sd2 at si0 drive 8 flags 0 2) I made a file system on sd2a and put a root file system there that boots (the original kernel) fine if the SCSI address of the drive is 0. I put the new (sd2) kernel on this root file system named vmunix. 3) I set up the drive as SCSI address 1 (with or with out SCSI address 0 being around) and properly terminate the SCSI bus and attempt a boot with the following command: >b sd(0,8,0) 4) This seems to be the correct way to address a drive at SCSI address 1 on a Sun 3/60, since I get the following responses: >b sd(0,8,0) Boot: sd(0,8,0) Load: sd(0,8,0)boot Boot: sd(0,8,0)vmunix But then NADA! Note: The same drive WILL boot fine at SCSI address 1 on a Sun 3/50 with the following boot sequence: >b sd(0,4,0) Boot: sd(0,4,0) Load: sd(0,4,0)boot Boot: sd(0,4,0)vmunix Sizes: nnnn, etc. . . . . Both my customer and myself would appreciate any hints at solving this dilemma. Thanks in advance. Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca. (415)369-9366 UUCP: mark@infopiz.UUCP or ...uunet!lupine!infopiz!mark
eggers@cs.buffalo.edu (Bill Eggers) (04/25/89)
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
mcneil@lll-crg.llnl.gov (Mike McNeill) (04/25/89)
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? I had the exact same situation earlier on a standalone 3/60 with 2 SCSI disks (addrs 0 and 1). The formula I got for determing unit in b(cntlr, unit, part) for embedded SCSI disks is unit = SCSI_address << 2. I leave it to someone else to explain _why_ this is so...............Mike
joerg@uunet.uu.net (Joerg Schilling) (04/27/89)
> 1) I build a kernel who's root and swap are on sd2a and sd2b > respectively, where 'sd2' is defined in the config file as: > disk sd2 at si0 drive 8 flags 0 Try: config vmunix root on sd2 We are using this on several machines that format disks for our customers and it works. J. Schilling H. Berthold AG Teltowkanalstr. 1-4 D 1000 Berlin 46 +49 30 7795 - 400 ... tub!berthold!joerg ... unido!berthold!joerg