Hi all, I'm having a bit of trouble with something and was wondering if anyone else has encountered this or knows what the problem is. I have one computer I would like to kickstart a centos 5.0 or 5.1 install. I have another computer which is the tftpboot server and contains the centos 5.0 and centos 5.1 install directories I wish to do the kickstart over nfs and my network is using MTU of 4500. The machine will kickstart to the point of fetching the kickstart script from the server, but soon after stop responding. The machine is not locked but seems to be waiting on network traffic. Are there any known issues with kickstarting over nfs with jumbo frames? Thanks! Adam
Adam Miller wrote:> Are there any known issues with kickstarting over nfs with jumbo frames?Is the system your kickstarting configured with jumbo frames? Last I checked I didn't see an option to enable jumbo frames during kickstart. If not, are you able to force TCP for NFS? UDP doesn't have MTU discovery as far as I know, so traffic will likey fail. Any reason not to use HTTP for kickstart? Faster, simpler, runs over TCP.. On my networks I only run jumbo frames on dedicated interfaces and VLANs, not on the main network, causes too many compatibility problems otherwise. Curious why your using a MTU of 4500? Seems like an unusual number, common MTU for jumbo is 9000. nate
Hi, On Tue, 29 Jan 2008, Adam Miller wrote:> According to these docs an MTU can be specified in the kickstart script. It > doesn't say much more than that though. > > http://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-kickstart2-options.html > > The reason for nfs and an mtu of 4500 is complicated and not in my control. > This is being used in a beowulf cluster environment. > > The process I'm following is currently working for kickstarting Fedora Core 4 > installs, so I am hopeful it will work in centos. > > AdamGetting this thread back on track... The problem seems to be that when syslinux hands over control to the anaconda image, anaconda (specifically /sbin/loader) blows away the mtu... I'm guessing that it actually does set the mtu, then resets the interface (in our case, a broacom 5704 using tg3) and thus instantly forgets the mtu change. If in the syslinux kernel args I pass a static ip/netmask/mtu to the kernel, it works appropriately. Oddly, when starting the kickstart, after the ks.cfg file it will dhcp AND it seems remember the mtu setting. Thanks, Paul