Thanks all for your input.  I am going the x86_64 route.  However, is anyone familiar with any differences (if any) between the x86_64 and i386 build with regards to kickstart?

I keep my ks.cfg files on the network and do an nfs install.  Here is a command that I use to assign net info and locate hte ks.cfg file:

linux ks=nfs:xxx.xxx.xxx.xxx:/var/ftp/pub/kickstart/ks.cfg ksdevice=eth0 ip=xxx.xxx.xxx.xxx netmask=255.255.255.0 gateway=xxx.xxx.xxx.xxx

With the i386 build of RHEL, this works without any issues, even on the new Opteron boxes.  However, when I boot off of disk1 of the x86_64 build and type the same command, it seems as though it is unable to locate the ks.cfg file.  I know it is binding the ip, because I can ping it.  I know thee NFS location of the ISO's is correct, but I do not think that kickstart is even getting the far.  I have tried this on both Update2 and 4

If I boot off of the i386 disk with my nfs tree pointing to the x86_64 iso's, it finds the tree, but gives an error about my boot media not matching my dir tree, which makes sense.

This leads me to believe that is something wrong with anaconda on x86_64.

Thanks
JD


--- Mark Hahn <hahn@physics.mcmaster.ca> wrote:

From: Mark Hahn <hahn@physics.mcmaster.ca>
Date: Mon, 18 Apr 2005 15:37:51 -0400 (EDT)
To: Bill Broadley <bill@cse.ucdavis.edu>
Cc: Jason DePaul <jdepaul@techemail.com>, <amd64-list@redhat.com>
Subject: Re: Opteron 252 install

> > I have received several HP DL385 / Opteron 252 servers and getting
> > ready to install Redhat ES 3.  My question is do I need to install
> > the x86_64 version of rhel to truely take advantage of the hardware,
> 
> Yes.

for some definition of "truely" ;)
seriously, it's no crime to treat opterons as "better xeons".
numa-awareness is a good thing, 64b is a good thing and all 
the extra registers are a good thing.  but you really need to 
look at your applications to tell whether they're good enough.
on the other hand, there's little downside to going 64b, even 
if you don't have >4GB ram, recompiled apps, etc.  

you might notice larger code sizes.  you might notice problems
resulting from sizeof(void*) and sizeof(long) == 8.

on my opteron cluster, I've had no complaints, either from people 
recompiling into native mode, or those running 32b executables.
(incidentally, running 32-on-64 actually does open up the memory 
map somewhat - there's a lot more VM with the kernel not slicing 
off the top 1G.)

regards, mark hahn.