NetBSD on a diskless SGI Indigo2

Of course, this HOWTO applies with minor modifications to any other architecture supported by NetBSD.

Last modification: Tue Jan 16 09:13:05 CET 2007

This is about installing NetBSD on a diskless SGI Indigo2 machine, just like this one. A good document is also available if you want to determine the exact hardware before opening it, as the support in the few operating systems available on this platform may not be optimal yet.

Installation instructions

First a word about the installation instructions. They were helpful, but I definitely feel like they could be improved. Besides being slightly out of sync with the actual content of the FTP server, I read stuff like "your DHCP server must be configured to specify this file as the boot file for the client". I would really appreciate either one of these instead:

I will try to describe things the former way here.

Opening the box

Compared to another workstation box that's on the floor around me (namely a DEC 3000 300LX), the case was a piece of cake to open. It just involves a number of steps:

Booting

This step was entertaining. There is no apparent serial port, so I tried to directly plug in a keyboard and a screen.

Keyboard

I did not even have any idea where to plug in my keyboard and mouse. The keyboard and mouse icons are kind of close to some (1) and (2) symbols, and the 4 plugs looks very similar (like PS/2 or Type 5 connectors, or S/Video if you want).

So I just tried to plug my Type 5 Sun keyboard into the (1) keyboard port. It turns out the (1) and (2) ports are actually the serial ports, and the machine accepts a regular PS/2 keyboard and a mouse in the actual keyboard and mouse ports. My dreams of Kr4zy Mu1tiH34d 5k1llZ were gone.

Screen

By chance I got an original SGI screen along with the box. It even has both 13W3 (Sun/SGI) and VGA ports. I used it for a long time with my Sun Ultra 60 desktop, but had to buy a 13W3 to VGA convertor because it would not work otherwise. I thought the screen was defective.

So I plugged the SGI to the VGA port through the adaptor. Fired up the gorgeous purple station. After the most beautiful boot ring I've ever heard (a few clear guitar notes from the internal speaker) I got the screen to flicker, and go back to sleep mode (the screen, not me). Maybe the station was broken after all.

Just before trying again with a more recent LCD monitor that also accepted my Sun as input, I gave it a try on the 13W3 port. Needless to say, I never saw a firmware screen looking so nice.

Removing the disk

The first screen I actually obtained was actually an error message from the disk controller. No hard disk drive found it said. At this stage I had found the official owner's guide and it says a SCSI terminator must be present in order for the machine to work. Well, I did not have any, and the original SCSI hard disk was pretty noisy, so I just removed it.

Choosing an OS

As you may have noticed, I'm keen on NetBSD these days. But I also have a strong background with Debian, and looked at both support pages. I initially thought my station would not be supported, but the firmware system information page said "IP22" which works with both for sure.

Knowing this, knowing how NetBSD nicely crafts their installation kernels with a complete ramdisk, and knowing how much easier it is to bootstrap a NetBSD disk image from the installation sets (without executing any native code) I simply chose NetBSD.

Booting over the network

Now comes the interesting part. First, give an IP address to the SGI box through the firmware screen. I never tested the serial interface but the command-line should be the same:

setenv netaddr 1.2.3.4

I could not find a way to let the machine get an address from DHCP or RARP.

You can also later force the machine to automatically boot over the network at startup (FIXME TODO XXX include the directives here).

Then, upload a kernel into the hierarchy of a tftp server on the network. I used the netbsd-INSTALL32_IP2x.ecoff.gz file first, but the netbsd-INSTALL32_IP2x.gz is probably better if it works. In my case the tftp server is launched via inetd, through this line in /etc/inetd.conf:

tftp	dgram	udp	wait	root	/usr/libexec/tftpd	tftpd -l -s /tftpboot

The -l flag tells it to log all requests, and the -s flag tells it to chroot to the repository directory (which is /tftpboot here), just to be safer (no trivial directory traversals for one).

You can already give a shot, by entering the following in the firmware command-line:

boot -f bootp():/netbsd

where /netbsd is the path to your kernel on the TFTP server.

Just a kernel, no keyboard

At this stage the kernel was booting properly, and I could confirm the exact kind of hardware I had in my hands (or actually, lying on the floor with its guts opened). At the "root device" prompt I quickly typed in "sq0" (the name of the network interface), pressed the enter key... Nothing happened? It didn't even take my input. After a bit of research I figured this is a known problem, with proposed fixes. Don't worry if you can't cross-compile a fresh kernel at this stage, we'll run a full native system soon.

Finally, set up an entry in your DHCP server configuration to force the machine to boot entirely from the network. It should look like this:

host indy {					#"indy" is the name of my machine
  hardware ethernet 08:00:01:02:03:04;		#replace with actual ethernet address
  fixed-address actual.host.name;		#use the IP address otherwise
  filename "/indy/netbsd";			#TFTP path to the kernel
  option root-path "/home/indy";		#NFS share containing the filesystem
  next-server 192.168.2.5;			#NFS hostname or address
  boot-desired-source;
}

and typically completes your existing /etc/dhcpd.conf file. Don't forget to reload or restart the server if necessary.

Enabling the NFS share should be documented in your host system's documentation. Here is what I use on NetBSD:

/home/indy -maproot=root actual.host.name

in the /etc/exports file. This alone will not be enough to enable the NFS server. On Linux the syntax is different. Also keep in mind that NFS is not a secure protocol regarding authentication and confidentiality, because the data is being transmitted in the clear on the network. For example, password hashes will be revealed. If you can't trust your network and care for the workstation's integrity, don't do it.

Full filesystem

I just mentioned an NFS share, and that's necessary now, as NetBSD figures out from now on with the information from the DHCP server. You want to download at least the following sets from the FTP server: base.tgz, etc.tgz, and possibly man.tgz. To get a working compiler, get comp.tgz, and I would also recommend the remaining misc.tgz, text.tgz and even games.tgz (for wtf). The installation of X is up to you.

Now that you have downloaded the installation sets, place yourself at the root of your NFS share and uncompress them as root; for each set you want to execute:

# tar -xzvf set.tgz

and then a few adjustments are necessary:

# (cd dev && sh MAKEDEV all)

to create the device nodes, and:

# echo 1.2.3.4:/path/to/root	/	nfs	rw > etc/fstab

to remind the initialization process that the filesystem root is mounted from NFS already. You can also run:

# echo actual.host.name > etc/myname
# echo 1.2.3.4 actual.host.name actual >> etc/hosts
# echo nameserver 1.2.3.1 > etc/resolv.conf

to give your machine a name, an address, and DNS lookup information.

A few more steps are necessary, notably to force better passwords (which is kind of useless here), but they are documented as usual in their respective manual pages. I'll make an extra effort for SSH.

As I mentioned above, NFS will reveal the content of files to listeners on the network. This applies to your precious private SSH host keys, and any of the files you will place on this share. This alone allows man-in-the-middle attacks (as far as I know). Anyway, make sure your /etc/rc.conf file ends like this:

rc_configured=YES
sshd=YES

and the SSH server should start upon the next boot. Don't hesitate to temporarily allow remote root logins to create your initial user account:

PermitRootLogin yes

in etc/ssh/sshd_login and then I use the following commands:

# groupadd -g 1000 mygroup
# useradd -G wheel -d /home/myname -g mygroup -m -s /bin/sh -u 1000 myname

to actually create myself an user.

At this stage the machine should be up and running, you have an account, and if you want the keyboard to work you can download, patch, compile and try newer kernels. I don't think I'll do this myself, I have enough other crazy projects to complete first.

Installing packages

NetBSD usually provides binary packages for the ports, but to my surprise (or not) there are none. Your best bet now is to either compile everything yourself, or use pkgsrc.

I chose to use pkgsrc to compile a few packages. The compilation is really slow (and the tree huge), so I mounted the tree via NFS:

1.2.3.1:/usr/pkgsrc	/usr/pkgsrc	nfs	ro

in etc/fstab, told it to not write in it in etc/mk.conf:

DISTDIR=/home/netbsd/pkgsrc/distfiles
WRKOBJDIR=/home/netbsd/pkgsrc/work

and added the machine into my existing usr/pkgsrc/pkgchk.conf:

console = another machine then myname

#console
chat/irssi		console
mail/mutt		console
etc, adapt this to your needs, then install pkg_chk on myname:
# cd /usr/pkgsrc/pkgtools/pkg_chk
# make install clean
and (!) run this:
# pkg_src -aus

Hopefully a couple hours later you have your software.

Wow this was complex, but you have a shiny purple box with a quite cool and not too outdated architecture and operating system to play with now. Phew!

Closing

Forget what I said about how practical the box was. While it was a pleasure to unmount, putting the cover back was a pain. Maybe I just forgot to check that the expansion slots' side was not pulled up a bit or something though.

Have fun!