[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

OTS: Need Help: Solaris + Sparc + Network Install + Linux



	This is probably at least a bit off topic for this list, but I am
at my wit's end here and I need some help.

	I am trying to install Solaris 2.6 on a Sparc IPX over the network
from a Linux (Debian 2.1) machine. The IPX has 32MB of RAM and a 1/2GB
disk (2GB will be installed if I can get this to work), but not CD-ROM
drive. By reverse engineering Sun's add_install_client and
setup_install_server scripts on the Solaris Install CD (which are meant to
be used on a Solaris machine), and consulting the S/Linux Net Boot Howto,
I have succeded in getting the IPX to boot off the network and begin the
install process, but it soon dies after that.

	On my Linux server (P100, Debian 2.1, Linux 2.0.35), I have
enabled rarp in the kernel and preloaded the rarp and arp kernel caches. I
have also enabled TFTP in inetd.conf and pointed TFTP to /boot. In /boot I
placed the file Solaris_2.6/Tools/Boot/usr/platforms/lib/fs/nfs/inetboot
from the Solaris CD with the filename of {Hex MAC Address of IPX}.SUN4C. I
chose this file as that was the one that the add_install_client was using
as the boot image for TFTP in its setup.
	Next I configured the rpc.bootparamd server on the same Linux
machine with the below information, which is once again what the
add_install_client was adding in configuration as well. Talvath is the
name of the IPX, and 192.168.7.4 is the Linux server. Then I start
bootparamd.

talvath            rootopts=:rsize=32768 \
 		   domain=rkirkpat.net \
		   ns=192.168.7.15:none \
		   boottype=:in \
	           root=192.168.7.4:/cdrom/Solaris_2.6/Tools/Boot \
                   install=192.168.7.4:/cdrom/Solaris_2.6/Products

	Next, I exported the directory that the CD was mounted on, /cdrom,
to Talvath as rw,nosecure,no_root_squash.
	Now, I booted the IPX (via serial console, w/o keyboard, don't
have a monitor for it), sent it a break, and entered into a new command
mode and got the PROM prompt 'ok'. I then execute the command 'boot net',
and soon it is loading the boot image from /boot on the linux server
happily. Then the following is displayed on the IPX's serial console:

hostname: talvath
domainname: (none)
X
Requesting Ethernet address for 127.0.0.1 = 7F000001
No reply received.
root server: 192.168.7.4
root directory: /cdrom/Solaris_2.6/Tools/Boot
RPC: Timed out.
NFS read timed out. Retrying...

	That is as far as I ever manage to get. Looking in the
/var/log/daemon.log of the linux server I see a log of the TFTP
connection, an NFS attempt by the IPX, and that the directory
/cdrom/Solaris_2.6/Tools/Boot has been mounted by the IPX. A tcpdump of
the packets on the network at this time show the rarp request, TFTP
transfer, bootparam request, and some conversion about NFS. In the end,
the below packets keep being sent over and over again. It appears that the
linux server (farstar) is sending the data that the IPX is requesting, but
the IPX is never recieving them:

19:28:58.019931 talvath.rkirkpat.net.39 > farstar.rkirkpat.net.nfs: 116 read [|nfs]
19:28:58.019931 farstar.rkirkpat.net > talvath.rkirkpat.net: (frag 39924:900@7400)
19:28:58.019931 farstar.rkirkpat.net > talvath.rkirkpat.net: (frag 39924:1480@5920+)
19:28:58.019931 farstar.rkirkpat.net > talvath.rkirkpat.net: (frag 39924:1480@4440+)
19:28:58.019931 farstar.rkirkpat.net > talvath.rkirkpat.net: (frag 39924:1480@2960+)
19:28:58.019931 farstar.rkirkpat.net > talvath.rkirkpat.net: (frag 39924:1480@1480+)
19:28:58.019931 farstar.rkirkpat.net.nfs > talvath.rkirkpat.net.39: reply ok 1472 read [|nfs] (frag 39924:1480@0+)

	At this point, I though that maybe the block read size was not set
right between the IPX and the linux server. I adjusted the rsize option of
/etc/bootparams to 8192, and 512, but got the same result. I tried another
Linux server to provide the root directory (a Alpha running Linux 2.0.35,
Debian 2.1), but the same failure. I have tried copying the root directory
to a hard disk and exporting from that, but still no luck. I know the NFS
servers on both Linux servers are working fine, especially as the Alpha is
the NFS fileserver for my network, and I have never had a problem with it.
	I dug around the net trying to find anything of help, but I found
very little. The only lead I was able to find was a mention that Solaris
2.x nfs clients and Linux 2.x nfs servers do not work together very well,
and that there was a patch for the Solaris 2.x nfs client. That does not
do me a lot of help in this case, unless I can patch inetboot. 
	A bit of background on the IPX: I bought it used, but in good
condition as far as I could tell. It has Solaris 2.4 on it, but the root
password (or any username/password pair) is unknown. It boots Solaris 2.4
just fine, but of course I can't login.
	So, at this point I have tried about everything I can think of and
am still stuck at the same NFS read timeout. Does any one have any idea
what I am doing wrong here, or how to solve this problem? If you do, or
even any other idea to try, please send them my way! Thanks!

	PS. I plan to install Debian/Linux for Sparc on this machine
eventually as well, but I need it running Solaris first (as devel web
server for a production Sparc 20/Solaris web server).

	PPS. I have installed Solaris on Sparc 20s and Sparc 5s a handful
of time in the past, so I am familar with these machines and thier install
processes, only I always used a local CD-drive for those installs.

----------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                     |
|                                            --- Philippians 1:21 (KJV)    |
----------------------------------------------------------------------------
|  Ryan Kirkpatrick  |  Boulder, Colorado  | rkirkpat@nag.cs.colorado.edu  |
----------------------------------------------------------------------------
|               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
----------------------------------------------------------------------------


Reply to: