Using remote tape drive

[Stuart Levy]

In article <28466D6D.7693 at orion.oac.uci.edu> fredv at 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 at geom.umn.edu