Hide Forgot
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 configuration. Steps to configure the Linux server: - Make sure that bootparamd, rarpd, tftp-server, nfs-utils, and xinetd are installed. - Add "sparcsys" (and "linuxsys", if it's missing(!) for some reason) to /etc/hosts. - Mount the Solaris 7 software media on /mnt/cdrom. - Create /etc/bootparams as: sparcname root=linuxsys:/mnt/cdrom/Solaris_2.7/Tools/Boot - 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) in /var/log/messages: Mar 8 19:13:39 linuxsys rarpd[31541]: RARP request from 08:00:20:31:c0:0d on eth0 Mar 8 19:13:39 linuxsys rarpd[31541]: RARP response to 08:00:20:31:c0:0d 10.0.0.5 on eth0 Mar 9 01:13:39 linuxsys tftpd[31551]: sending 0A000005.SUN4C Mar 8 19:13:44 linuxsys rarpd[31541]: RARP request from 08:00:20:31:c0:0d on eth0 Mar 8 19:13:44 linuxsys rarpd[31541]: 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: hostname: sparcsys domain: (none) 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 URLs: http://www.cs.toronto.edu/~cvs/unix/Solaris-Linux-NetInstall.html http://www.geocrawler.com/archives/3/71/1998/11/50/91545/ http://lists.sourceforge.net/pipermail/nfs/2000q4/002981.html http://lists.debian.org/debian-sparc-9903/msg00213.html 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: kernel-2.4.1-0.1.14 nfs-utils-0.2.1-10 rarpd-ss981107-8 bootparamd-0.17-6
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...