Installing Debian on a Netra T1

I wrote these notes because when I went to attempt this procedure, I wasn't able to find any references on the web to its feasibility. There are no particular problems doing the install, so if you're familiar with Debian installs on Sun hardware, you probably won't need the help.

This page is written for the Netra T105 in particularly. The Netra T1 series is an ultrasparcII-based (sun4u) 1U rackmountable machine, with two hotplug SCSI bays, two 10/100 ethernet ports, two serial ports (about which more shortly) and one free PCI slot. The Netra T1 is substantially different from the Netra X1, which is built mainly with commodity PC hardware (SDRAM, IDE bus, etc.). The T1 is the "carrier grade" model, with lots of redundant fans, check-engine lights, etc. "Carrier grade" was the fashionable thing at the time, as I recall. Both the X1 and T1 appear fairly often on craigslist, ebay and such places.

Some Netra units have a CDROM drive; this install doesn't call for it. The Netras don't have floppy drives, and once you're accustomed to doing network installs (something very easy and powerful on every architecture other than x86), that's much easier in any case.

Getting a Console

If you're accustomed to doing network installs, this is the only complicated part of the job. It isn't even that, if you have an adapter for the Netra's serial port. That serial port is an RJ45 jack used for Sun's "Lights out Management" features. You'll need an RJ45 to RS232 (DB9/DB25) adapter, or else you'll need to make one.

The Netra serial console operates at 9600bps, 8N1, and supports hardware flow control. To access the firmware you'll need to use a term program capable of issuing a break -- minicom works fine for that.

Not having an adapter on hand, I spliced one together. Here's how:

Fabricating an RJ45-DB9 adapter

Note: this isn't a particularly good way to do it; for a machine you really intend to deploy somewhere where reliability counts, get something made of actual molded and hardwired components.

First, make up the serial end of the connector. Cut the female end off a DB9 serial cable, leaving however much cable you'd like to have. Strip back the outer insulator to expose several centimeters of wiring. Cut off whatever tension relief cord or shielding is in there. Strip back a cm of insulation from each wire (you'll be using seven of the nine).

Using a continuity tester or a multimeter, match up each wire with its RS232/DB9 pinout. At this point it's probably a good idea to order them together in the order they'll be mated with the other side. The pairing is as follows:

DB9 PinRJ45 Pin
1 (DCD)no connect
2 (RX) 3 (TX)
3 (TX) 6 (RX)
4 (DTR)7 (DSR)
5 (GND)4 and 5 (GND)
6 (DSR)2 (DTR)
7 (RTS)8 (CTS)
8 (CTS)1 (RTS)
9 (RI) no connect

If you're looking at the mating face of a female DB9 plug, the #1 pin is on the upper left, and pins are numbered right-left, top-down. When looking at the mating face of an RJ45 plug, contacts down, the pins are numbered 1-8 from left to right.

If the wires in the serial cable are stiff and of a fine enough gauge, you can try crimping the RJ45 plug right onto the serial cable; this will spare you some work, but may not be as sturdy since a serial cable's outer insulator won't usually fit into the crimp fitting of an RJ45, so you the connector won't tolerate much pull force.

Assuming you can't crimp the end onto the serial cable itself, you'll need to join it to some wires you can crimp. The easy way is with a foot or so of Cat5 cable -- just order the wires straight from 1-8 and crimp it on (there's no need to cross over or mix twisted pairs; don't let any 10/100 wire-cross habits creep in).

Strip back the outer insulator and individual wire insulators from the other end of the cat5, then join against the RS232 wires by the chart above.

There's a superb reference to Sun serial cable pinouts here.

Booting the Debian Installer

To netboot the installer, you'll need another machine on the Netra's ethernet capable of doing RARP and TFTP. You can do RARP with rarpd, and serve TFTP with tftpd or atftpd, conveniently available from the Debian archive.

When booting the Netra, keep in mind that it takes longer for the PROM to start up than one might normally expect -- around 10-15sec, so don't start yanking the serial cable in frustration. A simple way to identify whether your cable is workable is to connect the Netra to power, but not to power it up -- then try to talk to the LOM over the serial port.

To configure rarpd, you'll need to know the Netra's ethernet MAC address; this can be gotten from the Sun PROM (it will mention its own MAC once the PROM gets control), or by letting the thing try to netboot and watching with tcpdump or following /var/log/daemon.log, looking for messages like these:

May 21 23:43:13 kesha rarpd[6595]: RARP request from 08:00:20:c2:27:01 on if-1073743596
May 21 23:43:13 kesha rarpd[6595]: not found in /etc/ethers

Having obtained the MAC address, add an entry to /etc/ethers to assign it the IP address you'd like it to boot with:


Next, prepare the tftp server to serve up the boot image. Download the sun4u tftpboot.img (for Woody) or sparc64 boot.img (for Sarge) from your local Debian mirror, and put it in your tftp directory (look at the tftp entry in /etc/inetd.conf to see where that is). It should be named (or symlinked to) the capitalized hex representation of the IP address specified by rarpd -- here, it'd be C0A80304. If you don't feel like doing conversions, just let it boot and watch the log to see what filename it asks for, as here:

May 22 01:23:04 kesha in.tftpd[14066]: connect from
May 22 01:23:04 kesha tftpd[14067]: tftpd: trying to get file: C0A80304
May 22 01:23:04 kesha tftpd[14067]: tftpd: serving file from /var/local/tftp

Be sure that rarpd is actually running, inetd is running, and that the protocols aren't firewalled.

Boot the Netra, and jump to the PROM loader with a BREAK. Give it a boot net command. The unit will issue a RARP request to obtain its IP address, then try to download its boot image over TFTP. Watching the daemon.log on the RARP/TFTP machine, you should see something like:

May 22 01:23:04 kesha rarpd[14042]: RARP request from 08:00:20:c2:27:01 on if-1073743756
May 22 01:23:04 kesha rarpd[14042]: RARP response to 08:00:20:c2:27:01 on eth0
May 22 01:23:04 kesha in.tftpd[14066]: connect from
May 22 01:23:04 kesha tftpd[14067]: tftpd: trying to get file: C0A80304
May 22 01:23:04 kesha tftpd[14067]: tftpd: serving file from /var/local/tftp

Over in the serial console, you'll see:

Resetting ...
Netra t1 (UltraSPARC-IIi 360MHz), No Keyboard
OpenBoot 3.10.25 ME, 320 MB memory installed, Serial #12725494.
Ethernet address 8:0:20:c2:27:1, Host ID: 80c22c31.

Executing last command: boot net
Boot device: /pci@1f,0/pci@1,1/network@1,1  File and args:
Remapping the kernel... done.
Booting Linux...
PROMLIB: Sun IEEE Boot Prom 3.10.25 2000/01/17 21:26
(full dmesg output here)

Rest of the Install

Not much to be said about this part -- once you get this far, it's a normal Debian install. All hardware is supported. Because the install needs to be done over a serial console at 9600bps, it's a bit cumbersome. However, once you can get ssh installed, everything's pretty painless.


cpu             : TI UltraSparc IIi
fpu             : UltraSparc IIi integrated FPU
promlib         : Version 3 Revision 10
prom            : 3.10.25
type            : sun4u
ncpus probed    : 1
ncpus active    : 1
Cpu0Bogo        : 719.25
Cpu0ClkTck      : 0000000015757754
MMU Type        : Spitfire

How Come It's so Slow?

This deserves a brief note. The Netra isn't a computationally fast machine by current standards, but neither is it troublesomely slow. If you've got something that seems to be slower than it ought to be, check to see if it was compiled for SPARCv8/v9 or not:

% file /bin/ls
/bin/ls: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
% file /usr/bin/gpg
/usr/bin/gpg: setuid ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

If it was only compiled for SPARC32, then it was built for compatibility with an ancient version of the SPARC architecture that didn't have an integer divide instruction and instead emulated it with subtraction. This is particularly apparent when doing ssh logins or validating keys with gpg. Look for versions compiled for v9 (ultrasparc), or compile them yourself by adding -mcpu=v9 -mtune=v9 to gcc commandlines as needed. Most crypto libraries in Debian are available in v9-optimized versions by default.

Devin Carraway, <>