Notes from bringing up the Sun 2/120 (sn 3108):

Netbooting:

ROM Rev. M does not ndbootd with NetBSD 5.1.2 properly, it appears to use an incorrect IP address.  Rev. R does work correctly.

Rev. M does not recognize the Intel Ethernet controller, only the 3COM; rev R supports both, as well as providing niceties like displaying the MAC address in the startup banner (and configuring the ethernet interface to use it...)

Managed to boot NetBSD 3.1 over the network (NetBSD 5.1 had trouble and wouldn't get anywhere), rarp/bootparamd was a bit spotty and only started working after I rebooted the server PC; unsure if this is a network issue or not.  Steps (copied from netbsd's site are):


You need: an ND (network disk) server, rarp, bootparamd, and nfs:

ND:
---

Recent NetBSD releases include ndbootd. For ancient releases you will need to download, build, and install the latest version under http://mit.edu/fredette/www/ndbootd/.

If you have built your own kernel, make sure you have the following in your config file:

pseudo-device   bpfilter        16

The GENERIC kernel distributed with NetBSD has this compiled in.

    Create an /etc/ethers file, listing your client:

    #/etc/ethers
    CC:CC:CC:CC:CC:CC     client

    Add your client to the /etc/hosts file:
    192.168.1.10 client

    # /usr/sbin/ndbootd -d -s /tftpboot /tftpboot/bootyy 

This will start ndbootd in debugging mode in the foreground (i.e. you can ^C out of it). When the server gets a request, it will print many debugging messages. 

RARP:
-----

If you have built your own kernel, make sure you have the following in your config file:

pseudo-device   bpfilter        16

The GENERIC kernel distributed with NetBSD has this compiled in.

    Create an /etc/ethers file, listing your client:

    #/etc/ethers
    CC:CC:CC:CC:CC:CC     client

    Add your client to the /etc/hosts file:
    192.168.1.10 client

    # ps -aux | grep rarp
    If it's not already running, then run:
    # /usr/sbin/rarpd -a -d 

This will start rarpd in debugging mode. When the rarpd server gets a request, it will print this:

got a packet

If RARP fails, the client will print:

No response for RARP request
le(0,0,0,0): Unknown error: code 60
boot: Unknown error: code 60

If RARP succeeds, the client will print:

boot: client IP address: 192.168.1.10


BOOTPARAMS:
-----------


    Create the /etc/bootparams file:

    # cat /etc/bootparams
    client root=nfsserver:/export/client/root
        

    Start the bootparamd daemon:

    # /usr/sbin/rpc.bootparamd -d
        

This runs the bootparamd server in debugging mode. When the bootparamd server gets a request, it will print the following messages:

rpc.bootparamd: whoami got question for 192.168.1.10
rpc.bootparamd: This is host client.test.net
rpc.bootparamd: Returning client       127.0.0.1
rpc.bootparamd: getfile got question for "client" and file "root"
rpc.bootparamd: returning server:nfsserver path:/export/client/root address: 192.168.1.5

If the requests fail, the client will print:

bootparamd: `whoami' call failed
le(0,0,0,0): Unknown error: code 60
boot: Unknown error: code 60

If the bootparams requests succeed, the client will print:

boot: client name: client.test.net
root addr=192.168.1.5 path=/export/client/root

(note also, from netbsd notes for the 3com ethernet card:
NFS has an all-or-nothing mentality about it, so the client will throw away any packets it did get and just send the request again, making for a vicious cycle. The solution is to tell NFS to only request 1 kilobyte at a time, which is done by adding an option to the client's mount command:

# mount -t nfs -o -r=1024 server:directory mountpoint
)

NFS:
---

pretty standard.  I used the "ramdisk" kernel image (uncompressed) and everything was good.  At this point, I made an image of the Micropolis MFM drive over NFS ("ifconfig ec0 192.168.1.20 netmask 255.255.255.0" to configure the ethernet, "mount -t nfs host_server_here:/path/to/export /mnt" and then a DD...)


Actual installation of SunOS via netboot seems to be impossible with a modern UNIX server; the ND protocol provided by NetBSD (the only game in town) only supports enough to bootstrap a NetBSD install and is insufficient to get SunOS installed.

INSTALLATION OF SUNOS 2.0:
-------------------------

This was done by hooking the Sun2's drive up (via the bridgeboard of course) to a system running SunOS 4.1.4 (others will probably work).  SunOS 4's "format" utility will happily format, partition, exercise, etc. the drive.

A couple of minor notes (from Bear) to get a filesystem that Sun2 is happy with:

> # newfs -i 4096 /dev/r(device)
> # fsck -c /dev/r(device)

> the fsck -c is the important part. the -i 4096 is to get the i/g down to 2048 or less, so fsck -c can convert to the static-table (old) format - depending on the size of the partition the default may be ok, or you may need to specify a larger or smaller value for newfs -i to get the i/g in the right place. 

> then and only then will you have a disk that can successfully be mounted r/w under SunOS 2.


> FWIW the conditions under which fsck -c will fail to convert are, number of rotational positions != 8, inodes per > group > 2048, cylinders per group > 32, or cpc (?) > 16. any one of these conditions will not get you where you > need to be.

Even with this on the first boot it was necessary to run fsck to correct a mangled superblock (specify "32" as the alternate block location).

Once you have the new partitions (A and G), mount them somewhere (/sun2/root and /sun2/root/usr works fine).
Untar the ROOT filesystem (file 6) to /sun2/root
Untar the man pages, demos, games, etc (files 7, 8, and 9) to /sun2/root/usr.

From tape 2 you can untar File 2 to /sun2/root/usr.  The 42MB Miniscribe drive is juuust large enough to fit all of this.
(usr will be at 101%...)

you'll need to run "installboot" from /sun2/root/usr/mdec specifying the "bootsd" file to make the disk bootable.

rename /sun2/root/usr/etc/ypbind to something else or when you reboot it'll assume you have a YP server on the network and essentially
prevent you from logging in.  (You can reboot single user to correct this.)

run MAKEDEV in /sun2/root/etc to build devices in DEV (or things will be very broken when you boot)

Create an fstab in /etc a-la:

/dev/sd0a / 4.2 rw,noquota 0 1
/dev/sd0g /usr 4.2 rw,noquota 0 1
/dev/sd0h /home 4.2 rw,noquota 0 1



Bringing up a "new" MFM drive (Priam V170):
------------------------------------------

Drive was originally used as a PC and jumpered as disk 1.

At boot, SunOS 4.1.4 describes it as: 

sd2:    non-CCS device found at target 2 lun 0 on esp0
sd2 at esp0 target 2 lun 0
sd2: Vendor 'ADAPTEC*', product 'ACB4000*********', (unknown capacity)

And "format" would not detect the disk (appears to hang, actually...)

Drive may in fact be dead...  Oh, and it's dead because I plugged it in using the tape drive power.  WHICH IS 24V.


Using Generic SCSI disks:
------------------------

It appears (based again on Ray's research) that drives that have Unit Attention enabled (most of them) will
fail during boot:

root on sd0
using 25 buffers containing 51200 bytes of main memory
sd0: not online
panic: rootmount cannot mount root
syncing disks... done

Disabling Unit Attention appears to work; not all drives support this.  The SCSI2SD does...