Linux is currently incapable of serving as an install server for Solaris
2.6 or 7.
My environment consists of an x86-based Linux server, and a SPARCstation 2
system which I am trying to install Solaris 7 on. Assumptions
below: "sparcsys" is the name of the sparc server, "linuxsys" is the name
of the linux server. Both systems must be on the same subnet for this
Steps to configure the Linux server:
- Make sure that bootparamd, rarpd, tftp-server, nfs-utils, and xinetd are
- Add "sparcsys" (and "linuxsys", if it's missing(!) for some reason)
- Mount the Solaris 7 software media on /mnt/cdrom.
- Create /etc/bootparams as:
- Create /etc/ethers as "<mac address> <ip address>", where the mac and ip
addresses are for "sparcsys" (obtain the mac address from the boot
information when the system starts).
- Create /tftpboot, and place the appropriate boot image from the
installation media in that directory. See
http://www.cs.toronto.edu/~cvs/unix/Solaris-Linux-NetInstall.html for a
few easy ways to determine where to find the boot image you need, and what
to name it in the tftpboot directory.
- for i in xinetd nfs rarpd bootparamd; service $i start; done # ;-)
- Power up "sparcsys" and hit STOP-A (or issue a BREAK at the serial
terminal) to drop to a PROM prompt. If the prompt is ">", type "n" and
press return, which should then give you an "ok" prompt. Type "boot net",
and press return.
- You should observe network traffic as "sparcsys" asks "linuxsys" for
bootparam data, then tftps the boot image. While the download is
occurring, a counter will be displayed on the terminal.
- "linuxsys" will log the following (or something similar)
Mar 8 19:13:39 linuxsys rarpd: RARP request from 08:00:20:31:c0:0d
Mar 8 19:13:39 linuxsys rarpd: RARP response to 08:00:20:31:c0:0d
10.0.0.5 on eth0
Mar 9 01:13:39 linuxsys tftpd: sending 0A000005.SUN4C
Mar 8 19:13:44 linuxsys rarpd: RARP request from 08:00:20:31:c0:0d
Mar 8 19:13:44 linuxsys rarpd: RARP response to 08:00:20:31:c0:0d
10.0.0.5 on eth0
- When the boot image is loaded, the server will display:
root server: linuxsys
root directory: /mnt/cdrom/Solaris_2.7/Tools/Boot
- "linuxsys" will log the following in /var/log/messages:
Mar 8 19:13:45 linuxsys rpc.mountd: authenticated mount request from
sparcsys:877 for /mnt/cdrom/Solaris_2.7/Tools/Boot (/mnt/cdrom)
- "sparcsys" will begin to display a "spinner" which would normally
indicate the loading of the second stage kernel from the root directory.
This will hang, and the following will be displayed:
RPC: timed out
NFS read timed out. Retrying...
- Left alone, "sparcsys" will continue repeating the above message.
I've found a few references to this issue on various forums. Here's a few
I'm willing to serve as a guinea pig to help get this working.
Just some quote followup points: this is stock wolverine, with the updated
0.1.14 kernel (since the original wolverine version hung on the WP check). The
relevant RPM versions:
If this is the same on 9, I'll poke someone.
This still doesn't work on 9, but it is not an NFS bug (in fact it's a solaris
bug). The problem is that when linux fragments packets it sends the last
fragment first but the solaris install minikernel doesn't deal with out-of-order
fragments, it just ignores them. It appears that AS2.1 sends the fragments
first-last instead of sending them backwards, as 2.1 does work fine as an
install server for solaris.
Since our stack gains enjoys a major performace gain
from type ordering we use, plus accepting out of oder
fragments is (I believe) mandatory, I see no reason to
change our working code for a broken stack...