sinclair@aerospace.aero.org (William S. Sinclair) (06/06/90)
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 setenv bootfile dksc(0,3,8)sash According to them, I don't have to do anything to "path". 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 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. Incidentally, I have several tapes with INST on them, and they all do the exact same thing. 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.
olson@anchor.esd.sgi.com (Dave Olson) (06/06/90)
sinclair@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.
shoshana@koko.UUCP (06/07/90)
> From: "William S. Sinclair" > another front-loading disk, which is on SCSI unit #3. We want to re-install > software on unit #3. If all you want to do is install the system software, you can boot the machine as usual, mkfs partitions 0 and 6 on unit #3, then mount them someplace. eg, mount dks0d3s0 on /installroot and dks0d3s6 on /installroot/usr. Then put the installation tape in the tape drive, and use the command inst -r /installroot The install program can be used while the machine is running - as long as you're not installing over the working operating system. I've done this several times with complete success -- however, the following caveats apply: 1. Used this way, the install program won't create a kernel for you. "lboot -u /installroot/unix" ought to do the trick. 2. You won't get anything in your volume header (this is partition 8, where sash lives - pretty crucial). You can use dvhtool to copy the programs from /stand into /dev/dsk/dks03vh. Of course this is all very sketchy, RTFM for details. As for booting off this disk, my superstitious belief is that the boot disk has to be scsi unit #1. But I've never tried to get around this, it might be possible. I'm also pretty sure that the boot disk has to be partitioned this way (using partitions 0,1,6 and of course 8). Anyone at SGI want to respond? -shoshana Shoshana Abrass Pacific Data Images pdi!shoshana@sgi.com === If I were more organized, I'd have a .sig ===