# QEMU/SunOS 4.1.4
## Motivation

This chapter describes the installation of SunOS 4.1.4 (= Solaris 1.1.2) on an emulated QEMU 1.4.0 SPARC machine. SunOS 4.1.4 is the last purely BSD based Unix operating system by Sun Microsystems. It was superseded by Solaris 2.x (= SunOS 5.x), based on System V Release 4. Programs compiled for SunOS 4.x won't run without binary emulation on Solaris version 2.x. The Unix file utility under Solaris 2.4 will print reports like
for SunOS 4.1.4 binaries and
for Solaris 2.4 binaries. If you want to run ancient computer programs of the first kind you might want to try it natively on SunOS 4.1.4.

## Prerequisites

* SunOS 4.1.4 installation CD-ROM image
* SPARCstation 5 ROM Rev. 2.15 image
In the following the CD image file is named solaris1.1.2.iso and the ROM image file is named ss5.bin. For our installation we create a disk image of 2 GB in size:
For compatibility with QEMU versions prior to 1.1 leave out compat=1.1. If you need more space, replace 2G by a higher value, but keep in mind that the installation program won't provide a predefined disk geometry. You'll have to enter the CHS values yourself during the installation.

## Copying the Miniroot Image

We start the emulated machine with the following command. Here and in the following all commands on the host (the system QEMU runs on) will have the shell prompt "$", the ROM prompt will be "ok", the guest prompt (of the system running on the emulated machine) will be "#" and the QEMU monitor prompt will be "(qemu)".
We omit the -machine option, which means QEMU will emulate a SPARCstation 5 (based on the sun4m architecture) as default. The emulated machine provides no usable graphics, so we disable graphical output with -nographic, redirecting all output to the terminal from which we started QEMU. Later we will explain how to run X Windows programs on the guest by exporting the display to an X server running on the host. Since there will be no keyboard emulation either, all input will be taken from the terminal as well. You will see the following ROM message:
The -monitor option lets us control QEMU over a telnet connection, in our example over port 4444. For this execute
in another console. Alternatively we could omit the -monitor option and use the "Ctrl-a c" command to switch between console (in which QEMU runs) and the QEMU monitor prompt. In this case type "Ctrl-a h" to get help. Useful commands are
to pause the emulated machine and
to resume. You will always have full CPU load on the host system while the emulated machine is not paused. This command terminates QEMU immediately:
Our emulated machine has 32 MB of RAM, indicated by the -m option. That seems to be the minimal amount that won't make QEMU exit with the error:
The maximal amount for a SPARCstation 5 ist 256 MB. Choose 32 MB if you don't want to wait for the ROM memory test, which takes some time. We don't make use of the emulated CD-ROM device via the -cdrom option because it doesn't work. Instead, we declare the installation CD to be the second hard drive. The start sequence of the ROM finishes with a failed network boot:
It seems that QEMU version 1.4.0 is not capable of allowing us to boot over network.
We boot with
from the fourth partition on the second hard drive (our CD image), which carries the boot block for our architecture.
Make the following choices:
Notice that the booted system has its own idea about how to order the attached drives. The device we booted from (the second hard disk) is given the name sd1 and our target disk is named sd3. We chose to format the latter. We select the type "SUN2.1G":
The predefined disk formats are stored in /etc/format.dat on the miniroot file system. The path to our miniroot image on the CD-ROM is:
In format.dat we find for the disk geometry of our disk type:
and for the predefined partitionings:
Notice that ncyl*nhead*nsect=4154160 is the number of 512 byte blocks in the third partition, which comprises the whole usable space, while the size of the disk is (ncyl+acyl)*nhead*nsect=4157200 blocks, which is approximately 1.98 GB or 2.13e9 Bytes. If you want to install on a disk image without predefined geometry you'll have to enter the figures yourself.
To write the partitioning to the disk and print the partition table do:
The size of the swap partition b is 100 MB. In SunOS 4.x the size of the swap partition should be at least the size of the RAM because every program has reserved swap space that amounts to its memory size. Change the swap space to your needs and exit the format utility with:
Extraction of the minroot by the extract script fails because the source CD-ROM device /dev/rsr0 doesn't exist. In the file /extract we find the figures (in bytes) to locate the miniroot image:
and the command to copy it:
With this information we can extract the miniroot to the swap partition of our target disk:
Reboot the machine with:

## Installation

Back on the ROM prompt we boot the miniroot:
The -w flag is necessary to make the mounted file system writable as required by the SunInstall program.
The SunInstall program won't let us select a hard disk as installation source. Therefore we link the CD-ROM device /dev/sr0 to the hard disk associated with our CD-ROM image:
SunInstall will recreate device names using the script /dev/MAKEDEV. To exclude/dev/sr0 from the recreation we remove its entry in MAKEDEV:
We are now ready to fire up SunInstall:
The terminal type ansi seems to work well enough. If you encounter problems with the display of the SunInstall menus you can redraw the screen with "Ctrl-l". If you know the name of your time zone, you can enter it directly. With "?" we are led through a menu to select our time zone. After confirming the correct time setting we are led to the form assigning the host information:
In this example we set the host name to "sunguest" and 10.0.2.15 is the standard address assigned to the guest system by QEMU. The next form lets us assign the disk information:
Eventually we set the source device and make a choice for a software selection:
We are then informed about the software packages to be installed and arrive at the final screen from which we can start the installation:
The existence of data files indicated by "+" means the entered data is not lost, even if we reboot the machine. After SunInstall has finished its job we can reboot with
and should be able to boot our fresh system with:
At the login prompt we can enter root and get a shell prompt without password. The system can be stopped with
and the machine can be shut down with:

## Network
### Guest Configuration

If you want to address the host system by a host name, assign it to the IP address 10.0.2.2 in /etc/hosts (on the guest):
where ^D means Ctrl-d. A host name is necessary to use rlogin, rsh and rcp on the guest. For a connection to the outside we set the default route with
and make it permanent with:
Check the routes with:

### User Networking

With the default networking back end of QEMU we can utilize the -redir option to enable connections between host and guest over Telnet (port 23), rlogin to the guest (port 513), or the copying of files between host and guest with rcp (port 514). Telnet can also be used to connect from the guest to the outside world if the host is connected to the Internet. For rlogin and rcp we'll need root access on a Linux host system to define packet filter rules. Start the emulated machine with:
Use the info command of the QEMU monitor to print a table of the forwarded ports:
The ports on the host that are forwarded must be greater than 1023 (as long as you don't run qemu as root). To check on which ports QEMU is listening, do:
After the guest system is booted we are able to connect from the host to the guest:
and from the guest to the host:
or from the guest to the outside (india.colorado.edu reports the current Coordinated Universal Time):
We can even check with the ping command from the guest that the host is alive:
Rlogin and rcp use fixed ports. We define port redirection rules on the host to get a connection to the guest. For this to work, it may be necessary to disable your firewall (or see below for a more accurate setting) before you execute as root:
Print the rules with:
These rules can be removed with:
Under openSUSE 11.4, disabling the firewall would remove these rules. Therefore we would stop the firewall first and then define the rules. Alternatively we could keep the firewall up and remove only the following single rule:
with the command:
This rule can be restored with:
or by stopping the firewall and starting it again. Now we should be able to connect from the host to the guest with:
and to copy files as root on the host in both directions:
To use rcp as a regular user on the host, we would have to create a user with the same name on the guest.
For reasons unknown to the author a remote shell command like
fails with:
Rlogin, rsh and rcp from the guest to the host do not work in this setting. Port redirection with
(as root) works for Telnet, but when redirecting the ports 513 and 514 over SSH, connections can't be established from the host. The error messages are:
when trying to rlogin to the guest and
when trying to rcp to the guest.

### Using a TAP Device

In the previous section we have seen the shortcomings of QEMU's user networking. Using the tap networking back end allows for a unrestricted connection between host and guest. To create and configure a TUN/TAP interfaces on a Linux host we need root access:
We start qemu with the command:
From the host we use the address 10.0.2.15 to access the host and from the guest we use the address 10.0.2.2 to access the host. For rlogin & co. on the guest we need to refer to the host system with the host name defined in /etc/hosts. We should be able to ping and to connect over Telnet, rlogin, rsh, and rcp without problem if permitted by the host configuration. The root rlogin may be disabled completely on the host and for users we usually need to add the address 10.0.2.2 to ~/.rhosts. A firewall on the host must be configured (or disabled) to allow for such connections. We can also run X Window programs on the guest by displaying them on the host X server:
(on the host) will allow access from the guest and
starts the terminal emulator for the X Window System on the guest, displayed in an window on the host. We can give the guest access to the Internet by enabling IP forwarding on the host:
where wlan0 is the network device that connects the host to the Internet (often eth0 for a LAN connection). The firewall on the host might need to be disabled to make it work.

## Running OpenWindows

With the TAP/TUN network setup, set the following environment variables on the guest:
We export the display to a second X server running inside a window of our host X server:
Start the window manager on the guest:
You should now see the OpenWindows desktop in he Xephyr window. Click with the right mouse button for the application menu. Unfortunately, the help viewer refuses to start with: