Bug 31135 - Solaris 2.6/7 net install fails, NFS incompatibility?
Solaris 2.6/7 net install fails, NFS incompatibility?
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-08 21:07 EST by Ed Marshall
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Ed Marshall 2001-03-08 21:07:48 EST
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.
Comment 1 Ed Marshall 2001-03-08 21:20:14 EST
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
Comment 2 Pete Zaitcev 2003-06-03 23:45:40 EDT
If this is the same on 9, I'll poke someone.
Comment 3 Jason Kohles 2003-08-08 10:08:51 EDT
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 15:35:20 EDT
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.