Bug 31135 - Solaris 2.6/7 net install fails, NFS incompatibility?
Summary: Solaris 2.6/7 net install fails, NFS incompatibility?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-09 02:07 UTC by Ed Marshall
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-15 20:58:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ed Marshall 2001-03-09 02:07:48 UTC
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) 
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 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 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 


I'm willing to serve as a guinea pig to help get this working.

Comment 1 Ed Marshall 2001-03-09 02:20:14 UTC
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:


Comment 2 Pete Zaitcev 2003-06-04 03:45:40 UTC
If this is the same on 9, I'll poke someone.

Comment 3 Jason Kohles 2003-08-08 14:08:51 UTC
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.

Comment 4 Steve Dickson 2003-08-11 19:35:20 UTC
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...

Note You need to log in before you can comment on or make changes to this bug.