srp@babar.mmwb.ucsf.edu (Scott R. Presnell%Cohen) (06/19/91)
I did updates on our systems last night (to 3.3.2). I used distcp to copy the tapes to a empty partition on host A, and did the updates using bootp() as described in the release notes for hosts B, C, and D. However, when It came to updating host A (where the files resided), I couldn't figure out how to "boot" and get the miniroot. For the "tapedevice" I tried things like dksc(0,1,6)/.../.../sa (I'm fairly sure this is the correct description: ctrl=0, drive=1, partition=6) but the prom came back with something about "couldn't determine fs type" When I tried using the tape device I had further trouble with the timeouts after the initial boot (booted, but couldn't find the mr). I ended up copying "sa" and "mr" back to host B and using boop() B:/.../.../sa, etc. So, how *would* one specifiy the so-called "tapedevice" for a local boot file? Was I close? Thanks. - Scott -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet
olson@anchor.esd.sgi.com (Dave Olson) (06/21/91)
In <srp.677343748@babar.mmwb.ucsf.edu> srp@babar.mmwb.ucsf.edu (Scott R. Presnell%Cohen) writes: | I did updates on our systems last night (to 3.3.2). I used distcp to copy | the tapes to a empty partition on host A, and did the updates using bootp() | as described in the release notes for hosts B, C, and D. | | However, when It came to updating host A (where the files resided), I | couldn't figure out how to "boot" and get the miniroot. | | For the "tapedevice" I tried things like dksc(0,1,6)/.../.../sa (I'm fairly | sure this is the correct description: ctrl=0, drive=1, partition=6) but the | prom came back with something about "couldn't determine fs type" | | When I tried using the tape device I had further trouble with the timeouts | after the initial boot (booted, but couldn't find the mr). I ended up | copying "sa" and "mr" back to host B and using boop() B:/.../.../sa, etc. | | So, how *would* one specifiy the so-called "tapedevice" for a local boot | file? Was I close? Unfortunately, the prom can only read the volume header filesystem, and not the EFS filesystem. This means that you can't load the sash from the sa file, but you shouldn't need to, you can just type 'sash' at the PROM monitor prompt to get your current sash (some older systems, like the 4D70, may require that you type 'dksc(0,1,8)sash'). Unfortunately, when reading from an EFS file, sash won't check the file to see if it is really a tape images, so you can't copy sa(mr). In IRIX 4.0, mkboottape has a new -x option to allow you to extract files from the tape image (mkboottape -f sa -x mr). Until then, about the only way you can get the mr image is to start an install on a system, then quit as soon as the install comes up, boot up single user, and copy the first miniroot image from your swap partition to a file with dd. You can figure out how much to copy by running mkboottape -l -f /some/path/name/sa You want to do the dd from single user mode (without going to multiuser first) to make sure you don't cause some swapping on top of the miniroot image. Once the mr (miniroot image) file has been extracted, then you can do the following at the sash prompt (assuming you have as scsi disk, with the mr file at /usr/some/path/mr): cp -b 16k dksc(0,1,6)/some/path/mr dksc(0,1,1) then when that completes, type dksc(0,1,1)unix.IP6 where IP6 is used for 4D20, 4d25, IP12 for 4D35, etc.; the appropriate one is displayed in the sash banner message when it starts, except that unix.IP5 is used for IP5, 7, and 9. Obviously if you have a 4D380 with ipi disks, or some other disk type, the disk name get adjusted appropriately. Also note that the standalone tools can't deal with logical volumes, so don't put the mr file on a filesystem that is a logical volume!