September 25, 2017

Sun Ultra 10 systems

These use 64 bit ultrasparc-III processors running at 270, 333, 360, or 400 Mhz. Ultra 10 boards can have up to 1024M of ECC ram in 4 slots. These were sold from 1998 to 2002.

The Ultra 5 is the same motherboard (more or less) in a pizza box, while the Ultra 10 is in a midtower case.

These are the first Sun machines to support EIDE drives. The Ultra 10 can have two of these via a CMD640 controller. They also have a SCSI controller to allow the usual chain of SCSI peripherals.

Hard times in Toledo

The only reason to have anything to do with these, is out of an interest in computing history, what is called "retrocomputing". Anyone using one of these nearly 20 year old machines for anything of actual importance in say 2018 needs to rethink things.

These things are slow. Miserably slow by todays standards. I had occasion to run cksum on a 1.5G file on an IDE disk. It took 3.8 seconds on a modern (x86_64 with 3.5 Ghz clock speed) linux system. On the ultra it took 132 seconds. A factor of 35. This means that things that would run in 5 minutes on my linux system will take over 2 hours on the ultra. It is good to know what you are in for. Forewarned is forarmed. The wise man looks ahead, sees trouble, and avoids it.

Standard configurations support 4 to 20 G drives. Reports indicate that 40G and 80G drives work fine, though not officially supported. Allegedly drives up to 120G can be used. These are 40 pin cable EIDE drives from the "good old days".

SCSI booting

A great idea, but the install media is unwilling to detect and install on a SCSI drive, even setup as target 3.

This seems like an option, and if it works, the whole IDE drive business could be bypassed. SCSI target 3 is the default boot disk. Target 6 is the default for a CDROM. So, the thing to do is to try installing on a SCSI drive.

Some related OBP (open boot prom) commands: 
ok setenv boot-device device[n]
ok setenv boot-device disk
ok setenv boot-device net
ok printenv boot-device
ok probe-ide
ok probe-scsi
ok probe-scsi-all
ok boot -r
The "boot -r" does a reconfiguration boot, which should be done only with great care.

Ancient SSH

Apparently the old funky ssh server on these Solaris 8 systems uses a deprecated key exchange protocol, so you add this to your .ssh/config file: 
Host 128.196.13.17
KexAlgorithms +diffie-hellman-group1-sha1
Or you can place the option "-oKexAlgorithms=+diffie-hellman-group1-sha1" on every ssh line, but that gets old quickly. Then to access the machines via a proxy port behind a firewall you do: 
ssh root@wall -p 1776
scp -P 1776 root@wall:/dir/file .

Adding a disk

These systems have both IDE controllers and SCSI controllers. Apparently they boot from the IDE drive inside the case. It is possible to install two drives. The drive jumpers should be set for CS (Cable select) rather than the usual Master/Slave configuration.

Sun disks are handled by special files in /dev/dsk and /dev/rdsk with names like c0t1d3s2. Here we have controller, target, disk, and "slice". Slice and partition are synonyms. Partition 2 goes for the whole disk. There are 8 partitions (0-7) and only 2 is special.

The fdisk utility exists, apparently only for the sake of confusion. You actually want to use "format" to manipulate partitions. When I run fdisk on a disk with solaris partitions, it simply reports that the entire disk is a solaris partition, which is confusing and not quite true.

If you run "prtvtoc /dev/rdsk/c0t0d0s2" you will get lots of useful information, including the solaris partition layout. prtvtoc is short for "print volume table of contents".

To create a filesystem, do something like: 
newfs /dev/rdsk/c0t1d0s7
fsck /dev/rdsk/c0t1d0s7

Large IDE disks

These are problematic due to bugs and limitations in Solaris. The sorts of issues you may encounter depend on what version of Solaris you are running, and perhaps more importantly, the vintage of the "Open Boot Prom" (OBP) firmware in your machine.

I have found that the kernel installed by the Solaris 8 install CD does not support or detect a second IDE drive. A more up to date kernel installed from a backup does, probably by virtue of patches or updates that someone applied back when these things were in service. Keep those backups!

It is not clear (to me at least) whether you need to fool with entries in the /etc/format.dat file. I never have. Both SCSI and IDE disks come formatted from the manufacturer and handle their own bad blocks internally.

Some people say that have no problem with disks as large as 120G. I have had a variety of strange problems. One source claims that you will see a capacity of N mod 32G, and this matches my experience with an 80G drive, where the Solaris 8 install found and used about 12G and thought that was the entire disk (note that 80 mod 32 is 16G, so that doesn't exactly match, but is in the ballpark).

If you want to try editing the /etc/format.dat file and adding your disk, the controller can be either SCSI or ATA.

Ultimately this has been nothing but misery and wasted time. I can partition and format a large IDE disk as a second disk just fine to full capacity. But this disk will not boot solaris. It will load the kernel, but then get in trouble trying to read /etc/system or finding the "init" program.

What may work is to install from CD on a larger drive. In the case of my 80G Seagate drive, it ends up thinking the entire drive is only 14G. But I am willing to take anything 4G or bigger, so I call this a win. This drive will boot, but the default 1.8G root partition is too small and an absolute nuisance. I end up moving /opt and /var/sadm off of the root and making symbolic links to get it to work.

A second IDE disk

This will work only with a more up to data kernel than the one supplied on the install CD. Mind you, I am working only with Solaris 8. However, I installed from CD and then pulled my hair out trying various cable arrangements and jumper settings. It just doesn't work. However if I take an old disk running Solaris 8 with a variety of updates and patches (which are no longer available anywhere I know about), it works fine.

Some helpful tips

Use "df -k" to get sizes in kb and percent usage. Why this is not the default is anybodies guess.

Start bash immediately in either a commandtool or shelltool.

To run "vi" from a remote login do something like this first: 

export TERM=xterm
stty cols 100

Solaris

The machines I am working with announce they are running SunOS 5.8. This means they are running Solaris 8. This is circa the year 2000 (support ended in 2012).

Booting

The following is a nice description of how Solaris boots. Note that the bootprom loads a bootblock, which then loads the kernel. This bootblock can be installed using the installboot program via: 
installboot bootblock raw-device
  .... i.e. ...
installboot /usr/platform/SUNW,Ulta-5_10/lib/fs/ufs/bootblk /dev/rdsk/c0t2d0s0
Note that the target device is slice 0, as per the Oracle docs.

Note also that "arch -k" yields sun4u, while "uname -i" yields SUNW,Ultra-5_10

So, the boot process goes like so:

  1. The boot command reads and loads the bootblock into memory.
  2. The bootblock locates and loads the secondary boot program, ufsboot, into memory and passes control to it. NOTE: A network boot uses a different secondary boot program: inetboot instead of ufsboot.
  3. ufsboot locates and loads the core kernel images and the required kernel runtime linker (krtld) into memory and passes control to the loaded kernel.
  4. The core kernel locates and loads mandatory kernel modules from the root disk directory tree and executes the main startup code.
  5. The kernel startup code executes, creating and initializing kernel structures, resources, and software components.
  6. The system executes shell scripts from system directories, bringing the system up to the init state specified in the /etc/inittab file.