fredv@rigel.acs.uci.edu (Fred Velijanian) (05/31/91)
I am trying to use the tape drive on our server 4D/320 from a 4D/25 while upgrading the client from 3.2 to 3.3. Using the #2 option in the menu (Install system software), I specify the 4D/320's name (called master) and after a brief pause, I get the following messages: Copying installation program to disk Waiting for the tape to become available Unable to open source tape bootp()master:/dev/tape(mr) Unable to continue; press Enter to return to menu I have tried the same procedure from another 4D/25 and a different EOE1 3.3 tape with the exact results. While the above messages appear, I check the 320 and can verify that the "tftp" process has started by user "guest", and that the tape drive is being used, however after a couple of minutes "tftp" goes away and the tape rewinds. The /etc/inetd.conf file specifies "bootp -f" and "tftp" without the "-s" as documented (sort of). Using a tape with no installation tools produces an error which indicates that the original tape is at least being identified as a an installation tape somewhere along the line. I think I have followed up all the instructions in the manual and even the phone support seems to be out of ideas. Therefore I now turn to the net for any help!! Thanks Fred Velijanian UC Irvine fredv@vmsa.oac.uci.edu
slevy@warschawski.geom.umn.edu (Stuart Levy) (06/01/91)
In article <28466D6D.7693@orion.oac.uci.edu> fredv@rigel.acs.uci.edu (Fred Velijanian) writes: >I am trying to use the tape drive on our server 4D/320 from a 4D/25 >while upgrading the client from 3.2 to 3.3. Using the #2 option in >the menu (Install system software), I specify the 4D/320's name >(called master) and after a brief pause, I get the following messages: > >Copying installation program to disk >Waiting for the tape to become available >Unable to open source tape bootp()master:/dev/tape(mr) >Unable to continue; press Enter to return to menu > ... >Fred Velijanian I find apparently the same problem in upgrading our 3.3.1 systems to 3.3.2. Installing from a local tape drive worked fine; however we couldn't install over the net, symptoms matching yours. Also couldn't 'distcp' the installation-tools tape onto a disk. It would successfully copy a 16MB "sa" (standalone?) component; then when trying to load "mr" (miniroot) distcp died with "No space left on device" (presumably trying to read past the tape's end-of-data mark; the disk wasn't full). If distcp had succeeded I'd have copied the miniroot to the swap partition, but oh well. It's still possible, though awkward, to get the miniroot loaded onto the swap partition and boot the installation tools from that. Maybe this information will keep some people from having to buy extra tape drives :-). First, get the 16-megabyte "sa" component into a disk file. You can get sa using distcp, or by just dd'ing successive files off the installation a.k.a. EOE1 tape until you get one about the right size. The trick is to find the miniroot, which begins somewhere in the "sa" image. That's probably easy if you know its internal format. Barring that you can scan it for something that looks like a filesystem. From /usr/include/sys/fs/efs_fs.h and efs_sb.h, the magic number 0x00072959 or 0x0007295a should appear at offset 0x1c of the superblock (= block 1 of the filesystem, so that's offset 0x21c of the whole filesystem). So, you could write a program that scans for magic numbers in each block of "sa", and on finding one, writes from the preceding block through end-of-file to stdout. (I just found the location, turned it into a block count, and used dd if=sa bs=NNb skip=MM with MM and NN chosen so MM*NN=desired offset). With this in hand, put the iris you're upgrading in single-user mode ("init s") and load the miniroot onto the swap partition over the network: iris_to_upgrade# rsh other_iris miniroot_extracting_pgm >/dev/swap You might check that you've done this correctly by fsck'ing it: iris_to_upgrade# sync; fsck /dev/swap If so then halt it, go to the command monitor (*NOT* "Install system software") and boot: >> sash (start sash first) ... sash: boot -f dksc(0,1,1)unix.IP6 (boot the real unix) This boots into the installation tools, where you would have been if the first-stage network install weren't broken. Some of this may vary for you. The final ",1" in dksc(0,1,1) selects partition 1 == conventional swap area, so it probably won't change. But the "dksc(0,1" part depends on your disk controller & drive number. Try "nvram bootfile" from UNIX or "printenv bootfile" from the command monitor and copy what it says. Also, the "unix.IP6" presumably has to agree with your processor type. Try "hinv" (from UNIX or the command monitor) and adjust the .IPn accordingly. I really wish it were easier than this... Stuart Levy, Geometry Center, University of Minnesota slevy@geom.umn.edu
olson@anchor.esd.sgi.com (Dave Olson) (06/02/91)
In <28466D6D.7693@orion.oac.uci.edu> fredv@rigel.acs.uci.edu (Fred Velijanian) writes: | I am trying to use the tape drive on our server 4D/320 from a 4D/25 | while upgrading the client from 3.2 to 3.3. Using the #2 option in | the menu (Install system software), I specify the 4D/320's name | (called master) and after a brief pause, I get the following messages: | | Copying installation program to disk | Waiting for the tape to become available | Unable to open source tape bootp()master:/dev/tape(mr) | Unable to continue; press Enter to return to menu | | I have tried the same procedure from another 4D/25 and a | different EOE1 3.3 tape with the exact results. | While the above messages appear, I check the 320 and | can verify that the "tftp" process has started by user "guest", | and that the tape drive is being used, however after a couple | of minutes "tftp" goes away and the tape rewinds. | The /etc/inetd.conf file specifies "bootp -f" and "tftp" without | the "-s" as documented (sort of). Did you do 'killall -HUP inetd bootp tftpd' after making the change on the server (or rebooted it since then)? If not, the change didn't take effect. I usually recommend turning on debugging on the server when seeing these kinds of problems. Try adding -d to the bootp line, and -l to the tftpd line in inetd.conf, then do the killall and retry the install. Frequently, after this, looking at /usr/adm/SYSLOG on the server reveals the problem. -- Dave Olson Life would be so much easier if we could just look at the source code.
eddc@opus.lerc.nasa.gov (Dave Carek) (06/04/91)
In article <28466D6D.7693@orion.oac.uci.edu> fredv@rigel.acs.uci.edu (Fred Velijanian) writes: >I am trying to use the tape drive on our server 4D/320 from a 4D/25 >while upgrading the client from 3.2 to 3.3. Using the #2 option in >the menu (Install system software), I specify the 4D/320's name >(called master) and after a brief pause, I get the following messages: > >Copying installation program to disk >Waiting for the tape to become available >Unable to open source tape bootp()master:/dev/tape(mr) >Unable to continue; press Enter to return to menu > . . . > >Fred Velijanian >UC Irvine >fredv@vmsa.oac.uci.edu I ran into problems when upgrading to 3.3 a while back. I put some notes together for our administrators that may or may not help you out. Also note the following bug fixes in 3.3.2: -The timeout value for network installation was too short (5 seconds) for some sites. This has been increased to 30 seconds. Fixed in 4D1-3.3.1. -The distcp command in 4D1-3.3.1 was not able to copy data from tapes to file systems. Fixed in 4D1-3.3.2 distcp did work for me in 3.2 and 3.3.0, but not 3.3.1, so you shouldn't have a problem if your going from 3.2 to 3.3.2. ---------------------Notes from 8/9/90------------------------------------- Just a few tips for any of you out there who are using remote tape drives to install software. In order to do software install properly using a remote tapedrive you must check the /usr/etc/inetd.conf files on both machines to make sure that the services of tftp and bootp are available (no # sign in front of them). bootp requires tftp to transfer files. If tftp is started in the secure mode (-s pathname (this is the default in OS3.3)) you can either remove the "-s pathname" from the file or change it to "-s /dev/nrtape". This tells tftp to only allow access to that pathname. You must then remove the password from the guest account on the remote machine (machine with tape drive). After this you can shut down the system and go into the software install option. The install program will ask you if you are using a remote tape (type "y") and for the remote hostname (short name in your /etc/hosts file). You must select manual instalation because the default for the network timeout is too short (for 3.3 anyway). Type "set" at the manual prompt to see the current settings. Next, type "set timeout 60". This changes the network timeout to 60 seconds. You can then select your subsystems and continue with your install. If you get a network timeout error try changing the timeout variable to a larger value. Don't forget to put a password back on the guest account of the remote machine. If you are installing more than one machine I would recommend using the distcp command (If you have the space). This makes installs go very quickly since ethernet speeds are usually faster than tape transfer speeds. You can load all of your tapes into a distribution directory on one machine and then do the install from it. I created the directory /usr/dist and modified my /usr/etc/inetd.conf file to look like the following on my distribution machine. tftp dgram udp wait guest /usr/etc/tftpd tftpd -s /usr/dist To load the software onto the distribution machine do the following. For the first tape type: distcp -v /dev/nrtape /usr/dist For all subsequent tapes type: distcp -vn /dev/nrtape /usr/dist This copies the tapes into the /usr/dist directory. On the machine that you want to install the software on, shutdown the system and go into Software Installation. Type "n" in response to the question, Are you using a remote tape. Then type in the remote host and the distribution directory for the hostname(eg. remhost:/usr/dist where remhost is the hostname where the distribution files reside). You probably won't have to change the timeout variable (I didn't anyway). You can then continue on installing as normal. Oh yeah, you must also take the password off of the distribution host's guest account before you do this method. Don't forget to put it back when your done. It also may be wise to comment out the bootp and tftp lines in /usr/etc/inetd.conf on both machines when your finished. -- ----------------------------------------------------------------------- | David Carek | phone: 216-433-8396 | | NASA Lewis Research Center | | | Cleveland, Ohio 44135 | email: eddc@opus.lerc.nasa.gov | |---------------------------------------------------------------------| | Engineer -> An innovative imaginative scientist who must design the | | improbable using the impossible on a budget that is invisible | -----------------------------------------------------------------------